# Arquitetura da carga de trabalho
**Topics**
+ [REL 3 Como você projeta sua arquitetura de serviços de carga de trabalho?](w2aac19b9b7b5.md)
+ [REL 4 Como você projeta interações em um sistema distribuído para evitar falhas?](w2aac19b9b7b7.md)
+ [REL 5 Como você projeta interações em um sistema distribuído para mitigar ou resistir a falhas?](w2aac19b9b7b9.md)
# REL 3 Como você projeta sua arquitetura de serviços de carga de trabalho?
Use uma Service-Oriented Architecture (SOA – Arquitetura orientada por serviços) ou uma arquitetura de microsserviços para criar cargas de trabalho altamente escaláveis e confiáveis. A SOA é a prática de tornar componentes de software reutilizáveis por meio de interfaces de serviço. A arquitetura de microsserviços vai além para tornar os componentes menores e mais simples.
**Topics**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Criar serviços voltados a domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fornecer contratos de serviço por API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Escolher como segmentar a workload
A segmentação de workloads é importante ao determinar os requisitos de resiliência de sua aplicação. Uma arquitetura monolítica deve ser evitada sempre que possível. Em vez disso, considere cuidadosamente quais componentes da aplicação podem ser distribuídos em microsserviços. Dependendo dos requisitos de sua aplicação, isso pode acabar sendo uma combinação de uma arquitetura orientada a serviços (SOA) com microsserviços sempre que possível. Workloads com capacidade para serem do tipo sem estado têm maior chance de serem implantadas como microsserviços.
**Resultado desejado:** as workloads devem ser compatíveis, escaláveis e o mais vagamente agrupadas possível.
Ao tomar decisões sobre como segmentar uma workload, pondere os benefícios e as complexidades. O que é ideal para um novo produto a caminho do seu primeiro lançamento não se aplica a uma workload que foi criada para escalabilidade a partir das necessidades iniciais. Ao refatorar um monólito existente, você vai precisar considerar o quanto a aplicação vai oferecer um bom suporte a uma decomposição em direção à condição sem estado. A divisão dos serviços em pedaços menores permite que equipes pequenas e bem definidas os desenvolvam e gerenciem. No entanto, serviços menores podem introduzir complexidades que incluem maior latência potencial, depuração mais complexa e carga operacional aumentada.
**Antipadrões comuns:**
+ O [microsserviço *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) é uma situação em que os componentes atômicos se tornam tão altamente interdependentes que a falha de um resulta em uma falha muito maior, o que torna os componentes tão rígidos e frágeis quanto um monólito.
**Benefícios do estabelecimento desta prática:**
+ Mais segmentos específicos geram maior agilidade, flexibilidade organizacional e escalabilidade.
+ Redução do impacto das interrupções do serviço.
+ Os componentes da aplicação podem ter requisitos de disponibilidade diferentes, aos quais uma segmentação mais atômica pode oferecer suporte.
+ Responsabilidades bem definidas para as equipes que oferecem suporte à workload.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação de implementação
Escolha o tipo de arquitetura com base no modo como você segmentará a workload. Escolha uma SOA ou arquitetura de microsserviços (ou, em alguns casos, uma arquitetura monolítica). Mesmo que você opte por começar com uma arquitetura monolítica, você deve garantir que ela seja modular e tenha a capacidade de evoluir para SOA ou microsserviços à medida que o produto escala com a adoção do usuário. A SOA e os microsserviços oferecem, respectivamente, segmentação menor, que é preferida como uma arquitetura moderna escalável e confiável, mas há compensações a serem consideradas, especialmente ao implantar uma arquitetura de microsserviços.
Uma compensação primária é que você agora tem uma arquitetura de computação distribuída que pode tornar mais difícil alcançar requisitos de latência do usuário final, e há complexidade adicional na depuração e no rastreamento de interações com o usuário. Use o AWS X-Ray para ajudar você a resolver esse problema. Outro efeito a ser considerado é o aumento da complexidade operacional à medida que você aumenta o número de aplicações que está gerenciando, o que requer a implantação de vários componentes de independência.
![\[Diagrama de comparação entre arquiteturas monolítica, orientada a serviços e de microsserviços\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Etapas da implementação
+ Determine a arquitetura adequada para refatorar ou desenvolver sua aplicação. A SOA e os microsserviços oferecem respectivamente segmentação menor, que é preferida por ser uma arquitetura moderna escalável e confiável. A SOA pode ser o meio-termo ideal para alcançar uma segmentação menor e também evitar algumas das complexidades dos microsserviços. Para obter mais detalhes, consulte [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Se sua carga de trabalho aceitá-la e sua organização puder sustentá-la, use uma arquitetura de microsserviços para obter a melhor agilidade e confiabilidade. Para obter mais detalhes, consulte [Implementação de microsserviços na AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Considere seguir o [*padrão* Strangler Fig](https://martinfowler.com/bliki/StranglerFigApplication.html) para refatorar um monólito em componentes menores. Isso envolve a substituição gradual de componentes específicos da aplicação por novas aplicações e serviços. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) atua como um ponto de partida para refatoração incremental. Para obter mais detalhes, consulte [Migração simplificada de workloads on-premises herdadas usando um padrão strangler](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ A implementação de microsserviços pode exigir um mecanismo de descoberta de serviços para permitir que esses serviços distribuídos se comuniquem entre si. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) pode ser usado com arquiteturas orientadas por serviços para fornecer descoberta confiável e acesso a serviços. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) também pode ser usado para descoberta dinâmica de serviços baseada em DNS.
+ Se você estiver migrando de um monólito para SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) pode ajudar a eliminar a lacuna como um barramento de serviço ao reprojetar aplicações herdadas na nuvem.
+ Para monólitos existentes com um único banco de dados compartilhado, escolha como reorganizar os dados em segmentos menores. Isso pode acontecer por unidade de negócios, padrão de acesso ou estrutura de dados. A esta altura no processo de refatoração, escolha se deseja prosseguir com um banco de dados relacional ou não relacional (NoSQL). Para obter mais detalhes, consulte [De SQL para NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Nível de esforço do plano de implementação:** Alto
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL03-BP02 Criar serviços voltados a domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md)
**Documentos relacionados:**
+ [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [O que é arquitetura orientada a serviços?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Contexto delimitado (um padrão central no design orientado por domínio)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microsserviços - uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html)
+ [Microsserviços na AWS](https://aws.amazon.com/microservices/)
+ [O que é o AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Exemplos relacionados:**
+ [Workshop de modernização iterativa de aplicações](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Vídeos relacionados:**
+ [Delivering Excellence with Microservices on AWS (Entregando excelência com microsserviços na AWS)](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Criar serviços voltados a domínios e funcionalidades de negócios específicos
A arquitetura orientada por serviços (SOA) cria serviços com funções bem delineadas que seguem as necessidades dos negócios. Os microsserviços usam modelos de domínio e contexto controlado para maior limitação de modo que cada serviço execute apenas uma ação. O foco na funcionalidade específica permite diferenciar os requisitos de confiabilidade de serviços diferentes e direcionar os investimentos de forma mais distinta. Um problema de negócio conciso e uma equipe pequena associada a cada serviço também facilitam a escalabilidade organizacional.
Ao projetar uma arquitetura de microsserviços, é útil usar o Design orientado por domínio (DDD) para modelar o problema de negócios usando entidades. Por exemplo, para o site Amazon.com, entidades podem incluir pacote, entrega, programação, preço, desconto e moeda. Em seguida, o modelo é dividido em modelos menores usando o [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), onde entidades que compartilham recursos e atributos semelhantes são agrupadas. Portanto, usar o pacote, a entrega e a programação de exemplo da Amazon.com seria parte do contexto de envio, enquanto preço, desconto e moeda fazem parte do contexto de definição de preço. Com o modelo dividido em contextos, surge um modelo de como delimitar microsserviços.
![\[Modelo de como limitar microsserviços\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/building-services.png)
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Projete a workload de acordo com os domínios de negócios e as respectivas funcionalidades. O foco na funcionalidade específica permite diferenciar os requisitos de confiabilidade de serviços diferentes e direcionar os investimentos de forma mais distinta. Um problema de negócio conciso e uma equipe pequena associada a cada serviço também facilitam a escalabilidade organizacional.
+ Execute a análise de domínio para mapear um Domain-Driven Design (DDD – Projeto orientado por domínio) para sua carga de trabalho. Em seguida, você pode escolher um tipo de arquitetura para atender às necessidades da sua workload.
+ [Como dividir uma monolítica em microsserviços](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Conceitos básicos do DDD quando cercado por sistemas herdados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans “Design Orientado por Domínio: Lidando com a Complexidade no Coração do Software”](https://www.amazon.com/gp/product/0321125215)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Decomponha os serviços nos menores componentes possíveis. Com a arquitetura de microsserviços, você pode separar sua carga de trabalho em componentes com a funcionalidade mínima para permitir escalabilidade e agilidade organizacionais.
+ Defina a API para a carga de trabalho e os respectivos objetivos, limites e outras considerações de uso do projeto.
+ Defina a API.
+ A definição da API deve permitir o crescimento e parâmetros adicionais.
+ Defina as disponibilidades projetadas.
+ Sua API pode ter vários objetivos de projeto para recursos diferentes.
+ Estabeleça limites
+ Use o teste para definir os limites de seus recursos de carga de trabalho.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexto delimitado (um padrão central no design orientado por domínio)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans “Design Orientado por Domínio: Lidando com a Complexidade no Coração do Software”](https://www.amazon.com/gp/product/0321125215)
+ [Conceitos básicos do DDD quando cercado por sistemas herdados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Como dividir uma monolítica em microsserviços](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microsserviços - uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html)
+ [Microsserviços na AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Fornecer contratos de serviço por API
Os contratos de serviço são acordos documentados entre as equipes que envolvem a integração dos serviços e incluem uma definição de API legível por máquina, limites de taxa e expectativas de performance. Uma estratégia de versionamento permite que os clientes continuem usando a API existente e migrem suas aplicações para a API mais recente quando estiverem prontas. A implantação pode acontecer a qualquer momento, desde que o contrato não seja violado. A equipe do provedor de serviços pode usar a pilha de tecnologia de sua preferência para cumprir o contrato de API. Da mesma forma, o consumidor do serviço pode usar sua própria tecnologia.
Os microsserviços levam o conceito de arquitetura orientada a serviços (SOA) ao ponto de criar serviços com um conjunto mínimo de funcionalidades. Cada serviço publica uma API e projeta metas, limites e outras considerações para ele ser utilizado. Isso estabelece um *contrato* com chamadas a aplicações. Assim, três benefícios principais são alcançados:
+ O serviço tem um problema de negócios conciso a ser resolvido e uma equipe pequena responsável por ele. Isso possibilita melhor escalabilidade organizacional.
+ A equipe pode implantar a qualquer momento, desde que atenda aos requisitos de API e a outros requisitos do contrato.
+ A equipe pode usar qualquer pilha de tecnologia desejada, desde que atenda os requisitos de API e outros requisitos do contrato.
O Amazon API Gateway é um serviço totalmente gerenciado que permite aos desenvolvedores criar, publicar, manter, monitorar e proteger APIs em qualquer escala com facilidade. Ele administra todas as tarefas envolvidas no recebimento e processamento de até centenas de milhares de chamadas de API simultâneas, inclusive gerenciamento de tráfego, controle de autorização e acesso, monitoramento, e gerenciamento de versões de API. Usando o OpenAPI Specification (OAS), anteriormente conhecido como Swagger Specification, você pode definir seu contrato de API e importá-lo para o API Gateway. Com o API Gateway, você pode controlar a versão e implantar as APIs.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Baixo
## Orientações para a implementação
+ Forneça contratos de serviço por API. Contratos de serviço são contratos documentados entre equipes na integração de serviços e incluem uma definição de API legível por máquina, limites de taxa e expectativas de performance.
+ [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Uma estratégia de versionamento permite que os clientes continuem usando a API existente e migrem seus aplicativos para a API mais recente quando estiverem prontos.
+ O Amazon API Gateway é um serviço totalmente gerenciado que facilita a criação de APIs em qualquer escala para os desenvolvedores. Ao usar o OpenAPI Specification (OAS), anteriormente conhecido como Swagger Specification, você pode definir seu contrato de API e importá-lo para o API Gateway. Com o API Gateway, você pode controlar a versão e implantar as APIs.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: configurar uma API REST usando o OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexto delimitado (um padrão central no design orientado por domínio)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementação de microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microsserviços - uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html)
+ [Microsserviços na AWS](https://aws.amazon.com/microservices/)
# 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).
**Topics**
+ [REL04-BP01 Identificar qual tipo de sistema distribuído é necessário](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementar dependências com acoplamento fraco](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Fazer um trabalho constante](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Fazer com que todas as respostas sejam idempotentes](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identificar 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.
Os [desafios mais difíceis com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) são para sistemas complexos distribuídos em tempo real, também conhecidos como serviços de solicitação/resposta. O que as dificulta é que as solicitações chegam de forma imprevisível e as respostas devem ser fornecidas rapidamente (por exemplo, o cliente está aguardando ativamente a resposta). Os exemplos incluem servidores Web front-end, pipeline de pedidos, transações de cartão de crédito, todas as APIs da AWS e telefonia.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ 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.
+ [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/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.
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops & Opening Minds: How to Take Control of Systems, Big & Small ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 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 de outros componentes que dependem dele, aumentando a resiliência e a agilidade.
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 só precisem saber a interface versionada e publicada. A implementação de um baixo acoplamento entre dependências isola uma falha em uma dependência para não afetar a outra.
O baixo acoplamento permite adicionar mais código ou recursos a um componente enquanto minimiza o risco para componentes que dependem dele. Além disso, a escalabilidade é melhorada pois você pode aumentar a escala verticalmente ou até mesmo alterar a implementação básica da dependência.
Para melhorar ainda mais a resiliência por meio do baixo acoplamento, torne as interações de componentes assíncronas sempre que possível. Esse modelo é adequado para qualquer interação que não precise de uma resposta imediata e em que uma confirmação de que uma solicitação foi registrada será suficiente. Envolve um componente que gera eventos e outro que os consome. Os dois componentes não se integram por meio de interação direta ponto a ponto, mas geralmente por meio de uma camada de armazenamento durável intermediária, como uma fila do SQS ou uma plataforma de dados de streaming, como o Amazon Kinesis ou o AWS Step Functions.
![\[Diagrama mostrando dependências como sistemas de enfileiramento e balanceadores de carga de acoplamento fraco\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Filas do Amazon SQS e Elastic Load Balancers são apenas duas maneiras de adicionar uma camada intermediária para baixo acoplamento. Arquiteturas orientadas por eventos também podem ser criadas na Nuvem AWS usando o Amazon EventBridge, que pode abstrair clientes (produtores de eventos) dos serviços dos quais eles dependem (consumidores de eventos). O Amazon Simple Notification Service (Amazon SNS) é uma solução eficaz quando você precisa de mensagens de alto throughput, baseadas em push e de muitos para muitos. Usando tópicos do Amazon SNS, seus sistemas de editores podem enviar mensagens para um grande número de endpoints assinantes para processamento paralelo.
Embora as filas ofereçam várias vantagens, na maioria dos sistemas complexos em tempo real, as solicitações mais antigas do que um tempo limite (geralmente segundos) devem ser consideradas obsoletas (o cliente desistiu e não está mais esperando por uma resposta) e não processadas. Dessa forma, as solicitações mais recentes (e provavelmente ainda válidas) podem ser processadas.
**Antipadrões comuns:**
+ Implantar um singleton como parte de uma carga de trabalho.
+ Invocar diretamente as APIs entre níveis de carga de trabalho sem recurso de failover ou processamento assíncrono da solicitação.
**Benefícios do estabelecimento desta prática recomendada:** O baixo acoplamento ajuda a isolar o comportamento de um componente de outros componentes que dependem dele, aumentando a resiliência e a agilidade. A falha em um componente é isolada dos demais.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Implemente 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 de outros componentes que dependem dele, aumentando a resiliência e a agilidade.
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ 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)](https://youtu.be/tvELVa9D9qU)
+ 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)](https://youtu.be/2rikdPIFc_Q)
## Recursos
**Documentos relacionados:**
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops & Opening Minds: How to Take Control of Systems, Big & Small ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 Fazer um trabalho constante
Os sistemas podem falhar quando há alterações grandes e rápidas na carga. Por exemplo, se a sua workload está realizando uma verificação de integridade que monitora a integridade de milhares de servidores, ela 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.
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 importante deixar metade desses servidores com problemas de integridade, o sistema de verificação de integridade ficará sobrecarregado tentando atualizar os sistemas de notificação e comunicar o estado com seus clientes. Portanto, em vez disso, o sistema de verificação de integridade deve enviar o snapshot completo do estado atual a cada vez. Os estados da integridade de 100.000 servidores, cada um representado por um bit, seriam apenas uma carga útil de 12,5 KB. independentemente de nenhum servidor ou falhar, ou todos eles falharem, o sistema de verificação de integridade está realizando um trabalho constante, e alterações grandes e rápidas não são uma ameaça para a estabilidade do sistema. Na verdade, é assim que o Amazon Route 53 lida com as verificações de integridade de endpoints (como endereços IP) para determinar como os usuários finais são roteados para eles.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Baixo
## Orientações para a implementação
+ Faça um trabalho constante para que os sistemas não falhem quando houver mudanças rápidas e grandes na carga.
+ Implemente 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 de outros componentes que dependem dele, aumentando a resiliência e a agilidade.
+ [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclui trabalho constante)](https://youtu.be/O8xLxNje30M?t=2482)
+ Para o exemplo de um sistema de verificação de integridade que monitora 100 mil servidores, crie as workloads de modo que os tamanhos da carga útil permaneçam constantes, seja qual for o número de êxitos ou falhas.
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclui trabalho constante)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops & Opening Minds: How to Take Control of Systems, Big & Small ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Fazer 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.
Em um sistema distribuído, é fácil executar uma ação no máximo uma vez (o cliente faz apenas uma solicitação) ou pelo menos uma vez (continue solicitando até o cliente receber a confirmação do sucesso). Porém, é difícil garantir que uma ação seja idempotente, o que significa que ela é executada *exatamente* uma vez, de modo que fazer várias solicitações idênticas tenha o mesmo efeito de uma única solicitação. Usando tokens de idempotência em APIs, os serviços podem receber uma solicitação mutante uma vez ou mais sem a criação de registros duplicados nem efeitos colaterais.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ 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: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: como garantir a idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [A Amazon Builders’ Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [A Amazon Builders’ Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops & Opening Minds: How to Take Control of Systems, Big & Small ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL 5 Como você projeta interações em um sistema distribuído para mitigar ou resistir a falhas?
Os sistemas distribuídos dependem de 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 permitem que as cargas de trabalho resistam a tensões ou falhas, recuperem-se mais rapidamente delas e reduzam o impacto de tais prejuízos. Como resultado, o Mean Time To Recovery (MTTR – Tempo médio até a recuperação) é melhorado.
**Topics**
+ [REL05-BP01 Implementar uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Controlar o fluxo de solicitações](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Controlar e limitar as chamadas de repetição](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Antecipar-se à falha e filas limitadas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Definir tempos limite do cliente](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Criar serviços sem estado sempre que possível](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementar medidas emergenciais](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implementar uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis
Quando as dependências de um componente não estão íntegras, o próprio componente ainda pode funcionar, embora de maneira prejudicada. Por exemplo, quando há falha em uma chamada de dependência, faça o failover para uma resposta estática predeterminada.
Considere um serviço B que é chamado pelo serviço A e, por sua vez, chama o serviço C.
![\[Diagrama mostrando que o serviço C falha quando chamado do serviço B. O serviço B retorna uma resposta degradada ao serviço A.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
Quando o serviço B chama o serviço C, ele recebeu um erro ou tempo limite dele. O serviço B, sem uma resposta do serviço C (e os dados que ele contém), retorna o que pode. Esse pode ser o último bom valor armazenado em cache, ou o serviço B pode substituir uma resposta estática pré-determinada pelo que receberia do serviço C. Em seguida, ele pode retornar uma resposta degradada ao chamador, o serviço A. Sem essa resposta estática, a falha no serviço C seria feita em cascata por meio do serviço B para o serviço A, resultando em uma perda de disponibilidade.
De acordo com o fator multiplicativo na equação de disponibilidade para dependências rígidas (consulte [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)), qualquer queda na disponibilidade do C afeta gravemente a disponibilidade efetiva do B. Ao retornar a resposta estática, o serviço B atenua a falha em C e, embora degradada, faz com que a disponibilidade do serviço C pareça 100% (supondo que ela retorne de forma confiável a resposta estática sob condições de erro). Observe que a resposta estática é uma alternativa simples para retornar um erro e não é uma tentativa de recalcular a resposta usando meios diferentes. Essas tentativas em um mecanismo completamente diferente para tentar alcançar o mesmo resultado são chamadas de comportamento de fallback e são um antipadrão a ser evitado.
Outro exemplo de degradação tranquila é o *padrão de disjuntor*. Estratégias de repetição devem ser usadas quando a falha é transitória. Quando esse não for o caso, e a operação provavelmente falhar, o padrão do disjuntor impedirá que o cliente execute uma solicitação que provavelmente falhará. Quando as solicitações estão sendo processadas normalmente, o disjuntor está fechado e as solicitações passam. Quando o sistema remoto começa a retornar erros ou exibe alta latência, o disjuntor abre e a dependência é ignorada ou os resultados são substituídos por respostas mais simples, mas menos abrangentes (que podem ser simplesmente um cache de resposta). O sistema periodicamente tenta chamar a dependência para determinar se ela se recuperou. Quando isso acontece, o disjuntor é fechado.
![\[Diagrama mostrando o disjuntor em estados abertos e fechados.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
Além dos estados fechado e aberto mostrados no diagrama, após um período configurável no estado aberto, o disjuntor pode fazer a transição para meio aberto. Nesse estado, ele tenta chamar o serviço periodicamente a uma taxa muito menor do que o normal. Esse teste é usado para verificar a integridade do serviço. Depois de vários êxitos no estado meio aberto, o disjuntor muda para fechado, e as solicitações normais são retomadas.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Implemente uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis. Quando as dependências de um componente não estão íntegras, o próprio componente ainda pode funcionar, embora de maneira prejudicada. Por exemplo, quando há falha em uma chamada de dependência, faça o failover para uma resposta estática predeterminada.
+ Ao retornar uma resposta estática, a workload atenua as falhas que ocorrem nas dependências dela.
+ [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ Detecte quando há probabilidade de falha na operação de repetição e impeça o cliente de fazer chamadas com falha com o padrão de disjuntor.
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (resume “Circuit Breaker” do livro “Release It\$1”)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard “Release It\$1 Design and Deploy Production-Ready Software”](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 Controlar o fluxo de solicitações
O controle de utilização de solicitações é um padrão de atenuação para responder a um aumento inesperado na demanda. Algumas solicitações são atendidas, mas aquelas que ultrapassam um limite definido são rejeitadas e retornam uma mensagem indicando que foram limitadas. A expectativa dos clientes é que eles recuem e abandonem a solicitação ou tentem novamente com uma taxa mais lenta.
Seus serviços devem ser projetados para processar uma capacidade conhecida de solicitações que cada nó ou célula pode processar. Esta capacidade pode ser estabelecida por meio de teste de carga. É preciso acompanhar a taxa de chegada das solicitações e, se ela ultrapassar esse limite, a resposta adequada será indicar que a solicitação foi limitada. Isso permite que o usuário tente outra vez, possivelmente para um nó ou célula diferente que talvez tenha capacidade disponível. O Amazon API Gateway fornece métodos para controle de solicitações. O Amazon SQS e o Amazon Kinesis podem armazenar solicitações em buffer, suavizar a taxa de solicitações e aliviar a necessidade de controle de utilização para solicitações que podem ser abordadas de forma assíncrona.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Controle o fluxo de solicitações. Esse é um padrão de mitigação para responder a um aumento inesperado na demanda. Algumas solicitações são atendidas, mas aquelas que ultrapassam um limite definido são rejeitadas e retornam uma mensagem indicando que foram limitadas. A expectativa dos clientes é que eles recuem e abandonem a solicitação ou tentem novamente com uma taxa mais lenta.
+ Use o Amazon API Gateway
+ [Controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 Controlar e limitar as chamadas de repetição
Use o recuo exponencial para tentar novamente após intervalos progressivamente mais longos. Introduza uma variação para tornar esses intervalos de repetição aleatórios e limite o número máximo de novas tentativas.
Os componentes típicos em um sistema de software distribuído incluem servidores, load balancers, bancos de dados e servidores DNS. Em operação, e sujeito a falhas, qualquer um deles pode começar a gerar erros. A técnica padrão para lidar com erros é implementar novas tentativas no lado do cliente. Essa técnica aumenta a confiabilidade e a disponibilidade do aplicativo. No entanto, em grande escala (e se os clientes tentarem repetir a operação com falha assim que ocorrer um erro) a rede poderá ficar rapidamente saturada com solicitações novas e repetidas, cada uma competindo pela largura de banda da rede. Isso pode resultar em uma *tempestade de repetições,* o que reduzirá a disponibilidade do serviço. Esse padrão pode continuar até que ocorra uma falha completa do sistema.
Para evitar tais cenários, algoritmos de recuo, como o *recuo exponencial* comum, devem ser usados. Os algoritmos de recuo exponencial diminuem gradualmente a taxa na qual novas tentativas são realizadas, evitando assim congestionamentos de rede.
Muitos SDKs e bibliotecas de software, incluindo os da AWS, implementam uma versão desses algoritmos. No entanto, **nunca presuma que exista um algoritmo de recuo, sempre teste e verifique se esse é o caso.**
O recuo simples não é suficiente porque, em sistemas distribuídos, todos os clientes podem recuar simultaneamente, criando clusters de chamadas de repetição. Marc Brooker, em sua publicação de blog [, Recuo exponencial e jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/), explica como modificar a função wait() no recuo exponencial para impedir clusters de chamadas de repetição. A solução é adicionar *jitter* na função wait(). Para evitar tentar novamente por muito tempo, as implementações devem limitar o recuo a um valor máximo.
Por fim, é importante configurar um *número máximo de repetições* ou tempo decorrido, após o qual uma repetição simplesmente falhará. Os AWS SDKs implementam isso por padrão, o que pode ser configurado. Para serviços mais baixos na pilha, um limite máximo de repetição zero ou um pode limitar o risco, mas ainda ser eficaz à medida que novas tentativas forem delegadas a serviços mais altos na pilha.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Controle e limite as chamadas de repetição. Use o recuo exponencial para tentar novamente após intervalos progressivamente mais longos. Introduza uma variação para tornar esses intervalos de repetição aleatórios e limite o número máximo de novas tentativas.
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Os SDKs da Amazon implementam repetições e recuo exponencial por padrão. Implemente uma lógica semelhante em sua camada de dependência ao chamar seus próprios serviços dependentes. Decida quais são os tempos limite e quando parar de tentar novamente com base no seu caso de uso.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 Antecipar-se à falha e filas limitadas
Se a carga de trabalho não puder responder a uma solicitação com êxito, gere uma falha rápida. Isso permite a liberação dos recursos associados a uma solicitação e permite que o serviço se recupere se estiver ficando sem recursos. Se a carga de trabalho puder responder com êxito, mas a taxa de solicitações for muito alta, use uma fila para armazenar as solicitações em buffer. No entanto, não permita filas longas que possam levar ao fornecimento de solicitações obsoletas que o cliente já tinha descartado.
Essa melhor prática se aplica ao lado do servidor, ou receptor, da solicitação.
Esteja ciente de que as filas podem ser criadas em vários níveis de um sistema e podem impedir seriamente a capacidade de recuperação rápida à medida que solicitações antigas obsoletas (que não precisam mais de uma resposta) são processadas antes de solicitações mais recentes. Esteja ciente dos locais onde as filas existem. Elas geralmente se ocultam em fluxos de trabalho ou em trabalhos registrados em um banco de dados.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Antecipe-se à falha e limite filas. Se a carga de trabalho não puder responder a uma solicitação com êxito, gere uma falha rápida. Isso permite a liberação dos recursos associados a uma solicitação e permite que o serviço se recupere se estiver ficando sem recursos. Se a carga de trabalho puder responder com êxito, mas a taxa de solicitações for muito alta, use uma fila para armazenar as solicitações em buffer. No entanto, não permita filas longas que possam levar ao fornecimento de solicitações obsoletas que o cliente já tinha descartado.
+ Implemente antecipação à falha quando o serviço estiver sob pressão.
+ [Falha rápida](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ Filas limitadas. Em um sistema baseado em fila, quando o processamento é interrompido, mas as mensagens continuam chegando, o débito de mensagens pode se acumular em uma lista grande de pendências, aumentando o tempo de processamento. Os resultados podem deixar de ser úteis por conta da demora na conclusão do trabalho, o que afeta principalmente a disponibilidade que o enfileiramento tinha que proteger.
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## Recursos
**Documentos relacionados:**
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Falha rápida](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 Definir tempos limite do cliente
Defina tempos limite adequados, verifique-os sistematicamente e não dependa de valores padrão, já que eles costumam ser muito altos.
Essa melhor prática se aplica ao lado do cliente, ou remetente, da solicitação.
Defina um tempo limite de conexão e um tempo limite de solicitação em qualquer chamada remota e, normalmente, em qualquer chamada entre processos. Muitas estruturas de trabalho oferecem recursos de tempo limite integrados, mas tenha cuidado, porque muitos deles têm valores padrão infinitos ou muito altos. Um valor muito alto reduz a utilidade do tempo limite porque os recursos continuam a ser consumidos enquanto o cliente aguarda o decorrer do tempo limite. Um valor muito baixo pode gerar maior tráfego no back-end e maior latência, porque muitas solicitações são repetidas. Em alguns casos, isso pode levar a interrupções completas porque todas as solicitações estão sendo repetidas.
Para saber mais sobre como a Amazon usa tempos limite, repetições e recuo com tremulação, consulte a [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Defina um tempo limite de conexão e um tempo limite de solicitação em qualquer chamada remota e, normalmente, em qualquer chamada entre processos. Muitas estruturas de trabalho oferecem recursos de tempo limite integrados, mas tenha cuidado, porque muitos deles têm valores padrão infinitos ou muito altos. Um valor muito alto reduz a utilidade do tempo limite porque os recursos continuam a ser consumidos enquanto o cliente aguarda o decorrer do tempo limite. Um valor muito baixo pode gerar maior tráfego no back-end e maior latência, porque muitas solicitações são repetidas. Em alguns casos, isso pode levar a interrupções completas porque todas as solicitações estão sendo repetidas.
+ [AWS SDK: repetições e tempos limite](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## Recursos
**Documentos relacionados:**
+ [AWS SDK: repetições e tempos limite](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 Criar serviços sem estado sempre que possível
Os serviços não devem exigir estado ou devem descarregar o estado de modo que não haja dependência entre solicitações de clientes diferentes em relação aos dados armazenados localmente no disco ou na memória. Isso permite que os servidores sejam substituídos quando necessário sem causar impacto na disponibilidade. O Amazon ElastiCache ou o Amazon DynamoDB são bons destinos para o estado descarregado.
![\[Nesta aplicação Web sem estado, o estado da sessão é descarregado para o Amazon ElastiCache.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
Quando os usuários ou serviços interagem com um aplicativo, eles geralmente executam uma série de interações que formam uma sessão. Uma sessão são dados exclusivos para usuários que persistem entre solicitações enquanto usam o aplicativo. Um aplicativo sem estado é um aplicativo que não precisa de conhecimento de interações anteriores e não armazena informações da sessão.
Depois de projetados para serem sem estado, você pode usar serviços de computação com tecnologia sem servidor, como o AWS Lambda ou o AWS Fargate.
Além da substituição do servidor, outro benefício dos aplicativos sem estado é que eles podem escalar horizontalmente, pois qualquer um dos recursos de computação disponíveis (como instâncias do EC2 e funções do AWS Lambda) pode atender a qualquer solicitação.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Crie aplicações sem estado. Os aplicativos sem estado permitem a escalabilidade horizontal e são tolerantes a falhas de um nó individual.
+ Remova o estado que realmente pode ser armazenado nos parâmetros de solicitação.
+ Depois de examinar se o estado é necessário, mova qualquer rastreamento de estado para um armazenamento em cache resiliente multizona ou armazenamento de dados, como o Amazon ElastiCache, o Amazon RDS, Amazon DynamoDB ou uma solução de dados distribuídos de terceiros. Armazene os estados que não puderam ser movidos para armazenamentos de dados resilientes.
+ Alguns dados (como cookies) podem ser inseridos em cabeçalhos ou parâmetros de consulta.
+ Faça a refatoração para remover o estado que pode ser inserido rapidamente nas solicitações.
+ Alguns dados talvez não sejam realmente necessários por solicitação e podem ser recuperados sob demanda.
+ Remova os dados que podem ser recuperados de forma assíncrona.
+ Escolha um armazenamento de dados que atenda aos requisitos de um estado necessário.
+ Considere um banco de dados NoSQL para dados não relacionais.
## Recursos
**Documentos relacionados:**
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 Implementar medidas emergenciais
Medidas emergenciais são processos rápidos que podem atenuar o impacto da disponibilidade na workload.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Implemente medidas emergenciais. Trata-se de processos rápidos que podem atenuar o impacto da disponibilidade sobre a carga de trabalho. Eles podem ser operados na ausência de uma causa raiz. Uma medida emergencial ideal reduz a carga cognitiva dos resolvedores a zero ao fornecer critérios de ativação e de desativação totalmente determinísticos. Geralmente, as medidas são manuais, mas também podem ser automatizadas
+ Exemplos de medidas incluem
+ Bloquear todo tráfego de robô
+ Servir páginas estáticas em vez de dinâmicas
+ Reduzir a frequência de chamadas a uma dependência
+ Limitar as chamadas de dependências
+ Dicas para implementar e usar medidas emergenciais
+ Quando as medidas forem ativadas, faça MENOS, e não mais
+ Simplifique, evite comportamento bimodal
+ Teste suas medidas periodicamente
+ Veja a seguir exemplos de ações que NÃO são medidas emergenciais
+ Adicionar capacidade
+ Chamar proprietários de serviços de clientes que dependem do seu serviço e solicitar que eles reduzam as chamadas
+ Fazer uma alteração no código e lançá-lo