El arte de escalar contenedores: Reintentos
Escalar contenedores es más que simplemente colocar un proxy frente a un servicio y marcharse. Escalar implica mucho más que simplemente distribuir, y en el acelerado mundo de los contenedores hay cinco capacidades distintas necesarias para garantizar la escala: reintentos, disyuntores, descubrimiento , distribución y monitoreo.
En esta publicación sobre el arte de escalar contenedores, profundizaremos en los reintentos.
Reintentos
Cuando eres un niño y juegas a un videojuego, el concepto de reintentar es común en muchos juegos. “¡Hazlo de nuevo!” es un grito común después de un fracaso, con la esperanza de que los otros jugadores te permitan intentarlo nuevamente. A veces lo hacen. A veces no lo hacen. He notado que eso rara vez detiene a un niño de intentarlo.
Al escalar aplicaciones (o servicios, si lo prefiere), el concepto de reintento es prácticamente el mismo. Un proxy, al elegir un servicio e intentar cumplir una solicitud, recibe un error. En escenarios básicos de equilibrio de carga, esto normalmente se determina examinando el código de respuesta HTTP. Cualquier valor que no sea “200 OK” es un error. Esto incluye tiempos de espera de capa TCP y de red. El balanceador de carga puede devolver ciegamente la respuesta fallida al
solicitante o, si es lo suficientemente inteligente, puede volver a intentar la solicitud con la esperanza de que una solicitud posterior dé como resultado una respuesta exitosa.
Esto suena bastante básico, pero al comienzo de la escala no existía tal cosa como un reintento. Si fallaba, fallaba y teníamos que lidiar con ello. Generalmente, al intentar recargar manualmente desde el navegador. Con el tiempo, los servidores proxy se volvieron lo suficientemente inteligentes como para realizar reintentos por sí solos, evitando que muchos teclados desgastaran las teclas “CTRL” y “R”.
A primera vista, este es un ejemplo existencial de la definición de locura. Después de todo, si la solicitud falló la primera vez, ¿por qué deberíamos esperar que tenga éxito la segunda (o incluso la tercera?).
La respuesta está en el motivo del fracaso. Al escalar aplicaciones, es importante comprender el impacto que tiene la capacidad de conexión en las fallas. La carga de un recurso determinado en un momento determinado no es fija. Las conexiones se abren y cierran constantemente. La plataforma de aplicación web subyacente (ya sea Apache o IIS, un motor node.js o alguna otra pila) tiene restricciones definidas en términos de capacidad. Sólo puede mantener X número de conexiones simultáneas. Cuando se alcanza ese límite, los intentos de abrir nuevas conexiones se bloquearán o fallarán.
Si esta es la causa de una falla, entonces en los microsegundos que tardó el proxy en recibir una respuesta fallida, es posible que se haya cerrado una conexión diferente, abriendo así la oportunidad de que un reintento sea exitoso.
En algunos casos, una falla es interna a la plataforma. El temido “ 500 Error interno del servidor ”. Este estado se ve a menudo cuando el servidor no está sobrecargado, pero ha realizado una llamada a otro servicio (externo) que no respondió a tiempo. A veces, esto es el resultado de que un grupo de conexiones de base de datos alcanza sus límites. La dependencia de servicios externos puede generar una cadena de errores que, como una sobrecarga de conexión, a menudo se resuelve cuando se recibe el error inicial.
También es posible que veas el tan útil error “ 503 Servicio no disponible ”. Esto podría ser en respuesta a una sobrecarga, pero como es el caso con todos los códigos de error HTTP, no siempre son buenos predictores de lo que realmente está saliendo mal. Es posible que vea esto en respuesta a una falla de DNS o, en el caso de IIS y ASP, una cola llena. Las posibilidades son realmente muy variadas. Y nuevamente, es posible que se hayan resuelto en el momento en que recibas el error, por lo que un reintento definitivamente debería ser tu primera respuesta.
Por supuesto, no puedes volver a intentarlo hasta que las vacas regresen a casa. Al igual que las consecuencias no deseadas de la retransmisión TCP (que pueden sobrecargar las redes y saturar a los receptores), los reintentos eventualmente se vuelven inútiles. No existe una regla estricta sobre cuántas veces debes volver a intentarlo antes de rendirte, pero lo habitual es entre 3 y 5.
En ese momento, es el momento de enviar disculpas al solicitante e iniciar un disyuntor. Profundizaremos en esa capacidad en nuestra próxima publicación.