As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
REL05-BP03 Controle e limite as chamadas de repetição
Use o recuo exponencial para tentar as solicitações novamente em intervalos progressivamente maiores entre cada nova tentativa. Introduza jitter entre as novas tentativas para tornar os intervalos de repetição aleatórios. Limite o número máximo de novas tentativas.
Resultado desejado: componentes típicos em um sistema de software distribuído incluem servidores, balanceadores de carga, bancos de dados e DNS servidores. Durante a operação normal, esses componentes podem responder a solicitações com erros temporários ou limitados, além de erros que seriam persistentes, independentemente de repetições. Quando os clientes fazem solicitações aos serviços, elas consomem recursos, incluindo memória, threads, conexões, portas ou quaisquer outros recursos limitados. Controlar e limitar as repetições é uma estratégia para liberar e minimizar o consumo de recursos para que os componentes do sistema sob pressão não fiquem sobrecarregados.
Quando as solicitações do cliente atingem o tempo limite ou recebem respostas de erro, ele deve determinar se deve ou não tentar novamente. Se tentar novamente, ele o fará com um recuo exponencial com jitter e um valor máximo de nova tentativa. Como resultado, os serviços e os processos de backend recebem alívio da carga e do tempo de recuperação automática, ocasionando uma recuperação mais rápida e atendimento bem-sucedido das solicitações.
Práticas comuns que devem ser evitadas:
-
Implementar novas tentativas sem adicionar recuo exponencial, jitter e valores máximos de novas tentativas. O recuo e o jitter ajudam a evitar picos artificiais de tráfego devido a novas tentativas coordenadas involuntariamente em intervalos comuns.
-
Implementar novas tentativas sem testar seus efeitos ou supor que as novas tentativas já estejam incorporadas e SDK sem testar cenários de repetição.
-
Não entender os códigos de erro publicados das dependências, ocasionando novas tentativas de todos os erros, inclusive aqueles com uma causa clara que indica falta de permissão, erro de configuração ou outra condição que, previsivelmente, não será resolvida sem intervenção manual.
-
Não abordar práticas de observabilidade, incluindo monitoramento e alertas sobre falhas repetidas de serviço para que os problemas subjacentes sejam divulgados e possam ser resolvidos.
-
Desenvolver mecanismos de novas tentativas personalizados quando os recursos de novas tentativas integrados ou de terceiros são suficientes.
-
Tentar novamente em várias camadas da pilha de aplicações de uma forma que agrava as novas tentativas, consumindo ainda mais recursos em uma tempestade de repetições. Entenda como esses erros afetam sua aplicação, as dependências nas quais você confia e implemente novas tentativas em apenas um nível.
-
Tentar novamente chamadas de serviço que não são idempotentes, causando efeitos colaterais inesperados, como resultados duplicados.
Benefícios de implementar esta prática recomendada: as novas tentativas ajudam os clientes a obter os resultados desejados quando as solicitações falham, mas também consomem mais tempo do servidor para obter as respostas bem-sucedidas que eles desejam. Quando as falhas são raras ou transitórias, as novas tentativas funcionam bem. Quando as falhas são causadas pela sobrecarga de recursos, as novas tentativas podem piorar as coisas. Adicionar um recuo exponencial com jitter às novas tentativas do cliente permite que os servidores se recuperem quando as falhas são causadas pela sobrecarga de recursos. O jitter evita o alinhamento das solicitações em picos, e o recuo diminui a escalação de carga causado pela adição de repetições à carga normal da solicitação. Por fim, é importante configurar um número máximo de novas tentativas ou o tempo decorrido para evitar a criação de backlogs que produzam falhas metaestáveis.
Nível de risco exposto se esta prática recomendada não for estabelecida: Alto
Orientação para implementação
Controle e limite as chamadas de novas tentativas. Use o recuo exponencial para tentar novamente após intervalos progressivamente mais longos. Introduza jitter para tornar esses intervalos de novas tentativas aleatórios e limite o número máximo de repetições.
Alguns AWS SDKs implementam novas tentativas e recuos exponenciais por padrão. Use essas AWS implementações integradas quando aplicável em sua carga de trabalho. Implemente uma lógica semelhante em sua workload ao chamar serviços que sejam idempotentes e em que repetições melhorem a disponibilidade do cliente. Decida quais são os tempos limite e quando parar de tentar novamente com base no seu caso de uso. Crie e simule cenários de teste para esses casos de uso de novas tentativas.
Etapas de implementação
-
Determine a camada ideal em sua pilha de aplicações para implementar novas tentativas para os serviços dos quais sua aplicação depende.
-
Esteja ciente de SDKs que existem estratégias de repetição comprovadas com recuo e instabilidade exponenciais para sua linguagem preferida e prefira essas estratégias em vez de escrever suas próprias implementações de repetição.
-
Verifique se os serviços são idempotentes
antes de implementar novas tentativas. Depois que as novas tentativas forem implementadas, elas deverão ser testadas e simuladas regularmente na produção. -
Ao chamar o AWS serviçoAPIs, use AWS SDKsAWS CLIe compreenda as opções de configuração de repetição. Determine se os padrões funcionam para seu caso de uso, teste e ajuste conforme necessário.
Recursos
Práticas recomendadas relacionadas:
Documentos relacionados:
Exemplos relacionados:
Vídeos relacionados:
Ferramentas relacionadas:
