cloud / sistemas
Um problema no Amazon EFS pode existir muito antes de ficar visível. Um sistema de arquivos pequeno pode atender uma carga por semanas ou meses enquanto consome uma reserva finita de créditos. A aplicação parece saudável, os dashboards ficam verdes e a arquitetura ganha confiança. Até que a reserva zera e a mesma carga encontra um limite sustentável muito menor.
O atraso faz a falha parecer repentina. Operacionalmente, ela não tem nada de repentina.
O descompasso escondido
Em Bursting Throughput, a taxa básica cresce com a quantidade de dados no EFS Standard. A AWS documenta 50 KiB/s por GiB, com pelo menos 1 MiB/s de throughput medido para qualquer sistema. Trabalho abaixo da taxa básica acumula créditos; acima dela, consome.
O padrão perigoso é uma carga cuja média de longo prazo supera um pouco essa taxa. O incidente não aparece de imediato porque os créditos acumulados pagam a diferença. Mas o saldo cai todos os dias.
Por que os sintomas apontam para o lugar errado
Quando o armazenamento demora, os workers esperam. No Linux, processos bloqueados em espera ininterruptível por I/O entram no load average; por isso, um gargalo de storage pode parecer falta de processamento. As requisições se acumulam, os pools de workers lotam e os timeouts se espalham, mesmo quando a CPU não é a causa.
Adicionar instâncias pode piorar tudo se cada worker novo aumentar as requisições ao mesmo armazenamento compartilhado já limitado. O gargalo é compartilhado; a concorrência extra só aumenta a pressão.
Seis meses sem falhar provam muito pouco
Um longo período sem falhas só valida a combinação de demanda, taxa básica e créditos restante naquele período. Não prova que a carga se sustenta depois do fim da reserva. Um BurstCreditBalance em queda não é apenas um detalhe de capacidade: é um sinal antecipado de confiabilidade.
O teste de carga deve cobrir o regime contínuo, não só um pico curto. Dez minutos podem mostrar que o teto de burst atende. Dizem pouco sobre um déficit que cresce durante milhares de horas.
Uma sequência melhor de investigação
- Compare uso de CPU, load average e espera por I/O.
- Observe no EFS a métrica
BurstCreditBalanceao longo de semanas ou meses. - Compare
MeteredIOBytescomPermittedThroughput. - Correlacione os limites de armazenamento com latência da aplicação e saturação de workers.
- Confira quanto dado está realmente em Standard: é isso que define a taxa básica de Bursting.
- Decida se a carga combina com Bursting, Elastic ou Provisioned Throughput.
A lição de engenharia
Capacidade de burst é uma reserva, não um plano de capacidade. Serviços baseados em créditos devem ser avaliados pela direção e velocidade do saldo, não só pelo fato de ainda estar acima de zero. O artigo anterior relata o incidente; o próximo transforma a lição num desenho concreto de monitoramento no CloudWatch.