O Flex Consumption oferece recursos de expansão rápida e ampla em um modelo sem servidor e oferece suporte a longos tempos de execução de funções, rede privada, seleção de tamanho de instância e controle de simultaneidade.
O GitHub é o lar dos desenvolvedores de software program do mundo, com mais de 100 milhões de desenvolvedores e 420 milhões de repositórios totais na plataforma. Para manter tudo funcionando perfeitamente e com segurança, o GitHub coleta uma quantidade enorme de dados por meio de um pipeline interno composto por vários componentes. Mas, embora tenha sido criado para tolerância a falhas e escalabilidade, o crescimento contínuo do GitHub levou a empresa a reavaliar o pipeline para garantir que ele atenda às demandas atuais e futuras.
“Tínhamos um problema de escalabilidade, atualmente coletamos cerca de 700 terabytes por dia de dados, que são muito usados para detectar comportamento malicioso contra nossa infraestrutura e para solução de problemas. Esse sistema interno estava limitando nosso crescimento.”
—Stephan Miehe, Diretor Sênior de Segurança de Plataforma do GitHub
O GitHub trabalhou com sua empresa controladora, a Microsoft, para encontrar uma solução. Para processar o fluxo de eventos em escala, a equipe do GitHub construiu um aplicativo de função que roda em Consumo flexível do Azure Featuresum plano lançado recentemente para visualização pública. O Flex Consumption oferece recursos de escalabilidade rápida e ampla em um modelo sem servidor e suporta longos tempos de execução de funções, rede privada, seleção de tamanho de instância e controle de simultaneidade.
Em um teste recente, o GitHub sustentou 1,6 milhão de eventos por segundo usando um aplicativo Flex Consumption acionado por um hub de eventos com restrição de rede.
“O que realmente importa para nós é que o aplicativo seja dimensionado para cima e para baixo com base na demanda. O Azure Features Flex Consumption é muito atraente para nós por causa de como ele é dimensionado dinamicamente com base no número de mensagens que são enfileiradas no Azure Occasion Hubs.”
—Stephan Miehe, Diretor Sênior de Segurança de Plataforma do GitHub

Uma olhada para trás
O problema do GitHub estava em um aplicativo de mensagens interno que orquestrava o fluxo entre os produtores e consumidores de telemetria. O aplicativo foi originalmente implantado usando binários baseados em Java e Hubs de eventos do Azure. Mas quando começou a processar até 460 gigabytes (GB) de eventos por dia, o aplicativo estava atingindo seus limites de design, e sua disponibilidade começou a diminuir.
Para melhor desempenho, cada consumidor da plataforma antiga exigia seu próprio ambiente e ajustes manuais demorados. Além disso, a base de código Java period propensa a quebras e difícil de solucionar problemas, e esses ambientes estavam ficando caros para manter conforme a sobrecarga de computação aumentava.
“Não podíamos aceitar os riscos e os desafios de escalabilidade da solução atual,“ Miehe diz. Ele e sua equipe começaram a pesar as alternativas. “Já estávamos usando o Azure Occasion Hubs, então fazia sentido explorar outros serviços do Azure. Dada a natureza simples da nossa necessidade — solicitação HTTP POST — queríamos algo sem servidor que carregasse o mínimo de sobrecarga.”
Familiarizada com o desenvolvimento de código sem servidor, a equipe se concentrou em soluções nativas do Azure semelhantes e chegou a Funções do Azure.
“Ambas as plataformas são bem conhecidas por serem boas para processamento simples de dados em larga escala, mas não queremos migrar para outro produto em seis meses porque atingimos um teto.”
—Stephan Miehe, Diretor Sênior de Segurança de Plataforma do GitHub
Um aplicativo de função pode dimensionar automaticamente a fila com base na quantidade de tráfego de registro. A questão period o quanto ele poderia dimensionar. Na época em que o GitHub começou a trabalhar com a equipe do Azure Features, o plano Flex Consumption tinha acabado de entrar em visualização privada. Com base em uma nova arquitetura subjacente, o Flex Consumption oferece suporte a até 1.000 partições e fornece uma experiência de dimensionamento mais rápida com base em destino. A equipe do produto criou uma prova de conceito que foi dimensionada para mais que o dobro do maior tópico da plataforma legada na época, mostrando que o Flex Consumption poderia lidar com o pipeline.
“O Azure Features Flex Consumption nos oferece uma solução sem servidor com 100% da capacidade de que precisamos agora, além de todo o espaço de que precisamos à medida que crescemos.”
—Stephan Miehe, Diretor Sênior de Segurança de Plataforma do GitHub
Tornando uma boa solução ótima
O GitHub se juntou à prévia privada e trabalhou em conjunto com a equipe de produtos do Azure Features para ver o que mais o Flex Consumption poderia fazer. O novo aplicativo de função é escrito em Python para consumir eventos dos Occasion Hubs. Ele consolida grandes lotes de mensagens em uma grande mensagem e as envia aos consumidores para processamento.
Encontrar o número certo para cada lote exigiu alguma experimentação, pois cada execução de função tem pelo menos uma pequena porcentagem de sobrecarga. Em horários de pico de uso, a plataforma processará mais de 1 milhão de eventos por segundo. Sabendo disso, a equipe do GitHub precisava encontrar o ponto superb na execução da função. Um número muito alto e não há memória suficiente para processar o lote. Um número muito pequeno e são necessárias muitas execuções para processar o lote e o desempenho fica lento.
O número correto foi de 5.000 mensagens por lote. “Nossos tempos de execução já são incrivelmente baixos — na faixa de 100 a 200 milissegundos,” Relatórios de Miehe.
Esta solução tem flexibilidade integrada. A equipe pode variar o número de mensagens por lote para diferentes casos de uso e pode confiar que os recursos de dimensionamento baseados em destino serão dimensionados para o número superb de instâncias. Neste modelo de dimensionamento, o Azure Features determina o número de mensagens não processadas no hub de eventos e, em seguida, dimensiona imediatamente para uma contagem de instâncias apropriada com base no tamanho do lote e na contagem de partições. No limite superior, o aplicativo de função dimensiona até uma instância por partição do hub de eventos, o que pode resultar em 1.000 instâncias para implantações de hub de eventos muito grandes.
“Se outros clientes quiserem fazer algo semelhante e acionar um aplicativo de função do Occasion Hubs, eles precisam ser muito deliberados no número de partições a serem usadas com base no tamanho de sua carga de trabalho. Se você não tiver o suficiente, restringirá o consumo..”
—Stephan Miehe, Diretor Sênior de Segurança de Plataforma do GitHub
O Azure Features oferece suporte a várias fontes de eventos além dos Hubs de Eventos, incluindo Apache Kafka, Banco de Dados Cosmos do Azure, Barramento de Serviço do Azure filas e tópicos, e Armazenamento de fila do Azure.
Alcançando além da rede digital
O modelo de função como serviço libera os desenvolvedores da sobrecarga de gerenciar muitas tarefas relacionadas à infraestrutura. Mas mesmo o código sem servidor pode ser restringido pelas limitações das redes onde ele é executado. O Flex Consumption aborda o problema com suporte aprimorado à rede digital (VNet). Os aplicativos de função podem ser protegidos por trás de uma VNet e podem alcançar outros serviços protegidos por trás de uma VNet — sem degradar o desempenho.
Como um dos primeiros a adotar o Flex Consumption, o GitHub se beneficiou das melhorias feitas nos bastidores na plataforma Azure Features. O Flex Consumption é executado no Legion, um spine de plataforma interna como serviço (PaaS) recém-arquitetado que melhora os recursos e o desempenho da rede para cenários de alta demanda. Por exemplo, o Legion é capaz de injetando computação em uma VNet existente em milissegundos — quando um aplicativo de função é dimensionado verticalmente, cada nova instância de computação alocada é iniciada e está pronta para execução, incluindo conectividade de VNet de saída, em 624 milissegundos (ms) no 50º percentil e 1.022 ms no 90º percentil. É assim que o aplicativo de processamento de mensagens do GitHub pode alcançar os Occasion Hubs protegidos por uma rede digital sem incorrer em atrasos significativos. Nos últimos 18 meses, a plataforma Azure Features latência de inicialização a frio reduzida em aproximadamente 53% em todas as regiões e para todos os idiomas e plataformas suportados.
Lidando com desafios
Este projeto expandiu os limites para as equipes de engenharia do GitHub e do Azure Features. Juntos, eles superaram vários desafios para atingir esse nível de rendimento:
- Na primeira execução de teste, o GitHub tinha tantas mensagens pendentes para processamento que causou um estouro de inteiro na lógica de dimensionamento do Azure Features, que foi corrigido imediatamente.
- Na segunda execução, o throughput foi severamente limitado devido à falta de pool de conexão. A equipe reescreveu o código da função para reutilizar corretamente as conexões de uma execução para a próxima.
- Em cerca de 800.000 eventos por segundo, o sistema parecia estar limitado no nível da rede, mas a causa não estava clara. Após semanas de investigação, a equipe do Azure Features encontrou um bug na configuração do buffer de recebimento na implementação de transporte do Superior Message Queuing Protocol (AMQP) do Azure SDK. Isso foi corrigido prontamente pela equipe do Azure SDK e permitiu que o GitHub enviasse mais de 1 milhão de eventos por segundo.
Melhores práticas para atingir um marco de produtividade
Com mais poder vem mais responsabilidade, e Miehe reconhece que o Flex Consumption deu à sua equipe “muitos botões para girar”, como ele disse. “Existe um equilíbrio entre a flexibilidade e o esforço que você tem que fazer para configurá-lo corretamente.”
Para esse fim, ele recomenda testar cedo e frequentemente, uma parte acquainted da cultura de solicitação de pull do GitHub. As seguintes práticas recomendadas ajudaram o GitHub a atingir seus marcos:
- Se puder, faça um lote: Receber mensagens em lotes aumenta o desempenho. Processar milhares de mensagens do hub de eventos em uma única execução de função melhora significativamente o rendimento do sistema.
- Experimente com tamanho de lote:A equipe de Miehe testou lotes de até 100.000 eventos e de até 100 antes de definir 5.000 como o tamanho máximo de lote para execução mais rápida.
- Automatize seus pipelines: O GitHub usa o Terraform para criar o aplicativo de função e as instâncias do Occasion Hubs. O provisionamento de ambos os componentes juntos reduz a quantidade de intervenção handbook necessária para gerenciar o pipeline de ingestão. Além disso, a equipe de Miehe conseguiu iterar incrivelmente rápido em resposta ao suggestions da equipe do produto.
A equipe do GitHub continua executando a nova plataforma em paralelo com a solução legada enquanto monitora o desempenho e determina uma knowledge de transição.
“Nós os temos executado lado a lado deliberadamente para descobrir onde está o teto,” Miehe explica.
A equipe ficou encantada. Como Miehe diz, “Estamos satisfeitos com os resultados e em breve eliminaremos toda a sobrecarga operacional da solução antiga.“
Discover soluções com o Azure Features