OpenAI가 10억 명 이상의 ChatGPT 사용자를 지원하는 온라인 저장소 플랫폼 'Habitat(하비타트)'의 기술 구조를 공개했다. 마이크로소프트의 Azure Cosmos DB를 기반으로 구축한 이 플랫폼이 500 페타바이트(PB) 이상의 데이터를 40개 지역에서 밀리초 단위의 응답 시간으로 처리하는 방식을 설명한 기술 문서(Part II)다.

OpenAI는 기술 블로그를 통해 "모든 OpenAI 제품이 빠르고 신뢰할 수 있는 데이터 접근을 필요로 하며, Habitat이 이를 제공한다"며 "폭발적 성장과 새로운 사용 사례를 지원하면서 동시에 신뢰성, 성능, 개발자 속도를 개선해야 하는 도전에 직면했다"고 밝혔다.

다중 테넌시와 성능의 갈등

Habitat의 핵심은 다중 테넌시(multi-tenancy) 구조다. 초기에 OpenAI는 단일 테넌시 방식(각 팀이 자체 시스템 운영)을 썼으나, 제품 팀과 서비스가 급증하면서 인프라 비용이 치솟았다. 다중 테넌시로 전환하면 중앙화된 데이터베이스 팀이 리소스를 효율적으로 프로비저닝할 수 있지만, '노이지 네이버(noisy neighbor)' 문제가 발생한다. 한 테넌트가 과도한 리소스를 소비하면 다른 테넌트의 성능이 급락하는 것이다.

OpenAI가 경험한 구체적 문제들:

1. 논리적 파티션 키 충돌: API 초기 설계로 클라이언트가 직접 파티션 키(user_id, workspace_id 등)를 선택하게 되면서 자주 충돌이 발생했다. 서로 다른 제품이 같은 사용자나 워크스페이스를 참조하면, Azure Cosmos DB의 파티션 키당 10,000 요청 단위(RU/s) 제한에 공동 영향을 받는다.

2. 물리 파티션의 숨은 제약: 논리적 파티션이 10,000 RU/s를 제약받는다고 하지만, 실제로는 같은 물리 파티션에 공존하는 모든 논리 파티션이 그 한계를 나눠 가진다. 결과적으로 주요 로그인·회원가입 기능이 소수의 niche 기능 워클로드에 의해 영향을 받을 수 있다.

3. 약한 파티션 함정: 물리 파티션의 처리량 한계는 가변적이다. 데이터 크기가 증가하면 물리 파티션이 분할되고, 파티션 수는 늘어나지만 전체 프로비저닝된 처리량은 유지되므로, 파티션당 실효 처리량이 감소한다. 대용량 blob 같은 저장소 집약적 워클로드에서 저장소 성장만으로도 활성 워클로드의 처리량이 줄어드는 악순환이 벌어진다.

해결책의 진화

OpenAI는 단일 테넌시 방식 전환으로 이 문제들을 부분 해결했다. 각 사용 사례마다 별도의 Cosmos DB 컨테이너를 할당하면, 각각 독립적인 물리 파티션을 가지므로 이웃 노이즈로부터 격리되고 파티션 키 충돌도 줄어든다. 동시에 약한 파티션 문제에 대응하기 위해 프로비저닝된 처리량과 물리 파티션 수를 동기화하는 자동화 스크립트도 도입했다.

다만 원래 기본 컨테이너에 저장된 레거시 서비스는 마이그레이션 없이 남겨져 있어, 이들 서비스 보호를 위해 여전히 별도의 격리 전략이 필요한 상태다.

산업적 의미와 교훈

OpenAI의 이 사례는 대규모 SaaS 플랫폼이 다중 테넌시 수용으로 간 뒤, 성능 저하 문제에 마주칠 수밖에 없다는 업계 통념을 보여준다. 기존 관계형 데이터베이스 기반 Postgres에서 캐싱과 임차 메커니즘을 통해 핫 키 문제를 관리했던 경험이, Azure Cosmos DB 같은 분산 데이터베이스에서도 반복된다는 뜻이다.

OpenAI는 Cosmos DB의 내장 기본 기능(primitives)을 최대한 활용하면서도 추가적인 격리 전략이 필요함을 인정했다. 이는 클라우드 데이터베이스 서비스의 추상화 수준과 실제 프로덕션 운영 간 격차가 존재함을 암시한다. 완전 자동화된 다중 테넌시 지원은 아직 도전 과제로 남아 있다는 뜻이다.

마이크로소프트 Azure 팀과의 긴밀한 협력으로 실행 가능한 '공동 관리형 컨테이너' 모델을 정착시킨 OpenAI의 접근은, 수십억 명 규모 사용자 기반을 가진 제품이 인프라 팀과 클라우드 제공자 간 파트너십 없이는 운영 불가능하다는 현실을 반영한다.