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

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

OpenAI는 10억 명 이상에게 서비스를 제공하는 Habitat의 Azure Cosmos DB 운영을 단일 테넌트 컨테이너 중심에서 개선된 멀티테넌시로 전환해, 워크로드 격리와 용량 계획 부담 완화를 함께 달성했다고 설명한다.

📌 핵심 요약

• Habitat은 OpenAI 제품의 온라인 스토리지 플랫폼으로, 40개 지리적 리전에 걸친 10억 명 이상의 사용자에게 밀리초 단위로 응답해야 하며 500페타바이트가 넘는 데이터를 제공한다.
• 초기 공유 Azure Cosmos DB 컨테이너에서는 제품별 논리 파티션 키 충돌, 물리 파티션을 공유하는 시끄러운 이웃, 데이터 증가에 따른 파티션별 처리량 감소가 신뢰성을 저해했다.
• 중요한 워크로드를 별도 컨테이너로 분리하고 파티션 수에 맞춰 처리량을 조정하면서 장애 영향 범위를 줄였지만, 출시 시 급증하는 부하에 대비한 용량 계획이 각 제품 팀의 부담으로 확대됐다.
• OpenAI는 Azure 팀과 협력해 핫 키 우선 제한, 요청 우선순위에 따른 QoS, 물리 파티션당 최대 10K RU/s와 RU 사용량 기반 분할을 지원하는 개선된 서버리스 모드를 적용하고 공유 컨테이너를 기본으로 사용하는 방향으로 돌아갔다.
• 이 변경으로 제품 팀의 사전·지속적 용량 계획 부담을 크게 줄이면서 워크로드 격리를 유지했으며, 제품 개발이 빨라지는 상황에서도 이후 수개월 동안 프로비저닝이나 시끄러운 이웃 관련 사고가 없었다고 보고한다.

🧩 주요 포인트

1. 공유 컨테이너의 논리 파티션 키와 물리 파티션 제약 → 테넌트별 사용량뿐 아니라 실제 자원 공유 단위까지 고려해야 신뢰성을 확보할 수 있다.
2. 별도 컨테이너를 통한 워크로드 격리 → 장애 영향 범위는 줄지만 부하를 합산하는 이점이 사라지고 제품 팀별 용량 계획 부담이 커진다.
3. 핫 키 제한·QoS·개선된 서버리스 모드를 결합한 멀티테넌시 → 공유 자원의 효율과 워크로드 격리를 함께 확보하면서 수동 처리량 조정 필요성을 줄인다.

🧠 상세 정리

1. Habitat의 규모와 이번 글의 범위

Habitat은 모든 OpenAI 제품이 필요한 데이터에 빠르고 안정적으로 접근하도록 만든 온라인 스토리지 플랫폼으로, 40개 지리적 리전에 걸친 10억 명 이상의 사용자에게 밀리초 단위로 응답해야 한다. 폭발적인 성장과 새로운 사용 사례를 지원하면서 신뢰성, 성능, 제품 개발 속도까지 개선해야 했기 때문에 플랫폼의 설계와 운영 방식을 재검토했다. 원문은 핵심 제품 트래픽을 감당할 신뢰성, 전 세계 사용자를 위한 속도, 대규모 운영 역량의 순서로 문제를 풀었다고 설명한다. 두 편으로 구성된 시리즈는 단순한 클라이언트 라이브러리와 데이터베이스가 500페타바이트 이상의 데이터를 제공하는 플랫폼으로 발전한 과정을 다룬다. Part I이 Python 클라이언트의 서비스 전환과 성능 확장에 집중했다면, Part II는 Azure 팀과의 협력을 통해 기반 스토리지인 Azure Cosmos DB를 확장한 과정을 설명한다.

2. 멀티테넌시의 이점과 Azure Cosmos DB의 기본 구조

싱글테넌시는 각 제품 팀이 자체 시스템을 유지하므로 소유권과 워크로드 격리가 명확하고 장애 영향 범위를 줄이기 쉽지만, 팀과 제품이 늘수록 운영비와 과잉 프로비저닝 문제가 커진다. 멀티테넌시는 자원 할당 경험이 있는 중앙 데이터베이스 팀에 제어를 모을 수 있는 대신, 한 테넌트가 자원을 과도하게 사용해 다른 테넌트에 영향을 주는 시끄러운 이웃 문제가 생긴다. Habitat은 하나의 공유 컨테이너에서 전용 컨테이너로 이동했다가 다시 공유 컨테이너를 기본으로 삼는 순환적인 경로를 거쳤으며, 가능한 한 Azure Cosmos DB의 기본 기능을 활용했다. Azure Cosmos DB 계정은 컨테이너 집합과 복제 정책을 정의하고, 각 컨테이너에는 초당 요청 단위인 RU/s로 처리량을 할당한다. 데이터는 지정된 논리 파티션 키에 따라 나뉘고 여러 논리 파티션이 물리 파티션을 공유하며, 저장량이나 필요한 처리량에 따라 물리 파티션이 분할된다.

3. 1단계: 논리 파티션 키 제한에 의존한 설계

초기 Habitat은 계정마다 기본 Azure Cosmos DB 컨테이너 하나를 사용하고, 논리 파티션 키당 명시된 10K RU/s 제한이 과도한 부하를 억제할 것으로 기대해 클라이언트 부하를 별도로 제한하지 않았다. 그러나 초기 API가 논리 파티션 키 선택을 클라이언트에 직접 노출하면서, 서로 다른 제품 사용 사례에서 user_id나 workspace_id 같은 흔한 키가 반복적으로 충돌했다. 이들 사용 사례가 같은 논리 파티션 키의 제한을 공유했기 때문에 특정 사용자가 이용할 수 있는 전체 처리량이 제약됐다. 원문은 Habitat과 Azure Cosmos DB로 이전하기 전 Postgres에서도 매우 활발한 조직이나 핫 키의 요청이 데이터베이스 전체를 마비시키는 문제를 겪었다고 회고한다. 당시에는 해당 키를 캐싱하고 캐시 미스 처리에 리스를 도입해 원본 데이터베이스로 부하가 몰리는 것을 막는 데 상당한 공동 노력이 필요했다.

4. 물리 파티션에서 드러난 시끄러운 이웃과 처리량 약화

문서상 저장량과 처리량 제한은 논리 파티션 키에 적용되지만, 실제 제한 집행 지점은 물리 파티션이므로 함께 배치된 논리 파티션들은 같은 자원 한도를 나눠 쓴다. 따라서 각 논리 파티션이 독립적으로 10,000 RU/s를 확보할 수 있는 것은 아니며, 일부 특수한 제품 기능의 부하가 핵심 로그인과 가입 흐름까지 방해할 수 있었다. 또 컨테이너에 할당한 전체 처리량은 물리 파티션들에 대체로 균등하게 배분되므로, 물리 파티션별 한도는 고정되어 있지 않다. 저장량 증가로 파티션이 분할돼도 전체 프로비저닝 처리량이 그대로라면 파티션 수가 늘어날수록 각 파티션의 처리량 한도가 줄어든다. 특히 저장 공간을 많이 쓰는 블롭과 유사한 사용 사례에서는 요청률과 이용량이 안정적이어도 데이터 증가만으로 활성 워크로드의 처리 여력이 줄어드는 실패 양상이 나타났다.

5. 2단계: 전용 컨테이너로 격리하고 장애 범위 축소

별도 컨테이너를 사용하면 독립적인 물리 파티션을 할당할 수 있어 논리 파티션 키 충돌과 시끄러운 이웃의 영향을 해당 컨테이너 내부로 제한할 수 있다. 다만 컨테이너마다 용량 계획이 필요하므로 OpenAI는 처음에는 강한 격리가 필요한 중요한 신규 사용 사례를 중심으로 분리했다. 여기에 물리 파티션 수에 맞춰 컨테이너의 전체 프로비저닝 처리량을 조정하는 스크립트를 결합해 기존 문제 대부분을 피할 수 있었다. 그러나 기존의 중요한 사용 사례 상당수는 데이터 마이그레이션 없이는 기본 공유 컨테이너에서 옮길 수 없었고, 그 컨테이너의 부하와 운영 사고는 계속 증가했다. 결국 신규 서비스나 대규모 제품 기능을 폭넓게 별도 컨테이너에 배치해 많은 사이트 전체 장애를 기능 또는 서비스 단위의 성능 저하로 제한했지만, 컨테이너별 운영 부담이 점차 누적됐다.

6. 격리의 대가: 출시 급증과 분산된 용량 계획

큰 공유 컨테이너에서는 개별 사용 사례가 0 QPS에서 100만 QPS로 성장해도 전체 합산 사용량에 미치는 변화가 상대적으로 작을 수 있지만, 전용 컨테이너에서는 같은 증가가 내부 시험 기준 부하의 1,000배에 이를 수 있다. 원문의 도해도 부하 테스트 시 1K RU/s였던 요구량이 출시 때 1M RU/s로 바뀌는 상황을 제시한다. 제품 팀이 출시 전에 예상 처리량을 확보해야 했지만 이를 놓치는 경우가 있었고, 출시 당일 심각한 장애 대응 과정에서 컨테이너를 급히 확장하게 됐다. 성장 추세를 기반으로 처리량을 높이는 기본 제어 스크립트만으로는 트래픽 변화 시점을 정확히 반영하기 어려워 제품별 상세 지식이 필요했다. 그 결과 사실상 모든 제품 팀이 용량 계획에 관여하게 됐고, 팀마다 프로비저닝에 들이는 주의 수준이 달라 조직 규모가 커질수록 이 운영 방식의 한계가 드러났다.

7. 3단계: 핫 키 제한과 QoS로 공유 자원 보호

조직이 커지면서 중앙 팀이 일관되게 용량 계획을 맡지 않는 방식의 문제가 두드러졌고, OpenAI는 Azure 팀과 함께 초기 멀티테넌시의 결함을 보완하는 방향으로 전환했다. 첫 번째 장치는 가장 뜨거운 키를 먼저 제한해 특정 핫 키가 물리 파티션의 가용 처리량을 모두 소비하지 못하게 하는 방식이다. 이는 하나의 핫 키에서 발생한 과부하가 시끄러운 이웃 효과를 통해 사이트 전체로 번지는 위험을 줄인다. 두 번째 장치는 요청을 계층화하는 QoS로, 대량 삽입이나 데이터 추출 같은 오프라인 워크로드의 요청에 낮은 우선순위를 부여한다. 자원이 부족할 때 이들 요청을 먼저 제한함으로써 최종 사용자에게 서비스를 제공하는 높은 우선순위의 대화형 요청을 보호하며, 공유 자원 안에서 워크로드 간 간섭을 제어하는 기반을 마련했다.

8. 개선된 서버리스 모드와 공유 컨테이너 복귀의 결과

기존 Azure Cosmos DB 서버리스 모드는 프로비저닝 방식에서 발생한 파티션별 처리량 약화 문제를 해결할 수 있었지만, 저장량만을 기준으로 확장하고 물리 파티션당 RU 사용량을 5K RU/s로 제한했다. 따라서 요청 단위 소모가 큰 사용 사례까지 확장하기에는 제약이 있었고, Azure Cosmos DB 팀은 OpenAI를 위해 개선된 서버리스 모드를 개발했다. 새 모드는 물리 파티션당 최대 10K RU/s를 지원하고 저장량뿐 아니라 RU 사용량에 따른 분할을 추가해, 컨테이너를 수동으로 모니터링하고 확장할 필요를 없앴다. 이러한 변경을 결합한 뒤 OpenAI는 하나의 공유 컨테이너를 사용하는 방향으로 돌아가 제품 팀의 사전·지속적 용량 계획 부담을 크게 줄이면서 워크로드 격리를 유지했다고 설명한다. 제품 개발이 가속되는 가운데 이후 수개월 동안 프로비저닝이나 시끄러운 이웃 관련 사고가 없었다고 보고하지만, 이는 해당 관찰 기간의 결과다. 이어지는 공동 관리 서비스의 신뢰성 논의는 제공된 원문이 문장 중간에서 끝나므로 구체적인 후속 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 테넌트별 논리적 분리만으로는 충분하지 않았다. 실제 처리량을 집행하는 물리 파티션을 공유한다는 점이 서로 무관한 제품 흐름 사이의 장애 전파를 설명한다.
• 전용 컨테이너는 기술적 격리를 강화했지만, 부하를 합산해 변동을 완화하는 효과를 잃으면서 제품 팀의 출시 준비와 용량 계획에 대한 의존도를 높였다.
• 공유 컨테이너로의 복귀는 초기 설계의 단순한 반복이 아니라 핫 키 제한, 요청 우선순위, 사용량 기반 분할을 추가한 결과다. 이후 수개월의 무사고 관찰은 개선 효과를 뒷받침하지만 장기적인 무사고를 보장하지는 않는다.

✅ 액션 아이템

• 공유 컨테이너 운영에서 논리 파티션 키 충돌과 물리 파티션 자원 공유가 신뢰성에 미치는 영향을 함께 검토.
• 별도 컨테이너 도입 시 워크로드 격리의 이점과 제품 팀별 용량 계획 부담을 함께 평가.
• 멀티테넌시 적용 시 핫 키 제한·QoS·개선된 서버리스 모드의 결합이 워크로드 격리와 수동 처리량 조정에 미치는 효과를 확인.

❓ 열린 질문

• 공유 컨테이너를 기본으로 사용하는 환경에서도 별도 컨테이너가 필요한 워크로드 격리 조건은 무엇인가?
• 핫 키 제한과 QoS는 물리 파티션의 처리량이 부족할 때 높은 우선순위의 요청을 어느 수준까지 보호할 수 있는가?
• 제품 개발과 부하가 계속 증가할 때도 수개월 동안 관찰된 프로비저닝·시끄러운 이웃 관련 무사고 상태가 유지될 수 있는가?