A queda do Dia dos Namorados de 2020 e a virada para chaos engineering

01 · CONTEXTO

Uma plataforma que já tinha deixado de ser monólito

O iFood é uma empresa de entrega de refeições que, segundo o post de engenharia usado neste caso, entrega mais de 60 milhões de pedidos por mês. O crescimento dos últimos anos levou a empresa a quebrar o monólito em vários microsserviços, o que trouxe escalabilidade mas, nas palavras do post, também um custo: complexidade e pontos adicionais de falha.

O mesmo post parte de uma ideia geral: é falacioso confiar em componentes de infraestrutura tomados como garantidos. Servidores de banco de dados saem do ar, brokers de mensagens caem, uma região inteira de um provedor de nuvem pode ficar indisponível por falta de energia e a banda de rede pode despencar sem aviso.

1. No desenho ilustrativo, o aplicativo chama um gateway de API.

2. O gateway encaminha a chamada ao serviço de pedidos.

3. O serviço de pedidos aparece ligado a um banco de dados e a uma fila de mensagens.

4. Um consumidor lê a fila e executa o trabalho assíncrono.

02 · A QUEDA

O que se sabe sobre a noite do Dia dos Namorados

Segundo o Canaltech, o Dia dos Namorados é uma data em que o aplicativo é especialmente demandado, principalmente porque os restaurantes se encontravam fechados devido à quarentena da COVID-19. Naquele dia, os usuários não conseguiam completar as transações de compra e entrega de refeições.

Entre os problemas mais notificados no Downdetector estavam compras online, funcionamento do app e falha geral. No Twitter, o tema virou trend topic, com mais de 16 mil menções.

Em declaração ao Canaltech, o iFood afirmou que a plataforma apresentou instabilidade por duas horas, impactando consumidores, restaurantes e entregadores, e pediu desculpas. Na mesma declaração, disse que errou, ficou frustrado e inconformado.

03 · A RESPOSTA

Fallbacks e circuit breakers para os serviços cruciais

O post de engenharia diz que, no Dia dos Namorados brasileiro de 2020, a plataforma desmoronou como um castelo de cartas. Logo depois da queda, a empresa decidiu implementar fallbacks e circuit breakers em todos os serviços cruciais para entregar um pedido ao cliente.

1. O diagrama ilustrativo mostra um cliente chamando o serviço de pedidos.

2. O serviço de pedidos chama um serviço dependente.

3. O serviço de pedidos também tem um caminho que leva a um fallback, uma resposta alternativa.

4. Nesta ilustração, o serviço dependente está marcado como indisponível, enquanto o serviço de pedidos e o fallback seguem sem marcação de falha.

5. O iFood relata ter implementado fallbacks e circuit breakers em todos os serviços cruciais para entregar um pedido; o diagrama mostra o padrão em um único serviço.

A pergunta que restou foi como garantir que esses mecanismos funcionariam de forma adequada em eventos críticos. Esperar para ver o que o futuro traria deixou de ser uma opção.

Um fallback só vira garantia depois de ser exercitado: sem teste, ele continua sendo uma hipótese sobre o comportamento do sistema.

04 · DO MANUAL AO AUTOMATIZADO

Testes manuais em produção e a adoção do LitmusChaos

O primeiro passo foi simples: em horário de baixo movimento, a empresa reuniu a maior parte dos times de engenharia para derrubar partes do ambiente de produção, principalmente serviços e bancos de dados. O post diz que a abordagem ajudou a ajustar os fallbacks e a entender efeitos colaterais de quedas de componentes.

O custo era alto: o processo envolvia muita gente e os testes eram sujeitos a erro. O post ilustra o problema com perguntas como quantos pods um serviço tinha antes do experimento e se as permissões do usuário do serviço no banco foram restabelecidas depois dos testes, e conclui que aquilo não escalava como a empresa desejava.

Ao levar a prática adiante, o time queria saber o que aconteceria com um pico de CPU, como derrubar uma conexão persistente com o banco e como simular uma queda do AWS SNS. Segundo o post, as outras ferramentas de chaos engineering não estavam preparadas para essas perguntas, e o LitmusChaos prometia uma faixa mais ampla de experimentos de forma simples e controlada. A empresa decidiu adotá-lo como ferramenta de fato em todos os times.

1. O post aponta como aspecto importante autenticar os usuários no LitmusChaos e restringir os serviços em que desenvolvedores podem injetar caos.

2. Cada projeto do LitmusChaos corresponde a um cluster Kubernetes, o que limita os experimentos de um desenvolvedor aos clusters onde seus serviços estão.

3. Os detalhes de auditoria do LitmusChaos são importantes para saber quem executou os experimentos.

05 · O QUE LEVAR

Provar que o mecanismo funciona antes do próximo pico

A sequência relatada vai da queda para os fallbacks e circuit breakers, depois para testes manuais em produção e, por fim, para uma ferramenta dedicada de chaos engineering.

Para o desenho de sistemas, a lição é que um mecanismo de resiliência só merece confiança depois de ser provocado de forma controlada. Isso pede regras sobre quem pode injetar falha, onde isso é permitido e um registro de quem executou cada experimento.