En este artículo se describe cómo implementar aplicaciones web críticas mediante 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 aplicación web confiable para .NET proporciona instrucciones para actualizar o replatar aplicaciones web que se mueven a la nube. Este enfoque le ayuda a minimizar los cambios de código necesarios y establecer como destino un objetivo de nivel de servicio (SLO) de 99,9%. Las cargas de trabajo críticas tienen requisitos de alta confiabilidad y disponibilidad. Para alcanzar un SLO de 99,95%, 99,99%, o superior, debe 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 introducir e implementar prácticas de diseño críticas.
Nota
Las instrucciones de este artículo se basan en la metodología de diseño y los procedimientos recomendados de la serie carga de trabajo crítica deWell-Architected Framework.
En las secciones siguientes se describe cómo:
- Revise una carga de trabajo existente para comprender sus componentes, flujos de usuario y sistema, así como los requisitos de disponibilidad y escalabilidad.
- Desarrolle e implemente una arquitectura de unidad de escalado optimizar la escalabilidad de un extremo a otro a través de la compartimentación y estandarizar el proceso de adición y eliminación de capacidad.
- Implemente unidades de escalado efímeras sin estado o stamps de implementación para permitir implementaciones de escalabilidad y sin tiempo de inactividad.
- Determine si puede dividir la carga de trabajo en componentes para prepararse para la escalabilidad. Los componentes individuales son necesarios para los flujos de escalabilidad y desacoplamiento.
- Prepárese para de 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.
- Desacopla los componentes e implementa una arquitectura controlada por eventos.
Arquitectura
En el diagrama siguiente se aplican las consideraciones anteriores al patrón de aplicación web confiable .
Descargar un archivo de Visio de esta arquitectura.
El cuadro rojo representa una unidad de escalado con servicios que se escalan juntos. Para escalarlas de forma eficaz, optimice el tamaño, la SKU y las direcciones IP disponibles de cada servicio. Por ejemplo, el número máximo de solicitudes que Azure App Configuration atiende 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 escalado individuales no tienen dependencias entre sí y solo se comunican con servicios compartidos fuera de la unidad de escalado individual. Puede usar estas unidades de escalado en un implementación azul-verde implementando nuevas unidades de escalado, validando que funcionan correctamente y moviendo gradualmente el tráfico de producción a ellas.
En este escenario, consideramos que las unidades de escalado son temporales, lo que optimiza los procesos de lanzamiento y proporciona escalabilidad dentro y entre regiones. Al adoptar este enfoque, debe almacenar datos solo en la base de datos porque la base de datos se replica en la región secundaria. Si necesita almacenar datos en la unidad de escalado, considere la posibilidad de usar Azure Cache for Redis para el almacenamiento en la unidad de escalado. Si se debe abandonar una unidad de escalado, volver a rellenar la memoria caché podría aumentar la latencia, pero no provoca interrupciones.
Application Insights se excluye de la unidad de escalado. Excluir servicios que almacenan o supervisan datos. Separe 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 para cada región.
Para más información, consulte Diseño de aplicaciones de cargas de trabajo críticas en Azure.
Componentes
Esta arquitectura usa los siguientes componentes.
- app Service es la plataforma de hospedaje de aplicaciones.
- Azure Cache for Redis almacena en caché las solicitudes.
- App Configuration almacena las opciones 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:
- Usar de 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.
- Incluir en contenedores la carga de trabajo. App Service admite la contenedorización, pero en este ejemplo la carga de trabajo no está en contenedores. Use contenedores para aumentar la confiabilidad y la portabilidad.
Para más información, consulte Consideraciones de la plataforma de aplicaciones para cargas de trabajo críticas en Azure.
Consideraciones para la alta disponibilidad
Independientemente de la plataforma de aplicaciones que elija, se recomienda priorizar el uso de zonas de disponibilidad para cargas de trabajo de producción.
conjuntos de disponibilidad distribuir implementaciones entre varios dominios de error y actualización dentro de un centro de datos. zonas de disponibilidad distribuir implementaciones entre centros de datos individuales dentro de una región de Azure. Las zonas de disponibilidad suelen tener prioridad, pero la estrategia que use depende de la carga de trabajo. Por ejemplo, las cargas de trabajo sensibles a la latencia o chatty 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. Cuando use 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 activas y activas que tienen operaciones de escritura en más de una instancia. En esta configuración, la plataforma de datos se limita a una estrategia activa-pasiva. Una estrategia activa-activa (parcial) en el nivel de aplicación es posible si hay réplicas de solo lectura en todas las regiones y solo se escribe en una sola región.
Varias bases de datos son comunes en arquitecturas complejas, como arquitecturas de microservicios que tienen una base de datos para cada servicio. Varias bases de datos permiten la adopción de una base de datos de escritura principal múltiple, como Azure Cosmos DB, lo 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. Permitir 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 de la plataforma de datos para 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.
Para definir un modelo de mantenimiento:
- Definición de flujos de usuario y sistema
- Especificación y comprensión de las dependencias entre los servicios
- Comprender el efecto que las interrupciones o una degradación del rendimiento en uno de los servicios pueden tener en la carga de trabajo general.
- Supervise y visualice la experiencia del cliente para habilitar la supervisión adecuada y mejorar las acciones manuales y automatizadas.
En el diagrama anterior se muestra cómo una interrupción o una degradación de un único componente, como App Configuration, puede provocar una posible degradación del rendimiento para el cliente. Al separar los 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.
Los criterios para determinar el estado de una unidad de escalado se definen en el modelo de mantenimiento. A continuación, este modelo se conecta al punto de conexión de mantenimiento de de la unidad de escalado, lo que permite al equilibrador de carga global consultar el estado de mantenimiento de una unidad de escalado y usar esa información para tomar decisiones de enrutamiento.
Para más información, consulte modelado y observabilidad de Health de cargas de trabajo críticas en Azure.
Seguridad y redes
Las cargas de trabajo críticas tienen requisitos estrictos de red y seguridad. Aplique la diligencia especialmente a las cargas de trabajo migradas desde un entorno local, ya que no todas las prácticas de seguridad locales establecidas se traducen en un entorno en la nube. Se recomienda volver a evaluar los requisitos de seguridad durante la migración de la aplicación.
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 abordar sus requisitos de seguridad de red, los servicios PaaS de Azure pueden usar Azure Private Link para implementar la red como perímetro de seguridad. Private Link ayuda a garantizar que los servicios solo son accesibles desde dentro de una red virtual. A continuación, 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.
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.
- Jump boxes 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. A continuación, filtre el tráfico mediante 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 que se deben tener en cuenta:
- Implementaciones sin tiempo de inactividad
- Implementaciones de color azul-verde efímero
- Análisis del ciclo de vida de los componentes individuales y agrupados
- Validación continua
implementaciones de tiempo de inactividad cero son clave para 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 sellos que se prueban de extremo a extremo antes de que el tráfico se enrute incrementalmente a ellos. Una vez que todo el tráfico se enruta a la nueva marca, los sellos antiguos se deshabilitan y quitan.
Para más información, consulte implementación y pruebas de para cargas de trabajo críticas en Azure.
Pasos siguientes
- ruta de aprendizaje de : 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 Learn: Diseño de un modelo de mantenimiento para la carga de trabajo crítica