REL05-BP05 Definir tempos limite do cliente - Framework Well-Architected da AWS
Orientação para implementaçãoEtapas de implementaçãoRecursos

REL05-BP05 Definir tempos limite do cliente

Defina tempos limite adequados para conexões e solicitações, verifique-os sistematicamente e não confie nos valores padrão, pois eles não estão cientes das especificações da workload.

Resultado desejado: os tempos limite do cliente devem considerar o custo para o cliente, o servidor e a workload associados à espera por solicitações que levam um tempo anormal para serem concluídas. Como não é possível saber a causa exata de nenhum tempo limite, os clientes devem usar o conhecimento dos serviços para desenvolver expectativas de causas prováveis e prazos apropriados.

As conexões do cliente atingem o tempo limite com base nos valores configurados. Depois de encontrar um tempo limite, os clientes tomam a decisão de recuar e tentar novamente ou abrir um disjuntor. Esses padrões evitam a emissão de solicitações que podem exacerbar uma condição de erro subjacente.

Práticas comuns que devem ser evitadas:

  • Não estar ciente dos tempos limite do sistema ou dos tempos limite padrão.

  • Não estar ciente do tempo normal de conclusão da solicitação.

  • Não estar ciente das possíveis causas das solicitações levarem muito tempo para serem concluídas ou dos custos de performance do cliente, do serviço ou da workload associados à espera por essas conclusões.

  • Não estar ciente da probabilidade de uma rede danificada fazer com que uma solicitação falhe somente quando o tempo limite é atingido e dos custos para a performance do cliente e da workload por não adotar um tempo limite mais curto.

  • Não testar cenários de tempo limite tanto para conexões quanto para solicitações.

  • Definir tempos limite muito altos, o que pode resultar em longos tempos de espera e aumentar a utilização de recursos.

  • Definir tempos limite muito baixos, gerando falhas artificiais.

  • Ignorar padrões para lidar com erros de tempo limite para chamadas remotas, como disjuntores e novas tentativas.

  • Não considerar o monitoramento de taxas de erro de chamadas de serviço, objetivos de nível de serviço para latência e valores atípicos de latência. Essas métricas podem fornecer informações sobre tempos limite agressivos ou permissivos.

Benefícios de implementar esta prática recomendada: os tempos limite de chamadas remotas são configurados e os sistemas são projetados para lidar com os tempos limite normalmente de forma que os recursos sejam conservados quando as chamadas remotas respondem de forma anormalmente lenta e os erros de tempo limite sejam tratados normalmente pelos clientes do serviço.

Nível de risco exposto se esta prática recomendada não for estabelecida: Alto

Orientação para implementação

Defina um tempo limite de conexão e um tempo limite de solicitação em qualquer chamada de dependência de serviço e, geralmente, em qualquer chamada entre processos. Muitas frameworks oferecem recursos de tempo limite integrados, mas tenha cuidado, pois algumas têm valores padrão infinitos ou superiores ao aceitável para seus objetivos de serviço. 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 backend 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.

Considere o seguinte ao determinar as estratégias de tempo limite:

  • As solicitações podem levar mais tempo do que o normal para serem processadas devido ao conteúdo, a deficiências em um serviço de destino ou a uma falha na partição de rede.

  • Solicitações com conteúdo anormalmente caro podem consumir recursos desnecessários do servidor e do cliente. Nesse caso, reduzir o tempo limite dessas solicitações e não tentar novamente pode preservar os recursos. Os serviços também devem se proteger de conteúdo anormalmente caro com limitações e tempos limite do servidor.

  • Solicitações que demoram muito devido a uma falha no serviço podem expirar e ser repetidas. Deve-se considerar os custos do serviço para a solicitação e a nova tentativa, mas se a causa for uma deficiência localizada, uma nova tentativa provavelmente não será cara e reduzirá o consumo de recursos do cliente. O tempo limite também pode liberar recursos do servidor, dependendo da natureza da deficiência.

  • Solicitações que demoram muito para serem concluídas porque a solicitação ou a resposta não foi entregue pela rede podem expirar e ser repetidas. Como a solicitação ou a resposta não foi entregue, a falha teria sido o resultado, independentemente da duração do tempo limite. Nesse caso, o tempo limite não liberará recursos do servidor, mas liberará recursos do cliente e melhorará a performance da workload.

Aproveite os padrões de design bem estabelecidos, como novas tentativas e disjuntores, para lidar com os tempos de espera de forma eficiente e oferecer compatibilidade com abordagens de antecipação à falha. AWS Os SDKs e a AWS CLI permitem a configuração de tempos limite de conexão e solicitação e novas tentativas com recuo exponencial e jitter. As funções do AWS Lambda são compatíveis com a configuração de tempos limite. E, com o AWS Step Functions, você pode criar disjuntores com pouco código que aproveitam as integrações pré-construídas com os serviços e SDKs da AWS. AWS App Mesh O Envoy oferece recursos de tempo limite e disjuntor.

Etapas de implementação

  • Configure tempos limite em chamadas de serviço remoto e utilize os recursos de tempo limite de linguagem integrados ou as bibliotecas de tempo limite de código aberto.

  • Quando sua workload fizer chamadas com um AWS SDK, revise a documentação para saber a configuração de tempo limite específica da linguagem.

  • Ao usar AWS SDKs ou comandos da AWS CLI em sua workload, configure os valores de tempo limite padrão definindo os padrões de configuração da AWS para connectTimeoutInMillis e tlsNegotiationTimeoutInMillis.

  • Aplique opções de linha de comando cli-connect-timeout e cli-read-timeout para controlar comandos da AWS CLI únicos para serviços da AWS.

  • Monitore o tempo limite de chamadas de serviço remoto e defina alarmes para erros persistentes para que você possa lidar proativamente com cenários de erro.

  • Implemente métricas do CloudWatch e detecção de anomalias do CloudWatch em taxas de erro de chamada, objetivos de nível de serviço para latência e valores atípicos de latência para fornecer informações sobre o gerenciamento de tempos limite excessivamente agressivos ou permissivos.

  • Configure tempos limite nas funções do Lambda.

  • Os clientes do API Gateway devem implementar suas próprias repetições ao lidar com os tempos limite. O API Gateway oferece suporte a um tempo limite de integração de 50 milissegundos a 29 segundos para integrações downstream e não tenta novamente quando a integração solicita o tempo limite.

  • Implemente o padrão de disjuntor para evitar fazer chamadas remotas quando o tempo limite está prestes a ser atingido. Abra o circuito para evitar falhas nas chamadas e feche-o quando as chamadas estiverem respondendo normalmente.

  • Para workloads baseadas em contêineres, revise os recursos do App Mesh Envoy para aproveitar os tempos limite e os disjuntores integrados.

  • Use o AWS Step Functions para criar disjuntores de pouco uso de código para chamadas de serviço remoto, especialmente ao chamar SDKs nativos da AWS e integrações do Step Functions compatíveis para simplificar sua workload.

Recursos

Práticas recomendadas relacionadas:

Documentos relacionados:

Exemplos relacionados:

Ferramentas relacionadas: