Compartir a través de

Aplicación web redundante por zonas de alta disponibilidad de línea de base

Azure App Service
Azure Application Gateway
Azure Storage
Azure SQL Database
Azure Private Link
Azure Virtual Network
Azure Monitor

Esta arquitectura de línea de base se basa en la arquitectura básica de aplicaciones web y proporciona instrucciones detalladas para diseñar una aplicación web segura, con redundancia de zona y de alta disponibilidad en Azure. En esta arquitectura, Azure Application Gateway con Azure Web Application Firewall expone un punto de conexión público y enruta las solicitudes a Azure App Service mediante Azure Private Link. La aplicación App Service usa la integración de red virtual y Private Link para comunicarse de forma segura con soluciones de plataforma como servicio (PaaS) de Azure, como Azure Key Vault y Azure SQL Database.

Importante

Una implementación de ejemplo muestra esta implementación de App Service de línea base en Azure. Utilícelo como base para su solución de producción.

Arquitectura

Diagrama que muestra una arquitectura con base de referencia de App Service con redundancia de zonas y alta disponibilidad.

Descargue un archivo Visio de esta arquitectura.

Componentes

Esta arquitectura comparte muchos componentes con la arquitectura básica de la aplicación web. En la lista siguiente se describen solo los componentes que difieren o amplían la arquitectura básica:

  • Application Gateway es un equilibrador de carga HTTP y HTTPS de nivel 7 y un administrador de tráfico web. En esta arquitectura, Application Gateway actúa como un único punto de entrada público. Application Gateway finaliza la seguridad de la capa de transporte (TLS) y evalúa las reglas de Azure Web Application Firewall. A continuación, reenvía las solicitudes aprobadas de forma privada a las instancias de App Service entre zonas de disponibilidad.

  • Azure Web Application Firewall es un servicio nativo en la nube que protege las aplicaciones web frente a vulnerabilidades de seguridad comunes, como la inserción de SQL y el scripting entre sitios (XSS). En esta arquitectura, Azure Web Application Firewall se ejecuta en Application Gateway y bloquea las solicitudes malintencionadas antes de llegar a App Service. Esta configuración mejora la seguridad y ayuda a mantener la disponibilidad.

  • Key Vault es un servicio que almacena y administra de forma segura secretos, claves de cifrado y certificados. En esta arquitectura, almacena el certificado TLS (X.509) que usa Application Gateway y contiene secretos de aplicación a los que App Service accede de forma privada.

  • Azure Virtual Network es un servicio que proporciona redes virtuales privadas aisladas y seguras en Azure. En esta arquitectura, la red virtual proporciona puntos de conexión privados, integración de App Service y subredes dedicadas para Application Gateway. Esta configuración aísla el tráfico y permite que App Service se comunique de forma segura con los servicios de Azure dependientes a través de puntos de conexión privados.

  • Private Link es un servicio de red que proporciona acceso privado a los servicios de Azure a través de la red troncal de Microsoft para eliminar la exposición a la red pública de Internet. En esta arquitectura, Private Link habilita conexiones de entrada privadas a App Service y conexiones salientes privadas de App Service a servicios como Key Vault, SQL Database y Azure Storage.

  • Azure DNS es un servicio de hospedaje para dominios del sistema de nombres de dominio (DNS). Proporciona resolución de nombres mediante la infraestructura de Microsoft Azure. Las zonas DNS privadas asignan el nombre de dominio completo (FQDN) de un servicio a la dirección IP de un punto de conexión privado. En esta arquitectura, las zonas DNS privadas asignan el dominio predeterminado de App Service y otros dominios de servicio PaaS a sus direcciones de punto de conexión privado para que todo el tráfico permanezca en la red privada.

Redes

La seguridad de red es fundamental para la arquitectura de línea de base de App Service. En un nivel alto, la arquitectura de red proporciona las siguientes funcionalidades:

  • Un único punto de entrada seguro para el tráfico de clientes

  • Filtrado del tráfico a través de Azure Web Application Firewall

  • Cifrado TLS de un extremo a otro para los datos en tránsito

  • Filtración de datos minimizada a través de Private Link, que mantiene el tráfico dentro de Azure

  • Agrupación lógica y aislamiento de recursos de red a través de la segmentación de red

Flujos de red

Diagrama que muestra los flujos de red en una arquitectura de red de App Service de línea base.

Flujo entrante

En los pasos siguientes se describe el flujo de entrada de Internet a la instancia de App Service:

  1. El usuario emite una solicitud a la dirección IP pública de Application Gateway.

  2. Application Gateway evalúa las reglas de Firewall de aplicaciones web, que protegen contra ataques como XSS e inyección de CÓDIGO SQL. Si una regla detecta una infracción, Application Gateway devuelve un error al solicitante y detiene el procesamiento. De lo contrario, Application Gateway enruta la solicitud al grupo de back-end, que en este caso es el dominio predeterminado de App Service.

  3. La zona privatelink.azurewebsites.net DNS privada se vincula a la red virtual. La zona DNS contiene un registro A que asigna el dominio predeterminado de App Service a la dirección IP privada del punto de conexión privado de App Service. Azure DNS usa este registro para resolver el dominio predeterminado a la dirección IP del punto de conexión privado.

  4. Application Gateway enruta la solicitud a una instancia de App Service a través del punto de conexión privado.

Flujo de salida

En los pasos siguientes se describe el flujo de salida de App Service a los servicios PaaS de Azure:

  1. App Service envía una solicitud al nombre DNS del servicio de Azure necesario, como Key Vault, Storage, SQL Database o cualquier otro servicio de Azure que admita Private Link. La función de integración de red virtual de App Service enruta la solicitud a través de la red virtual.

  2. De forma similar al paso 3 del flujo de entrada, la zona DNS privada vinculada contiene un registro A que asigna el dominio del servicio de Azure a su dirección IP del punto de conexión privado. Azure DNS usa este registro para resolver el dominio en la dirección IP del punto de conexión privado del servicio.

  3. La red virtual enruta la solicitud al servicio a través del punto de conexión privado.

El tráfico saliente que no va a los servicios paaS de Azure sale a través de una dirección IP pública que comparten varios clientes. Por ejemplo, una aplicación web podría llamar a una API pública durante una solicitud HTTP. Para controlar este tipo de tráfico de salida, enrutelo a través de un dispositivo de red como Azure Firewall. Para más información, consulte Control del tráfico saliente mediante Azure Firewall.

Implementación de Application Gateway

Application Gateway es un equilibrador de carga escalable, regional y de nivel 7 que admite la descarga de TLS y el firewall de aplicaciones web de Azure. Al implementar Application Gateway para el tráfico entrante a App Service, tenga en cuenta los siguientes puntos:

Flujo de App Service a servicios de Azure

Esta arquitectura usa la integración de red virtual para enrutar el tráfico de App Service a los puntos de conexión privados a través de la red virtual. La arquitectura de línea de base no habilita todo el enrutamiento de tráfico, lo que forzaría todo el tráfico saliente a través de la red virtual. En su lugar, enruta solo el tráfico interno enlazado a los puntos de conexión privados.

En el caso de los servicios de Azure que no requieren acceso público a Internet, permita puntos de conexión privados y bloquee los puntos de conexión públicos. Los puntos de conexión privados mejoran la seguridad al permitir que App Service se conecte a los servicios de Private Link directamente desde la red virtual privada sin direcciones IP públicas.

En esta arquitectura, SQL Database, Storage y Key Vault tienen bloqueados los puntos de conexión públicos. Sus firewalls de servicio permiten el tráfico solo desde otros servicios de Azure autorizados. Configure otros servicios de Azure, como Azure Cosmos DB y Azure Managed Redis, con puntos de conexión privados. En esta arquitectura, Azure Monitor no usa un punto de conexión privado, pero puede implementar uno mediante un ámbito de Private Link (AMPLS) de Azure Monitor.

La arquitectura de línea de base implementa una zona DNS privada para cada servicio. Cada zona DNS privada contiene un registro A que asigna el FQDN del servicio a la dirección IP del punto de conexión privado. Las zonas se vinculan a la red virtual. Los grupos de zonas DNS privadas crean y actualizan automáticamente registros DNS para puntos de conexión privados.

Tenga en cuenta los siguientes puntos al implementar la integración de red virtual y los puntos de conexión privados:

Segmentación y seguridad de la red virtual

La red de esta arquitectura tiene subredes independientes para Application Gateway, componentes de integración de App Service y puntos de conexión privados. Un grupo de seguridad de red (NSG) en cada subred solo permite el tráfico entrante y saliente necesario. En la tabla siguiente se describe una selección de reglas de NSG que puede agregar a cada subred.

Subred Entrada Salida
GatewaySubnet AppGw.In.Allow.ControlPlane: Permitir el acceso entrante al plano de control.

AppGw.In.Allow443.Internet: permite el acceso HTTPS entrante a Internet.		 AppGw.Out.Allow.PrivateEndpoints: permite el acceso saliente a PrivateEndpointsSubnet.

AppPlan.Out.Allow.AzureMonitor: permitir el acceso saliente a Azure Monitor.
PrivateEndpointsSubnet Reglas predeterminadas: permitir el acceso entrante desde la red virtual. Reglas predeterminadas: permitir el acceso saliente a la red virtual.
AppServiceSubnet Reglas predeterminadas: permitir el acceso entrante desde la red virtual. AppPlan.Out.Allow.PrivateEndpoints: permite el acceso saliente a PrivateEndpointsSubnet.

AppPlan.Out.Allow.AzureMonitor: permitir el acceso saliente a Azure Monitor.

Tenga en cuenta los siguientes puntos al implementar la segmentación y la seguridad de la red virtual:

  • Habilite la protección contra DDoS para la red virtual que contiene una subred de puerta de enlace de aplicaciones con una dirección IP pública.

  • Agregue un NSG (grupo de seguridad de red) a cada subred siempre que sea posible. Use las reglas más estrictas que permitan la funcionalidad completa de la solución.

  • Use grupos de seguridad de aplicaciones para agrupar recursos lógicamente, lo que simplifica la creación de reglas de NSG en entornos complejos.

En la tabla siguiente se muestra un esquema de red de ejemplo.

Tipo Nombre Intervalo de direcciones
Red de área virtual Prefijo de dirección 10.0.0.0/16
Subred GatewaySubnet 10.0.1.0/24
Subred AppServiceSubnet 10.0.0.0/24
Subred PrivateEndpointsSubnet 10.0.2.0/27
Subred AgentsSubnet 10.0.2.32/27

Consideraciones

Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Marco de buena arquitectura.

Reliability

La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para obtener más información, vea Lista de comprobación de revisión de diseño para lade confiabilidad.

La arquitectura de App Service de línea base se centra en la redundancia zonal para los servicios regionales clave. Las zonas de disponibilidad son ubicaciones físicamente independientes dentro de una región que proporcionan alta disponibilidad y tolerancia a errores. Al implementar dos o más instancias en zonas de disponibilidad en regiones admitidas, la falla de una zona no afecta a las demás. Este enfoque ayuda a mantener la disponibilidad del servicio.

La arquitectura también garantiza instancias suficientes de los servicios de Azure para satisfacer la demanda. En las secciones siguientes se proporcionan instrucciones de confiabilidad para cada servicio clave de la arquitectura.

Application Gateway

Implemente Application Gateway en una configuración con redundancia de zona con un recuento mínimo de instancias de escalado de tres o más. Varias instancias garantizan que el servicio permanece disponible durante los errores sin esperar el tiempo de inicio de seis minutos a siete minutos necesario para configurar una nueva instancia.

Servicio de Aplicaciones

  • Implemente un mínimo de dos instancias de App Service que admitan zonas de disponibilidad. Para lograr una mayor resistencia, implemente al menos una instancia para cada zona de disponibilidad de la región, además de instancias adicionales dentro de cada zona para la redundancia.

  • Implemente puntos de conexión de comprobación de estado en las aplicaciones y configure la característica de comprobación de estado de App Service para volver a enrutar las solicitudes de las instancias incorrectas. Para obtener más información, consulte Controlar instancias de App Service mediante comprobaciones de estado y las comprobaciones de estado en ASP.NET Core.

  • Capacidad de sobreaprovisionamiento para manejar los fallos de zona.

Almacenamiento de Blobs

  • Use el almacenamiento con redundancia de zona (ZRS), que replica los datos de forma sincrónica en tres zonas de disponibilidad de la región. Cree cuentas de almacenamiento ZRS estándar o almacenamiento con redundancia geozonal estándar (GZRS) para garantizar la replicación de datos en zonas de disponibilidad.

  • Cree cuentas de almacenamiento independientes para implementaciones, recursos web y otros datos para administrar y configurar cada cuenta de forma independiente.

SQL Database

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el uso indebido de sus valiosos datos y sistemas. Para obtener más información, vea Lista de comprobación de revisión de diseño para security.

La arquitectura de línea de base de App Service se centra en recomendaciones de seguridad esenciales para su aplicación web. Debe comprender cómo funciona el cifrado y la identidad en cada nivel para ayudar a proteger la carga de trabajo.

Servicio de Aplicaciones

  • Desactive los métodos de autenticación local para las implementaciones de sitio de Protocolo de transferencia de archivos (FTP) y administración de control de código fuente (SCM).

  • Desactiva la depuración remota.

  • Use la versión más reciente de TLS que admiten todos los clientes.

  • Active el plan de Microsoft Defender para App Service.

  • Use las versiones más recientes de las plataformas compatibles, los lenguajes de programación, los protocolos y los marcos.

  • Considere Entorno de App Service si necesita un mayor aislamiento o un acceso seguro a la red.

Cifrado

Las aplicaciones web de producción deben cifrar los datos en tránsito mediante HTTPS. HTTPS se basa en TLS y usa claves públicas y privadas para el cifrado. Almacene el certificado TLS (X.509) en Key Vault y conceda permiso a Application Gateway para recuperar la clave privada. Para los datos en reposo, algunos servicios cifran automáticamente los datos y otros le permiten personalizar la configuración.

Datos en tránsito

La arquitectura básica cifra los datos mientras se transfieren del usuario a la aplicación web en App Service.

Diagrama que muestra un flujo de cifrado de App Service de línea de base.

En el flujo de trabajo siguiente se describe cómo funciona el cifrado en un nivel alto:

  1. El usuario envía una solicitud HTTPS a la aplicación web.

  2. La solicitud HTTPS llega a la puerta de enlace de la aplicación.

  3. La puerta de enlace de aplicaciones utiliza un certificado (X.509) en Key Vault para crear una conexión TLS segura con el navegador web del usuario. La puerta de enlace de aplicaciones descifra la solicitud HTTPS para que el firewall de aplicaciones web pueda inspeccionarla.

  4. La puerta de enlace de aplicaciones crea una conexión TLS a App Service para volver a cifrar la solicitud de usuario. App Service proporciona compatibilidad nativa con HTTPS, por lo que no es necesario agregar un certificado a App Service. La puerta de enlace de aplicaciones envía el tráfico cifrado a App Service. App Service descifra el tráfico y la aplicación Web procesa la solicitud.

Tenga en cuenta las siguientes recomendaciones al configurar el cifrado de datos en tránsito:

  • Cree o cargue su certificado en Key Vault. El cifrado HTTPS requiere un certificado (X.509). Necesita un certificado de una autoridad de certificación de confianza para su dominio personalizado.

  • Almacene la clave privada del certificado en Key Vault.

  • Proporcione acceso a Application Gateway a la clave privada del certificado. Para más información, consulte Concesión de permisos mediante el control de acceso basado en rol de Azure (Azure RBAC) e identidades administradas para recursos de Azure. No utilice directivas de acceso al almacén de claves para proporcionar acceso. Las directivas de acceso permiten conceder solo permisos amplios, no valores específicos.

  • Active el cifrado de un extremo a otro. App Service es el grupo de back-end para la puerta de enlace de aplicaciones. Al configurar los ajustes del grupo de back-end, use el protocolo HTTPS en el puerto de back-end 443.

Datos en reposo

  • Use el cifrado de datos transparente para cifrar datos confidenciales en SQL Database. El cifrado de datos transparente cifra toda la base de datos, las copias de seguridad y los archivos de registro de transacciones y no requiere cambios en la aplicación web.

  • Coloque datos confidenciales en su propia base de datos y active el cifrado solo para esa base de datos. Este enfoque minimiza la latencia de cifrado de base de datos.

  • Comprende el soporte de cifrado integrado. Azure Storage cifra automáticamente los datos en reposo a través del cifrado del lado servidor (Estándar de cifrado avanzado de 256 bits [AES]). Azure Monitor cifra automáticamente los datos en reposo mediante claves administradas por Microsoft.

Gobernanza

Azure Policy ayuda a aplicar decisiones de arquitectura y seguridad para aplicaciones web. Puede impedir que los recursos no conformes se implementen (modo de denegación) o marcarlos para su revisión (modo de auditoría). Este enfoque ayuda a detectar el desfase de configuración de la arquitectura prevista, tanto si el desfase se produce a través de implementaciones de infraestructura como código (IaC) como cambios manuales en Azure Portal.

Coloque todos los recursos en su arquitectura bajo la gobernanza de Azure Policy. Use directivas integradas o iniciativas de directiva siempre que sea posible para aplicar la topología de red esencial, las características de servicio, la seguridad y las decisiones de supervisión. Tenga en cuenta las siguientes políticas integradas.

  • App Service debe deshabilitar el acceso a la red pública.
  • App Service debe usar la integración de red virtual.
  • App Service debe usar Private Link para conectarse a los servicios paaS.
  • App Service debe tener deshabilitados los métodos de autenticación local para las implementaciones de sitio FTP y SCM.
  • App Service debe tener desactivada la depuración remota.
  • Las aplicaciones de App Service deben usar la versión más reciente de TLS.
  • Defender para App Service debe estar habilitado.
  • Azure Web Application Firewall debe estar habilitado para Application Gateway.

Consulte más directivas integradas para servicios clave, como Application Gateway y componentes de red, App Service, Key Vault y componentes de supervisión. Puede crear directivas personalizadas o usar directivas de comunidad, como directivas de zonas de aterrizaje de Azure, si las directivas integradas no satisfacen sus necesidades. Se prefieren directivas integradas siempre que sea posible.

Administración de identidades y acceso

La arquitectura de línea de base de App Service configura la autenticación y autorización para las identidades de usuario (usuarios) y las identidades de carga de trabajo (recursos de Azure). Implementa el principio de privilegios mínimos.

Identidades de usuarios

  • Use el mecanismo de autenticación integrado para App Service, también denominado EasyAuth. EasyAuth simplifica la integración del proveedor de identidades con la aplicación web. Gestiona la autenticación fuera de su aplicación web, por lo que no tiene que realizar cambios significativos en el código.

  • Configura la URL de respuesta para el dominio personalizado. Establezca la dirección URL de redireccionamiento en https://<application-gateway-endpoint>/.auth/login/<provider>/callback.

    Reemplace por <application-gateway-endpoint> la dirección IP pública o el nombre de dominio personalizado de la puerta de enlace de aplicaciones. Reemplace <provider> con su proveedor de autenticación, como aad para Microsoft Entra ID.

    Para obtener instrucciones de configuración, consulte Consideraciones de Azure Front Door o Configuración de Application Gateway.

Identidades de cargas de trabajo

  • Use identidades administradas para las identidades de carga de trabajo. Las identidades administradas eliminan la necesidad de que los desarrolladores administren las credenciales de autenticación.

  • Utiliza identidades gestionadas asignadas por el usuario. Las identidades asignadas por el sistema pueden provocar errores en las implementaciones de IaC en función de las condiciones de paralelismo y el orden de las operaciones. Las identidades administradas asignadas por el usuario evitan algunos de estos escenarios de error de implementación. Para más información, consulte Identidades administradas.

Excelencia operativa

La excelencia operativa abarca los procesos de operaciones que implementan una aplicación y lo mantienen en ejecución en producción. Para obtener más información, vea Lista de comprobación de revisión de diseño para la excelencia operativa.

La implementación de la aplicación de App Service de línea base sigue las instrucciones de arquitectura de Azure Pipelines. Dado que la arquitectura de línea base deniega el acceso público a App Service y protege la cuenta de almacenamiento de implementación dentro de la red virtual, no se puede implementar desde fuera de la red virtual. Para solucionar esta restricción, la arquitectura usa agentes de implementación autohospedados que se ejecutan dentro de la red virtual. La siguiente guía de implementación se centra en la implementación del código de la aplicación, no en los cambios en la infraestructura ni en la base de datos.

Diagrama que muestra una arquitectura de implementación básica de App Service.

Flujo de implementación

  1. El pipeline de publicación envía una solicitud de trabajo a la cola de trabajos para los agentes autohospedados. El trabajo indica al agente que cargue el artefacto de compilación del archivo ZIP de publicación en una cuenta de almacenamiento.

  2. Un agente de implementación autohospedado sondea la cola, recoge la solicitud de trabajo y descarga la tarea y el artefacto de construcción.

  3. El agente de implementación autohospedado carga el archivo zip en la cuenta de almacenamiento mediante el punto de conexión privado de la cuenta de almacenamiento.

  4. La canalización continúa y un agente administrado recoge un trabajo posterior. El agente administrado realiza una llamada de interfaz de línea de comandos (CLI) para actualizar la configuración de la aplicación WEBSITE_RUN_FROM_PACKAGE y referenciar el nuevo archivo ZIP de publicación para el slot de ensayo.

    az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip

  5. App Service extrae el nuevo archivo ZIP de publicación del almacenamiento a través del punto de conexión privado de la cuenta de almacenamiento. Reinicia la instancia de almacenamiento provisional con el nuevo paquete porque WEBSITE_RUN_FROM_PACKAGE se estableció en un nombre de archivo diferente.

  6. La canalización reanuda y ejecuta pruebas de humo o espera la aprobación manual. Después de pruebas o aprobaciones exitosas, la canalización intercambia los espacios de ensayo y producción.

Guía para la implementación

Aplique las siguientes instrucciones de implementación para la arquitectura de línea base:

  • Ejecute la implementación directamente desde un paquete de App Service para evitar conflictos de implementación. Este enfoque monta el paquete ZIP directamente como directorio wwwroot de solo lectura en lugar de copiar archivos. Elimina los conflictos de bloqueo de archivos entre la implementación y el tiempo de ejecución y garantiza que solo se ejecuten aplicaciones totalmente implementadas.

  • Incluya números de versión en los nombres de archivo ZIP del paquete implementado. Al actualizar la configuración de la WEBSITE_RUN_FROM_PACKAGE aplicación para hacer referencia al paquete de implementación que tiene un nombre de archivo diferente, App Service extrae automáticamente el nuevo paquete y se reinicia.

  • Use ranuras de implementación para implementaciones de código resistentes.

  • Considere la posibilidad de usar agentes administrados y autohospedados.

  • Use IaC para automatizar las implementaciones de infraestructura.

  • Valide el rendimiento y la resistencia de la carga de trabajo continuamente mediante el uso de servicios como Azure Load Testing y Azure Chaos Studio.

Configuración

Las aplicaciones requieren tanto valores de configuración como secretos. Use las instrucciones siguientes para la configuración y la administración de secretos:

  • Nunca almacene secretos como contraseñas o claves de acceso en el control de código fuente. Almacene secretos en Key Vault.

  • Almacenar la configuración de la aplicación en la configuración de App Service. Si necesita compatibilidad con la configuración externa o el indicador de características, use Azure App Configuration.

  • Utilice referencias a Key Vault en la configuración de App Service para exponer secretos de forma segura en su aplicación.

  • Configura los ajustes de la aplicación específicos del slot si los slots de producción y preparación necesitan valores diferentes. De forma predeterminada, la configuración de la aplicación se intercambia con la ranura durante la implementación.

  • Use variables de entorno locales o características específicas de la plataforma para el desarrollo local. La configuración de App Service expone la configuración de la aplicación como variables de entorno. Las herramientas de desarrollo como Visual Studio permiten establecer variables de entorno en perfiles de inicio y proporcionar almacenamiento seguro para la configuración local a través de secretos de usuario.

Supervisión

La supervisión recopila y analiza los datos de los sistemas de tecnología de la información (TI) para proporcionar observabilidad. En esta arquitectura, la supervisión realiza un seguimiento del estado y la seguridad de las aplicaciones web en varias capas, lo que ayuda a mantener operaciones confiables.

Supervise tres capas clave:

  • Código de aplicación: Realice un seguimiento de la telemetría específica de la aplicación y las métricas personalizadas.

  • Infraestructura (tiempo de ejecución): Supervise el entorno de tiempo de ejecución de App Service.

  • Plataforma (recursos de Azure): Recopile métricas y registros de servicios de Azure como Application Gateway, SQL Database y Key Vault.

Para más información, consulte Registro de actividad de Azure, registros de recursos de Azure y registro de aplicaciones de App Service.

Supervisar la plataforma

La supervisión de la plataforma recopila datos de los servicios de Azure en la arquitectura.

Application Gateway

Application Gateway supervisa la salud del grupo de back-end mediante sondeos de salud predeterminados. Use los registros de acceso de Application Gateway para recopilar información como marcas de tiempo, códigos de respuesta HTTP y rutas de acceso url. Para obtener más información, consulte Registros de estado y diagnóstico de back-end.

Servicio de Aplicaciones

App Service proporciona capacidades de monitoreo incorporadas e integradas para mejorar la observabilidad. Si la aplicación web ya tiene características de telemetría y supervisión, como la instrumentación en proceso, esas características siguen funcionando en App Service.

  • Active la instrumentación automática para ampliar la instrumentación sin cambios en el código. Esta característica proporciona visibilidad de la supervisión del rendimiento de la aplicación (APM). Para más información, consulte Supervisión del rendimiento de App Service.

  • Active el seguimiento distribuido para realizar un seguimiento de las solicitudes en varios servicios y dependencias. Puede supervisar los sistemas en la nube distribuidos mediante el seguimiento distribuido y un generador de perfiles de rendimiento.

  • Utilice instrumentación basada en código para telemetría personalizada. Application Insights también admite la instrumentación basada en código para la telemetría de aplicaciones personalizada. Añada el SDK de Application Insights a su código y utilice la API de Application Insights.

  • Active los registros de App Service para los diagnósticos de nivel de plataforma. App Service proporciona cuatro tipos de registro para solucionar problemas: registros de aplicaciones, registros de servidor web, mensajes de error detallados y seguimiento de solicitudes con errores.

  • Utilice registros estructurados. Añada una biblioteca de registro estructurado al código de su aplicación. Actualice el código para usar pares clave-valor y active los registros de aplicación en App Service para almacenarlos en el área de trabajo de Log Analytics.

  • Active la característica de comprobación de estado de App Service para mantener la disponibilidad. Las comprobaciones de estado detectan instancias no saludables, redireccionan el tráfico lejos de ellas y las reemplazan automáticamente. Esta característica requiere dos o más instancias de App Service.

Base de datos

Eficiencia del rendimiento

La eficiencia del rendimiento hace referencia a la capacidad de escalado de la carga de trabajo para satisfacer las demandas de los usuarios de forma eficaz. Para obtener más información, vea Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

Application Gateway

Servicio de Aplicaciones

SQL Database

El escalado de bases de datos implica muchas consideraciones más allá del ámbito de esta arquitectura. Para obtener más información sobre el escalado de SQL Database, consulte los siguientes recursos:

Otros consejos sobre escalabilidad

Pasos siguientes