Tiempos de espera, reintentos y retardo con fluctuación

Cada vez que un servicio o un sistema llama a otro, pueden producirse errores. Estos errores pueden tener su origen en varios factores. Entre ellos se incluyen servidores, redes, balanceadores de carga, software, sistemas operativos o incluso errores de los operadores del sistema. Diseñamos nuestros sistemas con el fin de reducir la posibilidad de que ocurran errores, pero es imposible crear sistemas que nunca los cometan. Por lo tanto, en Amazon diseñamos los sistemas para tolerar y reducir la posibilidad de que ocurran errores, y evitamos que el pequeño porcentaje de errores se convierta en una interrupción completa. Para crear sistemas resistentes, utilizamos tres herramientas esenciales: los tiempos de espera, los reintentos y el retardo.

Muchos tipos de errores se vuelven evidentes cuando las solicitudes tardan más tiempo de lo habitual para completarse y posiblemente nunca lo hagan. Cuando un cliente espera más de lo normal para que se complete una solicitud, también retiene los recursos que estaba utilizando para ella durante más tiempo. Cuando cierta cantidad de solicitudes retiene los recursos durante un largo tiempo, el servidor puede agotar dichos recursos. Estos recursos pueden incluir la memoria, los subprocesos, las conexiones, los puertos efímeros o cualquier otro elemento que sea limitado. Para evitar esta situación, los clientes establecen tiempos de espera. Los tiempos de espera son la cantidad máxima de tiempo que un cliente espera para se complete una solicitud.

A menudo, cuando se intenta completar la misma solicitud de nuevo, esta tiene éxito. Esto se debe a que los tipos de sistemas que creamos no suelen presentar errores cuando operan como una sola unidad. En cambio, presentan errores parciales o transitorios. Cuando solo un porcentaje de las solicitudes tiene éxito, existe un error parcial. Cuando una solicitud presenta error durante un periodo corto, existe un error transitorio. Los reintentos permiten que los clientes se sobrepongan a estos errores parciales aleatorios y errores transitorios de corta duración mediante el reenvío de la misma solicitud.

No siempre es seguro llevar a cabo un reintento. Los reintentos pueden aumentar la carga en el sistema al que se está llamando, si es que este ya presenta errores porque está por sobrecargarse. Para evitar este problema, recomendamos a nuestros clientes que utilicen el retardo. Este mecanismo aumenta el tiempo entre los siguientes reintentos, lo que mantiene la carga pareja en el backend. El otro problema que surge con los reintentos es que algunas llamadas remotas generan efectos secundarios. La existencia de tiempo de espera o errores no significa necesariamente que han surgido efectos secundarios. Si no desea que se produzcan efectos secundarios varias veces, una práctica recomendada en estos casos es diseñar las API para que sean idempotentes, es decir, que puedan someterse a reintentos de forma segura.

Finalmente, la entrada de tráfico a los servicios de Amazon no tiene un ritmo constante. En cambio, con frecuencia, la tasa de llegada de las solicitudes presenta grandes aumentos en ráfagas. Estos aumentos en ráfagas pueden deberse al comportamiento del cliente, a la recuperación de errores e, incluso, a algo simple como un trabajo cron periódico. Si la carga provoca errores, es posible que los reintentos no sean efectivos en el caso de que todos los clientes realicen uno al mismo tiempo. Para evitar este problema, utilizamos la fluctuación. Esta consiste en una cantidad de tiempo aleatoria antes de realizar o volver a intentar una solicitud, cuyo fin es ayudar a prevenir grandes aumentos en ráfagas mediante la extensión de la tasa de llegada.

En las próximas secciones, se analizará cada una de estas soluciones.

Los reintentos son “egoístas”. En otras palabras, cuando un cliente vuelve a intentar una solicitud, el servidor tarda más tiempo para alcanzar una mayor oportunidad de éxito. Si los errores son poco comunes o transitorios, esto no representa un problema. Esto se debe a que la cantidad total de solicitudes con reintento es reducida y a que la compensación de aumentar la disponibilidad aparente funciona bien. Cuando la causa de los errores es una sobrecarga, los reintentos que aumentan la carga pueden empeorar la situación considerablemente. Incluso pueden retrasar la recuperación, ya que mantienen la carga alta durante mucho tiempo después de que se resuelve el problema original. Los reintentos se parecen a un medicamento potente; son útiles en su justa dosis, pero pueden causar daño significativo si se consumen en exceso. Desafortunadamente, en los sistemas distribuidos casi no hay manera de coordinar todos los clientes para lograr la cantidad correcta de reintentos.

La solución que se prefiere en Amazon es el retardo. En lugar de llevar a cabo un reintento de inmediato y con intensidad, el cliente espera determinada cantidad de tiempo entre los intentos. El patrón más común es el retardo exponencial, donde el tiempo de espera se incrementa exponencialmente después de cada intento. El retardo exponencial puede llevar a periodos de retardo muy largos, ya que las funciones exponenciales crecen rápidamente. Por lo general, las implementaciones limitan el retardo con un valor máximo para evitar que se extiendan durante demasiado tiempo los reintentos. Esto se denomina, como es de esperar, retardo exponencial limitado. Sin embargo, este mecanismo presenta otro problema. Ahora todos los clientes llevan a cabo reintentos constantemente con la tasa límite. En casi todos los casos, nuestra solución es limitar la cantidad de veces que el cliente realiza reintentos y solucionar el error resultante con anterioridad en la arquitectura orientada a servicios. En la mayoría de los casos, el cliente se dará por vencido con la llamada de todas maneras porque tiene sus propios tiempos de espera.

Existen otros problemas con los reintentos que se describen a continuación:

• Por lo general, los sistemas distribuidos tienen varias capas. Considere un sistema donde la llamada del cliente provoca una pila de cinco capas de llamadas a servicios. Finaliza con una consulta a la base de datos y tres reintentos en cada capa. ¿Qué sucede cuando la base de datos empieza a generar errores en las consultas con carga? Si cada capa realiza reintentos de manera independiente, la carga de la base de datos aumentará 243 veces, lo que convierte a la posibilidad de recuperación en muy remota. Esto se debe a que los reintentos en cada capa se multiplican (primero tres intentos, luego nueve y así sucesivamente). Por el contrario, los reintentos en la capa más alta de la pila podrían significar el desperdicio de trabajo correspondiente a las llamadas anteriores, lo que reduce la eficiencia. En general, para las operaciones de bajo costo en el plano de datos y en el de control, nuestra práctica recomendada es realizar el reintento en un único punto de la pila.
• Carga. Incluso con una sola capa de reintentos, el tráfico continúa creciendo de manera significativa cuando empiezan a aparecer los errores. Para solucionar este problema, se recomiendan con mucha frecuencia los interruptores, por los que se detienen completamente las llamadas a servicios posteriores cuando se supera el límite de error. Desafortunadamente, los interruptores introducen un comportamiento modal en los sistemas que es difícil de probar y pueden ingresar tiempo adicional de recuperación considerable. Hemos descubierto que podemos mitigar este riesgo si limitamos los reintentos a nivel local con un bucket de tokens. Esto permite que se vuelvan a intentar todas las llamadas, siempre que haya tokens, y luego realizar reintentos a una tasa establecida cuando se agoten los tokens. AWS incorporó este comportamiento a los SDK de AWS en 2016. Por lo tanto, los clientes que utilicen el SDK tienen integrado este comportamiento de limitación controlada.
• Decisión sobre cuándo realizar un reintento. En general, nuestra opinión es que las API con efectos secundarios no son seguras para los reintentos a menos que ofrezcan idempotencia. Esto garantiza que los efectos secundarios ocurran solo una vez, sin importar cuántas veces se realicen reintentos. Por lo general, las API de solo lectura son idempotentes, mientras que las API de creación de recursos tal vez no lo sean. Algunas API, como la API RunInstances de Amazon Elastic Compute Cloud (Amazon EC2), ofrecen mecanismos basados en tokens explícitos a fin de brindar idempotencia y preparar su seguridad para los reintentos. Se necesita un buen diseño de la API y cuidado a la hora de implementar los clientes para evitar los efectos secundarios duplicados.
• Conocimiento sobre qué errores vale la pena volver a intentar. HTTP ofrece una distinción clara entre los errores del cliente y los del servidor. Indica que los errores del cliente no deben volver a intentarse con la misma solicitud, ya que no van a tener éxito más tarde, mientras que los errores del servidor pueden llegar a tener éxito en los siguientes intentos. Lamentablemente, la consistencia final en los sistemas dificulta la distinción de manera considerable. A medida que se propaga el estado de error, en cierto momento, el error del cliente puede cambiar y tener éxito.

Más allá de estos riesgos y desafíos, los reintentos son un mecanismo potente para ofrecer alta disponibilidad frente a errores transitorios y aleatorios. Se requiere un juicio certero a la hora de encontrar el equilibrio adecuado para cada servicio. Según nuestra experiencia, un buen punto para comenzar es recordar que los reintentos son egoístas. Representan un mecanismo por el cual los clientes afirman la importancia de sus solicitudes y exigen que el servicio invierta más recursos en administrarlas. Si el cliente es demasiado egoísta, puede crear problemas de gran alcance.

Cuando la sobrecarga o la contención provocan los errores, a menudo el retardo no ayuda tanto como se piensa que debería. Esto se debe a la correlación. Si todas las llamadas con errores se atrasan al mismo momento, provocan contención o sobrecarga nuevamente cuando se intenta realizarlas de nuevo. Nuestra solución es la fluctuación. La fluctuación incorpora cierta cantidad de aleatoriedad al retardo para distribuir los reintentos en el tiempo. Para obtener más información acerca de la cantidad de fluctuación que se debe agregar y de las mejores maneras de hacerlo, consulte Exponential Backoff and Jitter (Fluctuación y retardo exponencial).

La fluctuación no sirve solo para los reintentos. La experiencia operativa nos ha enseñado que el tráfico hacia nuestros servicios, incluidos los planos de datos y de control, tiende a tener muchos picos. Estos picos de tráfico pueden ser muy cortos y, por lo general, los ocultan las métricas agrupadas. Al momento de crear los sistemas, consideramos incorporar un poco de fluctuación en todos los temporizadores, los trabajos periódicos y demás trabajos con retraso. Esto ayuda a extender los picos de trabajo y facilita el escalado a los servicios posteriores en beneficio de una carga de trabajo.

Si agregamos fluctuación a un trabajo programado, no seleccionamos la fluctuación en cada alojamiento de forma aleatoria. En cambio, utilizamos un método consistente que siempre produce la misma cantidad en el mismo alojamiento. De esta manera, si hay un servicio sobrecargado o una condición de carrera, esto sucede de la misma manera en un patrón. Los humanos somos buenos para identificar patrones y tenemos más posibilidades de determinar la causa raíz. El uso de un método aleatorio garantiza que si se está sobrecargando un recurso, esto solo suceda al azar. Esto hace que la resolución de los problemas sea mucho más difícil.

En sistemas en los que he trabajado, como Amazon Elastic Block Store (Amazon EBS) y AWS Lambda, descubrimos que, a menudo, los clientes envían las solicitudes en intervalos regulares, por ejemplo, de a una por minuto. Sin embargo, cuando un cliente tiene varios servidores que se comportan de la misma manera, puede alinear y activar las solicitudes al mismo tiempo. Esto puede tomar los primeros segundos de un minuto o los primeros segundos después de la medianoche para los trabajos diarios. Después de prestar atención a la carga por segundo y de trabajar con los clientes para fluctuar sus cargas de trabajo periódicas, logramos la misma cantidad de trabajo con menos capacidad de servidor.

Tenemos menos control sobre los picos de tráfico del cliente. Sin embargo, incluso para las tareas activadas por el cliente, es una buena idea agregar fluctuación donde no afecte la experiencia del cliente.

En los sistemas distribuidos, la latencia o los errores transitorios en las interacciones remotas son inevitables. Los tiempos de espera evitan que los sistemas tengan que aguardar durante un periodo ilógicamente largo; los reintentos pueden ocultar esos errores; y el retardo y la fluctuación pueden mejorar la utilización de los sistemas y reducir su congestión.

En Amazon, hemos aprendido que es importante tener cuidado con los reintentos. Estos pueden aumentar la carga en un sistema dependiente. Si el tiempo de espera de las llamadas a un sistema se está agotando, y dicho sistema está sobrecargado, los reintentos pueden empeorar la sobrecarga en lugar de aliviarla. Para evitar este aumento, realizamos reintentos solo cuando observamos que la dependencia está en buen estado. Dejamos de llevar a cabo reintentos cuando esta acción no ayuda a mejorar la disponibilidad.