Patrones de entrega de aplicaciones para escalar aplicaciones y API
Hoy en día, escalar aplicaciones y API no consiste en elegir el algoritmo de equilibrio de carga adecuado. En las más de dos décadas de evolución de la distribución de aplicaciones, lo único que se ha mantenido bastante constante son los algoritmos de equilibrio de carga. Su principal beneficio es mantener la disponibilidad. Su impacto en el rendimiento es, en el mejor de los casos, mínimo.
Esto no quiere decir que la elección de un algoritmo sea irrelevante. Después de todo, el método round robin rara vez es la mejor opción para una API o aplicação, pero la elección entre menos conexiones y la respuesta más rápida tiene menos probabilidades de tener un impacto en el rendimiento general y la disponibilidad de un servicio digital que su arquitectura.
Se trata de una perspectiva arquitectónica sobre la distribución de aplicaciones en respuesta a la elevación de la distribución de aplicaciones como una de las seis capacidades clave necesarias para diseñar y operar servicios digitales.
¿Qué es un algoritmo de balanceo de carga?
Un algoritmo de equilibrio de carga es un enfoque programático para distribuir la carga entre un grupo de recursos para garantizar la disponibilidad y mejorar el rendimiento.
Un algoritmo de equilibrio de carga especifica cómo se eligen recursos específicos y qué variables se consideran.
Round Robin es el algoritmo más simple y simplemente itera sobre un conjunto conocido de recursos en orden secuencial. Si hay tres recursos (A, B y C), el método round robin envía la primera solicitud a A, la segunda a B y la tercera a C. Luego, el proceso de selección comienza de nuevo.
Least Connections es un algoritmo basado en el segundo axioma operacional que establece que "a medida que aumenta la carga, el rendimiento disminuye". Por lo tanto, el algoritmo de menos conexiones elegirá el recurso con menos conexiones (carga). Existen variaciones de este algoritmo, la más notable es la de conexiones mínimas ponderadas , que permite diferencias en la capacidad entre los recursos.
El tiempo de respuesta más rápido se utiliza cuando el rendimiento es una prioridad máxima. El balanceador de carga determinará, ya sea pasiva o activamente, el tiempo de respuesta de cada recurso y, para cada solicitud, elegirá el más rápido. Este algoritmo no garantiza el tiempo de respuesta del usuario ya que no tiene efecto sobre la última milla ni sobre las condiciones de la red del usuario.
La IP de origen es un algoritmo que quedó del equilibrio de carga de la red que utiliza un valor hash simple para la IP de origen (cliente) para elegir un recurso. Este algoritmo siempre seleccionará el mismo recurso para una IP de origen determinada. Este algoritmo cayó en desgracia porque está sujeto al problema del "mega proxy", donde todos los usuarios que se originan desde un único proxy/dirección IP son dirigidos al mismo recurso. Esto tiende a saturar el recurso objetivo, lo que da como resultado un rendimiento deficiente y, en última instancia, un fracaso.
Los algoritmos de equilibrio de carga son una parte importante de la arquitectura de distribución de aplicaciones, pero tienen menos impacto en el rendimiento y la escala de una aplicación o servicio digital que el enfoque arquitectónico general.
¿Qué es la entrega de aplicaciones?
La entrega de aplicaciones es la disciplina de diseñar una arquitectura escalable y de alto rendimiento para aplicaciones, API y servicios digitales. Depende en gran medida del equilibrio de carga como componente central, pero incorpora capacidades modernas como el enrutamiento de capa 7 y aprovecha patrones arquitectónicos comunes para optimizar el rendimiento y la utilización eficiente de los recursos.
Usamos el término entrega de aplicaciones para trazar deliberadamente una línea entre el equilibrio de carga, que es un detalle de implementación, y la arquitectura, que es un proceso de diseño.
¿Por qué escalamos?
La escala es la respuesta técnica a un resultado empresarial. Es decir, la necesidad de mantener la disponibilidad y el rendimiento de las cargas de trabajo que componen un servicio digital para mejorar los puntajes de satisfacción del cliente, las tasas de conversión y la generación de ingresos. Esta última parte es particularmente importante, ya que nuestra investigación nos dice que la mayoría (58%) de las empresas actuales obtienen al menos la mitad de sus ingresos de servicios digitales.
Consideremos también, por ejemplo, el uso de la nube pública para la continuidad del negocio (BC). El BC es uno de los principales usos de la nube pública y en su núcleo es una implementación de escala global, es decir, equilibrio de carga global. La conmutación por error es una capacidad fundamental de la entrega de aplicaciones que, cuando se aplica a un sitio completo, permite redirigir rápidamente las solicitudes de una ubicación a otra. La disponibilidad continua de la presencia digital de una empresa es un resultado comercial, posibilitado por una respuesta técnica.
¿Cómo escalamos?
Responder a esta pregunta comienza nuestro viaje técnico hacia la arquitectura de distribución de aplicaciones. Hay dos modelos de escala: vertical (arriba) y horizontal (afuera).
La escala vertical se basa en el principio de que agregar más potencia de procesamiento a un sistema aumentará la capacidad. Este método de escala beneficia principalmente a las aplicações monolíticas y a los sistemas que son autónomos. Aparte de la infraestructura, la mayoría de las organizaciones ya no dependen de la escala vertical porque requiere cambiar el entorno físico (agregar CPU o RAM o ampliar la capacidad de la red). Si bien la escala vertical se hace mucho más rápida mediante la virtualización, especialmente en entornos de nube pública, el requisito de migrar software y sistemas, incluso a una nueva máquina virtual , puede ser disruptivo.
La escala horizontal es un enfoque arquitectónico para agregar más potencia de procesamiento incrementando los recursos totales disponibles. Esto se logra distribuyendo la potencia de procesamiento entre múltiples instancias de una aplicação, servicio o sistema. Este es el método de escalamiento más común hoy en día, ya que se basa en duplicar recursos en lugar de migrarlos. Además, la escala horizontal ofrece una mayor variedad de opciones arquitectónicas que la escala vertical , lo que la hace más adecuada para todas las aplicações y API.
No debería sorprender, entonces, que los patrones modernos de distribución de aplicaciones se basen en el principio de escala horizontal.
Patrones de entrega de aplicaciones
La simple elección de la escala horizontal no es el final de la discusión.
Una vez tomada la decisión (generalmente es la decisión predeterminada), consideraciones adicionales deben impulsar una decisión arquitectónica con respecto a la implementación. La forma más sencilla de abordar esa decisión es a través de la lente del cubo de escala , como se describe en el libro El arte de la escalabilidad .
En términos muy simples, hay tres ejes en el cubo de escala: x, y y z. Cada uno se asigna a un patrón arquitectónico de equilibrio de carga. Cada uno de estos patrones es apropiado para alcanzar resultados específicos relacionados con el rendimiento y la disponibilidad dados diferentes tipos de aplicações y API.
Es probable que un servicio digital utilice una arquitectura que incorpore múltiples patrones para optimizar el rendimiento y el consumo de recursos al mismo tiempo. Este enfoque requiere pensamiento sistémico, ya que debe considerar todos los componentes, cómo interactuarán y cómo fluirán las solicitudes del usuario a la aplicación y viceversa.
Escala del eje X
El patrón del eje X es el patrón más básico. Se basa en la duplicación horizontal y la mayor parte del trabajo se realiza mediante un algoritmo de equilibrio de carga. Es el patrón más simple y da como resultado lo que yo llamo equilibrio de carga simple (POLB).
Lo llamamos así debido a la simplicidad de la arquitectura, que no aprovecha las capacidades avanzadas de los balanceadores de carga modernos para interactuar con solicitudes y respuestas en la capa de aplicação .
En este patrón, las aplicações se duplican y las solicitudes se reenvían a una instancia según la decisión del algoritmo de equilibrio de carga configurado.
Debido a que este patrón se utiliza a menudo junto con TCP (capa 4), tiene ventajas de rendimiento sobre otros patrones que dependen de la inspección de HTTP (capa 7). Básicamente, las conexiones se pueden unir en lugar de usar proxy, lo que convierte efectivamente al balanceador de carga en un salto de red después de la conexión inicial. Esto genera un mayor rendimiento general, pero elimina la capacidad del balanceador de carga de inspeccionar o actuar sobre las solicitudes y respuestas después de la conexión inicial. Debido a que las arquitecturas de eje X se destacan por garantizar la disponibilidad y pueden tener un alto rendimiento, a menudo se las utiliza para escalar servicios de infraestructura y seguridad, como firewalls y puertas de enlace de aplicação .
Una variedad de aplicações tradicionales (monolitos, web de tres niveles y cliente-servidor) tienden a escalarse utilizando este patrón, ya que rara vez ocurre que estas aplicações se descomponen en componentes más discretos que se puedan aprovechar para arquitecturas de distribución de aplicaciones modernas.
Escala del eje Y
Este patrón se basa en la descomposición funcional y aprovecha las capacidades de la capa de aplicação (capa 7) de entrega de aplicaciones para escalar en función de funciones en lugar de sistemas completos. El patrón del eje y es el primer patrón en el que el enrutamiento de capa 7 se convierte en una herramienta clave en la caja de herramientas de la arquitectura de entrega de aplicaciones.
En general, los patrones basados en y y z aprovechan el enrutamiento de capa 7 para elegir un grupo y luego se utiliza un algoritmo de equilibrio de carga para seleccionar un recurso específico. Esto se aparta del patrón x básico, en el que no se utiliza enrutamiento de capa 7.
Este patrón asume una operación en la capa 7, generalmente HTTP, y utiliza alguna variable para distribuir el tráfico a instancias específicas de una aplicação o servicio. Por ejemplo, si se encuentra el patrón /login en la URI, entonces el balanceador de carga elegirá una instancia, según el algoritmo de balanceo de carga configurado, en un grupo de instancias de aplicaciones que solo manejan solicitudes de inicio de sesión. La variable puede ser cualquier cosa en el encabezado de la solicitud o en la carga útil de la solicitud. Esto permite el enrutamiento basado en agentes, enrutamiento de API y enrutamiento basado en contenido (imágenes, scripts, etc.).
Las instancias de aplicação pueden ser clones. Este suele ser el caso cuando existe una disparidad en el uso de una aplicación que puede identificarse mediante una variable en la solicitud. Por ejemplo, funciones de inicio de sesión versus pago se puede discernir en una solicitud basada en la URI, un valor en el encabezado HTTP o un valor en la carga útil de la solicitud. La aplicación de un patrón de eje y permite que las aplicações tradicionales escalen en función de la función, lo que genera una mayor eficiencia en la utilización de recursos porque se pueden asignar más recursos al manejo de funciones de gran volumen y al mismo tiempo mantener el rendimiento esperado de otras funciones.
El uso del patrón del eje y para escalar funcionalmente las aplicações tradicionales se originó antes de la prevalencia de los microservicios, que hoy descomponen funcionalmente las aplicações. El patrón del eje y todavía se aplica a los microservicios y, de hecho, los controladores de ingreso actuales lo implementan. Los lectores astutos notarán que este patrón también es aplicable a las API, dado que se basan en construcciones HTTP (capa 7), por lo que no sorprende que las puertas de enlace de API aprovechen este patrón fundamental.
Este patrón se hizo popular gracias a eBay en los primeros días de la Web 2.0. Su arquitectura de escalabilidad incluía entonces la segmentación de funciones en grupos de aplicação separados. La funcionalidad de venta era atendida por un conjunto de servidores de aplicação , la de licitación por otro, y la de búsqueda por otro más. En total, organizaron aproximadamente 16.000 servidores de aplicação en 220 grupos diferentes. Esto les permitió escalar cada pool independientemente uno del otro, según las demandas y el consumo de recursos de su función. Además, les permitió aislar y racionalizar las dependencias de recursos: el grupo de ventas solo necesitaba comunicarse con un subconjunto relativamente pequeño de recursos back-end, por ejemplo.
El patrón del eje y también se puede utilizar para distribuir distintos tipos de solicitudes de contenido, como imágenes a un grupo de recursos y otros tipos de contenido a otros.
El uso del eje y para distribuir la carga permite que los componentes de un servicio digital se escalen individualmente, lo que es mucho más eficiente en términos de utilización de recursos que un patrón de eje x. Permite la optimización de la configuración en la capa de servicio o aplicação que puede mejorar su rendimiento al ajustar variables específicas en el servidor web o de aplicaciones para optimizar un tipo de contenido determinado.
Escala del eje Z
El patrón del eje Z se hizo popular por pura necesidad con el crecimiento explosivo de las redes sociales e Internet en general. En esencia, es un patrón de escala del eje Y con segmentación adicional aplicada, generalmente basada en una variable específica como el nombre de usuario o un identificador de dispositivo.
Este patrón permite la diferenciación arquitectónica utilizando una técnica derivada de la fragmentación de datos.
Este patrón aplica los principios utilizados en las bases de datos para distribuir solicitudes en función de algún dato en la solicitud. Se puede utilizar para ayudar a abordar cuellos de botella en la capa de datos, así como también como un medio para garantizar el cumplimiento de las reglas de soberanía de datos. Utiliza una variable identificable, y normalmente única, para enrutar solicitudes a través de un grupo de recursos escalado horizontalmente. Este patrón se utiliza generalmente cuando se necesita un alto rendimiento, como volúmenes significativos de solicitudes para un servicio o aplicação específicos.
El patrón del eje Z es particularmente útil para administrar dispositivos IoT y de borde, cuyo número puede ascender a millones. Al utilizar identificadores de dispositivos como patrón base para las solicitudes de fragmentación, se puede mejorar significativamente la velocidad con la que se pueden transferir los datos. Esto puede ser especialmente útil para dispositivos que almacenan sus configuraciones en una ubicación remota (nube o centro de datos), ya que estos datos son exclusivos del dispositivo y se pueden compartir de forma segura.
Este patrón tiende a mejorar el rendimiento porque el acceso a los datos bajo alta carga puede degradar significativamente el rendimiento. De esta forma, al dividir el acceso a los datos entre más instancias, la carga disminuye y con ella, mejora el rendimiento. Esto requiere una atención cuidadosa a la integridad de los datos y puede generar problemas de consistencia cuando se utiliza para fragmentar datos compartidos. Meta elevó el tema de la fragmentación cuando desarrolló la fragmentación de servicios como parte de su arquitectura general. Su cuidadosa atención al desarrollo de una arquitectura de distribución de aplicaciones escalable y de alto rendimiento es un excelente ejemplo de cómo el reconocimiento de la distribución de aplicaciones como un nivel formal dentro de una arquitectura más grande puede generar beneficios significativos.
Para los servicios que acceden a fuentes de datos no primarias, un patrón de eje z puede mejorar el rendimiento sin afectar significativamente la calidad de los datos en todo el sistema. Este enfoque alivia la necesidad de agregar código para vincular una instancia específica de una aplicação o API a una fuente de datos, y se basa en cambio en la combinación de la configuración de los conectores de datos a nivel de instancia y el enrutamiento de entrega de la aplicación para garantizar que se utilice la fuente de datos correcta.
El secreto para escalar es la arquitectura de entrega de aplicaciones.
Hoy en día, en un mundo en el que se prestan servicios digitales, es poco común utilizar un único patrón de distribución de aplicaciones para diseñar un servicio digital confiable y de alto rendimiento. Esto se debe a la complejidad inherente de los servicios digitales y a la creciente diversidad de “usuarios”, que puede abarcar dispositivos, humanos y software.
Por lo tanto, un enfoque arquitectónico considera el mejor uso de los patrones de distribución de aplicaciones en un servicio digital para brindar una experiencia óptima a los usuarios.
No existe una solución arquitectónica "correcta" o "incorrecta" porque depende en gran medida de los servicios y aplicações que componen un servicio digital, excepto que dicha solución no debería basarse únicamente en algoritmos de equilibrio de carga.
De hecho, cabe señalar que no se ha mencionado la selección del algoritmo, ya que la elección de cómo se distribuye la carga dentro de un patrón de equilibrio de carga no es tan relevante como hacer la elección arquitectónica correcta para una aplicación o API específica.
Este es uno de los factores que impulsan la entrega de aplicaciones como disciplina . La forma en que hoy en día se utiliza e implementa la distribución y la seguridad de las aplicaciones va mucho más allá de la simple escala de un servidor web. Su implementación puede afectar el rendimiento, la disponibilidad y, en última instancia, el éxito o el fracaso de los resultados comerciales. Por lo tanto, es importante que las organizaciones aborden la entrega de aplicaciones como una herramienta estratégica y arquitectónica en su caja de herramientas de diseño.
El equilibrio de carga sigue siendo el requisito técnico fundamental para la escala. Comprender los patrones de distribución de aplicaciones y cómo aprovechan el equilibrio de carga brindará una mejor perspectiva sobre la arquitectura para la escala y el rendimiento de los servicios digitales, especialmente cuando esos servicios probablemente sean híbridos y comprendan una combinación de API y aplicaciones modernas y tradicionales.