cloud / sistemas
Por quase seis meses, tudo parecia funcionar perfeitamente. Esse longo período de tranquilidade era justamente o perigo.
Uma aplicação web usava o Amazon Elastic File System (EFS) como armazenamento compartilhado. Várias instâncias acessavam os mesmos arquivos, o deploy era simples e não havia um motivo evidente para questionar a arquitetura.
Então, aparentemente sem aviso, o site ficou extremamente lento e acabou parecendo parar de funcionar. A carga dos servidores subiu, as requisições expiravam e os processos da aplicação se acumulavam.
À primeira vista, parecia um problema de processamento. Não era. A causa real era o esgotamento dos créditos de burst do EFS.
Por que parecia um problema de CPU
Um dos sintomas enganosos era o load average alto no Linux. Um load average elevado não significa necessariamente CPUs no limite. Ele também inclui processos em espera ininterruptível, algo comum quando ficam bloqueados aguardando I/O de armazenamento.
Os workers esperavam as operações do EFS terminarem. Novas requisições continuavam chegando, mais workers ficavam bloqueados e a fila crescia:
- O throughput do EFS ficou limitado.
- As operações de arquivo demoravam mais.
- Os workers da aplicação continuavam ocupados esperando I/O.
- As requisições recebidas se acumulavam.
- A carga do sistema aumentava.
- O site acabou praticamente indisponível.
Adicionar CPU não teria resolvido a causa do problema.
Por que a falha levou seis meses para aparecer
O sistema de arquivos EFS estava configurado no modo Bursting Throughput . Nesse modo, o throughput básico sustentável depende da quantidade de dados na classe EFS Standard. Quando a carga fica abaixo dessa taxa, o sistema acumula créditos de burst. Quando passa dela, consome esses créditos.
Em sistemas de arquivos relativamente pequenos, isso pode criar uma situação enganosa:
- O volume armazenado permite uma taxa básica sustentável baixa.
- O saldo existente libera temporariamente um throughput muito maior.
- A aplicação funciona normalmente, mesmo com uma carga de longo prazo acima da capacidade sustentável.
- Enquanto há créditos, o desequilíbrio fica escondido.
- Quando o saldo chega a zero, o desempenho cai drasticamente.
Neste caso, os créditos acumulados duraram cerca de seis meses. A arquitetura já estava subdimensionada em throughput, mas o saldo escondia o problema. Era um déficit de capacidade que avançava devagar — uma bomba-relógio de seis meses.
Desempenho temporário de burst nunca deve ser confundido com throughput sustentável.
Escolher o modo de throughput adequado
Bursting Throughput
Bursting Throughput pode fazer sentido quando a necessidade de throughput cresce com o volume armazenado e há períodos tranquilos depois dos picos. Exige monitoramento cuidadoso. Um saldo que cai continuamente mostra que a carga não é sustentável nesse modo.
Elastic Throughput
Elastic Throughput costuma atender melhor a cargas imprevisíveis ou muito variáveis. O throughput acompanha a demanda, sem depender de um saldo finito de créditos. Isso aumenta a resiliência operacional, mas o custo por uso precisa ser avaliado quando o throughput é alto de forma constante.
Provisioned Throughput
Provisioned Throughput é útil quando a necessidade é conhecida e maior do que o volume armazenado permitiria. Ele oferece capacidade previsível, independente do tamanho do sistema de arquivos, mas o valor configurado precisa ser revisto conforme a demanda muda.
Também é importante não confundir o modo de throughput do EFS com seu modo de desempenho. Os modos de throughput definem como a capacidade é fornecida; os modos de desempenho tratam de características como latência e paralelismo.
O monitoramento que deveria existir
A métrica mais importante do CloudWatch para um EFS em Bursting Throughput é BurstCreditBalance. Um conjunto básico de monitoramento também deve incluir:
BurstCreditBalancepara detectar consumo contínuo dos créditosPercentIOLimitpara identificar aproximação do limite de I/OPermittedThroughputpara entender o throughput disponível naquele momentoMeteredIOBytese nasTotalIOBytespara observar o consumo de I/O- latência da aplicação, duração das requisições, timeouts e taxas de erro
- processos esperando I/O, correlacionados com load average e uso real de CPU
Monitorar apenas CPU, memória e códigos HTTP não basta. O armazenamento compartilhado é uma dependência crítica da aplicação e precisa ser acompanhado como parte do serviço, não apenas como componente de infraestrutura.
O alarme deve disparar muito antes de o saldo chegar a zero. Mais importante ainda é observar a tendência. Um saldo que cai por semanas já revela um déficit estrutural de throughput, mesmo que o número absoluto pareça confortável.
O que eu faria diferente
- Estimar o throughput sustentável ainda no projeto.
- Escolher o modo de throughput a partir do padrão real de acesso.
- Tratar créditos de burst como folga temporária, não como capacidade normal.
- Criar alarmes no CloudWatch para saldo de créditos e limites de I/O.
- Monitorar a velocidade de consumo dos créditos.
- Incluir throughput e latência do EFS nos testes de carga.
- Correlacionar load average do Linux, uso de CPU e espera por I/O.
- Reavaliar se arquivos acessados com frequência realmente precisam de armazenamento de rede compartilhado.
- Testar a aplicação com limitação de throughput e latência alta no armazenamento.
- Documentar o procedimento operacional para trocar o modo de throughput.
O aprendizado que ficou
O EFS pode ser uma excelente solução de armazenamento compartilhado, mas seu comportamento depende muito do modo de throughput e do perfil da carga.
O perigo deste incidente não foi só a perda de desempenho. Foi o sistema funcionar bem por seis meses antes dela. Os créditos atrasaram o sintoma visível por tempo suficiente para gerar confiança em uma arquitetura que não se sustentava.
A melhor proteção não é um saldo maior. É escolher o modo adequado, entender a capacidade sustentável e monitorar as métricas que mostram o desequilíbrio antes de o usuário perceber.