OpenAI, 10억 명 규모에 맞춰 Habitat 저장소 재설계

ChatGPT 규모의 Habitat 저장소

OpenAI의 10월 23일 기술 글은 온라인 저장 플랫폼 Habitat의 설계를 다룬 연재 두 번째 편이다. 회사는 이 플랫폼이 40개 지역에서 10억 명 이상의 사용자를 지원하고 전체적으로 500페타바이트 이상의 데이터를 관리한다고 설명한다. 이 수치는 OpenAI의 자체 시스템에 대한 발표이지 이 매체가 독립적으로 측정한 결과가 아니다. 첫 번째 편은 Python 클라이언트 라이브러리에서 서비스로 발전한 과정을, 두 번째 편은 Azure Cosmos DB를 이용한 저장 설계와 대규모 운영 문제를 다룬다.

핵심은 공유 방식과 분리 방식 중 하나로 계속 이동한 것이 아니라 여러 번 선택을 바꿨다는 점이다. Habitat는 먼저 공유 Cosmos DB 컨테이너를 썼고 다른 업무의 간섭을 줄이기 위해 일부 전용 컨테이너를 마련했다. 나중에는 Azure와 공동으로 문제를 개선해 공유를 다시 기본 방식으로 삼았다. 전용 컨테이너는 부하를 분리하는 장점이 있었지만 각 제품 팀이 출시 전 필요한 용량을 예측해야 했다. 새 서비스가 시험 트래픽에서 초당 100만 쿼리로 커질 때 사전 확장을 놓치면 출시일의 긴급 대응으로 이어질 수 있었다고 회사는 설명한다.

공유 설계가 다시 기본값이 된 이유

OpenAI에 따르면 수정된 설계는 사용량이 특히 큰 파티션 키를 먼저 제한해 한 업무가 물리적 파티션의 처리 능력을 모두 차지하기 어렵게 한다. 개선된 Azure Cosmos DB 서버리스 모드는 물리적 파티션 하나에서 초당 1만 요청 단위까지 확장하고 저장 용량뿐 아니라 요청 단위 사용량에 따라서도 파티션을 분할한다. 요청 단위는 데이터베이스 작업의 자원 소모량이며 사용자 요청 수와 같은 단위가 아니다. 따라서 초당 1만이라는 수치를 앱의 응답 속도나 요청 처리 건수로 바꾸어 말할 수 없다.

글은 최대 Cosmos DB 계정이 수십 페타바이트를 저장하고 초당 2천만 건 이상의 쿼리를 처리한다고 밝힌다. 2024년 말 지역 정전 뒤에는 가장 큰 계정을 다른 지역으로 전환하는 데 몇 시간이 필요한 사실이 드러났다고 한다. 공급업체가 관리하는 서비스라도 이처럼 예외적인 규모에서는 실제 자료와 트래픽으로 함께 복구 절차를 시험해야 한다. 일반적인 문서의 장애 전환 목표를 그대로 적용할 수 없다.

OpenAI는 세계 전체 읽기 지연의 중앙값이 약 120밀리초에서 10밀리초로 낮아져 12배 개선됐다고 보고했다. 특정 기간과 부하에서 얻은 회사 측정값이며 다른 기업이 같은 저장소를 쓰면 12배 빨라진다는 뜻이 아니다. 중앙값뿐 아니라 느린 요청, 쓰기 부담, 캐시와 장애 상황을 함께 살펴야 한다. 전체 플랫폼의 500페타바이트와 최대 계정의 수십 페타바이트도 서로 다른 수준의 숫자다.

다른 팀이 검증할 사항

작은 서비스는 모든 사용자를 무조건 공유하거나 분리해야 한다는 구호 대신 각 업무의 처리량, 파티션 키의 집중, 저장 증가와 허용 가능한 장애 시간을 비교해야 한다. 신제품 출시 때의 급증과 지역 장애 전환을 연습하고 누가 용량을 늘리고 과도한 사용자를 제한할지 정해야 한다. 공유 방식이 다른 사용자를 보호하는 동안 제한된 사용자에게 어떤 지연이 생기는지도 측정해야 한다.

이 글은 10월 26일 발행됐으며 10월 23일 원문에 나온 설계와 한계를 설명한다. OpenAI 내부 텔레메트리나 Azure의 비공개 계약에 접근했거나 성능 수치를 별도로 재현했다고 주장하지 않는다.

공유 방식으로 돌아간 결정에는 OpenAI의 조직 구조도 영향을 줬다. 수많은 제품 팀, 빠른 출시 주기, Azure와 직접 협의하는 통로가 다른 기업과 같지 않을 수 있다. 같은 관측, 제한 및 공동 장애 대응 능력이 없는 팀이 최종 설계만 모방하면 초기의 핫 키 문제가 다시 나타날 수 있다. 자신의 업무에서는 특별히 민감한 사용자를 분리해야 하는지도 검토해야 한다. 중요한 것은 대기업의 결론을 그대로 복사하는 일이 아니라 문제를 발견하고 책임 있게 복구할 능력을 확보하는 일이다.