Entrega de configuração de rede do Databricks para dezenas de milhões de VMs Serverless

Resumo

• A plataforma serverless da Databricks inicializa dezenas de milhões de VMs diariamente, e cada VM precisa de configuração de rede, como destinos permitidos e endpoints privados, antes de atender às cargas de trabalho dos clientes. Com cada nó buscando a configuração na inicialização e realizando consultas periódicas (polling) para atualizações ao longo de seu ciclo de vida, isso se traduz em bilhões de solicitações de configuração de rede por dia. A arquitetura antiga buscava essas informações de múltiplos serviços upstream de forma síncrona, criando gargalos de latência e disponibilidade.
• Rearquitetamos a entrega de configurações de rede usando pipelines orientados a eventos e pré-computação de snapshots, reduzindo a latência de RPC em 97,5% (5.000 ms → 125 ms) e alcançando 99,99% de disponibilidade do serviço.

Descrição do problema

A plataforma de computação serverless da Databricks alimenta praticamente todos os nossos produtos de dados e IA, como SQL warehouses, notebooks, endpoints de ML serving e muito mais. A plataforma inicializa dezenas de milhões de VMs diariamente na AWS, Azure e GCP.

Antes que qualquer carga de trabalho serverless possa ser executada, a VM precisa conhecer sua configuração de rede: Quais destinos de armazenamento ela pode acessar? Existem endpoints de link privado pelos quais ela deve rotear o tráfego? Há alterações recentes no Unity Catalog que concedem acesso a novos destinos de armazenamento? Devemos começar a consumir novos destinos compartilhados via Delta Sharing?

O desafio é que a configuração de rede não fica armazenada em um único lugar. Ela precisa ser reunida a partir de múltiplos serviços upstream, com cada um contribuindo com uma parte do cenário completo.

A arquitetura antiga

No design original, toda vez que um cluster serverless era iniciado, nosso serviço de configuração de rede chamava de forma síncrona todos os serviços upstream, agregava suas respostas, computava a configuração de rede por workspace e a retornava para o dataplane serverless. Isso acontecia no caminho crítico da criação do cluster.

Embora a arquitetura antiga fosse simples e funcionasse bem em pequena escala, ela sofria de problemas fundamentais, refletidos nas seguintes métricas que acompanhamos em nosso painel operacional:

1. Latência: Com múltiplos serviços upstream no caminho crítico, a latência de RPC para fornecer a configuração de rede era de 5.000 ms no p99. Isso afetava a latência de inicialização do cluster serverless.
2. Taxa de sucesso do servidor: Cada serviço upstream tem suas próprias características de disponibilidade. Com vários serviços em série, a disponibilidade composta cai rapidamente, o que se traduz em uma maior probabilidade de falhas na inicialização de clusters serverless por ano.

À medida que o uso de serverless continuou a crescer rapidamente, o modelo síncrono tornou-se cada vez mais insustentável. Cada chamada síncrona acionava operações caras em todos os workspaces, muitas vezes realizando computações duplicadas. Isso adicionava uma carga que crescia proporcionalmente ao número de tenants e seus recursos configurados.

Solução: Pré-computação orientada a eventos

Realizamos uma rearquitetura completa de como a Databricks entrega as configurações de rede. Ela foi desenvolvida com base nos seguintes princípios fundamentais:

1. Pipeline orientado a eventos: Em vez de fazer chamadas síncronas para todos os serviços upstream, o novo sistema assina eventos de alteração por meio de uma fila de mensagens. Quando um cliente cria uma nova conexão do Unity Catalog ou modifica uma política de rede, o serviço upstream emite um evento. O sistema o processa e atualiza a configuração pré-computada.
2. Pré-computação de snapshots: As configurações de rede são computadas de forma assíncrona em segundo plano e armazenadas em um repositório de snapshots pré-computados. O caminho de atendimento se torna uma busca única e simples no armazenamento, totalmente desacoplada dos serviços upstream.
3. Estabilidade estática: No caso de qualquer interrupção no serviço upstream, podemos manter uma configuração estática, proporcionando estabilidade estática para os clusters serverless.

A arquitetura separa claramente dois caminhos. O caminho de gerenciamento é executado de forma assíncrona em segundo plano: os serviços upstream emitem eventos de alteração para uma fila de mensagens, que um processador de eventos consome para determinar quais workspaces são afetados e propagar as notificações de atualização por workspace. Em seguida, um gerenciador de eventos local busca os detalhes relevantes do upstream, computa novamente a configuração de rede do workspace e armazena o resultado em um repositório de snapshots pré-computados. Um reconciliador periódico também sincroniza novamente todos os workspaces em segundo plano, garantindo a consistência eventual mesmo se houver perda de eventos. O caminho de atendimento, por outro lado, é crítico e rápido: quando um cluster serverless é iniciado e precisa de configuração de rede, o serviço de configuração de rede a fornece diretamente do repositório de snapshots com uma única leitura de armazenamento, sem a necessidade de chamadas de serviço upstream e reduzindo significativamente a carga sobre eles.

Principais decisões de design

• Os serviços upstream enviam (push) eventos de alteração para a fila de mensagens. O sistema processa esses eventos em segundo plano. Um reconciliador de baixa frequência sincroniza periodicamente todos os workspaces como uma rede de segurança, oferecendo a confiabilidade do framework síncrono com a eficiência do modelo push.
• As configurações de rede são computadas e armazenadas localmente dentro de cada partição de serviço, co-localizadas com os workspaces que atendem. Isso distribui a computação, reduz o raio de impacto (blast radius) durante incidentes e elimina dependências entre partições no caminho de atendimento.
• Os eventos carregam apenas identificadores de workspace e de recursos. Isso mantém os eventos leves, torna-os idempotentes (podem ser reproduzidos em qualquer ordem) e evita a transferência de dados confidenciais de clientes pelo pipeline de mensagens.

Como os eventos fluem

Quando um cliente cria uma nova conexão do Unity Catalog, o Unity Catalog emite um evento de alteração para a fila de mensagens. O processador de eventos recebe o evento, determina quais workspaces estão anexados ao metastore afetado e propaga uma notificação de atualização por workspace. Na partição de cada workspace, o gerenciador de eventos recebe essa notificação, busca os detalhes da conexão atualizada, computa novamente a configuração de rede do workspace e a armazena com uma nova marcação de versão. A partir desse momento, quando um cluster serverless solicita a configuração de rede, ela é fornecida diretamente do repositório de snapshots, sem a necessidade de chamadas upstream.

Impacto

Após a implementação da nova arquitetura, os resultados foram transformadores em todas as métricas operacionais:

Além das métricas principais:

1. O volume de chamadas upstream foi reduzido em 86%. O sistema só chama os serviços upstream quando um evento indica uma alteração, e não a cada solicitação.
2. Observamos uma melhoria significativa na atualização da configuração de rede.
3. O framework síncrono legado foi totalmente descontinuado.

Conclusão

Este projeto nos ensinou várias lições sobre a operação de infraestrutura de rede em escala de nuvem:

A pré-computação desacopla caminhos críticos. Ao mover a agregação dispendiosa para o segundo plano, o caminho de atendimento torna-se extremamente simples e rápido. Essa foi a decisão arquitetônica de maior impacto. Ela transformou uma cadeia de dependência de múltiplos serviços em uma única leitura de armazenamento.

A arquitetura orientada a eventos troca consistência por escalabilidade, e a reconciliação oferece a rede de segurança. O modelo push baseado em eventos lida com o caso comum de forma eficiente, enquanto um reconciliador periódico captura qualquer detalhe que passe despercebido.

Projete visando a extensibilidade desde o primeiro dia. A arquitetura modular baseada em etapas significa que adicionar suporte para uma nova fonte de dados upstream exige apenas a implementação de uma nova etapa, com zero alterações no pipeline principal. À medida que o portfólio de produtos da Databricks se expande, o sistema de configuração de rede escala junto com ele.

Hoje, esse sistema atende a bilhões de solicitações de configuração de rede por dia em toda a frota global serverless da Databricks, com latência de aproximadamente 125 ms e 99,99% de disponibilidade. À medida que a computação serverless continua seu rápido crescimento, a arquitetura orientada a eventos garante que a entrega de configurações de rede escale no mesmo ritmo.

Estamos sempre procurando engenheiros que gostem de enfrentar desafios de sistemas distribuídos em escala global. Se você se interessa por problemas como esses, adoraríamos conversar com você! Confira as vagas abertas em databricks.com/careers!

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original