Desvendando a Resiliência de Sistemas Distribuídos no GitHub

Introdução: Aprendizados com Desafios de Disponibilidade

Nas últimas semanas, o GitHub enfrentou desafios significativos de disponibilidade e performance em diversos serviços. Entendemos que a confiabilidade é fundamental para o trabalho diário de nossos usuários, e a AITY, como parceira de soluções, acompanha de perto as lições que podem ser extraídas desses eventos para a construção de sistemas mais robustos. A transparência do GitHub ao detalhar os incidentes de 2 e 9 de fevereiro, e 5 de março, oferece uma valiosa oportunidade de análise técnica sobre as causas e as medidas para fortalecer a resiliência de plataformas de infraestrutura crítica.

O Que Aconteceu: Causas Raiz dos Incidentes

Os incidentes ocorreram em um período de crescimento de uso extremamente rápido na plataforma, expondo limitações de escalabilidade em partes da arquitetura existente. A instabilidade recente foi impulsionada principalmente por:

• Rápido aumento da carga de trabalho.
• Acoplamento arquitetural que permitiu que problemas localizados se propagassem em cascata por serviços críticos.
• Incapacidade do sistema de descarregar adequadamente a carga de clientes mal-comportados.

Incidente de 9 de Fevereiro: Sobrecarga de Base de Dados

Em 9 de fevereiro, um incidente de alto impacto resultou da sobrecarga de um cluster de banco de dados central que suporta autenticação e gerenciamento de usuários. Os problemas que levaram a essa falha foram construídos ao longo de semanas:

• Aumento de Tráfego por Clientes: Duas aplicações cliente populares foram lançadas com mudanças não intencionais, gerando um aumento de mais de dez vezes no tráfego de leitura.
• Mudança no TTL de Cache: Em 7 de fevereiro, um novo modelo foi implantado, e o TTL (Time-To-Live) de refresh em um cache que armazenava configurações de usuário foi alterado de 12 para 2 horas para acomodar a capacidade limitada.
• Conflito de Cargas: Em 9 de fevereiro, a combinação da carga de pico regular, a atualização de muitos clientes para as novas versões dos aplicativos e o lançamento de outro novo modelo sobrecarregaram o cluster de banco de dados, devido ao volume de escrita (pelo TTL) e de leitura (pelos apps).
• Problemas Arquiteturais Legados: A investigação revelou que as configurações de usuário, inicialmente armazenadas de forma simples e compacta, haviam crescido de alguns bytes para kilobytes por usuário. Essa arquitetura, selecionada para simplicidade inicial, tornou-se perigosa com o tempo, especialmente quando o TTL mascarava o problema durante os períodos de menor carga.

Incidentes do GitHub Actions: Falhas de Failover

O GitHub também enfrentou dois incidentes significativos onde as soluções de failover foram insuficientes ou não funcionaram corretamente para o GitHub Actions:

• 2 de Fevereiro: Um conjunto em cascata de eventos, desencadeado por uma lacuna de telemetria, fez com que políticas de segurança existentes fossem aplicadas a contas de armazenamento internas críticas, afetando todas as regiões. Isso bloqueou o acesso a metadados de VM e interrompeu operações do ciclo de vida dos runners hospedados.
• 5 de Março: Um failover ocorreu em um cluster Redis usado pela orquestração de tarefas do Actions. Embora o failover tenha funcionado conforme o esperado, um problema de configuração latente deixou o cluster sem um primário gravável, exigindo correção manual para mitigação.

Fatores Contribuintes Comuns

Em todos esses incidentes, fatores comuns ampliaram o escopo ou a duração do impacto:

• Isolamento insuficiente entre componentes de caminho crítico na arquitetura.
• Salvaguardas inadequadas para descarregamento de carga (load shedding) e throttling.
• Lacunas na validação ponta a ponta, monitoramento de sinais iniciais e coordenação de parceiros durante a resposta a incidentes.

Ações Atuais e Futuras: Fortalecendo a Plataforma

As equipes de engenharia do GitHub estão focadas em mitigações de curto prazo e investimentos de arquitetura e processo de longo prazo, com o objetivo de gerenciar o aumento rápido da carga e prevenir que falhas localizadas causem degradação ampla do serviço.

Mitigações de Curto Prazo

• Redesenho do sistema de cache de usuário para acomodar volumes significativamente maiores em um cluster de banco de dados segmentado.
• Aceleração do planejamento de capacidade e auditoria completa da saúde fundamental da infraestrutura de dados e computação.
• Isolamento de dependências-chave para que sistemas críticos como GitHub Actions e Git não sejam impactados por problemas de infraestrutura compartilhada.
• Proteção de componentes downstream durante picos para evitar falhas em cascata, priorizando cargas de tráfego críticas.

Investimentos de Plataforma de Longo Prazo

• Migração para Azure: A infraestrutura está sendo migrada para Azure para acomodar crescimento rápido, permitindo escalabilidade vertical dentro das regiões e horizontal entre elas. Isso visa simplificar a arquitetura e aumentar a resiliência global através de serviços gerenciados.
• Decomposição do Monolito: Quebrar o monolito em serviços e domínios de dados mais isolados, permitindo escalabilidade independente, gerenciamento de mudanças mais isolado e decisões localizadas sobre descarregamento de tráfego.

Impacto Prático e Lições Aprendidas

Os recentes incidentes no GitHub servem como um lembrete crítico da complexidade e dos desafios inerentes à manutenção de sistemas distribuídos em escala massiva. Para nós, arquitetos e engenheiros de software na AITY, essas análises reforçam a importância de um projeto arquitetural robusto, com foco em isolamento de falhas, capacidade proativa, estratégias de failover rigorosas e mecanismos eficazes de descarregamento de carga. A migração para a nuvem e a decomposição de monolitos são estratégias chave que implementamos em nossos projetos para alcançar maior resiliência e escalabilidade, garantindo que as plataformas que construímos e gerenciamos possam suportar o crescimento e se recuperar eficientemente de falhas.