Single point of failure

Práticas mínimas para garantir integridade frente a eventos imprevisíveis.

Single point of failure (ponto único de falha) é o termo usado para falar sobre uma parte da rede ou de um software que é intolerante a falhas, e cuja queda ocasiona a indisponibilidade do serviço ou da rede inteira.

Exemplos de SPOF

  • Banco de dados único, sem réplica
  • Load balancer único (sem redundância no próprio LB)
  • DNS com um único provedor
  • Serviço rodando em uma única AZ, região ou datacenter
  • Certificado SSL ou domínio que expira sem alerta
  • Uma única pessoa que sabe operar um sistema crítico (bus factor, o SPOF “humano”)
  • Dependência de um único fornecedor terceiro (API externa, gateway de pagamento)
  • Fila de mensagens sem cluster
  • Chave de criptografia ou secret guardado em um único lugar, sem backup

Pensar na arquitetura de um sistema é ficar colocando na balança o que vale ou não a pena priorizar, implementar ou simplesmente deixar de lado. Não existem recursos infinitos, nem tempo infinito.

Então a pergunta geralmente gira em torno de:

“Qual o impacto financeiro ou na confiabilidade se eu não implementar isso?” “Quais as chances disso realmente parar?” “Quanto tempo leva para implementar? Temos prazo?”

É a partir dessas respostas que você decide o que vira redundância, failover ou health check agora, e o que fica documentado como risco aceito por enquanto.

Ver SPOF em empresa é o normal.

Ver SPOF prestes a explodir, e ninguém sabendo que ele existe, não deveria ser.

Como mitigar um SPOF

Existem diversas formas de mitigar um ponto único de falha. O mais ideal é sempre buscar redundância, mas em um ambiente com recursos escassos isso pode não ser viável. Nesses casos, o caminho é monitorar e desacoplar o SPOF do restante do sistema.

  1. Health checks: verificações periódicas do SPOF somadas a uma notificação, para garantir que a equipe seja avisada quando o recurso começa a apresentar problemas (tempo de resposta crescente, limite de recursos e aumento de erros, por exemplo).

    Um ponto importante aqui: garanta que as notificações sejam bem feitas. Não notifique sobre tudo. O intuito da notificação é alertar e chamar a atenção da equipe. Excesso causa o efeito oposto, fazendo um problema crítico passar batido no meio de tantas notificações. Se seu elemento dispara muitos erros críticos, algo de errado está acontecendo. Se ele dispara muitas notificações já previstas, você não filtrou o suficiente.

  2. Graceful degradation: é ter um plano B caso o SPOF caia.

    Em uma aplicação, o banco de dados é geralmente o SPOF mais comum. Se ele cair, sua aplicação cai junto. Então como evitar isso?

    Primeiro, mapeie onde o seu banco é consultado. Segundo, decida o que a aplicação vai fazer com os trabalhos em andamento. Terceiro, defina o que vai acontecer quando o banco voltar.

    Exemplo: seu banco de dados caiu. Clientes não conseguem criar conta nem fazer login, porque os dois casos requisitam o banco de dados. Mas o que acontece com os clientes que já estavam logados? Vamos derrubar a sessão de todos? E as funcionalidades, alguma delas pode ser assíncrona?

    Adicione mensageria. Avise ao cliente que a ação dele está sendo processada. Uma função assíncrona rodando em background identifica o que ficou pendente nesse período e executa de maneira gradual para evitar sobrecargas.

    O ponto principal aqui é a experiência de quem importa.

    Vale para outras peças também. Se o Redis é responsável pelo rate limiting, considere desativá-lo temporariamente em vez de derrubar o sistema inteiro. A balança aqui é trocar segurança por satisfação do cliente. Quanto custa para sua empresa um cliente insatisfeito? Qual o índice de incidentes de brute-force?

    Caso exista margem de tempo e uma equipe grande o suficiente, para validar as mitigações é recomendado uma engenharia do caos, técnica de derrubar um nó propositalmente em um ambiente controlado para provar que a mitigação funcionou.

    Quer ver mais sobre isso? Estude Circuit Breakers e Chaos Engineering.

Como resolver um SPOF

Se o seu servidor físico é o SPOF, você precisa ter mais servidores. Se o seu resolvedor de DNS é o SPOF, você precisa ter mais de um resolvedor. Se o seu banco de dados é o SPOF, você precisa ter uma replicação do banco de dados. Se o seu SPOF é uma pessoa, a redundância vem de documentação e de mais gente sabendo operar aquilo, não de mais um servidor.

E elevando um nível acima, se sua infra está toda em uma única região de datacenters, o ideal é multi-region ou multi-az. Mas você sabe que isso não é realidade na maioria dos casos.

Redundância custa dinheiro, então a decisão nunca é “ter redundância em tudo”. É voltar para aquelas perguntas lá do início: qual o impacto, qual a chance disso cair, quanto custa implementar. Redundância entra na lista quando a resposta dessas perguntas pesa mais que o custo de manter duas ou mais cópias de algo rodando.

Mas vale uma atenção aqui, a redundância deve ser bem configurada, caso contrário você pode enfrentar o que chamamos de “split-brain”, que é, em resumo as duas instâncias acharem que são a principal e corromperem os dados.

No fim, SPOF não se resolve de uma vez só. Você mapeia, prioriza, resolve com redundância o que dá pra resolver e monitora de perto o que sobrou. O sistema não precisa ser perfeito, só precisa não cair inteiro quando uma peça falhar.

Se quiser se aprofundar em como distribuir carga sem criar um SPOF no meio do caminho, escrevi sobre isso em Tudo que você precisa saber sobre Load Balancing, onde também falo de health checks na prática.