REL05-BP05 Definición de los tiempos de espera del cliente - Pilar de fiabilidad

REL05-BP05 Definición de los tiempos de espera del cliente

Defina tiempos de espera adecuados para las conexiones y las solicitudes, verifíquelos sistemáticamente y no use los valores predeterminados, ya que no tienen en cuenta las características específicas de la carga de trabajo.

Resultado deseado: en los tiempos de espera de los clientes, se debe tener en cuenta el costo para el cliente, el servidor y la carga de trabajo asociados a la espera de las solicitudes que tardan un tiempo anormal en completarse. Dado que no es posible conocer la causa exacta de ningún tiempo de espera, los clientes deben utilizar el conocimiento de los servicios para fijar expectativas sobre las causas probables y los tiempos de espera adecuados

El tiempo de espera de las conexiones del cliente se agota en función de los valores configurados. Cuando el tiempo de espera se agota, los clientes toman la decisión de dar marcha atrás y volver a intentarlo o abrir un disyuntor. Estos patrones evitan que se emitan solicitudes que puedan agravar una condición de error subyacente.

Patrones comunes de uso no recomendados:

  • No estar al tanto de los tiempos de espera del sistema o de los tiempos de espera predeterminados.

  • No estar al tanto del tiempo normal de finalización de las solicitudes.

  • No conocer las posibles causas por las que las solicitudes tardan un tiempo anormalmente largo en completarse ni los costos para el rendimiento del cliente, el servicio o la carga de trabajo asociados a la espera a que se completen.

  • No conocer la probabilidad de que la red deteriorada haga que una solicitud falle solo una vez que se haya agotado el tiempo de espera, ni de los costos que supone para el rendimiento del cliente y la carga de trabajo no utilizar un tiempo de espera más corto.

  • No probar escenarios de tiempo de espera tanto para las conexiones como para las solicitudes.

  • Definir tiempos de espera demasiado altos, lo que puede provocar tiempos de espera prolongados y aumentar el uso de los recursos.

  • Definir tiempos de espera demasiado bajos, lo que provoca errores artificiales.

  • Pasar por alto los patrones para solucionar los errores de tiempo de espera de las llamadas remotas, como disyuntores y reintentos.

  • No considerar la posibilidad de supervisar los índices de errores de las llamadas de servicio, los objetivos de nivel de servicio referentes a la latencia y los valores atípicos de latencia. Estas métricas pueden proporcionar información sobre tiempos de espera agresivos o permisivos

Beneficios de establecer esta práctica recomendada: los tiempos de espera de las llamadas remotas están configurados y los sistemas están diseñados para gestionar los tiempos de espera correctamente, de modo que los recursos se conserven cuando las llamadas remotas responden con una lentitud anormal y los clientes del servicio gestionan correctamente los errores de tiempo de espera.

Nivel de riesgo expuesto si no se establece esta práctica recomendada: alto

Guía para la implementación

Defina un tiempo de espera de conexión y un tiempo de espera de solicitud en cualquier llamada de dependencia del servicio y, normalmente, en todas las llamadas de los procesos. Muchos marcos integran capacidades de tiempo de espera, pero tenga cuidado, ya que algunos tienen valores predeterminados que son infinitos o superiores a lo aceptable para sus objetivos de servicio. Un valor demasiado alto reduce la utilidad del tiempo de espera porque se siguen consumiendo recursos mientras el cliente espera a que transcurra el tiempo de espera. Un valor demasiado bajo puede generar un aumento del tráfico en el backend y un aumento de la latencia debido a que las solicitudes hacen demasiados reintentos. En algunos casos, esto puede producir una interrupción completa si se reintentan todas las solicitudes.

Tenga en cuenta lo siguiente al determinar las estrategias de tiempo de espera:

  • Las solicitudes pueden tardar más de lo normal en procesarse debido a su contenido, a deficiencias en un servicio de destino o a un error en la partición de la red.

  • Las solicitudes con contenido anormalmente caro podrían consumir recursos innecesarios del servidor y del cliente. En este caso, si se agota el tiempo de espera de estas solicitudes y no se vuelven a intentar, se pueden conservar los recursos. Los servicios también deberían protegerse del contenido anormalmente caro con restricciones y tiempos de espera del lado del servidor.

  • Se puede agotar el tiempo de espera y volver a intentar las solicitudes que tarden un tiempo anormalmente largo debido a una interrupción del servicio. Se deben tener en cuenta los costos del servicio de la solicitud y el reintento, pero si la causa es una deficiencia localizada, es probable que el reintento no sea caro y reduzca el consumo de recursos del cliente. El tiempo de espera también puede liberar recursos del servidor según la naturaleza de la deficiencia.

  • Se puede agotar el tiempo de espera y volver a intentar las solicitudes que tarden mucho en completarse porque la red no ha podido entregar la solicitud o la respuesta. Como la solicitud o la respuesta no se han entregado, el resultado habría sido un error independientemente del tiempo de espera. En este caso, el tiempo de espera no liberará los recursos del servidor, pero sí liberará los recursos del cliente y mejorará el rendimiento de la carga de trabajo.

Aproveche patrones de diseño bien establecidos, como los reintentos y los disyuntores, para gestionar los tiempos de espera correctamente y ofrecer enfoques de respuesta rápida a los errores. AWS Los SDK y AWS CLI permiten configurar los tiempos de espera de conexión y solicitud y los reintentos con retrocesos y fluctuaciones exponenciales. Las funciones de AWS Lambda permiten configurar los tiempos de espera y, con AWS Step Functions, se pueden crear disyuntores con poco código que aprovechen las integraciones predefinidas con servicios de AWS y SDK. AWS App Mesh Envoy incluye capacidades de tiempo de espera y de disyuntor.

Pasos para la implementación

  • Configure tiempos de espera en las llamadas de servicio remotas y aproveche las características integradas de tiempo de espera del lenguaje o las bibliotecas de tiempo de espera de código abierto.

  • Cuando su carga de trabajo haga llamadas con un AWS SDK, consulte la documentación para ver la configuración del tiempo de espera específica de cada lenguaje.

  • Cuando utilice AWS SDK o comandos de la AWS CLI en su carga de trabajo, defina los valores predeterminados de tiempo de espera mediante la configuración de los valores predeterminados de configuración de AWS para connectTimeoutInMillis y tlsNegotiationTimeoutInMillis.

  • Aplique las opciones de línea de comandos cli-connect-timeout y cli-read-timeout para controlar comandos únicos de la AWS CLI para los servicios de AWS.

  • Supervise las llamadas de servicio remotas para comprobar si hay tiempos de espera y configure alarmas en caso de errores persistentes para poder gestionar los escenarios de error de forma proactiva.

  • Implemente métricas de CloudWatch y la detección de anomalías de CloudWatch en los índices de error de las llamadas, los objetivos de nivel de servicio en lo que se refiere a la latencia y los valores atípicos de latencia para proporcionar información sobre la administración de tiempos de espera demasiado agresivos o permisivos.

  • Configure los tiempos de espera en las funciones de Lambda.

  • Los clientes de API Gateway deben implementar sus propios reintentos al gestionar los tiempos de espera. API Gateway admite un tiempo de espera de integración de 50 milisegundos a 29 segundos para las integraciones posteriores y no lo vuelve a intentar cuando la integración solicita el tiempo de espera.

  • Implemente el patrón de disyuntor para que no se hagan llamadas remotas cuando se agote el tiempo de espera. Abra el circuito para evitar llamadas fallidas y ciérrelo cuando las llamadas respondan con normalidad.

  • Para las cargas de trabajo basadas en contenedores, consulte las funciones de App Mesh Envoy para aprovechar los tiempos de espera y los disyuntores integrados.

  • Utilice AWS Step Functions para crear disyuntores de poco código para las llamadas de servicio remotas, especialmente cuando se utilizan AWS SDK nativos e integraciones de Step Functions compatibles para simplificar la carga de trabajo.

Recursos

Prácticas recomendadas relacionadas:

Documentos relacionados:

Ejemplos relacionados:

Herramientas relacionadas: