PostgreSQL 확장성 한계: OpenAI 사례로 보는 EDB PGD 분산 아키텍처
작성자: Anil Kumar
작성일: 2026년 3월 5일
8억 명 이상의 사용자를 지원하는 OpenAI의 데이터베이스 운영 사례는 PostgreSQL 확장성이 대규모 글로벌 서비스에서 어떤 한계에 직면하는지 보여줍니다. 이 글에서는 싱글 프라이머리 구조와 물리적 스트리밍 복제의 제약을 살펴보고, EDB Postgres Distributed(PGD)가 트래픽 급증, 복제 지연, 무중단 유지보수, 스키마 변경 및 클라우드 종속 문제를 어떻게 해결하도록 설계되었는지 설명합니다.
OpenAI 사례로 본 PostgreSQL 확장성의 한계
OpenAI는 현재 8억 명 이상의 사용자를 지원하는 데이터베이스 아키텍처를 운영하며, 지속적인 글로벌 수요에 대응하기 위해 PostgreSQL의 한계를 넓혀가고 있습니다. OpenAI 팀은 Azure Flexible Server 환경에서 싱글 프라이머리(Single Primary) 아키텍처를 유지하면서 엄격한 SQL 리뷰, 5초 스키마 타임아웃, 쓰기 부하가 큰 데이터를 Azure Cosmos DB로 분산하는 폴리글랏(Polyglot) 접근 방식을 통해 이른바 ‘운영의 기적’을 일구어냈습니다.
그러나 이러한 복잡성은 물리적 스트리밍 복제(Physical Streaming Replication, PSR)의 구조적 한계에서 비롯됩니다. PSR은 유연한 수평 확장을 제한하며 장애 조치(Failover) 시 시스템을 취약하게 만듭니다. 또한 블록 수준의 일관성에 의존하기 때문에 복제 지연을 동적으로 제어하거나 서비스 중단 없이 DDL을 변경하기가 사실상 어렵습니다.
결국 엔지니어링 팀은 SEV-0 장애를 방지하기 위해 복잡한 애플리케이션 수준의 샤딩과 고도화된 모니터링에 의존하게 됩니다. 이는 현재의 관계형 시스템이 물리적 임계치에 도달했음을 시사합니다.
EDB는 이러한 취약한 평형 상태에서 벗어나 글로벌 규모의 고가용성(High Availability, HA), 성능 및 회복 탄력성을 위해 설계된 분산 PostgreSQL 아키텍처로 전환할 것을 제안합니다.
EDB Postgres Distributed(PGD)란?
EDB Postgres Distributed(PGD)는 과거 BDR로 알려진 기술로, 표준 PostgreSQL을 항상 가동되는(Always-on) 분산 데이터베이스 플랫폼으로 전환하는 통합 스택입니다.
액티브-액티브(Active-Active) 복제를 통해 비즈니스 연속성을 지원하며, 정의된 내구성 프로파일인 Commit Scopes를 사용해 데이터 내구성과 일관성 관리를 단순화합니다. PGD는 단순히 데이터를 복제하는 데 그치지 않고 각 리전(Region)의 활성 노드에서 애플리케이션을 온라인 상태로 유지하면서 데이터 지역성 전략과 자동화된 충돌 관리를 지원합니다.
전통적인 논리적 복제는 각 구독자(Subscriber)를 위해 Write-Ahead Log(WAL)를 디코딩하므로 CPU에 상당한 부하를 줄 수 있습니다. 반면 PGD는 소스 노드에서 논리적 디코딩을 한 번만 수행하고 그 결과인 논리적 변경 레코드(Logical Change Record, LCR)를 모든 스트림에 공유해 성능 저하를 줄입니다.
또한 병렬 적용(Parallel Apply)을 통해 처리량을 5배 향상시키며, Raft 합의 알고리즘을 내장해 결정론적 라우팅과 충돌 해결을 제공합니다.
PGD가 해결하는 6가지 PostgreSQL 운영 과제
다음은 OpenAI가 겪고 있는 주요 페인 포인트(Pain Points)를 기준으로 정리한 PGD의 6가지 핵심 솔루션입니다.
1. 트래픽 증폭과 부하 급증 대응
- 현재의 도전 과제: 싱글 프라이머리 노드가 한계에 도달하면 응답 시간이 늘어나고, 이는 애플리케이션의 재시도(Retry)를 유발해 트래픽을 배가시킵니다. Azure의
max_connections한도(약 6K)를 초과하는 커넥션 폭풍이 발생하면 데이터베이스가 쿼리 실행보다 프로세스 관리에 더 많은 자원을 소모하는 계단식 장애(Cascading Outage)로 이어집니다. - PGD의 솔루션:
- 통합 커넥션 매니저: PGD 6는 백그라운드 워커로 실행되는 빌트인 커넥션 매니저를 사용합니다. 외부 사이드카인 PgBouncer 등이 처리하기 어려운 분산 라우팅과 재시도 폭풍을 네이티브 방식으로 해결합니다.
- 액티브-액티브 아키텍처: 쓰기 작업을 여러 리드 라이터(Lead Writer)로 분산해 단일 노드에 부하가 집중되는 것을 방지하고, 커넥션 급증을 메시 전체에서 흡수합니다.
2. 쿼리와 애플리케이션 동작 최적화
- 현재의 도전 과제: 복잡한 12개 테이블 ORM 조인과 같은 비효율적인 쿼리는 CPU를 포화시키고 클러스터 전체의 지연을 초래합니다. 이를 방지하기 위해 현재 OpenAI는 수동 SQL 리뷰와 엄격한 워크로드 격리에 의존하고 있습니다.
- PGD의 솔루션:
- 무충돌 복제 데이터 타입(Conflict-free Replicated Data Types, CRDTs): 전역 카운터나 세션 상태처럼 업데이트가 빈번한 데이터를 글로벌 락(Lock) 없이 여러 노드에서 동시에 업데이트할 수 있게 해 성능 병목을 제거합니다.
- 고급 워크로드 격리: 구독 전용 노드(Subscriber-Only Nodes)를 통해 리포팅용 로컬 쓰기 트랜잭션이나 맞춤형 인덱스 생성을 지원합니다. 이를 통해 노이즈 네이버(Noisy Neighbor) 워크로드를 분리하고 프라이머리 엔진의 안정성을 보호합니다.
- 분석용 계층형 테이블(Tiered Tables): 오래된 세션 이력과 같은 콜드(Cold) 데이터를 저렴한 오브젝트 스토리지로 오프로드하고, 벡터화된 쿼리 엔진을 통해 표준 PostgreSQL보다 최대 30배 빠른 분석을 제공합니다.
3. 유지보수 경합과 스토리지 엔진 부하 완화
- 현재의 도전 과제:
VACUUM FULL이나REINDEX같은 작업은 배타적 락을 유발해 애플리케이션 쿼리를 차단합니다. 이를 피하려면 예정된 다운타임이나 엄격한 5초 락 타임아웃 규칙을 적용해야 하므로 운영 부담이 커집니다. - PGD의 솔루션:
- 순차적 온라인 유지보수(Rolling Online Maintenance): 액티브-액티브 특성을 활용해 노드별로 유지보수를 수행하면서 트래픽을 다른 노드로 동적으로 전환합니다. 이를 통해 서비스 중단 없는 유지보수를 일상적인 백그라운드 작업으로 전환할 수 있습니다.
4. 아키텍처와 복제 확장 한계 극복
- 현재의 도전 과제: 약 50개의 글로벌 복제본을 관리하면서 발생하는 WAL 전송 부하는 프라이머리 노드에 막대한 압박을 줍니다. 현재 계단식 복제(Cascading Replication)를 사용하고 있지만, 이 방식은 중간 노드 장애 시 복제 토폴로지가 취약해지는 문제가 있습니다.
- PGD의 솔루션:
- 복제 효율 최적화: 소스 노드에서 한 번만 디코딩하고 모든 복제본에 스트림을 공유합니다. 이를 통해 프라이머리의 CPU와 대역폭을 포화시키지 않고 읽기 전용 플릿을 수평 확장할 수 있습니다.
- 병렬 적용을 통한 처리량 가속: 트랜잭션 의존성을 분석해 충돌하지 않는 변경 사항을 다중 스레드에서 병렬로 적용합니다. 기존 대비 최대 5배 빠른 복제를 통해 전 세계 복제본 사이의 데이터 시차(Stale Reads)를 제거합니다.
5. 무중단 운영 변경 관리
- 현재의 도전 과제: 5초 이상의 스키마 마이그레이션을 자동으로 차단하는 규칙은 시스템 안정성을 지켜주지만 엔지니어링 속도를 크게 떨어뜨립니다.
- PGD의 솔루션:
- 순차적 스키마 업데이트: 클러스터 전체의 스키마가 일시적으로 다르더라도 작동하도록 지원합니다. 애플리케이션을 온라인 상태로 유지하면서 노드별로 순차적 업데이트를 수행할 수 있습니다.
- 제로 다운타임 메이저 업그레이드: 서로 다른 버전으로 구성된 클러스터를 지원해 PostgreSQL 15에서 16으로 업그레이드하는 것과 같은 대규모 작업을 중단 없이 수행할 수 있습니다.
6. 이식성과 클라우드 독립성 확보
- 현재의 도전 과제: Azure PostgreSQL 및 Cosmos DB에 대한 의존성은 특정 클라우드 서비스 제공업체(Cloud Service Provider, CSP)에 종속되는 PaaS 종속(PaaS Lock-in) 문제를 일으킵니다. Oracle과의 Stargate 프로젝트나 하이브리드 컴퓨팅 환경으로 확장할 때 데이터 계층의 이식성이 걸림돌이 됩니다.
- PGD의 솔루션:
- 인프라 독립성: PGD는 순수 소프트웨어 정의(Software-defined) 솔루션으로 Azure, AWS, Google Cloud, Oracle Cloud Infrastructure(OCI), 온프레미스 및 Kubernetes 환경에서 동일하게 작동합니다.
- 멀티클라우드 운영: Azure와 OCI를 잇는 단일 논리적 클러스터를 구성해 데이터를 실시간으로 복제할 수 있습니다. 이는 비용 최적화뿐 아니라 특정 클라우드 전체의 장애에 대비한 비즈니스 연속성을 보장합니다.
결론: 운영의 기적에서 아키텍처의 주권으로
OpenAI는 단일 PostgreSQL 코어로 8억 명의 사용자를 지원할 수 있음을 보여주었지만, 이는 수많은 엔지니어의 헌신적인 수동 개입이 있었기에 가능했습니다. 현재의 아키텍처는 늘어나는 운영 부채 위에 서 있는 과도기적 상태입니다.
EDB Postgres Distributed(PGD)로 전환하면 다음과 같은 가치를 얻을 수 있습니다.
- 폴리글랏 파편화 제거: NoSQL인 Cosmos DB로 분산했던 쓰기 워크로드를 통합된 분산 PostgreSQL 환경으로 다시 통합할 수 있습니다.
- 결정론적 회복 탄력성: 외부 모니터링 시스템에 의존하는 대신 데이터베이스 엔진에 내장된 Raft 합의 알고리즘을 통해 수학적 확실성에 기반한 장애 조치를 구현할 수 있습니다.
- 검증된 확장성: EDB의 분산 패턴은 이미 세계 최대 규모의 금융 기관과 결제 네트워크에서 99.999% 이상의 가용성을 입증했습니다.
- 완전한 인프라 이식성: 하이퍼스케일러에 종속되지 않고 데이터 계층이 컴퓨팅 성능을 따라 어디로든 이동할 수 있는 자유를 확보할 수 있습니다.
이제 수동 최적화의 시대를 지나 스스로 치유하고 확장하는 네이티브 분산 아키텍처로 나아갈 때입니다.
PostgreSQL 확장성과 EDB PGD FAQ
PostgreSQL의 싱글 프라이머리 아키텍처는 왜 확장에 한계가 있나요?
쓰기 부하와 연결이 하나의 프라이머리 노드에 집중되기 때문입니다. 노드가 한계에 도달하면 응답 지연과 애플리케이션 재시도가 맞물려 트래픽이 증폭되고 계단식 장애로 이어질 수 있습니다.
EDB Postgres Distributed(PGD)는 무엇인가요?
PGD는 표준 PostgreSQL을 항상 가동되는 분산 데이터베이스 플랫폼으로 전환하는 통합 스택입니다. 액티브-액티브 복제, Commit Scopes, 자동화된 충돌 관리 및 데이터 지역성 전략을 지원합니다.
PGD의 액티브-액티브 복제는 어떤 이점을 제공하나요?
여러 활성 노드에 쓰기 작업을 분산해 단일 노드로 부하가 집중되는 것을 줄입니다. 노드별 유지보수 중에도 트래픽을 다른 노드로 전환할 수 있어 비즈니스 연속성과 무중단 운영을 지원합니다.
PGD는 PostgreSQL 복제 성능을 어떻게 개선하나요?
소스 노드에서 논리적 디코딩을 한 번만 수행하고 LCR을 모든 스트림에 공유합니다. 또한 트랜잭션 의존성을 분석해 충돌하지 않는 변경 사항을 병렬로 적용함으로써 기존 대비 최대 5배 빠른 복제를 제공합니다.
PGD는 멀티클라우드 환경에서 사용할 수 있나요?
PGD는 Azure, AWS, Google Cloud, OCI, 온프레미스 및 Kubernetes에서 작동하는 소프트웨어 정의 솔루션입니다. 서로 다른 인프라를 단일 논리적 클러스터로 구성해 실시간 데이터 복제와 비즈니스 연속성을 지원합니다.