PostgreSQL 생태계에서 고가용성을 확보하는 다양한 방안
2025.09.30
김명준 차장 Consultant, Professional Services | EDB 코리아
모든 DBMS가 그러하듯, PostgreSQL 생태계에서도 성능, 데이터 정합성, 보안과 더불어 고가용성 보장은 가장 중요한 화두 중 하나이다.
그간 PostgreSQL은 고가용성 보장을 위해 많은 고민들을 해왔고, 현대의 PostgreSQL 시스템에는 그 고민의 흔적이 많이 묻어있다.
고가용성이란 높은 가용성을 보장하는 것으로, 단적으로 서비스의 연속성이 얼마나 보장되는지를 의미한다.
서비스의 중요도와 특성 등에 따라 각기 다른 수준의 고가용성 보장이 요구되고 있으며, PostgreSQL 생태계에는 고가용성을 보장하는 다양한 방식들이 있다.
가장 원시적인 Backup/Restore 방안부터, 사실상 제로 다운타임에 가까운 연속성을 제공하는 PGD(Postgres Distributed)에 이르기까지 PostgreSQL 생태계의 고가용성 보장을 위한 방안을 살펴보도록 하자.
1. Backup / Restore: 최후의 안전망
백업/복구는 현대적인 의미의 고가용성과는 거리가 있는 방법이다.
전체 클러스터를 백업하고, WAL을 아카이빙하여 장애가 발생하면 백업본과 아카이빙된 WAL 파일을 사용해 특정 시점으로 복구(Point-in-Time Recovery, PITR)를 진행한다. 소요 시간은 데이터 크기, 장비의 스펙, 네트워크 성능 등 수많은 요소에 영향을 받는다.
이를 위한 솔루션으로는 물리적 백업을 자동화하고 관리해주는 Barman, pgBackRest 등이 있다. (pg_dump를 이용한 논리적 백업도 있지만, PITR을 통한 정밀한 재해 복구에는 물리적 백업이 주로 사용된다.)
백업/복구는 즉각적인 가용성 확보보다는 재해 복구(DR) 관점에서 RPO/RTO 전략을 보완하는 최후의 안전망 역할을 한다.
2. Physical Replication: 가장 널리 쓰이는 PostgreSQL HA 방식
Physical Replication은 PostgreSQL 생태계에서 가장 널리 사용되는 고가용성(HA) 구성 방식이다.
읽기와 쓰기가 가능한 Primary 서버를 두고, 여기서 발생하는 트랜잭션들을 WAL을 통해 Standby 서버로 전달한다. Standby 서버는 전달받은 WAL을 재생하여 정합성을 맞춘다.
PostgreSQL 서버의 모든 변경사항이 WAL 레코드에 담겨 전송되고, 이를 그대로 반영하기 때문에 Standby 서버는 기본적으로 복구모드(Recovery)로 동작한다.
다만 Hot Standby 모드에서는 대기 중에도 읽기 전용 쿼리를 받아 부하 분산이 가능하다.
2-1. WAL Shipping
WAL Shipping은 WAL 파일을 직접 Standby 서버로 전달하는 방식이다. SCP, SFTP 등으로 구현할 수 있으나, 현업에서는 보통 archive_command/restore_command 기반의 로그 배송이나 Streaming Replication을 선호한다.
2-2. Streaming Replication
Streaming은 Primary에서 발생한 WAL 레코드를 거의 실시간으로 Standby 서버에 전달한다.
PostgreSQL이 기본적으로 지원하는 방식이며, 다수의 Replication 관리 솔루션들이 이를 기반으로 클러스터링을 제공한다.
대부분은 Streaming Replication을 통해 구성하며, 이는 다시 비동기(Asynchronous) 방식과 동기(Synchronous) 방식으로 나뉜다. 비동기 방식은 성능에 미치는 영향이 적지만 장애 시 약간의 데이터 손실이 발생할 수 있다. 반면, 동기 방식은 Standby 서버에 데이터가 안전하게 저장되었음을 확인한 후에 트랜잭션을 최종 완료하므로 데이터 무손실(RPO=0)을 보장할 수 있지만, 쓰기 성능에 부하가 발생할 수 있다.
Primary 장애 시 Standby 서버를 새로운 Primary로 승격시켜 고가용성을 확보하는데, 이 과정을 Failover라고 한다. 이 복잡한 과정을 관리자의 수작업이 아닌 자동화 솔루션(repmgr, EFM, Patroni 등)을 통해 처리하는 것이 일반적이다. 이러한 솔루션들은 장애 감지, 자동 승격, 그리고 기존 Primary가 예기치 않게 다시 살아나는 경우를 대비한 펜싱(Fencing) 기능까지 제공하여 안정적인 클러스터 운영을 보장한다.
Streaming 방식을 사용하면 Hot Standby 모드로 읽기 부하를 분산하거나, Warm Standby 모드로 DR 환경을 구축할 수도 있다.
장애 감지·자동 승격·라우팅 구성에 따라 보통 수 초 내에 복구가 가능하지만, 경우에 따라 수십 초~수분이 소요될 수 있다.
3. Logical Replication: 유연한 데이터 동기화
Logical Replication 역시 WAL을 활용하지만, WAL 레코드를 디코딩하여 테이블 단위로 복제를 제한하거나 양방향 복제를 가능하게 하는 점에서 발전된 방식이다.
약간의 오버헤드는 존재하나, 서로 다른 서버의 특정 테이블을 하나처럼 동기화할 수 있는 유연성이 있다. 이를 활용해 무중단 메이저 버전 업그레이드, 데이터 웨어하우스로의 데이터 통합, 마이크로서비스 간 데이터 동기화 등 다양한 시나리오를 구현할 수 있다.
PostgreSQL 16부터는 WAL origin 필터를 활용해 양방향 복제 시 루프를 방지할 수 있게 되었다.
이론적으로 Active-Active 구성이 가능하나, 양쪽 노드에서 동일한 데이터를 동시에 수정할 때 발생하는 쓰기 충돌(Write Conflict) 문제는 내장 기능만으로 해결되지 않으므로 애플리케이션 레벨에서 정교한 충돌 해결 정책을 설계해야 하는 과제가 남는다.
또한 커뮤니티 PostgreSQL의 기본 Logical Replication은 테이블 데이터 중심으로만 동작하며, DDL, 시퀀스, 함수 등은 자동 복제되지 않는다. 따라서 스키마 변경은 별도 관리가 필요하다.
4. EnterpriseDB PGD (Postgres Distributed)
PostgreSQL의 Logical Replication 장점을 서버 단위로 확장하고, 멀티-마스터의 한계를 극복한 솔루션이 바로 EnterpriseDB PGD (Postgres Distributed)이다. PGD는 논리적 복제 기술을 기반으로 자동 충돌 해결(Conflict Resolution), DDL 복제, 글로벌 합의(Consensus) 메커니즘을 더하여 지리적으로 분산된 멀티-마스터 클러스터를 안정적으로 운영할 수 있게 해준다. 주요 특징은 다음과 같다.
4-1. 진정한 ‘스케일아웃’ (True Scale-Out) 역량
PGD는 단일 노드의 한계를 넘어 쓰기 성능을 수평적으로 확장할 수 있다.
트랜잭션 부하가 높은 애플리케이션에서 노드를 추가함으로써 처리량을 크게 늘릴 수 있고, 비즈니스 성장에 따라 유연하게 확장 가능하다.
(단, 모든 워크로드에서 선형 확장이 보장되는 것은 아니며, 설계와 트랜잭션 특성에 따라 차이가 있다.)
4-2. 제로 다운타임 고가용성 및 재해 복구 (Zero Downtime HA/DR)
Multi-Master 아키텍처로 특정 노드 장애 시에도 다른 노드가 즉시 쓰기 작업을 이어받아 서비스 연속성을 보장한다.
지리적으로 분산된 데이터센터 간 복제를 통해 지역 단위 재해에도 데이터 손실 없이 서비스를 빠르게 재개할 수 있다.
4-3. 데이터 지역성 및 성능 최적화 (Data Locality & Performance Optimization)
여러 지역에 데이터 사본을 배치하여 사용자에게 가장 가까운 노드에서 읽기/쓰기 요청을 처리함으로써 지연을 최소화하고 응답 속도를 높일 수 있다.
전국 단위 또는 글로벌 서비스를 제공하는 조직에 특히 유용하다.
4-4. 유연한 마이그레이션 및 업그레이드 (Seamless Migration & Upgrades)
PGD는 분산 아키텍처를 기반으로 무중단 업그레이드, 패치 적용, 마이그레이션을 지원한다.
특정 노드를 클러스터에서 분리해 작업 후 재결합하는 방식으로 핵심 서비스의 연속성을 유지할 수 있다.
4-5. 오픈 소스 PostgreSQL의 모든 장점은 그대로
PGD는 PostgreSQL 기반으로 구축되어 오픈 소스의 강력한 기능과 생태계를 유지하면서도 분산 데이터베이스의 장점을 추가적으로 제공한다.
PGD는 멀티-마스터 아키텍처를 통해 기존 Physical Replication 기반 솔루션에서 발생하는 단절 시간을 최소화하며, 사실상 제로 다운타임에 가까운 고가용성 시나리오를 구현할 수 있다.
이를 통해 기존 PostgreSQL 생태계에서 일반적으로 사용되는 Physical Replication 기반 DR솔루션에서 한단계 더 진보된 형태의 DR 시스템 구축도 가능하다.
고가용성 방식별 비교표
| 방법 | RTO | RPO | 장점 | 단점 | 주요 용도 |
|---|---|---|---|---|---|
| Backup/Restore | 수십 분 ~ 수 일 | 수 분 ~ 수 시간 | 구현 단순, 최후의 안전망, PITR 가능 | HA 불가, 긴 복구 시간 | DR, 데이터 아카이빙 |
| Physical Replication (Async) | 수 초 ~ 수 분 | 수 초 이내 | 검증된 방식, 안정성, 읽기 부하 분산 | 데이터 유실 가능성 | 일반적 HA/DR |
| Physical Replication (Sync) | 수 초 ~ 수 분 | 0 (Zero) | 데이터 무손실 보장 | 성능 저하 가능 | 금융 등 핵심 서비스 |
| Logical Replication | 수 초 ~ 수 분 | 수 초 이내 | 선택적 복제, 무중단 마이그레이션 | 충돌 처리 필요 | 데이터 통합, 부분 복제 |
| PGD (Multi-Master) | 수 초 (무중단에 가까움) | 0 (동기 모드) | 글로벌 분산, 제로 다운타임 | 아키텍처 복잡, 상용 | 미션 크리티컬, 글로벌 서비스 |
결론: PostgreSQL 고가용성 확보 전략
위에서 설명한 각각의 방법은 나름의 장점을 가지고 있으며, 서비스의 중요도와 목적에 따라 Backup/Restore에서부터 PGD에 이르기까지 다양한 선택지가 존재한다.
서비스의 중요도와 특성에 따라 위에서 설명한 방법들을 선택하여 고가용성을 확보할 수 있다.
EnterpriseDB는 PostgreSQL 생태계를 확장시키고 풍요롭게 만들기 위해 노력중이며, 그 일환으로 고가용성에 대한 끊임없는 고민과 해결방안을 제시해왔다.
EnterpriseDB는 그간의 고민과 커뮤니티 기여 역량을 바탕으로 앞서 설명한 모든 구성 방안을 엔터프라이즈 수준에서 지원하고 있다.
