Como a OpenAI manteve o Azure Cosmos DB em pé sob a carga de 1 bilhão de usuários do ChatGPT

Habitat: a espinha dorsal de dados interna da OpenAI

Habitat é a plataforma de armazenamento interna da OpenAI por onde passam as requisições do ChatGPT, da API, do Codex e de dezenas de serviços internos. Ela precisa responder em milissegundos enquanto atende mais de um bilhão de usuários no mundo todo, armazenando mais de 500 petabytes de dados. O motor por trás de tudo é o Azure Cosmos DB. Os engenheiros da OpenAI John Lee, Grach Hakobyan e Chaoming Yu descreveram como reconstruíram, três vezes, o princípio de distribuição de carga entre produtos dentro desse banco, até encontrarem um esquema que funcionasse.

O problema do banco compartilhado e dos "vizinhos barulhentos"

Originalmente, todos os produtos escreviam em um único banco de dados (contêiner) compartilhado do Cosmos DB. Cada chave — por exemplo, um ID de usuário — tem um limite de 10 mil operações por segundo, mas, na prática, esse limite se aplica não à chave em si, mas à partição física do disco onde essa chave está armazenada junto com outras. Isso criava dois problemas:

• Produtos diferentes que usavam chaves semanticamente parecidas (como user_id) acabavam compartilhando esse limite entre si, mesmo sem motivo lógico para se sobreporem.
• Se um cliente aumentasse repentinamente a carga em "sua" partição, todos os outros usuários e recursos cujos dados estivessem por acaso próximos sofriam — às vezes a ponto de causar falhas de login em massa.

Além disso, surgiu o problema das "partições fracas": quando uma partição de disco crescia e o Cosmos DB a dividia em duas, a largura de banda de cada metade era reduzida proporcionalmente — ou seja, o crescimento do volume de dados por si só reduzia a velocidade, mesmo sem alteração no número de requisições.

Isolamento via bancos separados — e o seu custo

A solução foi criar bancos de dados separados para cada produto ou recurso novo importante. Isso de fato eliminou o efeito dos "vizinhos barulhentos" — agora a sobrecarga de um serviço não derrubava mais os outros. Mas a abordagem teve um custo:

• As equipes de produto precisavam solicitar antecipadamente a largura de banda necessária para o lançamento — e frequentemente se esqueciam disso, fazendo com que os lançamentos fossem acompanhados de reuniões de emergência de escalonamento de última hora.
• Uma carga que no banco compartilhado seria uma gota imperceptível (crescer de mil para um milhão de requisições por segundo é apenas 5% da capacidade total) podia, em um banco separado, representar mil vezes mais do que os recursos planejados.
• O planejamento de capacidade se espalhou por toda a empresa em vez de ficar com uma única equipe central, e a qualidade desse planejamento variava muito de equipe para equipe.

De volta ao banco compartilhado — mas com balanceamento inteligente

Ao perceber que nenhuma das abordagens escalava organizacionalmente, a equipe do Habitat, junto com engenheiros da Microsoft, remodelou a própria mecânica do Cosmos DB:

• Adicionaram limitação (throttling) prioritária para as chaves mais "quentes", de modo que um cliente agressivo não pudesse monopolizar toda a largura de banda de uma partição.
• Introduziram priorização de requisições (QoS): tarefas em segundo plano, como exportações massivas de dados, agora são as primeiras a serem limitadas, enquanto requisições interativas de usuários são as últimas.
• Junto com a Azure, aprimoraram o modo serverless do Cosmos DB, elevando o limite de 5 mil para 10 mil operações por segundo por partição e adicionando divisão automática baseada na carga, e não apenas no volume de dados.

Isso permitiu voltar a um único banco compartilhado sem planejamento manual de capacidade — e, segundo os autores, nos meses seguintes à mudança não houve nenhuma falha causada por sobrecarga ou vizinhos barulhentos.

Engenharia conjunta com a Microsoft

A maior conta de Cosmos DB da OpenAI armazena dezenas de petabytes e sustenta mais de 20 milhões de requisições por segundo — os autores a consideram a maior implantação conhecida do serviço. Nessa escala, o suporte padrão de um provedor de nuvem deixa de ser suficiente: no final de 2024, uma queda de energia em uma das regiões mostrou que a alternância para uma região de backup, para contas desse tamanho, levava várias horas — uma falha dessa magnitude nunca tinha sido testada antes. Um mês depois, ao reverter a alternância, ocorreu um segundo incidente: os clientes se apressaram em massa para se reconectar à região original e sobrecarregaram seu gateway, embora apenas parte dos dados tivesse retornado.

Após esses incidentes, as equipes da OpenAI e da Azure criaram uma colaboração direta: painéis compartilhados, testes conjuntos em uma cópia da conta de produção, canais diretos no Teams e a possibilidade de se contatarem diretamente, sem passar pelo suporte técnico padrão. No último ano, aprimoraram juntos a escalabilidade do gateway do Cosmos DB, adicionaram cache de metadados, reduziram o número de conexões dos serviços Python do Habitat e separaram cargas críticas das de fundo em redes distintas.

A principal conclusão para equipes de engenharia: sistemas multiusuário (compartilhados) são mais baratos e simples de operar, mas exigem mecanismos de isolamento embutidos pelo próprio provedor — sem eles, a única alternativa é a divisão manual em bancos separados, o que simplesmente transfere o problema de planejamento de capacidade para dezenas de equipes.