Falha de autoscaling ajudou a causar interrupção do GitHub

O papel do autoscaling na interrupção

A interrupção recente do GitHub envolveu um serviço cujo sidecar do Istio atingiu seus limites de concorrência. Segundo o relato público citado, o escalonamento automático falhou porque a política configurada observava os limites do serviço principal, mas não os do sidecar. Com isso, a capacidade adicional necessária não foi criada adequadamente quando a carga aumentou.

Autoscaling é o ajuste dinâmico dos recursos computacionais de um serviço conforme a carga recebida. Como o tráfego varia ao longo do tempo, uma organização pode provisionar capacidade para o pico ou adicionar e remover recursos de acordo com a demanda. Para funcionar, o autoscaling depende de uma política que escolha métricas representativas da carga e defina como os recursos devem variar quando essas métricas mudam.

CPU é uma métrica comum, mas não indica necessariamente que um serviço está saudável. Um serviço pode ficar saturado com baixo uso de CPU se, por exemplo, todas as threads estiverem bloqueadas esperando por operações de entrada e saída. Nesses casos, pode ser mais apropriado escalar pelo número de threads ou pelo volume de requisições recebidas, dependendo do comportamento do serviço.

Com base no relatório do GitHub, o autor supõe que a política do serviço afetado considerava apenas a carga do próprio serviço, ignorando a carga do sidecar do Istio. Como cada serviço reage de maneira diferente à carga, as políticas de autoscaling são, na prática, específicas para cada caso. Isso faz com que as equipes responsáveis também tenham de operar um sistema de controle com parâmetros personalizados, cuja adequação só pode ser verificada de forma confiável por meio de testes de carga. O autor observa que essas equipes provavelmente não são especialistas em autoscaling, o que torna plausível que uma política mal configurada tenha contribuído para o incidente.

Além do componente defeituoso

O autor considera importante corrigir o defeito identificado, mas alerta contra tratá-lo como explicação suficiente. Ele chama essa tendência de “falácia da substituição de componentes”, conceito associado a David Woods: a ideia de que melhorar a confiabilidade consiste principalmente em encontrar e consertar componentes defeituosos.

Sistemas contêm muitos defeitos latentes e, ainda assim, não falham continuamente. Portanto, os defeitos isolados não bastam para explicar uma interrupção; é preciso analisar as interações entre eles. No caso do GitHub, o relato menciona a combinação entre mudanças nos padrões de tráfego, inclusive de scrapers, a política de autoscaling, a saturação do sidecar do Istio, a lógica de novas tentativas, a saturação de nós do HAProxy e o tráfego de autenticação.

O texto ressalta que os relatórios públicos, divulgados rapidamente, não contêm todos os detalhes. Permanecem sem resposta perguntas sobre a história da política - como se ela existia antes da adoção dos sidecars do Istio - e sobre o tráfego problemático: que tipos de requisição o compunham, se o aumento foi súbito ou gradual e por que ocorreu. A conclusão é que organizações devem buscar essas respostas em seus próprios relatórios internos de incidentes.