Lv.2 초급PostgreSQL

2026.05.3114분 읽기Lv.2 초급

시리즈멀티 리전에서 Patroni H/A 운용하기 · 파트 1시리즈 허브 보기

멀티 리전에서 Patroni H/A 운용하기 — Part 1: 기초 개념과 아키텍처 설계 원칙

단일 DC Patroni 구성은 노드 장애에는 강하지만 리전 전체 장애에는 대응하지 못한다. 멀티 리전 HA 설계의 출발점인 RPO·RTO·RTT 트레이드오프부터, 동기 복제 3DC 자동 페일오버 패턴과 비동기 Standby Cluster 2DC 수동 페일오버 패턴의 차이, DCS 배치와 etcd 타임아웃 설계 원칙까지 아키텍처 선택 기준을 정리한다.

시리즈 구성 — 멀티 리전에서 Patroni H/A 운용하기

Part 1 — 기초 개념과 아키텍처 설계 원칙 (현재 편)

Part 2 — 동기 복제(Synchronous) 멀티 DC 구성 실습

Part 3 — 비동기 복제(Asynchronous) + Standby Cluster 구성 실습

Part 4 — Split-Brain 방지 전략 (STONITH, Watchdog, Quorum)

Part 5 — 장애 대응 Runbook 및 DR 훈련 시나리오

Part 6 — 모니터링, 운영 자동화 및 Best Practices

1. 왜 멀티 리전 HA가 필요한가?

단일 데이터센터(Single DC) 내에서 Patroni를 운영하는 것만으로도 노드 장애, OS 크래시 같은 일반적인 장애에는 충분히 대응할 수 있다. 그러나 클라우드 리전 전체가 다운되거나, 자연재해·광케이블 절단처럼 인프라 레벨의 광역 장애가 발생하면 단일 리전 클러스터는 속수무책이 된다.

멀티 리전 HA가 필요한 시나리오를 정리하면 다음과 같다.

장애 유형	단일 리전 대응	멀티 리전 필요 여부
특정 노드 장애	자동 페일오버 가능	불필요
가용 영역(AZ) 장애	AZ 분산 배치로 대응	조건부
리전 전체 장애	대응 불가	필수
네트워크 파티션 (리전 간)	대응 불가	필수
규제 요건 (DR 사이트 의무화)	대응 불가	필수

특히 금융, 공공, e-커머스 도메인에서는 재해복구(DR) 사이트 구성이 법적 의무인 경우가 많다. Patroni는 이런 요구를 충족하기 위한 멀티 DC 운영 방법을 공식 문서에서 명확히 가이드하고 있다.

2. Patroni 핵심 구성 요소 복습

멀티 리전 아키텍처를 이해하기 전에, Patroni의 핵심 구성 요소를 간략히 짚고 넘어가자.

Leader Key 관리: Primary 노드가 DCS에 Leader Key를 갱신(TTL 기반)하며 생존 신호를 보낸다.
자동 페일오버: Leader Key 갱신이 중단되면 Replica 중 하나가 Leader Race를 통해 새 Primary로 승격된다.
Split-Brain 방지: etcd의 Raft 합의 알고리즘과 Linux Watchdog을 이용해 두 노드가 동시에 Primary가 되는 상황을 원천 차단한다.

Patroni 4.1.2 기준, 지원되는 DCS: etcd v3, Consul, ZooKeeper, Kubernetes (내장 etcd 활용)

3. 멀티 리전 설계의 핵심: CAP 이론과 트레이드오프

멀티 리전 DB 운영의 본질적인 문제는 네트워크 지연(Latency)과 데이터 일관성(Consistency) 사이의 트레이드오프다. 분산 시스템에서 Partition Tolerance는 항상 전제 조건이며, 이를 바탕으로 Consistency와 Availability 중 무엇을 우선하느냐가 설계의 출발점이 된다.

멀티 리전에서 반드시 답해야 할 세 가지 질문:

Q1. RPO(Recovery Point Objective)를 0으로 보장해야 하는가?

YES → 동기 복제(Synchronous Replication) 필수
NO → 비동기 복제(Asynchronous Replication) 허용 가능

Q2. RTO(Recovery Time Objective)가 얼마나 짧아야 하는가?

수 초 이내 → 자동 페일오버 구성 필요 (3개 DC 이상 필수)
수 분~수십 분 허용 → 수동 페일오버 허용 (2 DC 구성 가능)

Q3. 리전 간 네트워크 지연을 감당할 수 있는가?

동기 복제 시 리전 간 왕복 지연(RTT)이 쓰기 레이턴시에 직접 더해진다.
예시: 서울-도쿄 RTT 약 30ms → 동기 복제 적용 시 모든 쓰기에 최소 30ms 추가

이 세 질문에 대한 답이 곧 아키텍처 선택의 기준이 된다.

4. 두 가지 주요 아키텍처 패턴

Patroni 공식 문서는 멀티 DC 구성을 크게 두 가지 패턴으로 구분한다.

패턴 A — 동기 복제 (3개 이상 DC, 자동 페일오버)

# patroni.yml — 동기 복제 설정
bootstrap:
  dcs:
    synchronous_mode: true
    synchronous_mode_strict: false

주요 특징:

최소 3개 DC에 etcd 노드를 1개씩 배치해야 Quorum 유지 가능
synchronous_mode: true 설정으로 Primary가 Synchronous Replica를 지정
DC 1개가 완전히 다운되어도 나머지 2개 DC로 자동 페일오버 가능
단점: 리전 간 RTT만큼 쓰기 지연 발생, 3개 DC 운영 비용 증가

synchronous_mode_strict: false는 Synchronous Replica가 없을 때도 쓰기를 허용한다. true로 설정하면 동기 레플리카가 없는 순간 쓰기가 차단되므로, 운영 전 가용성 정책을 명확히 결정해야 한다.

패턴 B — 비동기 복제 + Standby Cluster (2 DC, 수동 페일오버)

# patroni.yml — DC2 Standby Cluster 설정
bootstrap:
  dcs:
    standby_cluster:
      host: dc1-primary.example.com
      port: 5432
      primary_slot_name: dc2_standby

주요 특징:

각 DC가 독립된 etcd 클러스터를 운영
DC2는 Patroni의 standby_cluster 기능으로 DC1에서 WAL을 수신
DC1 장애 시 자동 페일오버 불가 → 수동으로 standby_cluster 설정 제거 후 승격
승격 전 DC1이 완전히 중단되었는지 반드시 확인해야 함 (Split-Brain 방지)
장점: 비동기이므로 리전 간 지연에 자유롭고, 구성 비용이 패턴 A보다 낮음

⚠️ DC1이 살아있는 상태에서 DC2를 승격하면 Split-Brain이 발생한다. STONITH(Shoot The Other Node In The Head)로 DC1을 강제 종료한 뒤 승격해야 한다. 승격 전 DC1 차단은 선택이 아니라 필수 절차다.

primary_slot_name에 지정한 복제 슬롯은 DC1 Primary에 미리 생성해 두어야 한다. 슬롯이 없으면 DC2의 WAL 수신이 시작되지 않는다.

5. DCS 배치 전략

DCS(etcd, Consul 등)의 배치는 멀티 리전 HA의 핵심이다. 잘못 설계하면 DCS 자체가 단일 장애 지점(SPOF)이 된다.

etcd 홀수 노드 원칙

etcd는 Raft 합의 알고리즘을 사용하기 때문에 항상 홀수 개의 노드로 구성해야 한다.

etcd 노드 수	Quorum (과반)	허용 장애 노드 수
3	2	1
5	3	2
7	4	3

짝수 노드 구성은 Quorum 안정성을 높이지 않는다. 노드 4개와 3개의 허용 장애 수는 동일(1개)하므로, 짝수 노드는 비용만 증가시킨다.

리전 배치 가이드

권장: 5개 노드를 3개 리전에 분산
  Region A: etcd × 2
  Region B: etcd × 2
  Region C: etcd × 1  (Tiebreaker / Witness)

주의: 리전 간 네트워크 지연이 etcd heartbeat timeout보다 짧아야 함
  기본 heartbeat: 100ms, election timeout: 1000ms
  멀티 리전 환경에서는 이 값을 RTT에 맞게 조정 필요

etcd 타임아웃 조정

# etcd 설정 — 서울-도쿄-싱가포르 구성 예시 (RTT 약 30-80ms 가정)
heartbeat-interval: 500   # ms, 기본 100ms에서 RTT 고려해 상향
election-timeout: 5000    # ms, heartbeat-interval × 10 비율 유지

# patroni.yml — etcd3 연결 설정 (TLS)
etcd3:
  hosts:
    - seoul-etcd-1:2379
    - tokyo-etcd-1:2379
    - singapore-etcd-1:2379
  protocol: https
  cacert: /etc/ssl/etcd/ca.crt
  cert: /etc/ssl/etcd/client.crt
  key: /etc/ssl/etcd/client.key

heartbeat-interval과 election-timeout은 실제 리전 간 RTT를 측정한 뒤 설정해야 한다. 일반적으로 heartbeat-interval은 RTT의 5-10배, election-timeout은 heartbeat-interval의 10배를 기준으로 잡는다. 값이 너무 낮으면 네트워크 지연만으로도 잦은 리더 재선출이 발생한다.

6. 아키텍처 선택 기준 정리

항목	패턴 A (동기, 3DC)	패턴 B (비동기, 2DC)
최소 DC 수	3개	2개
RPO	0 (데이터 손실 없음)	수 초~수 분 (네트워크 지연 종속)
RTO	수 초 (자동 페일오버)	수 분~수십 분 (수동)
쓰기 성능 영향	높음 (RTT 추가)	낮음
운영 복잡도	높음	중간
비용	높음	중간
주요 위험	리전 간 지연으로 인한 쓰기 성능 저하	Split-Brain (수동 운영 절차 미숙 시)

어느 패턴을 선택하든 공통 전제가 있다. etcd 노드는 홀수로 리전에 분산 배치하고, 리전 간 RTT를 실측한 뒤 heartbeat-interval과 election-timeout을 조정해야 한다. PostgreSQL 노드 배치가 완벽해도 DCS 설계가 잘못되면 DCS 자체가 장애 지점이 된다.

참고 자료

Patroni 공식 문서 — Multi-Datacenter HA Configuration
Patroni 공식 문서 — Standby Cluster
Percona — Patroni Architecture Guide
Blue Crystal Solutions — PostgreSQL HA with Patroni, etcd & Barman (2026)
Stormatics — Split-Brain Scenarios in HA PostgreSQL Clusters