OpenAI은 10억 명 이상의 ChatGPT 사용자를 지원하기 위해 온라인 저장소 인프라를 확장하고 있으며, 이는 플랫폼 부하와 사용자 생성 데이터의 급격한 증가를 반영한다.

OpenAI 제품은 사용자가 로그인하거나, Codex 설정을 조정하거나, 새로운 ChatGPT 대화를 시작하는 등 데이터에 빠르고 안정적으로 접근해야 합니다. 각 작업은 제품이 응답하기 전에 수십 개의 데이터베이스 조회를 트리거할 수 있습니다. 느린 요청은 제품을 느리게 만들고, 실패한 요청은 완전히 중단시킵니다.

Habitat은 OpenAI 제품에 안정적이고 고속의 데이터 접근을 제공하기 위해 구축된 온라인 저장소 플랫폼입니다. 이 플랫폼은 현재 초당 7천만 개 이상의 요청을 처리하며, 거의 40개의 지리적 지역에서 매주 10억 명 이상의 사용자가 사용하는 제품을 지원합니다. 2년 전 단일 데이터베이스에 연결된 간단한 파이썬 클라이언트 라이브러리로 시작한 것이 이제는 500 페타바이트 이상의 데이터를 제공하는 복잡한 분산 시스템으로 진화했습니다.

이러한 규모의 인프라를 구축하는 것은 일반적인 과제를 제시하지만, OpenAI의 상황은 독특합니다. 이 회사는 지난 3년간 매년 10배 이상 확장하면서 동시에 성숙한 플랫폼을 구축하고 있습니다. 대부분의 시스템 엔지니어는 10배의 성장을 설계하고 수년 동안 이를 유지하기를 희망합니다. Habitat을 운영하려면 일련의 전술적 결정과 순서 조정이 필요했습니다. 기존 스택에서 최대 효율성을 추출하면서 저장소 및 계산 제약을 관리하여 기초적 투자를 위한 시간을 확보해야 했습니다.

Habitat은 서로 다른 단계를 거쳐 진화했습니다. 먼저 핵심 제품 트래픽을 위해 충분히 안정적이 되었고, 그 다음 전 세계 사용자를 위해 충분히 빨라졌으며, 마지막으로 대규모에서 안정적으로 운영되었습니다. 이러한 진행 과정은 Habitat을 라이브러리에서 서비스로 전환해야 했습니다.

처음에 2024년 중반에 Habitat은 ChatGPT의 메인 서버와 인터페이스하는 작은 파이썬 라이브러리였습니다. 기본 데이터베이스 애플리케이션인 Azure Cosmos DB에 매핑된 제한된 작업 집합을 지원했습니다. 이 라이브러리는 스키마 조회, 라우팅, 인증, 암호화, 직렬화, 요청 형성, 연결 풀링을 처리하여 제품 엔지니어를 데이터베이스 관리 세부사항으로부터 보호했습니다. 개발자는 데이터가 Azure Cosmos DB, 캐시 또는 다른 저장소 유형에서 왔는지 알 필요가 없었습니다.

이 라이브러리는 자체 서비스 Postgres 및 Azure Cosmos DB에서 멀어지려는 공식적인 조직적 움직임이 없었음에도 불구하고 빠르게 채택되었습니다. 제품 요구사항이 진화함에 따라 공유 라이브러리는 클라이언트 측 캐싱, 압축, 암호화와 같은 새로운 기능을 쉽게 수용했습니다.

2025년 중반까지 Habitat은 클라이언트 측 모델을 넘어섰습니다. 이 계층이 더욱 복잡해지고 OpenAI의 서비스 수가 증가하면서, 역호환성이 있는 프로토콜 변경은 실행 불가능해졌습니다. 한 가지 예로, OpenAI는 지역 데이터베이스 계정을 지역적으로 분산된 Azure Cosmos DB 계정으로 마이그레이션하여 중요 데이터 세트에서 지역 장애의 영향 범위를 줄이고 싶었습니다. 이를 구현하려면 기능 플래그 뒤의 클라이언트에 라우팅 로직을 도입하고, 수십 개의 서비스 전체에서 롤아웃을 조정해야 했습니다. 이 과정에는 며칠이 걸렸습니다. 추가적인 shadowing 작업, 버그 수정, 재조정은 타임라인을 더욱 연장했습니다. 결국 한 팀이 관련 없는 이유로 서비스를 이전의 버그가 있는 클라이언트 버전으로 롤백했을 때, 조정된 노력이 방지하려고 했던 바로 그 지역 장애를 트리거했습니다.

운영 분산은 클라이언트 라이브러리 변경을 점점 더 취약하고 오류가 발생하기 쉽게 만들었습니다. 이 분산된 복잡성을 줄이기 위해 OpenAI는 Habitat을 중앙 집중식 서비스로 전환했습니다. 이는 배포, 관찰 가능성, 플랫폼 개선을 위한 단일 제어점을 확립했습니다. 분산된 업데이트를 중앙 집중식 개선으로 대체하여 모든 제품에 즉시 이점을 제공했습니다. 이 서비스는 또한 중요한 보안 체크포인트가 되어 접근 제어 정책을 중앙으로 실행하고, 감사 로깅을 수행하며, 기본 저장소 리소스에 대한 접근을 제한하면서 외부, 내부, 에이전트 기반 위협으로부터 사용자 데이터를 보호했습니다.

파이썬 서비스를 규모로 운영하는 것은 고유한 트레이드오프를 제시합니다. 서비스로서 파이썬의 오버헤드는 네트워크 지연 시간을 증가시키고, 로컬 라이브러리 실행과 비교하여 상당한 CPU 및 메모리 확장 비용을 추가합니다. OpenAI는 파이썬의 비효율성이 100배 수요로 확장되지 않을 것이며, 결국 재작성이 불가피하다는 것을 인식했습니다. 그러나 그들은 이를 전략적 기술 부채로 받아들였습니다. 우선순위는 제품 개발자를 차단 해제하고 단기 비용 최적화보다 플랫폼 안정성을 달성하는 것이었습니다. 또한 그들은 자신의 코딩 모델의 빠른 발전이 결국 파이썬에서의 마이그레이션을 단순하게 할 것이라고 예상했습니다. 이는 옳은 것으로 판명되었습니다.

성능 트레이드오프는 피할 수 없었지만, 의미 있는 지연 시간 악화는 수용할 수 없었습니다. 평균 사용자 요청이 수백 개의 데이터베이스 호출을 트리거할 때, 가장 느린 호출이 인식된 속도를 결정합니다. 이 규모로 파이썬을 실행하는 데 있어 중심 과제는 테일 지연 시간을 관리하는 것입니다.

파이썬의 asyncio는 I/O 바운드 동시성을 처리하지만 Global Interpreter Lock을 해결할 수 없으며 CPU 병렬성을 제공할 수 없습니다. I/O 집약적 요청 프록싱을 넘어, Habitat은 CPU 집약적 책임을 처리합니다. 라우팅, 압축, 암호화, 체크섬, 다운스트림 상태 확인, shadowing, 그리고 hedging입니다. 많은 CPU 집약적 워크로드와 백그라운드 작업으로 인해, asyncio 스케줄링 지연이 테일 요청 지연 시간을 쉽게 지배합니다. 초기 추적은 p99 이상의 지연 시간을 가진 요청의 경우, 다운스트림 저장소가 빠르게 응답했지만 요청은 응답을 파싱하기 위해 책임 있는 코루틴이 다시 스케줄되기를 기다리며 자주 정체되었음을 보여주었습니다.