Meta apresenta ZGateway, nova camada de proxy que unifica tráfego do ZippyDB e processa mais de um bilhão de operações por segundo
A Meta revelou o ZGateway, uma camada de proxy sem estado posicionada entre os aplicativos clientes e o ZippyDB, o principal sistema de armazenamento de chave-valor da empresa. O novo componente já responde por mais de um bilhão de operações por segundo, representando cerca de 40% do tráfego do ZippyDB, com projeção de ultrapassar 60%. O sistema foi projetado para adicionar aproximadamente 6% de sobrecarga computacional em casos de uso médios.
O ZippyDB sustenta metadados de produtos, contadores e configurações da empresa, executando bilhões de operações por segundo. Antes da criação do ZGateway, cada cliente do ZippyDB se conectava diretamente a cada host de banco de dados necessário. Um único cliente podia acessar dezenas de milhares de fragmentos distribuídos por centenas de milhares de hosts, fazendo com que tanto os clientes quanto os servidores carregassem dezenas de milhares de conexões TLS simultâneas. Cada conexão ociosa consumia memória, processamento e descritores de arquivo em ambas as extremidades, e o número de conexões de entrada aumentava a cada novo grupo de clientes adicionado ao sistema.
Esse cenário provocava falhas graves. Tempestades de reconexão causavam travamentos por esgotamento de descritores de arquivo e por erros de memória insuficiente. Em um incidente específico, um bug de roteamento fez com que cada cliente abrisse uma conexão por fragmento, levando toda a frota de servidores a um ciclo contínuo de reinicializações. Tentar corrigir o problema diretamente nos clientes era inviável, pois centenas de equipes diferentes mantêm seus próprios códigos de acesso ao ZippyDB.
O ZGateway resolve essa questão atuando como uma camada intermediária stateless, ou seja, sem armazenar estado próprio entre requisições. Ele opera como tiers regionais descobertos por meio do ServiceRouter, a malha de serviços interna da Meta, e está disponível em duas modalidades: proxy puro e cache com leitura otimizada. O motor do sistema é o cliente nativo em C++ do ZippyDB, fazendo com que o ZGateway funcione essencialmente como um cliente gerenciado do banco de dados.
Quando um cliente envia uma requisição, ela chega por uma conexão persistente a um host regional do ZGateway, que finaliza a negociação TLS, verifica as permissões com base nas listas de controle de acesso de cada caso de uso, aplica controles de admissão e modelagem de tráfego por cliente, resolve o fragmento correto, consulta o cache local quando disponível, agrupa a requisição com outras operações em andamento para aquele mesmo fragmento e a encaminha para as réplicas apropriadas. As respostas são devolvidas ao cliente original junto com métricas, rastros de execução e dados de consumo de cota, separados por caso de uso.
A Meta modela o sistema como bolas lançadas em compartimentos para calcular o ganho de eficiência. Com os números reais de produção — 20 regiões, 500 mil hosts de banco de dados, 30 mil hosts de proxy e um milhão de clientes —, a quantidade de conexões por host caiu entre 97% e 98%, enquanto o total de conexões persistentes na frota diminuiu cerca de 19 vezes. O ganho mais profundo está na escalabilidade: no acesso direto, o número de conexões cresce linearmente conforme novos clientes são adicionados, enquanto com o ZGateway o fan-in, isto é, o número de destinos que cada origem precisa alcançar, torna-se um valor limitado controlado pela empresa, independente do tamanho de ambas as frotas.
Diversas funcionalidades foram incorporadas ao longo do desenvolvimento. A migração segura foi viabilizada por flags de configuração que permitem rampas de adoção por porcentagem, filtros por região e um interruptor global de desligamento. O Discriminant Load Shedding, mecanismo de descarte seletivo de carga, separa requisições em filas por cliente e prioridade, garantindo que um cliente sobrecarregado afete apenas a própria fila. Em um teste controlado acima de 90% de uso de processador com aproximadamente 1.350 grupos de clientes, apenas seis vizinhos barulhentos tiveram requisições descartadas, o restante executou 99,9% das solicitações sem rejeições e o throughput útil se manteve entre 97% e 98%, com custo de cerca de 8% de CPU.
O cache de leitura atende requisições frequentes em processo, utiliza travas por chave para evitar preenchimentos duplicados e se mantém atualizado por meio de eventos de captura de dados alterados, dentro de um contrato de desatualização limitada. O balanceamento de carga é feito por um controlador que ajusta o peso de cada host no ServiceRouter de forma inversamente proporcional ao uso recente de processador, considerando que os hosts variam entre 26 e 126 núcleos. A resiliência entre regiões permite que um tier regional saturado transfira tráfego para capacidade saudável próxima por meio de roteamento global, mega-regiões e anéis de failover. As transações, antes controladas pelos próprios clientes, foram consolidadas no gateway em nove fases, atingindo 100% do tráfego sem regressões de confiabilidade.
O ZGateway é uma solução de uso interno da Meta e não está disponível para implantação fora da empresa. O valor do projeto está nos padrões arquiteturais adotados para lidar com sistemas distribuídos em escala extrema, em que a introdução de uma camada intermediária stateless se mostrou eficaz para estabilizar conexões, otimizar recursos e habilitar funcionalidades avançadas como descarte seletivo de carga, cache coordenado e failover regional.
