Escalar contenedores implica 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 específicas para garantizarla: reintentos, disyuntores, descubrimiento, distribución y supervisión.
En esta segunda publicación sobre el arte de escalar contenedores, profundizaremos en los disyuntores.
Disyuntores
Thomas Edison, célebre por haber inventado miles de artilugios que no funcionaban y unos pocos muy conocidos que sí lo hacían, nos legó el concepto del disyuntor en una solicitud de patente de 1879. Sí, las patentes ya existían por aquel entonces. Aunque la versión de Edison utilizaba fusibles que debían sustituirse (algunos quizá recordemos haberlos buscado desesperadamente en nuestros coches de antaño), las versiones más modernas están diseñadas para «saltar» e interrumpir el paso de la corriente eléctrica. Después pueden rearmarse para restablecer el flujo y el funcionamiento normales.
En el contexto del escalado, los disyuntores funcionan según el mismo principio. Detectan una «sobrecarga» e interrumpen deliberadamente el flujo para evitar saturar los servicios situados al otro extremo de la conexión. También pueden restablecerse para recuperar posteriormente el flujo normal de solicitudes y respuestas.
Los disyuntores forman parte de los proxies de balanceo de carga desde hace bastante tiempo. La premisa es que, si después de X intentos sigue sin poder accederse a un servicio determinado, este se encuentra fuera de servicio. No tiene sentido seguir pidiéndole algo que no puede proporcionar, ya que hacerlo solo malgasta recursos del proxy y de la red. Por tanto, tras un número de fallos (normalmente) configurable, el proxy «abrirá» el circuito y se negará a intentar establecer más conexiones.
No es lo mismo que un reintento, aunque el proceso pueda parecer similar. Los reintentos parten de la premisa de que la solicitud acabará realizándose correctamente. Un disyuntor parte de la premisa de que la solicitud fallará y, por tanto, se debe evitar perder tiempo y recursos intentándolo.
Una vez resuelto el problema, el disyuntor se puede «restablecer» y el flujo normal puede reanudarse.
Al principio, este proceso era manual. Un operador debía restablecer el disyuntor tras comprobar que el servicio de destino volvía a estar operativo. En los últimos años, este proceso se ha automatizado mediante la supervisión del estado del servicio. Por lo general, se realizan intentos periódicos de conexión con el servicio y, cuando uno de ellos tiene éxito, se restablece el disyuntor para reanudar el funcionamiento normal.
Los disyuntores son especialmente importantes en entornos de microservicios en contenedores debido al elevado volumen de tráfico que fluye hacia y desde los servicios, así como entre ellos. Aunque algunos fallos pueden detectarse rápidamente, otros no se advertirán hasta que se produzca un tiempo de espera de TCP prolongado debido a problemas en la pila de red. Los tiempos de espera introducen una latencia no deseada, por lo que tanto la apertura del circuito como los reintentos deben tener en cuenta la tolerancia general de la aplicación a la latencia (o su intolerancia, según el caso). Al configurar estos valores, deben tenerse en cuenta los tiempos de espera y las expectativas de la empresa en cuanto al rendimiento. Una baja tolerancia a la latencia puede requerir menos reintentos y una apertura más rápida del circuito.
Sobre el autor
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 VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.