Este artículo describe cómo implementar aplicaciones web críticas usando Azure App Service. La arquitectura usa el patrón de aplicación web confiable como punto de partida. Use esta arquitectura si tiene una carga de trabajo heredada y quiere adoptar servicios de plataforma como servicio (PaaS).
Patrón de aplicaciones web fiables para .NET proporciona orientación para actualizar o replanificar aplicaciones web que se trasladan a la nube, minimizando los cambios de código necesarios y alcanzando un objetivo de nivel de servicio (SLO) del 99,9 %. Las cargas de trabajo críticas tienen requisitos de alta confiabilidad y disponibilidad. Para alcanzar un SLO del 99,95 %, 99,99 % o superior, es necesario aplicar patrones de diseño críticos complementarios y rigor operativo. En este artículo se describen las áreas técnicas clave y cómo implementar e introducir prácticas de diseño críticas.
Nota
Las orientaciones de este artículo se basan en la metodología de diseño y los procedimientos recomendados de la serie de Carga de trabajo crítica en un marco de buena arquitectura.
En las secciones siguientes se describe cómo:
- Revise la carga de trabajo existente para comprender sus componentes, los flujos de usuario y del sistema, y los requisitos de disponibilidad y escalabilidad.
- Desarrolle e implemente una arquitectura de unidades de escala para optimizar la escalabilidad de extremo a extremo mediante la compartimentación y para estandarizar el proceso de adición y eliminación de capacidad.
- Implemente unidades de escalado efímeras y sin estado o sellos de implementación para habilitar la escalabilidad y las implementaciones sin tiempo de inactividad.
- Determine si puede dividir la carga de trabajo en componentes para preparar la escalabilidad. Los componentes individuales son necesarios para los flujos de escalabilidad y desacoplamiento.
- Prepárese para la distribución global mediante la implementación de una carga de trabajo en más de una región de Azure para mejorar la proximidad al cliente y prepararse para posibles interrupciones regionales.
- Desacople los componentes e implemente una arquitectura basada en eventos.
Architecture
En el diagrama siguiente se aplican las consideraciones anteriores al patrón de aplicación web confiable.
Descargue un archivo Visio de esta arquitectura.
El cuadro rojo representa una unidad de escalado con servicios que se escalan juntos. Para escalarlos juntos con eficacia, optimice el tamaño de cada servicio, la SKU y las direcciones IP disponibles. Por ejemplo, el número máximo de solicitudes que sirve Azure App Configuration se correlaciona con el número de solicitudes por segundo que proporciona una unidad de escalado. Al agregar más capacidad en una región, también debe agregar más unidades de escalado individuales.
Estas unidades de escala individuales no tienen interdependencias y solo se comunican con servicios compartidos fuera de la unidad de escalado individual. Puede probar las unidades de escalado independientes por adelantado. Para evitar que afecte a otras áreas de implementación, implemente unidades de escalado independientes e introduzca la opción de reemplazar los servicios en una nueva versión.
En el caso de las cargas de trabajo críticas, las unidades de escalado independientes son temporales, lo que optimiza los procesos de lanzamiento y proporciona escalabilidad dentro y entre regiones. Evite almacenar el estado en unidades de escalado independientes. Considere usar Azure Cache for Redis para el almacenamiento en la unidad de escalado, y almacene solo el estado crítico o los datos que también se almacenan en la base de datos. Si se produce una interrupción de la unidad de escalado o se conmuta a otra unidad de escalado, es posible que se produzca una ralentización o que sea necesario un nuevo inicio de sesión, pero Azure Cache for Redis seguirá funcionando.
Application Insights se excluye de la unidad de escalado. Excluya los servicios que almacenan o supervisan los datos. Sepárelos en su propio grupo de recursos con su propio ciclo de vida.
Al reemplazar una unidad de escalado o implementar una nueva, mantenga los datos históricos y use una instancia por región.
Para más información, consulte Diseño de aplicaciones de cargas de trabajo críticas en Azure.
Componentes
Esta arquitectura utiliza los siguientes componentes.
- App Service es la plataforma de hospedaje de aplicaciones.
- Azure Cache for Redis almacena en caché las solicitudes.
- App Configuration almacena los valores de configuración.
- Azure SQL es la base de datos back-end.
- Application Insights obtiene telemetría de la aplicación.
Alternativas
En el patrón de aplicación web confiable, puede hacer lo siguiente:
- Use Azure Kubernetes Service (AKS) en lugar de App Service. Esta opción funciona bien para cargas de trabajo complejas que tienen un gran número de microservicios. AKS proporciona más control sobre la infraestructura subyacente y permite configuraciones complejas de varios niveles.
- Convierta la carga de trabajo en contenedores. App Service admite la contenedorización, pero en este ejemplo la carga de trabajo no está en contenedor. Use contenedores para aumentar la confiabilidad y la portabilidad.
Para más información, consulte Consideraciones sobre la plataforma de aplicaciones para las cargas de trabajo críticas en Azure.
Elección de la plataforma de aplicaciones
El nivel de disponibilidad depende de su elección y configuración de la plataforma de aplicaciones. Tenga en cuenta las siguientes instrucciones críticas:
- Use zonas de disponibilidad siempre que sea posible.
- Seleccione el servicio de plataforma adecuado para la carga de trabajo.
- Convierta la carga de trabajo en contenedores.
Los conjuntos de disponibilidad propagan las implementaciones entre varios dominios de error y actualización dentro de un centro de datos. Las zonas de disponibilidad distribuyen las implementaciones entre centros de datos individuales dentro de una región de Azure. Las zonas de disponibilidad suelen tener prioridad, pero la estrategia que se usa depende de la carga de trabajo. Por ejemplo, las cargas de trabajo sensibles a la latencia o locuaces pueden beneficiarse de la priorización de conjuntos de disponibilidad. Si distribuye la carga de trabajo entre zonas de disponibilidad, puede aumentar la latencia y el costo del tráfico entre zonas. Al usar zonas de disponibilidad, asegúrese de que todos los servicios de una unidad de escalado los admitan. Todos los servicios del patrón de aplicación web confiable admiten zonas de disponibilidad.
Elección de la plataforma de datos
La plataforma de base de datos que elija afecta a la arquitectura general de la carga de trabajo, especialmente la compatibilidad con la configuración activa-activa o activa-pasiva de la plataforma. El patrón de aplicación web confiable usa Azure SQL, que no admite de forma nativa implementaciones de configuración activa-activa con operaciones de escritura en más de una instancia. Por lo tanto, el nivel de base de datos se limita a una estrategia activa-pasiva. Una estrategia activa-activa en el nivel de aplicación es posible si hay réplicas de solo lectura y se escribe en una sola región.
Descargue un archivo Visio de esta arquitectura.
Varias bases de datos son comunes en arquitecturas complejas, como arquitecturas de microservicios que tienen una base de datos para cada servicio. Las bases de datos múltiples permiten la adopción de una base de datos de escritura múltiple como Azure Cosmos DB, que mejora la alta disponibilidad y la baja latencia. La latencia entre regiones puede crear limitaciones. Es fundamental tener en cuenta los requisitos no funcionales y factores como la coherencia, la operabilidad, el costo y la complejidad. Permita que los servicios individuales usen almacenes de datos independientes y tecnologías de datos especializadas para satisfacer sus requisitos únicos. Para más información, consulte Consideraciones sobre la plataforma de datos para las cargas de trabajo críticas en Azure.
Definición de un modelo de mantenimiento
En cargas de trabajo complejas de varios niveles que se distribuyen entre varios centros de datos y regiones geográficas, debe definir un modelo de mantenimiento. Defina los flujos de usuarios y sistemas, especifique y comprenda las dependencias entre los servicios, comprenda el efecto que las interrupciones o una degradación del rendimiento en uno de los servicios pueden tener en la carga de trabajo global, y supervise y visualice la experiencia del cliente para habilitar una supervisión adecuada y mejorar las acciones manuales y automatizadas.
El diagrama anterior muestra cómo una interrupción o una degradación de un único componente, como App Configuration, puede causar una degradación potencial del rendimiento para el cliente.
Al separar componentes en unidades de escalado, permite dejar de enviar tráfico a la parte afectada de la aplicación, como una unidad de escalado afectada o la región completa.
Para más información, consulta Modelado de estado y observabilidad de cargas de trabajo críticas en Azure.
Seguridad y redes
Existen requisitos estrictos de red y seguridad para las cargas de trabajo que se migran desde una implementación empresarial local. No todos los procesos locales establecidos se traducen en un entorno de nube. Evalúe estos requisitos si son aplicables en entornos de nube.
La identidad suele ser el perímetro de seguridad principal para los patrones nativos de la nube. Es posible que los clientes empresariales necesiten medidas de seguridad más importantes. Para satisfacer sus requisitos de seguridad de red, la mayoría de los servicios PaaS de Azure pueden usar Azure Private Link para implementar la red como perímetro de seguridad. Private Link puede garantizar que solo se pueda acceder a los servicios desde dentro de una red virtual. Solo se puede acceder a todos los servicios a través de puntos de conexión privados. En el diagrama siguiente se muestra cómo el único punto de conexión público accesible desde Internet es Azure Front Door.
Descargue un archivo Visio de esta arquitectura.
Para que el patrón de aplicación web confiable configure una red como perímetro de seguridad, debe usar:
- Private Link para todos los servicios que lo admiten.
- Azure Front Door Premium como único punto de conexión público accesible desde Internet.
- Jumpboxes para acceder a los servicios a través de Azure Bastion.
- Agentes de compilación autohospedados que pueden acceder a los servicios.
Otro requisito de red común para las aplicaciones críticas es restringir el tráfico de salida para evitar la filtración de datos. Restrinja el tráfico de salida mediante el enrutamiento de un firewall de Azure a través de un dispositivo de firewall adecuado y filtrándolo con el dispositivo. La arquitectura de línea base crítica de Azure con controles de red usa un firewall y Private Link.
Implementación y pruebas
El tiempo de inactividad causado por versiones erróneas o errores humanos puede ser un problema para una carga de trabajo que siempre debe estar disponible. Estas son algunas áreas clave a tener en cuenta:
- Implementaciones de tiempo de inactividad cero
- Implementaciones azules-verdes transitorias
- Análisis del ciclo de vida de los componentes individuales y agrupación de los mismos
- Validación continua
Las implementaciones de tiempo de inactividad cero son clave para las cargas de trabajo críticas. Una carga de trabajo que siempre debe estar en funcionamiento no puede tener una ventana de mantenimiento para implementar versiones más recientes. Para solucionar esta limitación, la arquitectura crítica de Azure sigue el patrón de implementaciones de tiempo de inactividad cero. Los cambios se implementan como nuevas unidades de escalado o stamps que se prueban de un extremo a otro antes de que el tráfico se enrute incrementalmente a ellas. Después de que todo el tráfico se enrute a la nueva marca, los stamps antiguos se deshabilitan y se quitan.
Para más información, consulte Implementación y pruebas de cargas de trabajo críticas en Azure.
Pasos siguientes
- Ruta de aprendizaje: Creación de cargas de trabajo críticas en Azure
- Proyecto de desafío: Diseño de una aplicación web crítica
- Módulo de aprendizaje: Diseño de un modelo de estado para la carga de trabajo crítica