Consecuencias no deseadas: Proxies bajo carga
Hoy en día, la necesidad de escalabilidad ya ni siquiera es un problema. La respuesta siempre es sí, lo necesitas. El crecimiento empresarial depende del crecimiento operativo de las aplicações que, después de todo, son parte integral de los modelos de negocio actuales, sin importar la industria. Así es como los sistemas generalmente se implementan con las cosas necesarias para lograr esa escala cuando –no si– será necesaria. Generalmente eso significa un proxy. Y los servidores proxy responsables de la escala (normalmente un equilibrador de carga) son, por tanto, componentes bastante críticos en cualquier arquitectura moderna.
No es solo que estos proxies sirvan como mecanismo para escalar, sino que cada vez se les exige más que lo hagan de manera automática a través de las maravillas del autoescalamiento. Esa simple palabra con guion implica mucho; como por ejemplo, la capacidad de instruir, mediante programación, a un sistema no solo para que lance capacidad adicional, sino también para asegurarse de que el proxy responsable de la escalabilidad conozca su existencia y pueda dirigirle solicitudes.
Se supone que cualquier proxy que se precie tiene las interfaces programáticas necesarias. La economía de las API no se trata solo de compartir entre aplicaciones y personas; después de todo, también se trata de compartir entre sistemas, locales y externos, en la nube. Pero lo que a menudo no reconocemos es que la tarea de agregar un nuevo recurso a un proxy de equilibrio de carga se lleva a cabo en el plano de administración o control, no en el plano de datos.
Eso tiene sentido. No queremos interferir con el funcionamiento del sistema mientras recopilamos estadísticas o manipulamos su configuración. Eso es un no-no, especialmente en una situación en la que estamos tratando de agregar capacidad porque el sistema está funcionando a toda máquina, entregando aplicaciones a usuarios ansiosos.
¿Pero qué ocurre cuando ocurre lo contrario? ¿Cuándo el funcionamiento del sistema interfiere con la capacidad de gestionar el sistema?
Su escalamiento automático (o escalamiento manual, en ese caso) va a fallar. Lo que significa que la capacidad de la aplicación no va a aumentar y el negocio va a sufrir.
Eso es malo, como si necesitaras que te lo dijera.
La razón por la que esto sucede es porque muchos servidores proxy (que no se crearon con esta paradoja en mente) comparten recursos del sistema para los planos de control y de datos. No hay aislamiento entre ellos. La misma red que entrega las aplicaciones se utiliza para administrar el proxy. La misma RAM y el mismo cálculo asignados para entregar aplicaciones se asignan para administrar el proxy. Bajo carga, sólo uno de estos dos obtiene los recursos. Si intentas agregar recursos de la aplicación al proxy para escalar y no puedes acceder al sistema para hacerlo, tendrás graves problemas.
Por eso es importante evaluar la elección de servidores proxy teniendo en cuenta su manejabilidad. No sólo su facilidad de manejo. No sólo sus capacidades de API y scripting, sino también su manejabilidad bajo carga . Los servidores proxy que han sido diseñados específicamente para una escala masiva deben tener un conjunto separado de recursos designados como recursos de “administración” para garantizar que, sin importar cuán cargado esté el plano de datos con la entrega de aplicaciones, aún se pueda administrar y monitorear.
En el mundo de la red, esto lo llamamos gestión fuera de banda, porque ocurre fuera de la ruta de datos : la ruta principal, la ruta crítica.
La capacidad de administrar un proxy bajo carga, fuera de banda, es importante para la capacidad general de escalar (automática o manualmente) las aplicaciones y, a través de ellas, el negocio.