El arte de escalar contenedores: reintentos

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Escalar contenedores es mucho más que limitarse a colocar un proxy delante de un servicio y olvidarse del asunto. La escalabilidad no consiste únicamente en la distribución y, en el vertiginoso mundo de los contenedores, se requieren cinco capacidades distintas para garantizarla: reintentos, disyuntores, descubrimiento, distribución, y supervisión.

En este artículo sobre el arte de escalar contenedores, profundizaremos en los reintentos.

Reintentos

Cuando eres niño y estás jugando, el concepto de volver a intentarlo es habitual en muchos juegos. «¡Otra vez!» suele exclamarse después de fallar, con la esperanza de que los demás jugadores te dejen intentarlo de nuevo. A veces te dejan. A veces no. Pero he observado que eso rara vez impide que un niño siga intentándolo.

Al escalar aplicaciones (o servicios, si lo prefieres), el concepto de reintento es muy similar. Un proxy, tras elegir un servicio e intentar atender una solicitud, recibe un error. En situaciones básicas de balanceo de carga, esto suele determinarse examinando el código de respuesta HTTP. Cualquier respuesta que no sea «200 OK» se considera un error. Esto incluye los tiempos de espera agotados en la red y en la capa TCP. El balanceador de carga puede limitarse a devolver la respuesta fallida al

solicitante o, si es lo suficientemente inteligente, puede volver a intentar la solicitud con la esperanza de que un intento posterior dé lugar a una respuesta satisfactoria.

Esto parece bastante básico, pero en los inicios del escalado no existían los reintentos. Si algo fallaba, fallaba y nos las apañábamos. Normalmente, intentando volver a cargar la página manualmente desde el navegador. Con el tiempo, los proxies se volvieron lo bastante inteligentes como para realizar reintentos por sí solos, evitando que las teclas «CTRL» y «R» de muchos teclados acabaran desgastadas.

A primera vista, este es un ejemplo existencial de la definición de locura. Al fin y al cabo, si la solicitud falló la primera vez, ¿por qué deberíamos esperar que tuviera éxito la segunda (o incluso la tercera)?

La respuesta está en el motivo del fallo. Al escalar aplicaciones, es importante comprender cómo afecta la capacidad de conexión a los fallos. La carga de un recurso determinado en un momento dado no es fija. Las conexiones se abren y se cierran constantemente. La plataforma subyacente de la aplicación web —ya sea Apache o IIS, un motor de node.js o cualquier otra pila tecnológica— tiene limitaciones de capacidad definidas. Solo puede mantener X conexiones simultáneas. Cuando se alcanza ese límite, los intentos de abrir nuevas conexiones se quedarán bloqueados o fallarán.

Si esta es la causa del fallo, es posible que, durante los microsegundos que tardó el proxy en recibir una respuesta fallida, se cerrara otra conexión, lo que permitiría que un nuevo intento tuviera éxito.

En algunos casos, el fallo es interno a la plataforma. El temido «Error interno del servidor 500». Este estado suele aparecer cuando el servidor no está sobrecargado, pero ha realizado una llamada a otro servicio (externo) que no ha respondido a tiempo. A veces, esto se debe a que un grupo de conexiones a la base de datos ha alcanzado sus límites. La dependencia de servicios externos puede provocar una cadena de errores en cascada que, al igual que una sobrecarga de conexiones, suele haberse resuelto para cuando se recibe el error inicial.

También puede que aparezca el «siempre tan útil» error “503 Servicio no disponible”. Puede deberse a una sobrecarga, pero, como ocurre con todos los códigos de error HTTP, no siempre permite determinar con precisión qué está fallando realmente. Puede aparecer debido a un fallo de DNS o, en el caso de IIS y ASP, porque la cola esté llena. Las causas posibles son realmente muy variadas. Y, una vez más, puede que el problema ya se haya resuelto cuando reciba el error, por lo que volver a intentarlo debería ser, sin duda, su primera medida.

Por supuesto, no puedes seguir reintentándolo indefinidamente. Al igual que ocurre con las consecuencias imprevistas de la retransmisión TCP —que puede sobrecargar las redes y saturar los receptores—, llega un momento en que los reintentos dejan de ser útiles. No existe una regla estricta sobre cuántas veces debes reintentarlo antes de desistir, pero lo habitual es hacerlo entre 3 y 5 veces.

Llegados a ese punto, es hora de comunicar al solicitante que no se ha podido atender la petición y activar un disyuntor. Profundizaremos en esta funcionalidad en nuestra próxima publicación.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie