Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)

OpenAI 엔지니어링 글의 앞부분(소개, Habitat 개요, Cosmos DB 입문, 1단계의 문제)을 기준으로 옮겼어요. 2단계 이후와 결론은 읽지 못했어요.

Habitat이 뭔가요

OpenAI의 모든 제품은 저장 플랫폼 Habitat으로 데이터에 접근해요. 40개 지역의 10억 명 넘는 사용자에게 밀리초 단위로 응답해야 하고, 지금은 500PB 넘는 데이터를 다뤄요. ChatGPT, API, Codex, 내부 서비스가 클라이언트이고, Habitat은 캐싱, ACL, 데이터 상주지 배치, 암호화, 다중 테넌시 격리, 속도 제한, 라우팅을 맡아요. 뒤에는 Azure Cosmos DB, Nanobase, Valkey 캐시, Blob 저장소가 있고 변경 데이터 캡처(CDC)로 Databricks, Rockset, Kafka 등에 흘려요.

원칙은 먼저 핵심 트래픽에 충분히 믿을 만하게, 다음 전 세계 사용자에게 충분히 빠르게, 마지막으로 거대한 규모에서 능숙하게 운영하는 거예요. 1부는 Python 클라이언트가 서비스로 바뀐 과정, 2부는 하부 저장소 Azure Cosmos DB 확장 이야기예요. Azure 팀과 긴밀히 협력해 공동 관리 컨테이너 방식의 다중 테넌시에 이르렀대요.

단일 테넌트 vs 다중 테넌트

• 단일 테넌트는 피해 범위가 작고 소유 경계가 분명하지만, 팀마다 용량을 계획해야 해서 과잉 프로비저닝이 흔하고 비싸요.
• 다중 테넌트는 중앙 DB 팀이 관리하지만 한 테넌트가 자원을 독차지하는 시끄러운 이웃 문제가 생겨요.

Habitat은 다중 테넌트 컨테이너 하나 → 단일 테넌트 컨테이너 → 다시 기본 다중 테넌트로 한 바퀴 돌았대요.

Cosmos DB 기초

계정은 컨테이너와 복제 정책을 정하고, 컨테이너마다 처리량(RU/s)을 할당해요. 데이터는 논리 파티션 키로 샤딩되고, Cosmos DB가 이를 더 적은 물리 파티션에 나눠 담다가 저장량이나 처리량이 넘으면 쪼개요.

1단계에서 생긴 문제

처음엔 논리 파티션 키당 10K RU/s 한도를 역압으로 믿고 계정마다 기본 컨테이너 하나만 썼어요.

• 파티션 키 충돌: 초기 API가 키 선택을 클라이언트에 맡겨 user_id, workspace_id 같은 키가 여러 제품에서 겹쳤고, 한 사용자의 전체 처리량이 묶였어요. Postgres 시절에도 뜨거운 키 하나가 DB 전체를 쓰러뜨리는 문제로 캐시와 리스를 많이 만들었대요.
• 시끄러운 이웃: 한도는 사실 물리 파티션에서 걸려서, 같은 물리 파티션의 키들이 한도를 나눠 써요. 틈새 기능 작업이 로그인·가입 흐름까지 방해했대요.
• 약한 파티션: 물리 파티션의 처리량은 컨테이너 전체 처리량을 고르게 나눈 값이라, 데이터가 늘어 파티션이 쪼개질수록 달라져요.