Hacer que las aplicaciones sean escalables

Ahora que comprende los conceptos básicos de la preparación para el crecimiento y conoce los factores que se deben tener en cuenta en el planeamiento de la capacidad, puede asumir el desafío de hacer que las aplicaciones sean lo más escalables posible.

Revisiones de arquitectura

Un punto clave que hay que recordar es que debe realizar revisiones de arquitectura periódicas de los sistemas.

Sabes que puedes aplicar prácticas como infraestructura como código para mejorar el despliegue de tus recursos en la nube. Actualiza y mejora el código de la aplicación con regularidad y debe hacer lo mismo con los recursos de la plataforma subyacentes.

Realizar una revisión de arquitectura le ayuda a identificar las áreas que necesitan mejora.

El Centro de arquitectura de Azure tiene una gran cantidad de recursos para ayudarle a diseñar sus aplicaciones en la nube y hay muchas recomendaciones de escalabilidad que puede encontrar en la guía de arquitectura de aplicaciones en el siguiente vínculo:

Centro de arquitectura Azure

Escenario: Arquitectura de Tailwind Traders

Un primer paso es realizar una evaluación de la arquitectura y la aplicación, no solo para determinar dónde se encuentran sus puntos débiles, sino también para reconocer sus puntos fuertes. ¿Qué tiene de bueno?

Eche otro vistazo al escenario que vio en la unidad anterior. Este es un diagrama de la arquitectura de la organización de nuevo.

Han descomponido la aplicación en microservicios más pequeños y algunos de estos servicios están sentados como contenedores en Azure Kubernetes Service o podrían ejecutarse en máquinas virtuales o App Service. También usan algunos servicios intrínsecamente escalables , como Functions y Logic Apps.

Este cambio es bueno, pero hay algunas mejoras que harían que la aplicación fuera más escalable. Por ejemplo, céntrese ahora en el servicio Products. En el diagrama, el servicio de producto se ejecuta en Kubernetes, pero se supone que se ejecuta en una máquina virtual en Azure. Los conceptos de escalado, posiblemente con una implementación ligeramente diferente, se pueden aplicar a las aplicaciones si se ejecutan en servidores, App Service o en contenedores.

El producto se ejecuta actualmente en una sola máquina virtual, conectada a una base de datos de Azure SQL única. Debe habilitar esta máquina virtual para escalar horizontalmente. Puede hacerlo mediante conjuntos de escalado de máquinas virtuales de Azure, lo que le permite crear y administrar un grupo de máquinas virtuales idénticas con equilibrio de carga. Dado que ahora tiene más de una máquina virtual, debe introducir un equilibrador de carga para distribuir el tráfico entre las máquinas virtuales.

Conjuntos de escalado de máquinas virtuales

Al aplicar conjuntos de escalado de máquinas virtuales a través de máquinas virtuales únicas, obtendrá algunas ventajas:

• Puede utilizar la escalabilidad automática en función de métricas de host, métricas de invitado, Application Insights o mediante programación.
• Puede usar Availability Zones (AZ), que son ubicaciones físicamente independientes dentro de una región de Azure, cada una formada por uno o varios centros de datos. Con la compatibilidad con AZ, puede distribuir las máquinas virtuales entre varias AZ, lo que hace que la aplicación sea más confiable y la proteja de los errores del centro de datos. Las nuevas instancias de un conjunto de escalado se distribuyen uniformemente de forma automática entre varias AZ.
• La adición de un equilibrador de carga resulta más fácil. Los conjuntos de escalado de máquinas virtuales admiten el uso de Azure Load Balancer para la distribución básica del tráfico de nivel 4. También admiten Azure Application Gateway para la distribución de tráfico L7 más avanzada y la terminación SSL.

Hay algunos factores importantes que debe tener en cuenta antes de implementar conjuntos de escalado. Concretamente:

• Evite la permanencia de la instancia para que ningún cliente se quede atascado en un back-end específico.
• Quite los datos persistentes de la máquina virtual y almacénelo en otro lugar, como en Azure Storage o en una base de datos.
• Diseñe la reducción horizontal. También es importante que tu aplicación pueda escalarse hacia abajo fácilmente. Tiene que gestionar adecuadamente no solo tener más instancias agregadas al grupo de servidores que gestionan el tráfico, sino también la terminación abrupta de las instancias a medida que la carga disminuye. A menudo se pasa por alto el aspecto de reducción vertical del escalado.

Desacoplamiento

Ha agregado más máquinas virtuales con conjuntos de escalado. El escalado horizontal es la respuesta típica a "necesitamos escalar". Sin embargo, solo puede escalar en una sola métrica y esta respuesta podría no ser relevante para todas las tareas realizadas por el servicio de producto.

En nuestro escenario, el servicio de productos tiene un trabajo: cuando se carga una imagen de producto, transcodifica esa imagen y la almacena en varios tamaños diferentes para miniaturas, imágenes en el catálogo, etc. El procesamiento de imágenes consume mucha CPU, pero el uso general consume mucha memoria.

El procesamiento de imágenes es una tarea asincrónica que se puede dividir en un trabajo en segundo plano. Para hacerlo, desacople el servicio de procesamiento de imágenes mediante una cola. El desacoplamiento permite escalar ambos servicios de forma independiente: uno por memoria (el servicio de producto) y el otro (el servicio de procesamiento de imágenes) por CPU o incluso por la longitud de la cola, y permite que otro conjunto de escalado consuma esos mensajes y procese las imágenes.

Escalado con colas

Azure tiene dos tipos de ofertas de cola:

• Colas de Azure Service Bus Una oferta de puesta en cola más avanzada, que forma parte del producto Azure Service Bus más general, que ofrece patrones de integración publicados y enviados (pub/sub) y más avanzados.
• Azure Storage Queues Una sencilla interfaz de cola basada en REST basada en Azure Storage. Ofrece mensajería confiable y persistente.

Los requisitos de este escenario son simples, de modo que puede usar Azure Storage Queues. El nivel de servicio del producto no tiene que escalarse en absoluto, ya que esta tarea en segundo plano se ha desacoplado.

Almacenamiento en caché en memoria

Otra manera de mejorar el rendimiento de la aplicación es implementar una caché en memoria.

Ahora sabe que el rendimiento no es igual a la escalabilidad exactamente, pero al mejorar el rendimiento de la aplicación, puede reducir la carga en otros recursos. Esta mejora significa que es posible que no tenga que escalar tan pronto.

Azure Managed Redis (anteriormente Azure Cache for Redis) es una oferta administrada de Redis. Redis se puede usar para muchos patrones y casos de uso. Para el servicio de producto de este escenario, es probable que implemente el patrón cache-aside. En este patrón, se cargan elementos de la base de datos en la memoria caché según sea necesario, lo que hace que la aplicación sea más eficaz y reduzca la carga en la base de datos.

Redis también se puede usar como una cola de mensajería, para almacenar contenido web en caché o para el almacenamiento en caché de sesiones de usuario. Este tipo de almacenamiento en caché puede ser más adecuado para otros servicios del sistema, como el servicio de carro de la compra, donde puede almacenar los datos del carro de la compra por sesión en Redis en lugar de usar una cookie.

Escalado de la base de datos

Ahora que ha hecho que los recursos de proceso sean más escalables, eche un vistazo a la base de datos. En este escenario, usa Azure SQL Database, que es una oferta de SQL Server administrada de Azure.

Las bases de datos relacionales son más difíciles de escalar horizontalmente que las bases de datos no relacionales. Lo primero que puede hacer para escalar la base de datos es aumentar el tamaño de la base de datos. Este cambio de tamaño se puede realizar fácilmente con un breve momento de pérdida de conectividad, ya sea mediante una llamada API simple en Azure SQL o mediante un control deslizante en el portal.

Si esta configuración no se ajusta a sus necesidades, dependiendo de las características del tráfico, podría ser conveniente escalar horizontalmente las operaciones de lectura en la base de datos, lo que le permitiría enrutar el tráfico de lectura hacia su réplica de lectura.

Este cambio debe implementarse en el código. Especifique la intención de enrutamiento estableciendo el atributo ApplicationIntent en la cadena de conexión de la base de datos. Use ReadOnly para conectarse a la réplica o ReadWrite para conectarse al servidor principal.

El enfoque recomendado es usar identidades administradas para la autenticación y almacenar cualquier configuración necesaria en Azure Key Vault:

#Read Replica Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;Authentication=Active Directory Default;Encrypt=True;

#Primary Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;Authentication=Active Directory Default;Encrypt=True;

Dado que este cambio debe implementarse en el código, puede que no sea una solución adecuada para su situación. ¿Qué ocurre si cada servicio de producto necesita la capacidad de leer y escribir?

En ese caso, puede considerar el escalado horizontal de Azure SQL Database mediante el particionamiento.

Partición de base de datos

Si después del escalado vertical o la implementación de réplicas de lectura, los recursos de la base de datos siguen sin satisfacer las necesidades del sistema, la siguiente opción es el particionamiento.

El particionamiento es una técnica para distribuir grandes cantidades de datos estructurados de forma idéntica en muchas bases de datos independientes. El particionamiento puede ser necesario por muchos motivos. Por ejemplo:

• La cantidad total de datos es demasiado grande para ajustarse a las restricciones de una base de datos individual.
• El rendimiento de la transacción de la carga de trabajo general supera las funcionalidades de una base de datos individual.
• Los inquilinos independientes deben residir en bases de datos físicas diferentes por motivos de cumplimiento (este requisito es menor en cuanto al escalado, pero es otra situación en la que se usa el particionamiento).

La aplicación agrega los datos pertinentes a la partición pertinente y, por tanto, hace que el sistema sea escalable más allá de las restricciones de la base de datos individual.

Azure SQL ofrece las herramientas de Azure Elastic Database. Estas herramientas le ayudan a crear, mantener y consultar bases de datos SQL particionadas en Azure desde la lógica de la aplicación.