OpenAI가 ChatGPT 8억 명의 사용자를 지원하기 위해 어떤 데이터베이스를 쓰고 있을까요?

많은 분들이 최첨단 AI 회사니까 뭔가 특별한 기술을 쓸 거라고 생각하실 수 있어요.

그런데 놀랍게도 OpenAI의 핵심 시스템은 PostgreSQL로 돌아갑니다.

30년 넘은 오픈소스 데이터베이스요.

더 놀라운 건 샤딩도 안 하고 단일 주 서버에 읽기 복제본만 붙여서 이 규모를 감당하고 있다는 겁니다.

저는 에이전시를 운영하면서 수백 개의 스타트업 프로젝트를 진행했는데요.

데이터베이스 선택에 대한 질문을 정말 많이 받았어요.

우리 서비스가 커지면 어떻게 하죠? 샤딩을 해야 하나요?

NoSQL로 바꿔야 하나요? 이런 걱정들이요. 오늘 OpenAI의 사례를 보면서 이런 걱정들에 대한 답을 찾아보려고 합니다.

단순함을 유지하면서도 엄청난 규모로 확장할 수 있다는 것.

그리고 그 방법을 구체적으로 알려드리겠습니다. 먼저 OpenAI의 아키텍처를 살펴볼게요.

OpenAI는 Azure의 매니지드 PostgreSQL 서비스를 사용합니다. 구조는 단순해요.

하나의 주 서버가 모든 쓰기 작업을 담당하고 수십 개의 읽기 복제본이 읽기 요청을 분산 처리합니다.

50개 이상의 복제본이 있고 일부는 다른 지역에 배치되어 있어요.

이 구조로 초당 수백만 건의 쿼리를 처리합니다. 모니터링은 DataDog을 쓰고, Kubernetes에서 서비스들이 PgBouncer 커넥션 풀을 통해 데이터베이스에 접근해요.

왜 샤딩을 안 할까요? 샤딩은 데이터를 여러 서버에 나누어 저장하는 건데 확장성은 좋지만 복잡도가 엄청나게 올라갑니다.

조인 쿼리가 어려워지고 트랜잭션 관리가 복잡해지고 운영 부담이 커져요.

OpenAI의 보한 장 엔지니어는 이렇게 말했어요.

OpenAI에서 우리는 샤딩 없는 아키텍처를 사용합니다. 하나의 쓰기 서버와 여러 읽기 서버로 구성되어 있고, PostgreSQL이 대규모 읽기 부하에서 우아하게 확장될 수 있다는 것을 보여주고 있습니다.

왜 MongoDB나 Cassandra 같은 NoSQL 데이터베이스가 아니라 PostgreSQL일까요? PostgreSQL은 30년 넘게 검증된 기술이에요.

데이터 정합성이 중요한 서비스에서는 관계형 데이터베이스의 트랜잭션 보장이 필수입니다.

ChatGPT에서 사용자의 대화 기록, 결제 정보, 구독 상태 같은 데이터는 절대로 잘못되면 안 되잖아요.

PostgreSQL은 이런 데이터를 안전하게 관리할 수 있어요. 게다가 PostgreSQL 생태계가 엄청 풍부합니다.

모니터링 도구, 백업 솔루션, 클라우드 매니지드 서비스까지 다 갖춰져 있어요.

커넥션 풀링도 중요한 부분이에요. OpenAI는 PgBouncer를 사용합니다.

데이터베이스 커넥션은 비싼 리소스예요. 매번 새로 만들고 끊으면 오버헤드가 큽니다.

PgBouncer는 커넥션을 재사용해서 이 비용을 줄여줘요.

특히 Kubernetes처럼 서비스가 빈번하게 뜨고 내리는 환경에서는 커넥션 풀링이 필수입니다.

OpenAI는 비즈니스 로직 쪽에 PgBouncer를 두고 데이터베이스 클러스터에 접근하게 했어요.

그런데 이 단순한 구조에는 치명적인 문제가 있어요.

바로 쓰기 병목입니다. 읽기는 복제본을 늘리면 해결되지만, 쓰기는 모든 요청이 단일 주 서버로 몰려요.

트래픽이 급증하면서 실제로 데이터베이스 성능이 서비스 전체에 영향을 미치는 장애가 발생했습니다.

이게 OpenAI의 가장 큰 도전이었어요. 그래서 쓰기 부하를 줄이기 위한 다양한 전략을 도입했습니다.

첫 번째 전략은 불필요한 쓰기 제거예요. 애플리케이션 레벨에서 정말 필요한 쓰기인지 검토하고, 필요 없는 쓰기는 과감하게 없앴어요.

급하지 않은 쓰기는 즉시 처리하지 않고 모아서 나중에 처리해요.

이렇게 하면 순간적인 쓰기 폭주를 평탄화할 수 있습니다.

세 번째는 데이터 백필 속도 제어예요. 대량의 데이터를 넣어야 할 때 한꺼번에 넣지 않고 속도를 조절해서 넣습니다.

이 세 가지만으로도 쓰기 병목을 상당히 완화할 수 있었어요.

여기서 잠깐, 영상이 도움이 되셨다면 좋아요, 구독, 알림 설정 부탁드리구요.

바이브 코딩을 위한 필수 프롬프트 3종을 무료로 받아보시려면 heyjames.

ai를 방문해주세요. 설명란에 링크가 있습니다. 쓰기 문제를 어느 정도 해결한 후에는 읽기 최적화에 집중했어요.

ChatGPT의 트래픽 대부분은 읽기 요청이거든요.

핵심 전략은 요청 우선순위 구분이에요.

모든 읽기 요청이 똑같이 중요하지 않잖아요.

사용자가 바로 기다리는 요청과 백그라운드에서 처리해도 되는 요청을 구분합니다.

높은 우선순위 요청에는 전용 읽기 복제본을 할당해요.

이렇게 하면 중요한 요청이 다른 트래픽에 영향받지 않고 빠르게 처리됩니다.

쿼리 최적화도 중요합니다. OpenAI에서 겪었던 문제 중 하나가 12개 테이블을 조인하는 복잡한 쿼리였어요.

ORM이 자동으로 생성한 비효율적인 쿼리가 성능을 갉아먹고 있었던 거죠.

세션, 문장, 클라이언트 레벨에서 타임아웃을 설정해서 오래 실행되는 트랜잭션을 방지했습니다.

이건 우리가 흔히 간과하는 부분인데 느린 쿼리 하나가 전체 시스템을 망칠 수 있어요.

OpenAI는 스키마 변경에 대해서도 엄격한 규칙을 적용합니다.

새로운 테이블이나 워크로드를 PostgreSQL에 추가하는 것을 금지했어요.

가벼운 컬럼 작업만 허용하고, 그것도 5초 타임아웃을 걸었습니다.

인덱스 생성은 반드시 동시성 옵션을 사용해야 하고, 1초 이상 지속되는 쿼리가 있으면 스키마 변경이 실패하도록 막아뒀어요.

왜 이렇게까지 할까요? 대규모 시스템에서 스키마 변경은 정말 위험하거든요.

잘못하면 전체 서비스가 멈출 수 있습니다. OpenAI가 겪었던 장애 사례도 흥미로워요.

첫 번째 사례는 캐시 장애의 연쇄 효과입니다.

Redis 캐시에 문제가 생기자 평소에 캐시에서 처리되던 요청들이 데이터베이스로 몰렸어요.

데이터베이스가 갑자기 늘어난 부하를 감당하지 못하면서 연쇄 장애가 발생했습니다.

이건 캐시와 데이터베이스를 함께 설계해야 한다는 교훈을 줘요.

캐시가 죽었을 때 데이터베이스가 버틸 수 있어야 합니다.

두 번째 사례는 더 기술적인데요. CPU 사용량이 극도로 높아졌을 때 발생한 버그입니다.

CPU가 정상으로 돌아온 후에도 walsender 프로세스가 루프에 빠져서 WAL 로그를 제대로 복제본에 보내지 못했어요.

그 결과 복제 지연이 늘어났습니다. 이런 엣지 케이스는 예측하기 어렵지만 모니터링과 빠른 대응이 중요하다는 걸 보여줘요.

OpenAI는 이런 경험을 통해 9개월 동안 PostgreSQL 관련 중대 장애를 단 1건만 겪었다고 합니다.

OpenAI는 PostgreSQL 커뮤니티에 몇 가지 기능을 요청하기도 했어요.

1. 인덱스 비활성화 기능입니다.

사용하지 않는 인덱스는 쓰기 성능을 떨어뜨리고 유지보수 부담을 늘려요.

그런데 인덱스를 바로 삭제하면 문제가 생길 수 있으니까 먼저 비활성화해서 성능을 모니터링한 후 삭제하고 싶다는 거예요.

2. 지연 시간 백분위수 메트릭입니다. 현재 pg_stat_statement는 평균 응답 시간만 제공하는데 PostgreSQL의 MVCC 설계에서 오는 도전도 있습니다.

MVCC는 멀티 버전 동시성 제어라는 건데 P95나 P99 같은 백분위수 지표가 필요하다고 요청했어요.

쓰기가 발생할 때마다 새로운 버전의 행을 만들어요.

이게 동시성에는 좋지만 테이블과 인덱스 블로트, 즉 부풀어 오르는 현상이 생깁니다.

그래서 autovacuum이라는 청소 프로세스가 필요한데, 이걸 튜닝하는 게 쉽지 않아요.

복제본이 많아지면 가시성 체크 오버헤드 때문에 복제 지연이 늘어날 수도 있습니다.

OpenAI도 이런 문제들과 씨름했어요.

흥미로운 건 OpenAI가 새로운 쓰기 워크로드를 Cosmos DB로 분산시켰다는 거예요.

PostgreSQL의 단일 쓰기 서버 한계를 인정하고, 새로운 테이블이나 기능은 Cosmos DB에 추가하는 거죠.

이건 현실적인 타협이에요. 기존 시스템을 유지하면서 새로운 요구사항을 수용하는 방법입니다.

마이그레이션은 수 개월에서 수 년이 걸릴 수 있다고 OpenAI도 인정했거든요.

완벽한 아키텍처를 추구하기보다 현실적인 해결책을 찾은 거예요.

이 사례에서 우리가 배울 수 있는 교훈이 있습니다. 첫째, 단순함의 가치예요.

OpenAI는 최첨단 AI 회사지만 데이터베이스는 가장 검증된 기술을 씁니다.

샤딩 같은 복잡한 구조 대신 단일 주 서버와 읽기 복제본이라는 단순한 구조로 8억 사용자를 지원해요.

복잡한 기술이 항상 답은 아닙니다.

2. 읽기와 쓰기의 분리예요. 대부분의 웹 애플리케이션은 읽기가 훨씬 많습니다.

ChatGPT도 마찬가지예요. 읽기는 복제본으로 확장하고, 쓰기는 최대한 줄이는 전략이 효과적입니다.

제가 에이전시를 운영할 때도 이 원칙을 적용했는데요, 불필요한 쓰기를 줄이는 것만으로도 데이터베이스 부하가 확 줄어들었어요.

한 프로젝트에서는 페이지 조회수를 매번 데이터베이스에 기록하고 있었는데, 이걸 인메모리에 모아뒀다가 주기적으로 배치로 쓰는 방식으로 바꿨더니 데이터베이스 부하가 절반으로 줄었습니다.

3. 우선순위 기반 리소스 할당이에요.

모든 요청을 동등하게 취급하면 중요한 요청이 피해를 봅니다.

사용자가 기다리는 요청과 백그라운드 요청을 구분하고, 중요한 요청에 전용 리소스를 할당하세요.

OpenAI는 다단계 속도 제한도 적용해서 리소스 고갈을 방지했어요.

4. 장애를 대비한 설계입니다. 캐시가 죽으면 어떻게 되나요?

복제본 하나가 죽으면요? 이런 상황을 미리 생각하고 설계해야 합니다.

OpenAI는 주 서버 장애 시 읽기 전용 요청을 복제본으로 라우팅하는 방식으로 서비스 중단을 최소화해요.

5. 매니지드 서비스의 활용이에요. OpenAI는 직접 PostgreSQL을 운영하지 않고 Azure의 매니지드 서비스를 씁니다.

오픈AI가 8억 사용자를 단일 PostgreSQL로 처리하는 비결

인썸니아와 핑거를 운영하면서
삶의 다양한 문제를 해결해가는 개발자
제임스의 유튜브 채널입니다

플랫폼 개발 문의는 
https://fingr.io 로 남겨주세요

프리랜서를 위한 강의를 인프런에 런칭했습니다
https://www.inflearn.com/course/%ED%94%84%EB%A6%AC%EB%9E%9C%EC%84%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%99%84%EB%B2%BD%EA%B0%80%EC%9D%B4%EB%93%9C

AICOMPANY@V29EYH


헤이, 제임스! - 코딩, AI, 창업

OpenAI는 ChatGPT의 8억 사용자를 지원하기 위해 샤딩 없이 단일 PostgreSQL 주 서버와 50개 이상의 읽기 복제본을 활용하는 단순한 아키텍처를 사용합니다.

쓰기 병목 현상을 해결하기 위해 불필요한 쓰기 제거, 지연 쓰기, 데이터 백필 속도 제어 전략을 사용하고, 읽기 최적화를 위해 요청 우선순위를 구분하여 중요한 요청에 전용 복제본을 할당합니다.

검증된 기술인 PostgreSQL을 깊이 이해하고 최적화하는 것이 중요하며, 서비스 초기부터 복잡한 아키텍처를 설계하기보다 단순함을 유지하고 문제가 발생할 때마다 해결해나가는 것이 효과적입니다.

많은 이들이 OpenAI와 같은 최첨단 AI 회사가 특별한 데이터베이스 기술을 사용할 것이라 예상하지만, 놀랍게도 **OpenAI의 핵심 시스템은 30년이 넘은 오픈소스 데이터베이스인 PostgreSQL로 운영**됩니다. 더욱이 샤딩 없이 단일 주 서버와 읽기 복제본만으로 8억 명 이상의 사용자를 지원하며 초당 수백만 건의 쿼리를 처리하는 경이로운 확장성을 보여주고 있습니다.

OpenAI는 Azure의 매니지드 PostgreSQL 서비스를 활용하며, **하나의 주 서버가 모든 쓰기 작업을 담당하고 50개 이상의 읽기 복제본이 읽기 요청을 분산 처리하는 단순한 구조**를 가지고 있습니다. 서비스들은 Kubernetes 환경에서 PgBouncer 커넥션 풀을 통해 데이터베이스에 접근하며 DataDog으로 모니터링합니다.

PostgreSQL 선택과 샤딩 회피 이유

OpenAI가 샤딩을 피하는 주된 이유는 **샤딩이 엄청난 복잡도를 초래하기 때문**입니다. 샤딩은 확장성을 높이지만 조인 쿼리, 트랜잭션 관리, 운영 부담 등에서 복잡성이 증가합니다. OpenAI 엔지니어는 샤딩 없는 아키텍처가 대규모 읽기 부하에서 우아하게 확장될 수 있음을 보여준다고 언급했습니다.

MongoDB나 Cassandra와 같은 NoSQL 대신 PostgreSQL을 선택한 것은 **데이터 정합성이 중요한 서비스에서는 관계형 데이터베이스의 트랜잭션 보장이 필수적**이기 때문입니다. ChatGPT의 대화 기록, 결제 정보, 구독 상태 등은 절대 오류가 발생해서는 안 되는 중요한 데이터이며, PostgreSQL은 이를 안전하게 관리할 수 있습니다. 또한, PostgreSQL은 풍부한 생태계(모니터링 도구, 백업 솔루션, 클라우드 매니지드 서비스)를 갖추고 있어 운영에 이점을 제공합니다.

OpenAI는 **PgBouncer를 활용하여 데이터베이스 커넥션 풀링을 구현**합니다. 데이터베이스 커넥션은 비싼 리소스이므로, 커넥션을 재사용함으로써 오버헤드를 줄입니다. 특히 Kubernetes처럼 서비스가 빈번하게 생성되고 소멸되는 환경에서는 커넥션 풀링이 필수적입니다.

단일 주 서버 구조는 읽기 확장성에는 유리하지만 **모든 쓰기 요청이 단일 서버로 집중되어 쓰기 병목 현상이 발생**하는 치명적인 문제가 있습니다. 실제로 트래픽 급증 시 데이터베이스 성능 저하로 인한 서비스 장애를 겪기도 했습니다. OpenAI는 이 문제를 해결하기 위해 여러 전략을 도입했습니다.

첫째, **불필요한 쓰기를 애플리케이션 레벨에서 제거**하여 꼭 필요한 쓰기만 데이터베이스에 전달합니다. 둘째, 급하지 않은 쓰기는 **지연 쓰기(deferred writes) 방식을 통해 즉시 처리하지 않고 모아서 나중에 처리**하여 순간적인 쓰기 폭주를 평탄화합니다. 셋째, 대량의 데이터를 삽입할 때 **데이터 백필 속도를 제어**하여 한꺼번에 부하가 몰리지 않도록 조절합니다. 이 세 가지 전략으로 쓰기 병목을 상당히 완화할 수 있었습니다.

쓰기 문제 해결 후 OpenAI는 읽기 최적화에 집중했습니다. ChatGPT 트래픽의 대부분이 읽기 요청이기 때문입니다. 핵심 전략은 **요청 우선순위를 구분하고 중요한 요청에 전용 읽기 복제본을 할당**하는 것입니다. 이를 통해 중요한 요청이 다른 트래픽의 영향을 받지 않고 빠르게 처리되도록 합니다.

또한, **쿼리 최적화는 매우 중요**하며, ORM이 생성하는 비효율적인 쿼리를 개선해야 합니다. OpenAI는 12개 테이블을 조인하는 복잡한 쿼리 문제와 느린 쿼리 하나가 전체 시스템에 미치는 영향을 경험하며 세션, 문장, 클라이언트 레벨에서 타임아웃을 설정하여 오래 실행되는 트랜잭션을 방지했습니다.

스키마 변경에 대해서도 엄격한 규칙을 적용합니다. 새로운 테이블이나 워크로드는 PostgreSQL에 추가하는 것을 금지하고, 가벼운 컬럼 작업만 5초 타임아웃으로 허용합니다. **1초 이상 지속되는 쿼리가 있으면 스키마 변경이 실패하도록 막아 대규모 시스템의 안정성을 유지**합니다. 이는 스키마 변경이 전체 서비스에 심각한 영향을 미칠 수 있기 때문입니다.

OpenAI는 두 가지 주요 장애 사례를 통해 교훈을 얻었습니다. 첫째, Redis 캐시 장애 시 평소 캐시에서 처리되던 요청이 데이터베이스로 몰려 연쇄 장애가 발생한 경우입니다. 이는 **캐시와 데이터베이스를 함께 설계하고 캐시 장애 시 데이터베이스가 버틸 수 있도록 대비해야 함**을 시사합니다. 둘째, CPU 사용량이 극도로 높아진 후 walsender 프로세스가 WAL 로그를 복제본에 제대로 보내지 못해 복제 지연이 발생한 버그입니다. 이는 예측하기 어려운 엣지 케이스지만, **모니터링과 빠른 대응의 중요성**을 보여줍니다.

OpenAI는 PostgreSQL 커뮤니티에 사용하지 않는 인덱스를 삭제 전 모니터링하기 위한 **인덱스 비활성화 기능**과 `pg_stat_statement`에 **지연 시간 백분위수(P95, P99) 메트릭**을 추가해 줄 것을 요청했습니다. 또한, PostgreSQL의 MVCC(멀티 버전 동시성 제어) 설계로 인한 테이블 및 인덱스 블로트(부풀어 오름) 현상과 `autovacuum` 튜닝의 어려움, 복제본 증가에 따른 가시성 체크 오버헤드 등도 극복해야 할 과제로 인식했습니다.

OpenAI는 PostgreSQL의 단일 쓰기 서버 한계를 인정하고, **새로운 쓰기 워크로드를 Cosmos DB로 분산시키는 현실적인 타협**을 했습니다. 이는 기존 시스템을 유지하면서 새로운 요구사항을 수용하는 방법이며, 완벽한 아키텍처를 추구하기보다 현실적인 해결책을 찾는 접근 방식입니다.

OpenAI 사례를 통해 얻을 수 있는 주요 교훈은 다음과 같습니다. 첫째, **단순함의 가치**입니다. 복잡한 기술이 항상 답은 아니며, 검증된 단순한 구조로도 엄청난 규모의 확장이 가능합니다. 둘째, **읽기와 쓰기의 명확한 분리**입니다. 대부분의 웹 애플리케이션은 읽기 트래픽이 훨씬 많으므로, 읽기는 복제본으로 확장하고 쓰기는 최대한 줄이는 전략이 효과적입니다.

셋째, **우선순위 기반 리소스 할당**입니다. 모든 요청을 동등하게 취급하기보다, 중요한 요청에 전용 리소스를 할당하고 다단계 속도 제한을 적용하여 리소스 고갈을 방지해야 합니다. 넷째, **장애를 대비한 설계**입니다. 캐시나 복제본 장애 상황을 미리 예측하고 주 서버 장애 시 읽기 전용 요청을 복제본으로 라우팅하는 등의 대책을 마련해야 합니다.

마지막으로, **매니지드 서비스의 적극적인 활용**입니다. OpenAI처럼 대규모 회사도 직접 데이터베이스를 운영하지 않고 Azure의 매니지드 서비스를 사용합니다. 자동 백업, 고가용성, 패치 관리 등 저수준 작업을 클라우드에 맡김으로써 팀은 애플리케이션 레벨의 최적화에 집중할 수 있습니다. 초기 스타트업 역시 인프라를 단순하게 가져가고 매니지드 서비스를 활용하여 핵심 기능 개발에 집중하는 것이 효율적입니다.

OpenAI는 8억 사용자를 샤딩 없이 PostgreSQL 단일 주 서버와 50개 이상의 읽기 복제본으로 지원합니다. 이는 **단순한 구조를 유지하면서 최적화하는 것만으로도 엄청난 규모를 감당할 수 있음**을 보여줍니다. 복잡함은 운영, 개발, 장애 대응 비용을 증가시키므로, 서비스를 만들 때 최대한 단순함을 유지하는 것이 중요합니다.

여러분 서비스에 당장 적용할 수 있는 액션 아이템은 두 가지입니다. 첫째, **데이터베이스에 불필요한 쓰기가 없는지 점검**하여 로그나 매번 업데이트되는 타임스탬프 같은 쓰기를 최적화합니다. 둘째, **느린 쿼리가 있는지 슬로우 쿼리 로그를 통해 확인**하고 최적화합니다. 이 두 가지만으로도 데이터베이스 성능을 크게 개선할 수 있습니다.

많은 사람들이 서비스가 커지면 무조건 복잡한 아키텍처(샤딩, 분산 데이터베이스, 마이크로서비스)가 필요하다고 생각하지만, OpenAI 사례는 그렇지 않음을 보여줍니다. **검증된 기술을 깊이 이해하고 최적화하는 것이 새 기술로 무작정 갈아타는 것보다 더 중요**합니다. 문제가 생기면 그때 해결해도 늦지 않으니, 미리 복잡하게 만들어 발목을 잡히지 않도록 단순함을 유지하는 데 집중해야 합니다.

OpenAI가 8억 명의 사용자를 단일 PostgreSQL로 처리할 수 있었던 핵심 아키텍처는 무엇이며, 샤딩 대신 이러한 방식을 택한 주된 이유는 무엇인가요?

쓰기 병목 현상과 읽기 최적화를 해결하기 위해 OpenAI가 도입한 주요 전략들은 무엇이며, 각 전략의 구체적인 내용은 무엇인가요?

PostgreSQL 사용의 장점으로 언급된 데이터 정합성, 풍부한 생태계 외에, OpenAI가 매니지드 서비스(Azure PostgreSQL)와 PgBouncer를 활용한 이유는 무엇인가요?

OpenAI의 사례에서 얻을 수 있는 주요 교훈 5가지는 무엇이며, 각 교훈이 스타트업이나 개발자에게 시사하는 바는 무엇인가요?

PostgreSQL의 단일 쓰기 서버 한계를 인정하며 OpenAI가 새로운 쓰기 워크로드를 Cosmos DB로 분산시킨 것은 어떤 의미가 있으며, 이는 초기 아키텍처 선택에 어떤 교훈을 주나요?

OpenAI의 ChatGPT 데이터베이스 선택 및 아키텍처

OpenAI는 ChatGPT 8억 명의 사용자를 지원하기 위해 30년 넘은 오픈소스 데이터베이스인 PostgreSQL을 사용한다.

샤딩 없이 단일 주 서버와 읽기 복제본만으로 대규모 트래픽을 감당한다.

핵심 메시지는 단순함을 유지하면서도 엄청난 규모로 확장할 수 있다는 것이다.

OpenAI는 Azure의 매니지드 PostgreSQL 서비스를 사용하며, 하나의 주 서버가 모든 쓰기 작업을 담당하고 수십 개의 읽기 복제본이 읽기 요청을 분산 처리한다.

모니터링은 DataDog을 사용하고, Kubernetes 서비스들은 PgBouncer 커넥션 풀을 통해 데이터베이스에 접근한다.

샤딩 및 NoSQL 대신 PostgreSQL을 선택한 이유

샤딩은 확장성은 좋지만 복잡도가 엄청나게 올라가 조인 쿼리, 트랜잭션 관리, 운영 부담이 커진다.

PostgreSQL은 30년 넘게 검증된 기술로, 데이터 정합성이 중요한 서비스에 필수적인 트랜잭션 보장을 제공한다.

PostgreSQL 생태계가 풍부하여 모니터링 도구, 백업 솔루션, 클라우드 매니지드 서비스 등을 갖추고 있다.

PgBouncer를 사용하여 데이터베이스 커넥션 풀링을 통해 커넥션 재사용 및 오버헤드를 줄인다.

읽기는 복제본을 늘리면 해결되지만, 쓰기는 단일 주 서버로 몰려 병목 현상을 일으킨다.

첫 번째 전략은 애플리케이션 레벨에서 불필요한 쓰기를 제거하는 것이다.

두 번째는 급하지 않은 쓰기를 즉시 처리하지 않고 모아서 나중에 처리하는 지연 쓰기이다.

세 번째는 대량의 데이터 백필 시 속도를 조절하는 것이다.

ChatGPT 트래픽의 대부분은 읽기 요청이므로 읽기 최적화에 집중한다.

요청 우선순위를 구분하여 중요한 요청에 전용 읽기 복제본을 할당한다.

ORM이 생성한 비효율적인 복잡한 쿼리를 최적화하고, 오래 실행되는 트랜잭션을 방지하기 위해 타임아웃을 설정한다.

스키마 변경에 대해 엄격한 규칙을 적용하여 위험을 최소화하고, 가벼운 컬럼 작업만 허용하며 인덱스 생성 시 동시성 옵션을 사용한다.

Redis 캐시 장애 시 요청이 데이터베이스로 몰려 연쇄 장애가 발생, 캐시와 데이터베이스를 함께 설계해야 한다는 교훈을 얻었다.

CPU 사용량 급증 시 walsender 프로세스 버그로 복제 지연이 발생, 모니터링과 빠른 대응의 중요성을 확인했다.

PostgreSQL 커뮤니티 요청 및 MVCC 도전

인덱스 비활성화 기능을 요청하여 사용하지 않는 인덱스를 안전하게 관리하고자 한다.

지연 시간 백분위수 메트릭(P95, P99)을 요청하여 평균 응답 시간 외의 더 상세한 성능 지표를 얻고자 한다.

PostgreSQL의 MVCC(멀티 버전 동시성 제어)는 동시성에는 좋지만 테이블 및 인덱스 블로트를 유발하며 autovacuum 튜닝이 어렵다.

새로운 워크로드 분산 및 현실적 타협

OpenAI는 PostgreSQL의 단일 쓰기 서버 한계를 인정하고 새로운 쓰기 워크로드를 Cosmos DB로 분산시켰다.

기존 시스템을 유지하면서 새로운 요구사항을 수용하는 현실적인 타협점을 찾았다.

단순함의 가치: 검증된 기술과 단순한 아키텍처로 대규모 서비스를 지원한다.

읽기와 쓰기의 분리: 읽기는 복제본으로 확장하고 쓰기는 최대한 줄이는 전략이 효과적이다.

우선순위 기반 리소스 할당: 중요한 요청에 전용 리소스를 할당하고 다단계 속도 제한을 적용한다.

장애를 대비한 설계: 캐시나 복제본 장애 상황을 미리 고려하여 서비스 중단을 최소화한다.

매니지드 서비스의 활용: Azure의 매니지드 서비스를 사용하여 인프라 운영 부담을 줄이고 핵심 기능 개발에 집중한다.

OpenAI는 샤딩 없이 PostgreSQL 단일 주 서버와 50개 이상의 읽기 복제본으로 8억 사용자를 지원한다.

쓰기 병목 해결을 위해 불필요한 쓰기 제거, 지연 쓰기, 백필 속도 제어를 사용한다.

읽기 최적화를 위해 요청 우선순위를 구분하고 전용 복제본을 할당한다.

서비스에서 불필요한 쓰기 점검 및 느린 쿼리 확인을 통해 데이터베이스 성능을 개선할 수 있다.

단순한 구조를 유지하면서 최적화하는 것만으로도 엄청난 규모를 감당할 수 있으며, 복잡함은 운영 비용, 개발 비용, 장애 대응 비용을 증가시킨다.

검증된 기술을 깊이 이해하고 최적화하는 것이 새로운 기술에 매번 갈아타는 것보다 더 중요하다.

서비스를 만들 때 단순함을 최대한 유지하고, 문제가 생길 때 해결해 나가는 점진적인 접근 방식이 효과적이다.

오픈AI가 8억 사용자를 단일 PostgreSQL로 처리하는 비결

스크립트