Papers
Metastable Failures in Distributed Systems
Nathan Bronson, Abutalib Aghayev, Aleksey Charapko, Timothy Zhu · HotOS 2021 (Workshop on Hot Topics in Operating Systems), 2021
O problema: sistemas que quebram sem nenhum defeito aparente
Os autores partem de cerca de uma década de experiência operando sistemas distribuídos de grande escala para descrever um padrão de falha que pode derrubar um serviço mesmo sem falha de hardware, configuração errada ou bug de software. Esses incidentes se parecem com cisnes negros: nada no histórico avisa que vão acontecer, o impacto é severo e eles são muito mais fáceis de explicar depois do que de prever. Na superfície, cada incidente parece único, com gatilho e sintomas diferentes, mas o paper defende que todos compartilham uma estrutura comum, e por isso propõe um framework para descrevê-los. O texto aplica esse framework a exemplos vividos pelos próprios autores e faz um levantamento de correções ad hoc que equipes criaram depois que o estrago aconteceu. A conclusão é honesta: uma abordagem sistemática para construir sistemas robustos contra falhas metaestáveis ainda desconhecidas continua sendo um problema em aberto. Trata-se de um artigo de workshop (HotOS), ou seja, de posicionamento e conceituação, não de um sistema novo avaliado com benchmarks. Seu valor está em dar nome e vocabulário a um tipo de outage que engenheiros de plantão já conheciam, mas tinham dificuldade de classificar.
A ideia central: gatilho, estado vulnerável e efeito sustentador
Uma falha metaestável ocorre em sistemas abertos, isto é, com uma fonte de carga que o sistema não controla (clientes que continuam chegando). Um gatilho empurra o sistema para um estado ruim que persiste mesmo depois que o gatilho desaparece. O que mantém o sistema preso nesse estado é um efeito sustentador: um ciclo de realimentação que amplifica o trabalho (por exemplo, mais tentativas de requisição gerando mais carga) e que costuma esgotar algum recurso. Por isso o paper sustenta que a causa-raiz real é o ciclo sustentador, e não o gatilho: vários gatilhos diferentes (um pico de carga, uma falha breve, um deploy) podem levar ao mesmo estado de falha, então tratar apenas o gatilho previne pouco. Existe ainda o conceito de estado vulnerável: o sistema funciona bem sob carga alta enquanto nenhuma sobrecarga temporária acontece, mas basta um gatilho para iniciar a amplificação e levá-lo ao estado metaestável. Muitos sistemas de produção operam em estado vulnerável de forma permanente, porque ele é mais eficiente do que operar com folga. Para sair do estado metaestável costuma ser preciso uma ação corretiva forte, como reduzir drasticamente a carga ou reiniciar o sistema, e não apenas esperar o gatilho passar.
Exemplos clássicos: retentativas e cache look-aside
Duas fontes de amplificação aparecem como exemplos centrais. A primeira são as retentativas (retries): elas mascaram falhas transitórias e melhoram a experiência no caso comum, mas acrescentam trabalho justamente quando o sistema está sobrecarregado. Filas crescem, a latência sobe, os clientes estouram o timeout antes de receber resposta e reenviam o pedido, enquanto o servidor gasta capacidade em requisições que ninguém mais está esperando; o resultado é um sistema ainda ativo, porém entregando pouco trabalho útil. A segunda é o cache look-aside, que é uma otimização do caso comum. Num exemplo ilustrativo usado em resumos do paper, com taxa de acerto de 90%, apenas 1 em cada 10 requisições chega ao banco, então o mesmo banco sustenta cerca de 3.000 QPS no total, mas só aguentaria cerca de 300 QPS se todas as requisições chegassem a ele. Se o cache é perdido, a carga no banco se multiplica por 10. Acima de 300 QPS o sistema está, portanto, em estado vulnerável: tudo funciona, mas uma perda do cache vira uma sobrecarga que o banco não consegue drenar, mantendo a falha. O paper também menciona outros mecanismos, como tratamento lento de erros e efeitos emergentes de balanceamento de carga.
Trade-off e mitigações: otimizar o caso comum cria fragilidade
O trade-off central é que otimizações do caso comum (cache, retentativas, operar perto do limite de capacidade) tornam o sistema mais eficiente e mais barato, mas o aproximam de um estado vulnerável em que uma sobrecarga temporária dispara um ciclo de amplificação. Segundo resumos do paper, as mitigações discutidas atacam o ciclo sustentador em vez de apenas o gatilho: mudar a política do sistema durante a sobrecarga, priorizar e impor justiça entre requisições, usar caminhos rápidos de erro e tratamento de outliers, e autoescalar. Também se menciona o alinhamento de incentivos organizacionais, para que times não sejam recompensados por mudanças que melhoram métricas do dia a dia mas adicionam fragilidade, e a criação de uma métrica característica que mostre o estado do ciclo de realimentação, de modo a prever falhas antes que ocorram, o que aproxima sistemas distribuídos da teoria de controle. Vale a ressalva do próprio paper: ele apresenta correções ad hoc e deixa em aberto uma abordagem sistemática. Um crítico, Marc Brooker, também argumenta que as ideias têm precedentes em teoria de controle e pesquisa operacional, então a novidade está mais no enquadramento do que em um fenômeno inédito.
Legado: da ideia à evidência empírica em incidentes reais
O vocabulário do paper foi adotado e testado por trabalho posterior. O estudo 'Metastable Failures in the Wild' (OSDI 2022) analisou incidentes reais e encontrou 22 falhas metaestáveis em 11 organizações, de grandes provedores a empresas pequenas. Ele também relata que pelo menos 4 de 15 grandes outages da AWS na última década foram causados por esse tipo de falha, e estende o modelo original com dois tipos de gatilho e dois tipos de mecanismo de amplificação, confirmados com aplicações de exemplo que reproduzem as falhas em ambiente controlado. Um resumo secundário desse estudo afirma que a amplificação por retentativas foi o efeito sustentador mais comum, presente em mais da metade dos incidentes; esse número vem de fonte secundária e deve ser lido com cautela. Na prática de design de sistemas, o paper serve de lente para revisar decisões comuns em entrevistas e em produção: política de retry com limites, proteção contra perda total de cache, controle de admissão e descarte de carga sob sobrecarga, e atenção a sinais precoces como outliers de latência, que segundo resumos do paper frequentemente aparecem antes do incidente.
Veja as ideias em ação
Pratique na escola de System Design os desenhos que usam este paper.