- Engenheiros de sistemas distribuídos muitas vezes aprendem por meio das cicatrizes causadas por erros em produção
- Este texto foi escrito para evitar que novos engenheiros passem por essas mesmas cicatrizes
Sistemas distribuídos falham com frequência
- Diferentemente de outras áreas da engenharia de software, sistemas distribuídos têm alta probabilidade de falha. Em especial, a probabilidade de falhas parciais é alta.
- Engenheiros de sistemas sem experiência em computação distribuída costumam sugerir ideias como "é só enviar a gravação para dois sistemas" ou "basta continuar tentando gravar até dar certo"
- Sistemas em rede falham com mais frequência do que uma máquina única, e essas falhas tendem a ser parciais
- Uma das gravações pode ter sucesso e a outra falhar; então, como obter uma visão consistente dos dados agora? Essas falhas parciais são muito mais difíceis de raciocinar
- Podem ocorrer problemas como queda de switch, o líder "sumir" por causa do garbage collection, ou uma escrita em socket parecer bem-sucedida quando na verdade falhou. Ler da memória local é muito mais confiável do que ler através de alguns switches
- É preciso "projetar para a falha"
Escrever sistemas distribuídos robustos custa mais caro
- Para criar uma solução distribuída robusta, o custo é maior do que o de uma solução em máquina única.
- Máquinas virtuais e tecnologias de nuvem tornaram a engenharia de sistemas distribuídos mais barata, mas ainda assim ela continua exigindo muito investimento.
- Simulações são úteis, mas não conseguem resolver todos os problemas que surgem em um ambiente distribuído real.
Sistemas distribuídos robustos de código aberto são raros
- O custo de operar muitas máquinas por longos períodos é um peso para a comunidade open source.
- Pessoas que escrevem código open source como hobby não têm recursos financeiros suficientes para explorar ou resolver muitos dos problemas de sistemas distribuídos.
- Alguns problemas são resolvidos por engenheiros de empresas, mas as prioridades deles nem sempre estão alinhadas.
Coordenação é muito difícil. Evite-a sempre que possível
- A essência da escalabilidade horizontal é a independência. É preciso minimizar a comunicação e o consenso entre máquinas.
- Sempre que duas máquinas precisam concordar sobre algo, a implementação do serviço fica mais difícil.
- O algoritmo Paxos é extremamente difícil de implementar.
Se o problema cabe na memória, provavelmente é trivial
- Para engenheiros de sistemas distribuídos, problemas limitados a uma única máquina são considerados fáceis.
- Quando os dados estão a alguns switches de distância, processá-los rapidamente é mais difícil.
"Lentidão" é o problema mais difícil
- "Lentidão" pode significar que um ou mais dos vários sistemas que atendem a uma solicitação do usuário estão lentos.
- Falhas parciais não aparecem em gráficos e, até que fiquem evidentes, é difícil conseguir os recursos necessários para resolvê-las.
É preciso implementar backpressure em todo o sistema
- Backpressure significa sinalizar falhas do sistema fornecedor para o sistema solicitante, e o sistema solicitante saber como lidar com essas falhas.
- Sem um mecanismo de backpressure, é muito provável que ocorram falhas em cascata ou perda não intencional de mensagens.
É preciso encontrar maneiras de ser parcialmente disponível
- Isso significa a capacidade de retornar alguns resultados mesmo quando parte do sistema falha.
- Por exemplo, um sistema de busca pode retornar os resultados coletados se não conseguir pesquisar todos os documentos dentro de um determinado tempo.
Métricas são a única forma de fazer o trabalho
- Expor métricas é a única forma de entender como o sistema realmente funciona.
- Arquivos de log são úteis, mas muitas vezes mentem. Logs de sucesso geralmente são redundantes na maior parte dos casos, por isso não são registrados.
Use percentis, não médias
- Percentis são mais precisos e úteis do que médias. Médias frequentemente levam a decisões erradas.
É preciso aprender a estimar capacidade
- Saber quantas máquinas são necessárias para executar uma tarefa é importante.
- Por exemplo, é comum fazer cálculos de guardanapo sobre quantos IDs de tweet cabem na memória.
Feature flags são a forma de fazer rollout de infraestrutura
- Feature flags são uma forma comum de fazer rollout de novas funcionalidades no sistema.
- Com feature flags, é possível ganhar confiança no projeto e reduzir o custo de falhas.
É preciso escolher o espaço de IDs com sabedoria
- O espaço de IDs de um sistema molda a estrutura do próprio sistema.
- Por exemplo, os IDs de tweet da API do Twitter são simples números de 64 bits, sem ligação com outros dados.
É preciso aproveitar a localidade dos dados
- Manter o processamento e o cache dos dados próximos do armazenamento persistente é mais eficiente.
- A rede sofre mais falhas e latência do que um dereference de ponteiro e
fread(3).
Regravar dados em cache no armazenamento persistente é ruim
- Muitos sistemas sofrem com esse problema. Ele aparece com frequência especialmente em sistemas projetados por pessoas com pouca experiência em sistemas distribuídos.
Computadores conseguem fazer mais do que você imagina
- Há muita desinformação sobre a capacidade dos computadores vinda de profissionais menos experientes.
- Servidores web modernos conseguem processar milhares de requisições em algumas centenas de milissegundos.
Use o teorema CAP para criticar sistemas
- O teorema CAP não é algo que se usa para construir sistemas. No entanto, ele é útil para criticar o design de sistemas distribuídos.
É preciso extrair serviços
- Aqui, serviços significam sistemas distribuídos que contêm lógica em um nível mais alto do que sistemas de armazenamento.
- Extrair serviços permite implantar de forma mais rápida e fácil do que criar bibliotecas.
Resumo do GN⁺
- A engenharia de sistemas distribuídos é diferente de outras áreas da engenharia de software por causa da alta probabilidade de falhas e das falhas parciais.
- Escrever sistemas distribuídos robustos custa mais caro, e eles são raros na comunidade open source.
- É importante entender e implementar conceitos como coordenação, localidade de dados, backpressure e disponibilidade parcial.
- O uso de métricas e percentis, feature flags e a escolha do espaço de IDs podem aumentar a eficiência e a estabilidade do sistema.
- É recomendável usar o teorema CAP para criticar sistemas e extrair serviços quando necessário.
1 comentários
Comentário no Hacker News
O princípio CALM (Consistency as Logical Monotonicity) é mais fácil de entender do que CAP e é um resultado mais fundamental
Entrega exatamente uma vez é impossível; é preciso escolher entre entrega no máximo uma vez ou no mínimo uma vez
Bom artigo. Embora tenha sido escrito há 8 anos, ainda há muito conteúdo que continua válido
Links para discussões anteriores:
Gosto da explicação prática e realista. Não há jargões da moda como "microservices"
Quando trabalhava na Lookout, Jeff Hodges apresentou este ensaio
Já tive a experiência de trabalhar com o autor deste texto
Muita coisa mudou desde 2013