OpenAI reescreve o armazenamento Habitat: 500 PB de dados e 1 bilhão de usuários no Cosmos DB

O Habitat, plataforma que sustenta o ChatGPT, a API, o Codex e os serviços internos da OpenAI, atende mais de 1 bilhão de usuários em 40 regiões geográficas e armazena mais de 500 petabytes de dados. A resposta precisa vir em milissegundos. Na segunda parte da análise de engenharia, Jon Lee, Hrachya Hakobyan e Chaomin Yu contam como a equipe extraiu o máximo do Azure Cosmos DB, passou por três modelos de multitenancy e acabou voltando a um único contêiner compartilhado.

Fase I: contêiner compartilhado e três problemas sistêmicos

No início, a OpenAI aceitava qualquer carga de clientes e contava com o limite documentado do Cosmos DB, de 10K RU/s por chave de partição lógica, como back pressure natural. Cada conta tinha um único contêiner, o padrão. Funcionou até que a escala expôs três problemas.

O primeiro: por decisões iniciais de API, a escolha da chave de partição ficou nas mãos dos clientes. Chaves populares, como user_id ou workspace_id, coincidiam entre cenários de produto diferentes, que passavam a dividir o limite de uma mesma chave. O segundo: os limites são aplicados de fato no nível da partição física, então a chave lógica nunca chega a 10 000 RU/s, e os vizinhos de partição atrapalham uns aos outros.

Features secundárias afetavam fluxos críticos de login e cadastro. O terceiro: a vazão do contêiner é dividida igualmente entre as partições físicas. Quando os dados crescem e as partições se dividem, o provisionamento total continua o mesmo, mas o limite por partição cai.

Em cenários pesados, parecidos com blobs, o crescimento do armazenamento por si só reduzia a vazão disponível, mesmo com tráfego estável.

Fase II: isolamento que não escalou organizacionalmente

Contêineres separados resolveram parte dos problemas. Cada um tem suas próprias partições físicas, e os vizinhos barulhentos só podem ser cargas do mesmo contêiner. Para novos cenários críticos, a equipe alocava contêineres, e um script sincronizava o provisionamento com o número de partições físicas e tratava as partições fracas. Isso evitou falhas generalizadas: os problemas ficavam restritos à degradação de uma feature ou de um serviço.

Mas o custo operacional crescia. O motivo principal: em um contêiner compartilhado, a entrada de um novo cenário indo de 0 a 1 milhão de QPS mal mexia no agregado. Em um contêiner dedicado de 10K RU/s, o mesmo salto, de 1K RU/s no teste de carga para 1M RU/s no lançamento, significava 10 000% da folga disponível, enquanto em um contêiner compartilhado de 100M RU/s com 80% de utilização ele representava cerca de 5%. As equipes lançavam features e esqueciam de escalar com antecedência, e no dia do lançamento os engenheiros acabavam em salas de SEV. O planejamento de capacidade exigia que cada equipe conhecesse bem o produto, e a qualidade desse trabalho variava muito.

Fase III: volta ao contêiner compartilhado, junto com o

Azure

A OpenAI retomou a multitenancy como padrão e, em conjunto com a equipe do Azure, eliminou as falhas originais:

• Hot key throttling. O throttling das chaves mais quentes entra primeiro e impede que uma única chave consuma toda a vazão de uma partição física.
• Quality of Service. Requisições em níveis de prioridade: cargas offline, como inserções em lote (bulk) e exportações, recebem baixa prioridade e sofrem throttling primeiro, e o tráfego interativo dos usuários fica intacto.
• Novo modo serverless. O anterior escalava apenas por armazenamento e limitava cada partição física a 5K RU/s. O novo permite que cada partição cresça até 10K RU/s e acrescenta splits por carga de RU, além dos splits por volume. Não é mais preciso monitorar nem elevar o provisionamento manualmente.

Resultado: um único contêiner compartilhado, planejamento de capacidade bem mais simples para as equipes de produto e isolamento de cargas preservado. Nos meses seguintes à migração, não houve incidentes de provisionamento nem de vizinhos barulhentos, e o desenvolvimento de produtos ganhou velocidade.

O que levar para a sua equipe

A história da OpenAI serve como checklist para qualquer equipe que esteja construindo uma plataforma de dados compartilhada.

• Não deixe os clientes escolherem a chave de partição. Essa escolha de API, feita no início, depois precisou ser compensada por uma infraestrutura inteira.
• Acompanhe o limite efetivo por partição física, não por chave lógica. Nos splits, ele cai sem que o tráfego mude.
• Isolar por contêineres sai caro do ponto de vista organizacional: cada equipe vira planejadora de capacidade, e o crescimento agregado estável deixa de existir.
• Priorize o tráfego. Inserções em lote (bulk) e exportações devem sofrer throttling antes das requisições dos usuários.
• Em grande escala, cobre ajustes do fornecedor. A OpenAI conseguiu da Azure um modo serverless específico, em vez de contornar as limitações do seu lado.

A própria OpenAI diz que ainda está no começo do caminho em multitenancy. Por enquanto, porém, o ganho é claro: menos salas de SEV nos lançamentos e menos trabalho manual para as equipes de produto.