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가 8억 사용자를 단일 PostgreSQL로 처리하는 비결

Scripts