Hacer que las aplicaciones sean escalables
- 8 minutos
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 de 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. Está usando 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 de 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 única de Azure SQL. Debe habilitar esta máquina virtual para escalar horizontalmente. Puede hacerlo mediante conjuntos de escalado de máquinas virtuales de Azure, que le permiten crear y administrar un grupo de máquinas virtuales idénticas y 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 centros de datos independientes independientes dentro de una región de Azure. 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 proteja las máquinas virtuales frente a 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 una distribución de tráfico L7 más avanzada y 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. Se toma una imagen del producto y después esa imagen se carga. 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.
- Colas de Azure Storage Una sencilla interfaz de cola basada en REST y creada a partir de Azure Storage. Ofrece mensajería confiable y persistente.
Los requisitos de este escenario son sencillos, por lo 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 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, va a usar 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. El cambio de tamaño se puede realizar fácilmente con un tiempo de inactividad medio de menos de cuatro segundos. Mediante una llamada a una API sencilla en Azure SQL o mediante un control deslizante en el portal de Azure SQL.
Si este aumento de tamaño no cumple sus requisitos, puede ser conveniente escalar horizontalmente las lecturas en la base de datos en función de las características del tráfico. Permite enrutar el tráfico de lectura a la réplica de lectura.
Nota:
Con Azure SQL, si usa los niveles de servicio Premium o Crítico para la empresa, el escalado horizontal de lectura se habilita de forma predeterminada. No se puede habilitar en los niveles básico o estándar.
Este cambio debe implementarse en el código. Así es como hacerlo.
#Azure SQL Connection String
#Master Connection String
ApplicationIntent=ReadWrite
#Read Replica Connection String
ApplicationIntent=ReadOnly
#Full Example
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;
Actualice el atributo de la ApplicationIntent cadena de conexión de la base de datos para especificar en qué servidor desea conectarse. Use ReadOnly si desea conectarse a la réplica o ReadWrite si desea conectarse al maestro.
Dado que este comando 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 SQL DB 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.