El arte de escalar contenedores: Distribución
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 la distribución.
Distribución
La fórmula secreta para escalar cualquier cosa siempre ha dependido, en parte, de cómo se distribuyen las solicitudes entre un conjunto finito de recursos. Ni siquiera la nube y su aparentemente infinito suministro de recursos computacionales cambian esa receta. En el momento en que se recibe una solicitud, la lista posible de recursos que pueden aceptar esa solicitud y procesarla es finita. Período.
La decisión, entonces, de dónde dirigir una solicitud se vuelve bastante importante. Envíelo al recurso equivocado y el rendimiento puede verse afectado. Envíelo al recurso adecuado y el consumidor/empleado estará encantado con el resultado.
En los primeros tiempos de la escala, esas decisiones se basaban únicamente en algoritmos. Sistema de todos contra todos. Menos conexiones. Respuesta más rápida. Estos mecanismos robustos todavía existen hoy en día, pero poco a poco se han convertido en un factor más en el proceso de toma de decisiones, en lugar de ser el único factor.
Esto se debe a que ya no dependemos únicamente de procesos de toma de decisiones basados en la conexión (también conocidos como "equilibrio de carga tradicional"). Cuando el equilibrio de carga consistía principalmente en gestionar conexiones TCP, tenían sentido los esquemas de distribución basados en conexiones. Pero ahora la escala se basa tanto en la arquitectura como en sus algoritmos, y la distribución de solicitudes puede ser un cálculo complejo que involucra muchas variables por encima (literalmente) y más allá de los protocolos de capa 4.
Lo que complica la distribución es la realidad de que las arquitecturas actuales están cada vez más distribuidas. No sólo a través de nubes, sino también a través de contenedores. Es posible que haya varias versiones de la misma aplicación (o API) en servicio al mismo tiempo. El sistema responsable de distribuir la solicitud debe ser consciente y capaz de distinguir entre ellas y garantizar la entrega al punto final correcto .
Hoy en día, las decisiones se toman no sólo en función de la capacidad de conexión, sino cada vez más en función de los parámetros de la capa 7 (HTTP). Nombres de host. Métodos API (también conocidos como URI). Claves API. Encabezados HTTP personalizados con números de versión incorporados. Ubicación. Dispositivo. Usuario. Las solicitudes se evalúan en el contexto en que se realizan y las decisiones se toman en microsegundos.
Hoy en día la distribución requiere un enfoque arquitectónico escalonado. Cuanto más se profundiza en la arquitectura de la aplicación, menos granular se vuelve. Para cuando un proxy toma una decisión de equilibrio de carga entre X clones del mismo microservicio, es muy posible que no esté usando nada más que ecuaciones tradicionales basadas en algoritmos. Mientras tanto, en los bordes exteriores del entorno, los controladores de ingreso toman decisiones a veces complejas basadas en variables de la capa HTTP.
En el exterior, la distribución está marcada por la arquitectura . En el interior, mediante algoritmos .
Ambos son componentes críticos –el más crítico, quizás– para escalar contenedores.
Ambos dependen de información precisa y en tiempo real sobre el estado (salud) de los recursos a los que podrían distribuir solicitudes. Hablaremos del monitoreo en las próximas publicaciones de esta serie.