본문으로 건너뛰기
피드

OCI에서 PostgreSQL HA 구성할 때, 페일오버 테스트는 통과하는데 프로덕션에서 깨지는 이유

devops 약 5분

OCI에서 PostgreSQL HA 클러스터의 VIP가 페일오버 시 자동으로 이동하지 않는 문제를 다룬다. AWS/Azure와 달리 OCI는 VIP가 VNIC에 명시적으로 바인딩되어 있어 OCI API 호출이 필요하며, 이를 해결하는 두 가지 프로덕션 검증된 방법(HAProxy vs OCI API 콜백)을 제시한다.

  • 1

    OCI에서는 VIP가 VNIC에 명시적 바인딩되어 자동 이동 안 됨

  • 2

    OS 레벨 ip addr add만으로는 부족 — OCI 컨트롤 플레인 API 호출 필수

  • 3

    해법 1: HAProxy + Patroni REST API 헬스체크로 VIP 우회

  • 4

    해법 2: Patroni 콜백에서 OCI CLI로 VIP 재할당

  • 5

    클러스터 상태가 정상으로 보여도 앱 연결까지 테스트해야 함

  • 시나리오: Patroni 클러스터가 새 프라이머리를 승격시킴. patronictl list는 정상. 그런데 앱은 여전히 죽은 옛 노드에 트래픽을 보내고 있음. OCI의 VIP(Virtual IP) 문제임

  • AWS에서는 secondary private IP가 서브넷 내 인스턴스 간에 자유롭게 이동함. Azure도 NIC IP 설정만 업데이트하면 됨. 근데 OCI는 다름. VIP(secondary private IP)가 특정 인스턴스의 VNIC에 명시적으로 바인딩되어 있어서, 자동으로 따라오지 않음

왜 이게 무서운가

  • 페일오버 일어나면 새 노드가 OS 레벨에서 ip addr add로 VIP를 올림. 같은 호스트에서 ping하면 됨. 하지만 OCI 네트워킹 패브릭은 여전히 옛 VNIC으로 패킷을 라우팅함. OS에서 IP가 올라와 있다는 건 OCI한테 아무 의미가 없음

  • 옛 노드가 완전히 죽었으면 앱에서 타임아웃이 뜸. 더 나쁜 경우: 옛 노드가 레플리카로 강등되어 살아 있으면, 앱이 정상 연결은 되지만 모든 쓰기에서 에러 발생. 클러스터 상태만 보면 전부 초록불인데 앱 관점에서는 장애임

⚠️주의

> 이 문제가 위험한 이유는 테스트에서 안 잡힌다는 것. patronictl list만 확인하면 정상으로 보이고, 앱 연결까지 확인하는 테스트를 하지 않으면 프로덕션에서야 발견됨.

해법 1: HAProxy + 헬스체크 (VIP를 아예 안 쓰기)

  • HAProxy를 앱과 PostgreSQL 사이에 놓고, Patroni REST API로 헬스체크:
    • GET /primary → 현재 프라이머리에서만 HTTP 200
    • GET /replica → 레플리카에서만 HTTP 200
  • 페일오버 시 HAProxy의 다음 헬스체크 사이클에서 자동 감지. VIP 이동도 OCI API 호출도 필요 없음
  • 읽기/쓰기 분리도 공짜로 얻을 수 있음 (프라이머리/레플리카용 리스너 분리)
  • 주의점: HAProxy 자체가 SPOF가 되므로 Keepalived나 OCI NLB로 이중화 필수. 헬스체크 inter 3s, fall 3 설정이면 약 9초 만에 장애 노드 제거

해법 2: Patroni 콜백 + OCI API (VIP 유지)

  • 앱 커넥션 스트링이 이미 VIP에 하드코딩되어 있거나, 네트워크 보안 모델상 프록시를 못 쓰는 경우
  • Patroni가 새 프라이머리 승격 시 콜백 스크립트를 실행해서:
    1. OCI 컨트롤 플레인: oci network vnic assign-private-ip --unassign-if-already-assigned로 VIP를 새 VNIC에 재할당
    2. OS 레벨: ip addr add로 인터페이스에 IP 추가 + gratuitous ARP 전송
  • 두 단계 모두 해야 함. 하나라도 빠지면 다시 무음 장애
  • 필수 사전 작업: 모든 노드에 OCI CLI 설치, 인스턴스 프린시펄 인증 설정 (동적 그룹 + IAM 정책), 각 노드 VNIC OCID 확보, arping 유틸리티 설치

교훈

  • OS 레벨 IP만으로는 부족함. OCI API 호출 없이 ip addr add만 하면, 같은 호스트에서는 되지만 다른 호스트에서 트래픽이 안 옴
  • OCI API 권한은 첫 페일오버 드릴 전에 반드시 수동 테스트할 것
  • 콜백 스크립트는 타임스탬프, 액션, 롤, VNIC ID, API 응답 전부 로깅할 것 — 새벽 2시에 고마울 것임
  • OCI API가 느리거나 일시 불가할 때를 대비해 지수 백오프 리트라이 로직 추가 권장

AWS/Azure 기반 HA 가이드를 OCI에 그대로 적용하면 조용히 깨지는 지점. 문제를 찾는 게 고치는 것보다 오래 걸린다는 게 핵심.

댓글

댓글

댓글을 불러오는 중...

devops

디지털 스택을 유럽으로 옮겨보니, 생각보다 꽤 실전적이었다

한 개발자가 분석, 메일, 비밀번호 관리, 컴퓨트, 오브젝트 스토리지, 백업, 이메일, 에러 추적, AI API까지 유럽 중심 스택으로 옮긴 경험을 정리한 글이다. 핵심은 반미 감정이 아니라 데이터가 어디에 있고, 누가 접근할 수 있고, 정치나 기업 정책 변화에 얼마나 휘둘리는지를 의식하자는 얘기다.

devops

개인용 컴퓨터 다음은 개인용 클러스터라는 주장

이 글은 AI 시대에 개인 한 명이 쓰는 컴퓨팅 자원이 점점 ‘클러스터 한 덩어리’ 수준으로 커질 거라고 주장한다. PC가 직장, 취미 개발자, 게임 문화로 퍼졌듯이 개인용 클러스터도 업무용 AI, 오픈소스 실험, 게임 같은 흐름을 타고 대중화될 수 있다는 시나리오다.

devops

AI 에이전트 부하에 흔들린 GitHub, 왜 다른 서비스보다 더 아팠나

GitHub가 최근 몇 달 동안 가용성 저하, 검색 장애, GitHub Actions 문제, 심지어 squash merge에서 커밋이 빠지는 데이터 무결성 사고까지 겪었다. GitHub CTO는 AI 에이전트발 부하 증가를 원인으로 들었지만, 실제로는 2년간 약 3.5배 증가한 부하와 Azure 이전, 오래된 시스템, 조직적 지연이 겹친 문제에 가깝다. 개발자 입장에선 GitHub가 ‘없으면 안 되는 도구’에서 ‘업무를 막는 병목’으로 보이기 시작했다는 게 핵심이다.

devops

한국 클라우드 시장, 이제 GPU랑 데이터센터 싸움으로 넘어감

국내 클라우드 서비스 제공사들이 AI 전환 수요를 잡기 위해 GPUaaS, 데이터센터, 공공 클라우드 사업에 공격적으로 투자하고 있어. 네이버클라우드, KT클라우드, NHN클라우드 모두 2026년 1분기 실적에서 AI 인프라를 핵심 성장축으로 내세웠고, 정부의 2조805억원 규모 GPU 구축 사업이 판을 더 키우는 중이야.

devops

칩값 뛰니 K게임의 콘솔·피시 전환 해법으로 다시 뜨는 클라우드 게임

국내 게임사들이 모바일 중심에서 콘솔·피시로 넘어가려는 타이밍에 고성능 지피유와 콘솔 가격 상승이 발목을 잡고 있다. 이용자 입장에서는 300만원대 게이밍 피시, 오른 콘솔 가격, 스팀 가격 기준 개편까지 겹치면서 고사양 게임 접근성이 떨어지는 상황이다. 업계는 원격 서버에서 게임을 실행해 스트리밍하는 클라우드 게임을 다시 현실적인 대안으로 보고 있다.