REL 4: Como você projeta interações em um sistema distribuído para evitar falhas?

Os sistemas distribuídos dependem das redes de comunicação para interconectar componentes, como servidores ou serviços. Sua carga de trabalho deve operar de forma confiável, apesar da perda de dados ou da latência nessas redes. Os componentes do sistema distribuído devem operar sem afetar negativamente outros componentes ou a carga de trabalho. Essas melhores práticas evitam falhas e melhoram o Mean Time Between Failures (MTBF – Tempo médio entre falhas).

Recursos

AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability)
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
Amazon EC2: Ensuring Idempotency
The Amazon Builders' Library: Challenges with distributed systems

Melhores práticas:

• Identifique qual tipo de sistema distribuído é necessário: Os sistemas distribuídos em tempo real rígidos exigem respostas síncronas e rápidas, enquanto os sistemas em tempo real flexíveis têm uma janela de tempo para resposta maior, de minutos ou mais. Os sistemas off-line gerenciam as respostas por meio do processamento em lote ou assíncrono. Os sistemas distribuídos em tempo real rígidos têm os requisitos de confiabilidade mais rigorosos.

• Implementar dependências com acoplamento fraco: As dependências, como sistemas de enfileiramento, sistemas de streaming, fluxos de trabalho e load balancers, têm acoplamento fraco. O baixo acoplamento ajuda a isolar o comportamento de um componente dos outros componentes que dependem dele, o que aumenta a resiliência e a agilidade

• Faça com que todas as respostas sejam idempotentes: Um serviço idempotente garante que cada solicitação seja concluída exatamente uma vez, de modo que fazer várias solicitações idênticas tem o mesmo efeito de uma única solicitação. Um serviço idempotente facilita para um cliente implementar novas tentativas sem o receio de que uma solicitação seja processada erroneamente várias vezes. Para fazer isso, os clientes podem emitir solicitações de API com um token de idempotência. O mesmo token é usado sempre que a solicitação é repetida. Uma API de serviço idempotente usa o token para retornar uma resposta idêntica à resposta que foi retornada na primeira vez que a solicitação foi concluída.

• Faça um trabalho constante: Os sistemas podem falhar quando há alterações grandes e rápidas na carga. Por exemplo, um sistema de verificação de integridade que monitora a integridade de milhares de servidores deve sempre enviar a carga útil com o mesmo tamanho (um snapshot completo do estado atual). Se houver uma falha em todos os servidores ou se não houver falha alguma, o sistema de verificação de integridade realizará um trabalho constante sem alterações grandes e rápidas.

Plano de melhoria

Identifique qual tipo de sistema distribuído é necessário

Identifique qual tipo de sistema distribuído é necessário: Os desafios dos sistemas distribuídos envolviam latência, escalabilidade, conhecimento das APIs de rede, marshalling e unmarshalling de dados e complexidade de algoritmos, como Paxos. À medida que os sistemas crescem e se tornam mais distribuídos, o que antes eram casos de borda hipotéticos se tornam ocorrências regulares.
The Amazon Builders' Library: Challenges with distributed systems

• Os sistemas distribuídos em tempo real rígidos exigem respostas síncronas e rápidas.
• Os sistemas em tempo real flexíveis têm uma janela de tempo para resposta maior, de minutos ou mais
• Os sistemas off-line gerenciam as respostas por meio do processamento em lote ou assíncrono.
• Os sistemas distribuídos em tempo real rígidos têm os requisitos de confiabilidade mais rigorosos.

Implementar dependências com acoplamento fraco

Implementar dependências com acoplamento fraco: As dependências, como sistemas de enfileiramento, sistemas de streaming, fluxos de trabalho e load balancers, têm acoplamento fraco. O baixo acoplamento ajuda a isolar o comportamento de um componente dos outros componentes que dependem dele, o que aumenta a resiliência e a agilidade
AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?

• O Amazon EventBridge permite criar arquiteturas orientadas por eventos, que são acopladas de maneira fraca e distribuídas
  AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)
• Se as alterações em um componente forçarem outros componentes que dependem dele a serem também alterados, eles serão fortemente acoplados. O baixo acoplamento interrompe essa dependência para que os componentes dependentes precisem apenas reconhecer a interface versionada e publicada.
• Sempre que possível, crie interações de componentes assíncronas. Esse modelo é adequado para qualquer interação que não precise de uma resposta imediata e quando uma confirmação de que uma solicitação foi registrada é suficiente.
  AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)

Faça com que todas as respostas sejam idempotentes

Faça com que todas as respostas sejam idempotentes: Um serviço idempotente garante que cada solicitação seja concluída exatamente uma vez, de modo que fazer várias solicitações idênticas tem o mesmo efeito de uma única solicitação.

• Os clientes podem emitir solicitações de API com um token de idempotência. O mesmo token é usado sempre que a solicitação é repetida. Uma API de serviço idempotente usa o token para retornar uma resposta idêntica à resposta que foi retornada na primeira vez que a solicitação foi concluída.
  Amazon EC2: Ensuring Idempotency

Faça um trabalho constante

Faça um trabalho constante: Os sistemas podem falhar quando há alterações grandes e rápidas na carga
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)

• Crie as cargas de trabalho de modo que os tamanhos da carga útil permaneçam iguais, seja qual for o número de êxitos ou falhas.
  • Por exemplo, se o sistema de verificação de integridade estiver monitorando 100.000 servidores, a carga nele será nominal a uma taxa de falha do servidor normalmente leve. No entanto, se um evento crítico fizer com que metade desses servidores se torne não íntegra, o sistema de verificação de integridade ficará sobrecarregado ao tentar atualizar os sistemas de notificação e comunicar o estado aos clientes dele. Em vez disso, o sistema de verificação de integridade deve sempre enviar o snapshot completo do estado atual. Os estados da integridade de 100.000 servidores, cada um representado por um bit, seriam apenas uma carga útil de 12,5 KB. Se houver uma falha em todos os servidores ou se não houver falha alguma, o sistema de verificação de integridade realizará um trabalho constante, e as alterações grandes e rápidas não serão uma ameaça à estabilidade do sistema. Na verdade, é assim que o plano de controle é projetado para as verificações de integridade do Amazon Route 53.