OpenAI scales storage infrastructure to support over 1 billion ChatGPT users

모든 OpenAI 제품은 누군가 로그인하거나, Codex 설정을 확인하거나, ChatGPT에서 새 대화를 시작하든 빠르고 안정적인 데이터 접근에 의존합니다. 이러한 각 작업은 제품이 응답하기 전에 많은 개별 데이터 조회를 필요로 할 수 있습니다. 해당 요청들이 느려지면 제품이 느려 보이고, 해당 요청들이 실패하면 제품이 완전히 작동을 멈춥니다.

Habitat은 OpenAI 제품들이 필요한 정보에 빠르고 안정적으로 접근할 수 있도록 우리가 구축한 온라인 저장소 플랫폼입니다. Habitat은 현재 초당 7천만 건 이상의 요청을 처리하고 있으며, 전 세계 거의 40개 지역에 걸쳐 주당 10억 명 이상이 사용하는 제품들을 지원합니다. Habitat은 2023년 DevDay에서 GPT들을 지원하기 위해 처음 출시되었으며, 클라이언트 측의 간단한 Python 라이브러리로 단일 데이터베이스에 연결되어 있었습니다. 오늘날 이는 500 페타바이트 이상의 데이터를 제공하는 복잡한 분산 시스템입니다.

이러한 규모의 인프라를 구축하고 운영하는 것은 쉽지 않지만, 특별히 어려운 것도 아닙니다. 우리의 상황을 독특하게 만든 것은 성숙한 플랫폼을 구축하면서 엄청난 사용자 성장과 제품 수요를 지원하기 위해 전례 없는 속도로 확장해야 했다는 것입니다. 종종 시스템 엔지니어들은 10배 더 큰 규모를 대비하여 구축하고 몇 년 동안 서비스하면서 10배 성장을 준비합니다. 우리의 경우, 지난 3년 동안 매년 10배 이상 성장했습니다. 따라서 Habitat을 구축하고 운영하는 것은 일련의 전술적 결정과 순서 정하기였습니다. 우리는 각 구성 요소를 가장 낮은 수준까지 이해하여 기존 스택에서 최대한의 이점을 얻으면서도, 저장소와 계산 용량 부족을 피하여 근본적인 투자를 위한 시간을 확보했습니다.

OpenAI가 성장하면서 Habitat도 함께 성장해야 했습니다. 먼저 중요한 제품 트래픽에 충분히 안정적이 되었고, 그 다음 전 세계 사용자를 위해 빠르게 되었으며, 마지막으로 엄청난 규모에서 능숙하게 운영할 수 있게 되었습니다. 이 출판물은 온라인 저장소를 확장하는 방법에 대한 2부작 시리즈의 첫 번째입니다. 여기서 Habitat이 어떻게 발전했는지, 왜 라이브러리에서 서비스로 변환했는지, 그리고 서빙 스택에서 흔하지 않은 언어인 Python으로 작성된 서비스를 어떻게 확장하여 안정적인 저장소 플랫폼 계층이 되도록 했는지 공유하겠습니다.

향후 출판물에서는 대규모 멀티 테넌트 안정성을 어떻게 달성했는지, 읽기 최적화를 위한 계층화된 전략, 그리고 Azure Cosmos DB와의 파트너십을 어떻게 확장하여 전례 없는 수요를 안정적으로 충족했는지 자세히 설명하겠습니다.

Habitat은 간단한 아이디어로 시작했습니다. 제품 엔지니어들은 데이터베이스 관리에 대해 생각할 필요가 없어야 한다는 것입니다. Habitat은 2023년 DevDay에서 GPT들을 지원하기 위해 ChatGPT의 주 서버와 통신하는 작은 Python 라이브러리로 처음 출시되었습니다. 이는 Azure Cosmos DB의 데이터베이스 애플리케이션 작업에 내부적으로 매핑되는 작은 작업 집합을 지원했습니다.

라이브러리의 역할은 제품 팀들이 기본 세부 사항을 배울 필요 없이 데이터를 저장하고 검색하는 간단한 방법을 제공하는 것이었습니다. Habitat은 필요한 작업을 처리했습니다. 어떤 종류의 데이터가 포함되었는지 판단하고, 데이터가 어디에서 와야 하거나 어디로 가야 하는지 결정하고, 요청이 허가되었는지 여부를 확인하고 등등의 작업들입니다.

제품 엔지니어들은 스키마 조회, 라우팅, 권한 부여, 암호화, 직렬화, 요청 서명 및 연결 풀링에 대해 걱정할 필요가 없었습니다. 또한 데이터가 어디에서 왔는지에 대해 생각할 필요도 없었습니다. Azure Cosmos DB, 캐시 또는 다른 저장소 유형 말입니다.

저장소 논리를 독립적인 서비스로 분리함으로써 우리는 배포, 관찰성 및 플랫폼 개선을 위한 단일 제어점을 만들었습니다.

이 Python 라이브러리는 잘 작동했으며, Postgres 및 Azure Cosmos DB의 자체 서비스 사용을 장려하기 위한 중앙화된 계획이 없었음에도 불구하고 Habitat은 OpenAI의 제품 엔지니어들에게 빠르게 채택되었습니다.

제품 요구 사항이 진화하면서, 개발자들이 클라이언트측 캐싱, 압축 또는 암호화와 같은 기능에 대한 공유 라이브러리의 지원을 추가하는 것도 쉬웠습니다.

2025년 중반까지 Habitat은 클라이언트측 라이브러리로서의 구현의 한계에 도달했습니다. Habitat 계층이 더욱 복잡해지고 OpenAI 서비스의 수가 증가하면서, 프로토콜에 대한 하위 호환성 있는 변경은 더 이상 가능하지 않았습니다.

한 사례에서 우리는 지역 재해의 영향을 가장 중요한 데이터 세트에 미치도록 줄이기 위해 이들을 지역 분산된 Azure Cosmos DB 계정 그룹으로 마이그레이션하고 싶었습니다. 이 변경은 클라이언트에 추가 라우팅 논리가 필요했으며, 기능 플래그 뒤에 비활성화되어 있었고, 모든 클라이언트에 롤아웃한 후 기능 플래그를 활성화해야 했습니다.

수십 개의 서비스 간 배포를 조율하고 각 팀과 협력하여 롤아웃하는 데 몇 주가 걸렸습니다. 활성화하기 전에 우리는 샤딩 논리가 올바른지 확인하기 위해 섀도잉을 도입해야 한다는 것을 깨달았습니다. 그러기 위해 2일이 더 필요했습니다. 우리가 부러져 있는 것을 깨닫고 있던 무언가의 버그에 대한 해결책? 2일이 더 필요했습니다. 결국 우리는 플래그를 활성화할 준비가 되었지만, 그들의 팀 중 하나가 클라이언트 문제와 관련 없는 이유로 이전 버그로 인해 서비스를 롤백했고, 이는 우리가 그렇게 열심히 방지하려고 했던 서비스에서 정확히 같은 정전을 야기했습니다.

클라이언트 라이브러리의 변경은 수십 개의 서비스 간 복잡한 조율을 필요로 했으며, 이 프로세스는 점점 더 취약해지고, 비효율적이 되고, 운영상의 실패에 취약해졌습니다. 향후 배포에서 이러한 운영 부담을 줄이기 위해 우리는 Habitat을 자체 서비스로 분리하기로 결정했습니다.

저장소 논리를 독립적인 서비스로 분리함으로써 우리는 배포, 관찰성 및 플랫폼 개선을 위한 단일 제어점을 만들었습니다. 단편화된 업데이트를 관리하는 대신, 우리는 개선 사항을 중앙에서 구현하고 모든 OpenAI 제품에 즉시 이점을 제공할 수 있었습니다.

중앙화된 서비스는 또한 데이터 보안과 개인정보 보호를 위한 가장 강력한 요소를 제공하는 단일 병목 지점을 제공합니다. Habitat 서비스에서 우리는 접근 제어 정책, 감사 로그를 중앙에서 시행할 수 있으며, Azure Cosmos DB와 같은 기본 저장소 리소스에 대한 접근을 제한할 수 있습니다. Habitat은 사용자 데이터를 보호하고 외부 행위자, 내부 위협 및 에이전트로부터의 무단 접근을 방지하는 데 중요한 역할을 합니다.

우리는 서비스가 필요하다는 것을 알았지만, 현재로서는 추가 비용이 들지만 Python을 떠나고 싶지 않았습니다. 고처리량 서비스로 Python을 사용하는 것은 라이브러리를 로컬에서 실행하는 것에 비해 네트워크 지연과 CPU 및 메모리 확장 비용을 증가시켰습니다. 더욱이, 우리는 Python의 비효율성이 100배 규모에서는 용납될 수 없을 것이라는 것을 이해했으므로 재작성이 거의 확실해 보였습니다.

그러나 우리는 이를 전략적으로 수용된 기술 부채로 보았습니다. 당시 우리의 주요 목표는 비용이나 리소스를 최적화하는 것이 아니라 제품 개발자들이 앞으로 나아가고 플랫폼의 안정성을 달성하도록 하는 것이었습니다. Python 서비스의 성능 절충을 일시적으로 수용함으로써, 우리는 보다 긴급한 문제들에 우선순위를 두고, 핵심 API를 확립하고, 강력한 인프라를 구축할 수 있었습니다.

또한 우리는 우리의 코드 모델의 빠른 진전이 기술적 경로를 단순화할 것이라는 계산된 내기를 했습니다. 우리는 Python에서의 완전한 마이그레이션이 필요해지면, Codex와 GPT가 이를 가능하게 할 것이라고 믿었습니다. 결국 그 내기는 맞았습니다.

Python 서비스로 Habitat을 실행하는 것은 성능에는 이상적이지 않았지만, 필요한 선택이었습니다. Python은 우리가 빠르게 움직일 수 있게 했지만, 그것이 위험을 무시하고 훨씬 더 나쁜 지연을 수용할 수 있다는 의미는 아닙니다. 평균 사용자 요청이 수백 개의 데이터베이스 호출로 이어질 때, 가장 느린 데이터베이스 호출이 사용자가 느낄 수 있는 것입니다. 우리는 이 규모에서 Python 서비스를 실행하는 데 있어 주요 과제가 극단적인 지연을 관리하는 것임을 발견했습니다.

Asyncio는 Python이 I/O 바운드 워크로드를 동시에 실행하도록 도와주지만, Python의 GIL을 극복하지 못하고 CPU 병렬화를 제공하지 않습니다. 많은 요청을 프록시하는 것 이상으로...