8억 사용자도 PostgreSQL로 가능!

커뮤니티에서는 8억 사용자 규모에서 단일 PostgreSQL 주(Primary) 인스턴스를 유지하는 것이 핵심 통찰이라고 평가합니다. 대부분의 스타트업이 불필요하게 복잡한 샤딩(Sharding)이나 분산 데이터베이스를 조기에 도입하는 경향이 있지만, OpenAI는 읽기 부하를 분산하고 쓰기 집약적인 기능은 다른 시스템으로 분리하는 방식으로 단순성을 유지했다고 언급됩니다. 이는 단순한 아키텍처(Simpler Architecture)가 특정 규모까지는 충분히 확장 가능하다는 강력한 증거로 제시됩니다.

사용자들은 OpenAI가 쓰기 부하 증가에 직면했을 때 PostgreSQL의 한계를 인지하고, 새로운 테이블이 필요한 기능은 Azure Cosmos DB와 같은 데이터 격리 아키텍처(Data Isolation Architecture)를 활용했다고 지적합니다. PostgreSQL의 MVCC(Multiversion Concurrency Control) 구현이 쓰기 증폭(Write Amplification)과 테이블/인덱스 블로트(Bloat)를 유발하여 쓰기 집약적인 워크로드에 비효율적이라는 분석이 나옵니다. 따라서 쓰기 집약적 워크로드(Write-Heavy Workloads)는 별도의 샤딩 시스템으로 분리하는 전략이 효과적이라고 언급됩니다.

댓글에서는 PostgreSQL의 장기 실행 쿼리(Long-Running Queries)와 유휴 트랜잭션(Idle Transactions)이 autovacuum을 차단하고 연결 슬롯을 비효율적으로 소모하는 문제를 지적합니다. `idle_in_transaction_session_timeout` 설정의 중요성이 강조되며, Rust 코드베이스에서 컴파일 타임 체크를 통해 비동기 함수 호출 시 PostgreSQL 연결이 범위 내에 있는지 확인하는 사례가 공유되었습니다. 이를 통해 10,000개 연결 풀이 필요했던 환경에서 32개로 줄이는 등 연결 풀 최적화(Connection Pool Optimization)가 가능했다고 합니다.

스키마 변경 시 발생하는 잠금 경합(Lock Contention)을 완화하기 위해, 스키마 롤아웃과 동시에 잠금을 유발하는 워크로드를 선제적으로 종료(Proactively Cancel)하는 스크립트 실행을 제안합니다. 고성능 테이블의 경우, 잠금이 유지되어 트래픽을 차단하는 것보다 충돌 워크로드 취소(Conflicting Workload Cancellation)가 더 큰 피해를 줄일 수 있다는 의견입니다. 이는 PostgreSQL에 무거운 잠금(Heavyweight Locks)이 충돌하는 워크로드를 자동으로 취소하는 기능이 있다면 유용할 것이라고 언급됩니다.

일부 사용자들은 OpenAI의 사례가 PostgreSQL과 같은 비분산 데이터베이스(Non-Distributed Database)가 여전히 강력한 선택지임을 보여준다고 주장합니다. 8억 사용자 규모에서도 단일 주(Primary)와 50개의 읽기 복제본(Read Replicas)으로 운영 가능하다는 점은, 설계 및 운영의 단순성(Simplicity in Design and Operation)과 비용 효율성(Cost Efficiency) 측면에서 큰 이점을 제공한다고 평가합니다. 특히 최신 하드웨어의 발전으로 과거보다 훨씬 적은 리소스로 높은 성능을 달성할 수 있음을 시사합니다.

약 50개의 읽기 복제본(Read Replicas)을 운영하면서 복제 지연(Replication Lag)을 거의 0에 가깝게 유지하는 OpenAI의 설정에 대한 궁금증이 제기됩니다. CPU/메모리 사용량 급증 시 복제본이 지연될 가능성과, 이로 인해 WAL(Write-Ahead Logging) 전송을 위해 주(Primary) 인스턴스가 대기해야 하는 상황에 대한 우려가 언급됩니다. 이는 비동기 복제(Async Replication) 설정과 스트래글러(Straggler) 관리에 대한 심도 있는 논의를 필요로 합니다.