Slack jan/2021: o gateway de rede (AWS Transit Gateway) que não escalou na volta das férias

01 · CONTEXTO

A volta das férias

A queda do Slack aconteceu no primeiro dia útil do ano para muita gente, 4 de janeiro de 2021. A equipe foi acionada por um serviço externo de monitoramento porque as taxas de erro estavam subindo.

O tráfego do Slack é menor durante as festas. Na primeira segunda-feira depois delas, os caches dos clientes estão frios e cada cliente baixa mais dados que o normal ao se conectar, então a empresa vai da época mais calma do ano a um de seus maiores dias praticamente da noite para o dia.

Os sistemas que atendem os usuários escalam rápido para esse tipo de pico e sempre tinham passado por essa volta das festas sem problemas nos anos anteriores.

02 · A LINHA DO TEMPO

Da taxa de erro à indisponibilidade

Enquanto a equipe estava nos primeiros momentos da investigação, o serviço de painéis e alertas ficou indisponível. Sem os painéis usuais, a depuração ficou prejudicada, mas ainda havia consoles internos, ferramentas de linha de comando e logs.

O Slack tem minipicos de tráfego no início de cada hora e de cada meia hora, e a camada web e os backends são escalados para eles. O minipico das 7h, somado ao problema de rede que já existia, saturou a camada web: a perda de pacotes elevou a latência das chamadas aos backends e o Slack ficou indisponível.

03 · O AUTOSCALING

Escalar para cima também precisa de saúde

A camada web escala por dois sinais: o uso de CPU e o uso das threads de trabalho do Apache. Com a rede ruim, as threads passaram mais tempo esperando e a CPU caiu, o que disparou um downscaling automático. Logo depois veio um upscaling significativo, porque o uso das threads subiu conforme a rede piorava.

1. Com a rede degradada, a camada web espera mais tempo pelas respostas dos backends e as threads passam mais tempo esperando.

2. O autoscaling vê a CPU cair, porque as threads estão esperando, e dispara um downscaling.

3. Logo depois o uso das threads sobe e a empresa tenta adicionar 1.200 servidores à camada web entre 7h01 e 7h15.

4. O provision-service conversa com as APIs da AWS e com sistemas internos pela mesma rede degradada e, com tantas instâncias ao mesmo tempo, atinge dois gargalos de recursos.

5. Muitas instâncias são criadas sem ficar totalmente provisionadas e sem servir tráfego, e as instâncias quebradas levam a atingir os limites dos grupos de autoscaling.

6. Por volta das 8h15 o provision-service volta e instâncias saudáveis passam a entrar em serviço.

Sem os painéis, vários engenheiros estavam logados em instâncias de produção investigando. Muitas sessões SSH foram encerradas de repente porque essas instâncias foram desprovisionadas, o que dificultou ainda mais a investigação; o downscaling foi então desativado para facilitar a investigação e preservar a capacidade de atendimento.

04 · COMO VOLTOU A SERVIR

Modo de pânico, retentativas e circuit breaking

Os health checks dos balanceadores continuavam falhando em taxa muito alta por causa da rede. Os balanceadores têm um modo de pânico que distribui as requisições por todas as instâncias quando muitas falham nos health checks, e isso, junto com retentativas e circuit breaking, fez o sistema voltar a atender.

1. Os clientes enviam requisições aos balanceadores, que fazem health checks nas instâncias web.

2. Quando muitas instâncias falham nos health checks, o balanceador entra em modo de pânico e passa a distribuir requisições por todas elas.

3. Esse modo, somado a retentativas e circuit breaking, fez o Slack voltar a servir, mais lento e com mais erros que o normal.

Por volta das 9h15 o Slack estava degradado, não fora do ar. Levou uma hora para provisionar instâncias suficientes e baixar os erros a um nível baixo, por dois motivos: a rede ainda não estava saudável, então foram necessárias mais instâncias que o normal, e o próprio provisionamento demorou mais que o usual.

05 · A CAUSA

O Transit Gateway que não escalou a tempo

Quando o Slack já tinha se recuperado, os engenheiros da AWS tinham encontrado o gatilho: parte da infraestrutura de rede da AWS ficou saturada e descartava pacotes.

O Slack usa AWS Transit Gateways (TGWs) como hubs para ligar suas VPCs. Os TGWs são gerenciados pela AWS e feitos para escalar de forma transparente para o cliente, mas desta vez não escalaram rápido o bastante. Os engenheiros da AWS foram alertados pelo próprio monitoramento e aumentaram a capacidade manualmente.

1. O Transit Gateway liga VPCs diferentes; os painéis e os bancos de apoio estavam em VPCs distintas.

2. Por estarem em VPCs diferentes, os painéis dependiam do Transit Gateway para falar com seus bancos.

3. Quando o Transit Gateway ficou saturado e passou a descartar pacotes, os painéis e alertas falharam.

06 · O QUE MUDOU

Lições e correções anunciadas

Ao desenhar um sistema para um pico previsível, vale checar também a rede, as ferramentas de provisionamento e os painéis de observabilidade, e não só a quantidade de servidores. Pedir capacidade demais de uma vez a um provisionador pode sobrecarregá-lo; limitar o ritmo dos pedidos é uma forma de controle de sobrecarga.