Perspectiva del Framework de Azure Well-Architected sobre Azure App Service (Aplicaciones Web)
Azure App Service es una plataforma como servicio (PaaS) que proporciona un entorno de hospedaje totalmente administrado para compilar, implementar y escalar aplicaciones web. Como solución PaaS, App Service abstrae la infraestructura subyacente, lo que le permite centrarse en el desarrollo de aplicaciones. App Service (Aplicación web) ejecuta las aplicaciones en el contexto de un plan de App Service, que determina los recursos, el sistema operativo, la región y el modelo de precios (SKU) que se usan para hospedar la aplicación.
Este artículo asume que, como arquitecto, ha revisado el árbol de decisiones de computación y ha elegido App Service como computación para su carga de trabajo. La guía de este artículo proporciona recomendaciones arquitectónicas que se alinean con los principios de los pilares de Azure Well-Architected Framework.
Importante
Cómo usar esta guía
Cada sección contiene una lista de comprobación de diseño que resalta las consideraciones y estrategias arquitectónicas para Azure App Service. Recomendaciones ofrecen instrucciones específicas para implementar esas estrategias.
Las recomendaciones no representan una lista exhaustiva de todas las configuraciones disponibles para la característica Web Apps de Azure App Service y sus dependencias. En su lugar, enumeran las recomendaciones clave asignadas a las perspectivas de diseño. Use las recomendaciones para compilar la prueba de concepto o optimizar los entornos existentes.
Arquitectura de base que demuestra las recomendaciones clave: Arquitectura base de App Service.
alcance de la tecnología
Esta revisión se centra en las decisiones relacionadas entre sí para los siguientes recursos de Azure:
- Planes de App Service
- Aplicaciones web
Otras ofertas de Azure están asociadas a App Service, como Azure Functions, Azure Logic Apps y App Service Environment. Esas ofertas están fuera del ámbito de este artículo. Se hace referencia a App Service Environment ocasionalmente para ayudar a aclarar las características o opciones de las ofertas principales de App Service.
Fiabilidad
El propósito del pilar Fiabilidad es proporcionar una funcionalidad continuada mediante la creación de suficiente resiliencia y la capacidad de recuperarse rápidamente de los fallos.
Los principios de diseño de confiabilidad de proporcionan una estrategia de diseño de alto nivel aplicada a componentes individuales, flujos del sistema y al sistema en su conjunto.
Lista de comprobación de diseño
Comience su estrategia de diseño basándose en la lista de comprobación de revisión de diseño para Fiabilidad. Determine su relevancia para los requisitos empresariales, a la vez que tenga en cuenta los niveles y las características de App Service y sus dependencias. Amplíe la estrategia para incluir más enfoques según sea necesario.
Priorizar flujos de usuario: no todos los flujos son igualmente críticos. Identifique las rutas de acceso críticas de la aplicación y asigne prioridades a cada flujo para guiar las decisiones de diseño. El diseño del flujo de usuario puede influir en qué niveles de servicio y el número de instancias que elija para un plan y una configuración de App Service.
Por ejemplo, su aplicación podría incluir niveles de front-end y back-end que se comunican a través de un corredor de mensajes. Puede optar por segmentar los niveles en varias aplicaciones web para permitir el escalado independiente, la administración del ciclo de vida y el mantenimiento. La colocación de una aplicación grande en un solo plan puede provocar problemas de memoria o CPU y afectar a la confiabilidad.
Es posible que necesite más instancias en el front-end para obtener un rendimiento óptimo en la interfaz de usuario. Sin embargo, es posible que el back-end no requiera el mismo número de instancias.
Prever posibles errores: planee estrategias de mitigación para posibles errores. En la tabla siguiente se muestran ejemplos de análisis del modo de error.
Fracaso Mitigación Error de los componentes subyacentes o abstractos de App Service Tener redundancia de componentes en instancias y dependencias. Supervise el estado de las instancias, el rendimiento de la red y el rendimiento del almacenamiento. Falla de dependencias externas Utilice patrones de diseño como el patrón Retry y el patrón Circuit Breaker. Supervise las dependencias externas y establezca los tiempos de espera adecuados. Fallo debido a que el tráfico se enruta a instancias no sanas Supervise la salud de las instancias. Tenga en cuenta la capacidad de respuesta y evite enviar solicitudes a instancias no saludables. Para obtener más información, consulte Análisis del modo de fallo para aplicaciones Azure.
Construir redundancia: Construya redundancia en la aplicación y la infraestructura de soporte. Distribuir instancias entre zonas de disponibilidad para mejorar la tolerancia a errores. El tráfico se enruta a otras zonas si se produce un error en una zona. Implemente la aplicación en varias regiones para asegurarse de que la aplicación permanece disponible, incluso si toda una región experimenta una interrupción.
Cree niveles similares de redundancia en los servicios dependientes. Por ejemplo, las instancias de aplicación se enlazan a Blob Storage. Considere la posibilidad de configurar la cuenta de almacenamiento asociada con almacenamiento con redundancia de zona (ZRS) si una aplicación usa una implementación con redundancia de zona.
Usar varias instancias: ejecutar la aplicación solo en una instancia es un único punto de error inmediato. Asigne varias instancias a la aplicación para garantizar la alta disponibilidad. Si se produce un error en una instancia, otras instancias todavía pueden controlar las solicitudes entrantes. Tenga en cuenta que el código de la aplicación debe poder controlar varias instancias sin problemas de sincronización al leer o escribir en orígenes de datos.
Tener redundancia en los componentes de red. Por ejemplo, use direcciones IP con redundancia de zona y equilibradores de carga.
Tener una estrategia de escalado confiable: la carga inesperada en una aplicación puede hacer que no sea confiable. Tenga en cuenta el enfoque de escalado adecuado en función de las características de la carga de trabajo. El escalado horizontal (scaling out) permite agregar más instancias para distribuir la carga, mientras que el escalado vertical (scaling up) implica incrementar la capacidad de una instancia existente (CPU, memoria). Tenga cuidado con el exceso de aprovisionamiento, ya que agregar instancias innecesarias aumenta los costos sin ventajas de rendimiento tangibles.
A veces puedes aumentar la capacidad para manejar la carga. Sin embargo, si la carga sigue aumentando, escale a nuevas instancias. Prefiere el escalado automático o automático sobre los enfoques manuales. Mantener siempre un búfer de capacidad adicional durante las operaciones de escalado para evitar la degradación del rendimiento[Elegir la opción de escalado para App Service](Escalado automático en Azure App Service)
El nivel del plan de servicio de aplicaciones que elija afecta al escalado en cuanto al número de instancias y las unidades de cómputo.
Asegúrese de que la inicialización de la aplicación sea adecuada para que las nuevas instancias se calienten rápidamente y puedan recibir solicitudes.
Busque aplicaciones sin estado siempre que sea posible. El escalado confiable del estado con nuevas instancias puede aumentar la complejidad. Considere un almacén de datos externo que puede escalar de forma independiente si necesita almacenar el estado de la aplicación. El almacenamiento del estado de sesión en la memoria puede provocar la pérdida de estado de sesión cuando se produce un problema con la aplicación o App Service. También limita la posibilidad de distribuir la carga entre otras instancias.
Pruebe periódicamente las reglas de escalado automático. Simulación de escenarios de carga para comprobar que la aplicación se escala según lo previsto. Debe registrar eventos de escalado para que pueda solucionar problemas que puedan surgir y optimizar la estrategia de escalado a lo largo del tiempo.
App Service tiene una limitación en el número de instancias de un plan, lo que puede afectar a la confiabilidad del escalado. Una estrategia consiste en utilizar sellos de implementación idénticos, cada uno ejecutando una instancia del plan de App Service con su propio punto de conexión. Es esencial que enfrente todas las estampas con un equilibrador de carga externo para distribuir el tráfico entre ellas. Use Azure Application Gateway para implementaciones de zona única y Azure Front Door para implementaciones de varias regiones. Este enfoque es ideal para aplicaciones críticas en las que la confiabilidad es fundamental. Para obtener más información, consulte Línea base de misión crítica con App Service.
Planear la capacidad de recuperación: la redundancia es fundamental para la continuidad empresarial. Realizar un cambio automático a otra instancia si una instancia es inalcanzable. Explore las funcionalidades de recuperación automática en App Service, como la reparación automática de instancias.
Implemente patrones de diseño para gestionar la degradación controlada de errores transitorios, como problemas de conectividad de red, y eventos a gran escala, como interrupciones regionales. Tenga en cuenta los siguientes patrones de diseño:
El patrón Bulkhead segmenta su aplicación en grupos aislados para evitar que un fallo afecte a todo el sistema.
El patrón de nivelación de carga basado en colas pone en cola elementos de trabajo que sirven de amortiguador para suavizar los picos de tráfico.
el patrón Retry controla los errores transitorios debido a problemas de red, conexiones de base de datos interrumpidas o servicios ocupados.
el patrón Circuit Breaker impide que una aplicación intente realizar repetidamente una operación que probablemente produzca un error.
Puede usar WebJobs para ejecutar tareas en segundo plano en la aplicación web. Para ejecutar esas tareas de forma confiable, asegúrese de que la aplicación que hospeda el trabajo se ejecuta continuamente según una programación o basada en desencadenadores controlados por eventos.
Para obtener más información, consulte patrones de confiabilidad de .
Realizar pruebas de confiabilidad: realice pruebas de carga para evaluar la confiabilidad y el rendimiento de la aplicación bajo carga. Los planes de prueba deben incluir escenarios que validen las operaciones de recuperación automatizadas.
Utilice la inyección de fallos para introducir intencionadamente fallos y validar sus mecanismos de autorreparación y autoconservación. Explore la biblioteca de fallos proporcionada por Azure Chaos Studio.
App Service impone límites de recursos en las aplicaciones hospedadas. El plan de App Service determina estos límites. Asegúrese de que las pruebas confirmen que la aplicación se ejecuta dentro de esos límites de recursos. Para más información, consulte límites, cuotas y restricciones de suscripción y servicio de Azure.
Usar la característica de comprobación de estado para identificar trabajadores que no responden: App Service tiene funcionalidades integradas que hacen ping periódicamente a una ruta específica de su aplicación web. La plataforma hace ping a esta ruta de acceso para determinar si la aplicación es correcta y responde a las solicitudes. Cuando el sitio se escala a varias instancias, App Service excluirá automáticamente las instancias no saludables de atender solicitudes, mejorando así la disponibilidad general. La ruta de comprobación de estado de la aplicación debe sondear los componentes críticos de la aplicación, como la base de datos, la caché o el servicio de mensajería. Esto asegura que el estado devuelto por la ruta de comprobación de salud es una imagen precisa de la salud general de su aplicación. Configure su ruta de comprobación de estado
Usar la característica de recuperación automática: a veces, la aplicación podría experimentar comportamientos inesperados que podrían resolverse mediante un reinicio simple. Las funciones de Auto-Curación le permiten definir una "condición" que desencadenaría la Auto-Curación y la "acción" que la Auto-Curación iniciará cuando se cumpla la condición. Herramientas de diagnóstico del servicio de aplicaciones y función de autocuración
Informe de puntuación de resistencia del servicio de la aplicación: para revisar las recomendaciones de mejores prácticas adaptadas, consulte el informe de puntuación de resistencia.Informe de puntuación de resistencia del servicio de la aplicación
Recomendaciones
Recomendación | Beneficio |
---|---|
(App Service) Elija el nivel Premium v3 de un plan de App Service para cargas de trabajo de producción. Establezca el número máximo y mínimo de trabajadores según el planeamiento de capacidad. Para obtener más información, consulte Descripción general del plan de App Service. |
Un plan de App Service Premium V3 ofrece características de escalado avanzadas y garantiza la redundancia si se producen errores. |
(App Service) Habilitar redundancia de zona. Considere la posibilidad de aprovisionar más de tres instancias para mejorar la tolerancia a errores. Compruebe la compatibilidad regional con la redundancia de zona porque no todas las regiones ofrecen esta característica. |
La aplicación puede resistir errores en una sola zona cuando varias instancias se distribuyen entre zonas. El tráfico cambia automáticamente a instancias saludables en otras zonas y mantiene la confiabilidad de la aplicación en caso de que una zona no esté disponible. |
(Aplicación web) Considere la posibilidad de deshabilitar la característica de afinidad de enrutamiento de solicitudes de aplicación (ARR). La afinidad ARR crea sesiones pegajosas que redirigen a los usuarios al nodo que administró sus solicitudes anteriores. | Las solicitudes entrantes se distribuyen uniformemente entre todos los nodos disponibles al deshabilitar la afinidad de ARR. Las solicitudes distribuidas uniformemente impiden que el tráfico sobrepase cualquier nodo único. Las solicitudes se pueden redirigir sin problemas a otros nodos correctos si un nodo no está disponible. Evite la afinidad de sesiones para garantizar que su instancia de App Service permanezca sin estado. Un servicio de aplicación sin estado reduce la complejidad y asegura un comportamiento coherente entre los nodos. Quite las sesiones permanentes para que App Service pueda agregar o quitar instancias para escalar horizontalmente. |
(Web App) Definir reglas de recuperación automática en función del recuento de solicitudes, solicitudes lentas, límites de memoria y otros indicadores que forman parte de la línea de base de rendimiento. Considere esta configuración como parte de la estrategia de escalado. | Las reglas de recuperación automática ayudan a la aplicación a recuperarse automáticamente de problemas inesperados. Las reglas configuradas desencadenan acciones de recuperación cuando se infringen los umbrales. La recuperación automática permite el mantenimiento proactivo automático. |
(Aplicación web) Habilitar la característica de comprobación de estado y proporcionar una ruta de acceso que responda a las solicitudes de comprobación de estado. | Las comprobaciones de estado pueden detectar problemas temprano. A continuación, el sistema puede realizar automáticamente acciones correctivas cuando se produce un error en una solicitud de comprobación de estado. El equilibrador de carga enruta el tráfico lejos de las instancias no saludables, lo que dirige a los usuarios a nodos saludables. |
Seguridad
El propósito del pilar de seguridad es proporcionar garantías de confidencialidad, integridad y disponibilidad a la carga de trabajo.
Los principios de diseño de Security proporcionan una estrategia de diseño de alto nivel para lograr esos objetivos aplicando enfoques al diseño técnico en torno al hospedaje en App Service.
Lista de comprobación de diseño
Comience su estrategia de diseño basándose en la lista de comprobación de revisión de diseño para Seguridad e identifique vulnerabilidades y controles para mejorar la postura de seguridad. Amplíe la estrategia para incluir más enfoques según sea necesario.
Revise las líneas base de seguridad: para mejorar la posición de seguridad de la aplicación hospedada en un plan de App Service, revise la línea base de seguridad de para App Service.
Use el entorno de ejecución y las bibliotecas más recientes: pruebe exhaustivamente las compilaciones de la aplicación antes de realizar actualizaciones para detectar problemas al principio y asegurar una transición sin problemas a la nueva versión. App Service admite la política de soporte de tiempo de ejecución de idioma para actualizar las pilas existentes y retirar las pilas que han dejado de ser compatibles.
Crear segmentación a través de límites de aislamiento para contener la brecha: Aplica la segmentación de identidad. Por ejemplo, implemente el control de acceso basado en rol (RBAC) para asignar permisos específicos basados en roles. Siga el principio de privilegios mínimos para limitar los derechos de acceso solo a lo necesario. Cree también la segmentación en el nivel de red. Insertar aplicaciones de App Service en una red virtual de Azure para el aislamiento y definir grupos de seguridad de red (NSG) para filtrar el tráfico.
Los planes de App Service ofrecen el nivel de App Service Environment que proporciona un alto grado de aislamiento. Con el entorno de servicio de aplicaciones, obtienes cómputo y redes dedicados.
Aplicar controles de acceso a identidades: restrinja tanto el acceso entrante a la aplicación web como el acceso externo desde la aplicación web a otros recursos. Esta configuración aplica controles de acceso a las identidades y ayuda a mantener la posición de seguridad general de la carga de trabajo.
Use Microsoft Entra ID para todas las necesidades de autenticación y autorización. Utilice funciones integradas, como Contribuidor del plan web, Contribuidor del sitio web y Contribuidor genérico, Lector y Propietario.
Aplicar controles de seguridad de red: integre App Service con una red virtual (VNet) para controlar el tráfico saliente. Use puntos de conexión privados para controlar el tráfico entrante y limitar el acceso a App Service desde la red virtual y deshabilitar el acceso a Internet público. Proteger la red, controlar el tráfico entrante y saliente
Implemente un firewall de aplicaciones web (WAF) para protegerse frente a vulnerabilidades comunes. Application Gateway y Azure Front Door tienen funcionalidades de WAF integradas.
Configure las reglas de proxy inverso y las opciones de red adecuadamente para lograr el nivel deseado de seguridad y control. Por ejemplo, agregue reglas de NSG en la subred del punto de conexión privado para aceptar solo el tráfico del proxy inverso.
El tráfico de salida de la aplicación a otros servicios paaS debe estar a través de puntos de conexión privados. Considere la posibilidad de colocar un componente de firewall para restringir el tráfico de salida a la red pública de Internet. Ambos enfoques impiden la filtración de datos.
Para obtener una visión completa, consulte Características de red del servicio de aplicaciones.
Cifrar datos: proteja los datos en tránsito con seguridad de la capa de transporte (TLS) de un extremo a otro. Use las claves administradas por el cliente para el cifrado completo de datos en reposo. Para obtener más información, consulte Encriptación en reposo mediante claves administradas por el cliente.
No use protocolos heredados como TLS 1.0 y 1.1. Asegúrese de que todas las aplicaciones web solo usan HTTPS y aplican TLS 1.2 o posterior. La versión mínima predeterminada de TLS es la 1.2. Para obtener más información, consulte Descripción general de TLS del servicio de aplicaciones.
Todas las instancias de App Service tienen un nombre de dominio predeterminado. Use un dominio personalizado y proteja ese dominio con certificados.
Cifrado TLS de un extremo a otro: El cifrado TLS de un extremo a otro está disponible en los planes de App Service Premium. Esta característica cifra el tráfico a lo largo de toda la transacción, lo que minimiza el riesgo de interceptación del tráfico.
Reducir la superficie expuesta a ataques: quite las configuraciones predeterminadas que no necesite. Por ejemplo, deshabilite la depuración remota, la autenticación local para sitios del Administrador de control de código fuente (SCM) y la autenticación básica. Deshabilite protocolos no seguros como HTTP y Protocolo de transferencia de archivos (FTP). Aplicar configuraciones mediante directivas de Azure. Para obtener más información, consulte Políticas Azure.
Implementar directivas restrictivas de compartición de recursos entre orígenes (CORS): use directivas CORS restrictivas en la aplicación web para aceptar solo solicitudes que cumplan con los dominios, encabezados y otros criterios permitidos. Aplique directivas de CORS con definiciones de directivas de Azure integradas.
Uso de identidades administradas: habilite las identidades administradas para que App Service acceda de forma segura a otros servicios de Azure sin necesidad de administrar las credenciales. Obtenga información sobre las identidades administradas.
Proteger secretos de aplicación: debe controlar información confidencial, como claves de API o tokens de autenticación. En lugar de codificar estos secretos directamente en el código de aplicación o los archivos de configuración, puede usar referencias de Azure Key Vault en la configuración de la aplicación. Cuando se inicia la aplicación, App Service recupera automáticamente los valores secretos de Key Vault mediante la identidad administrada de la aplicación.
Habilitar registros de recursos para la aplicación: habilite los registros de recursos de la aplicación para crear pistas de actividad completas que proporcionen datos valiosos durante las investigaciones que siguen los incidentes de seguridad. Consulte la guía de supervisión de registros para obtener instrucciones detalladas.
Considere la posibilidad de registrar como parte del proceso de modelado de amenazas al evaluar las amenazas.
Recomendaciones
Recomendación | Beneficio |
---|---|
(Aplicación web) Asignar identidades administradas a la aplicación web. Para mantener los límites de aislamiento, no comparta ni reutilice identidades entre aplicaciones. Asegúrese de conectarse de forma segura a su registro de contenedores si utiliza contenedores para su implementación. |
La aplicación recupera secretos de Key Vault para autenticar la comunicación externa desde la aplicación. Azure administra la identidad y no requiere que aprovisione ni cambie ningún secreto. Dispone de identidades distintas para la granularidad del control. Las identidades distintas facilitan la revocación si una identidad está en peligro. |
(Web App) Configure dominios personalizados para las aplicaciones. Deshabilite HTTP y acepte solo solicitudes HTTPS. |
Los dominios personalizados permiten la comunicación segura a través de HTTPS mediante el protocolo seguridad de la capa de transporte (TLS), lo que garantiza la protección de datos confidenciales y crea confianza del usuario. |
(Web App) valore si la Autenticación integrada de App Service es el mecanismo adecuado para autenticar a los usuarios que acceden a su aplicación. La autenticación integrada de App Service se integra con microsoft Entra ID. Esta característica controla la validación de tokens y la administración de identidades de usuario en varios proveedores de inicio de sesión y admite OpenID Connect. Con esta característica, no tiene autorización en un nivel granular y no tiene un mecanismo para probar la autenticación. | Al usar esta característica, no es necesario usar bibliotecas de autenticación en el código de aplicación, lo que reduce la complejidad. El usuario ya está autenticado cuando una solicitud llega a la aplicación. |
(Aplicación web) Configure la aplicación para la integración de la red virtual . Utilice puntos de conexión privados para las aplicaciones de App Service. Bloquear todo el tráfico público. Enrute la extracción de la imagen del contenedor a través de la red virtual de integración. Todo el tráfico saliente de la aplicación pasa a través de la red virtual. |
Obtenga las ventajas de seguridad de usar una red virtual de Azure. Por ejemplo, la aplicación puede acceder de forma segura a los recursos dentro de la red. Agregue un punto de conexión privado para ayudar a proteger la aplicación. Los puntos de conexión privados limitan la exposición directa a la red pública y permiten el acceso controlado a través del proxy inverso. |
(Web App) Para implementar el endurecimiento: - Deshabilitar la autenticación básica que usa un nombre de usuario y una contraseña en favor de la autenticación basada en id. de Microsoft Entra. - Desactive la depuración remota para que no se abran los puertos de entrada. - Habilite Políticas CORS para endurecer las peticiones entrantes. - Deshabilitar protocolos, como FTP. |
No se recomienda la autenticación básica como método de implementación segura. Microsoft Entra ID emplea la autenticación basada en tokens de OAuth 2.0, que ofrece numerosas ventajas y mejoras que abordan las limitaciones asociadas a la autenticación básica. Las directivas restringen el acceso a los recursos de la aplicación, solo permiten solicitudes de dominios específicos y protegen las solicitudes entre regiones. |
(Web App) Utilice siempre referencias de Key Vault como configuración de la aplicación. |
Los secretos se mantienen separados de la configuración de la aplicación. La configuración de la aplicación se cifra en reposo. App Service también administra la rotación de secretos. |
(App Service) Habilitar Microsoft Defender for Cloud en App Service. | Obtenga protección en tiempo real para los recursos que se ejecutan en un plan de App Service. Proteja contra amenazas y mejore su posición general de seguridad. |
(App Service) Habilitar el registro de diagnóstico y añadir instrumentación a su aplicación. Los registros se envían a cuentas de Azure Storage, Azure Event Hubs y Log Analytics. Para obtener más información sobre los tipos de registro de auditoría, consulte tipos de registro compatibles. | El registro captura los patrones de acceso. Registra eventos relevantes que proporcionan información valiosa sobre cómo interactúan los usuarios con una aplicación o plataforma. Esta información es fundamental para fines de responsabilidad, cumplimiento y seguridad. |
Optimización de costos
La optimización de costes se centra en detectar patrones de gasto, priorizar inversiones en áreas críticas y optimizar en otras para ajustarse al presupuesto de la organización al tiempo que se cumplen los requisitos empresariales.
Principios de diseño para la optimización de costos proporcionan una estrategia de diseño de alto nivel para lograr esos objetivos y hacer concesiones cuando sea necesario en el diseño técnico relacionado con tus aplicaciones web y el entorno en el que se ejecutan.
Lista de comprobación de diseño
Inicie su estrategia de diseño basándose en la lista de comprobación de revisión del diseño para la optimización de costes para inversiones y ajuste el diseño para que la carga de trabajo esté alineada con el presupuesto asignado para la carga de trabajo. El diseño debe usar las funcionalidades adecuadas de Azure, supervisar las inversiones y encontrar oportunidades para optimizar con el tiempo.
Calcular el costo inicial: como parte del ejercicio de modelado de costos, use la calculadora de precios de Azure para evaluar los costos aproximados asociados a varios niveles en función del número de instancias que planea ejecutar. Cada nivel de App Service ofrece diferentes opciones de proceso.
Supervise continuamente el modelo de costos para realizar un seguimiento de los gastos.
Evaluar las opciones con descuento: los niveles superiores incluyen instancias de cómputo dedicadas. Puede aplicar un descuento por reserva si la carga de trabajo tiene un patrón de uso predecible y coherente. Asegúrese de analizar los datos de uso para determinar el tipo de reserva que se adapte a la carga de trabajo. Para obtener más información, consulte Ahorre costes con instancias reservadas de App Service.
Descripción de los medidores de uso: Azure cobra una tarifa por hora, prorrateada al segundo, en función del nivel de precios del plan de App Service. Los cargos se aplican a cada instancia escalada de su plan, en función del tiempo que asigne a la instancia VM. Preste atención a los recursos informáticos infrautilizados que podrían aumentar sus costes como resultado de la sobreasignación debida a una selección de SKU subóptima o a una configuración de escalado mal configurada.
Las características adicionales de App Service, como el registro de dominio personalizado y los certificados personalizados, pueden agregar costos. Otros recursos, como redes virtuales para aislar su solución o bóvedas de claves para proteger los secretos de la carga de trabajo, que se integran con sus recursos de App Service también pueden añadir costes. Para obtener más información, consulte el modelo de facturación de App Services .
Considere los compromisos entre la densidad y el aislamiento: puede usar planes de App Service para hospedar varias aplicaciones en los mismos recursos de computación, ahorrando costos con entornos compartidos. Para obtener más información, consulte Desventajas.
Evaluar el efecto de su estrategia de escalado en el coste: Debe diseñar, probar y configurar correctamente para el escalado de salida y para el escalado de entrada cuando implemente el autoescalado. Establezca límites máximos y mínimos precisos en el escalado automático.
Inicialice proactivamente la aplicación para el escalado confiable. Por ejemplo, no espere hasta que la CPU alcance el 95% de uso. En su lugar, active el escalado en torno al 65% para dar tiempo suficiente a que se asignen e inicialicen nuevas instancias durante el proceso de escalado. Sin embargo, esta estrategia podría dar lugar a una capacidad sin usar.
Se recomienda combinar y equilibrar los mecanismos para escalar verticalmente y escalar horizontalmente. Por ejemplo, una aplicación puede escalar verticalmente durante algún tiempo y, a continuación, escalar horizontalmente según sea necesario. Explore los niveles altos que ofrecen una gran capacidad y un uso eficaz de los recursos. En función de los patrones de uso, los niveles Premium más altos suelen ser más rentables porque son más capaces.
Optimizar los costos del entorno: considere el nivel Básico o Gratis para ejecutar entornos de preproducción. Estos niveles son de bajo rendimiento y bajo costo. Si usa el nivel Básico o Gratis, use la gobernanza para aplicar el nivel, restringir el número de instancias y CPU, restringir el escalado y limitar la retención de registros.
Implementar patrones de diseño: esta estrategia reduce el volumen de solicitudes que genera la carga de trabajo. Considere la posibilidad de usar patrones como el patrón Backends for Frontends y el patrón de agregación de puerta de enlace, que puede minimizar el número de solicitudes y reducir los costos.
comprobar periódicamente los costos relacionados con los datos: los períodos de retención de datos extendidos o los niveles de almacenamiento costosos pueden dar lugar a altos costos de almacenamiento. Se pueden acumular más gastos debido al uso de ancho de banda y a la retención prolongada de los datos de registro.
Considere la posibilidad de implementar el almacenamiento en caché para minimizar los costos de transferencia de datos. Comience con el almacenamiento en caché local en memoria y, a continuación, explore las opciones de almacenamiento en caché distribuido para reducir el número de solicitudes a la base de datos back-end. Tenga en cuenta los costos de tráfico de ancho de banda asociados a la comunicación entre regiones si la base de datos se encuentra en otra región.
Optimizar los costos de implementación: aproveche las ranuras de implementación para optimizar los costos. La ranura se ejecuta en el mismo entorno informático que la instancia de producción. Utilícelos estratégicamente para escenarios como implementaciones azul-verde que cambian entre ranuras. Este enfoque minimiza el tiempo de inactividad y garantiza transiciones suaves.
Utilice las ranuras de despliegue con precaución. Puede presentar problemas, como excepciones o pérdidas de memoria, que podrían afectar tanto a las instancias existentes como a las nuevas. Asegúrese de probar exhaustivamente los cambios. Para obtener instrucciones operativas, consulte Operational Excellence.
Recomendaciones
Recomendación | Beneficio |
---|---|
(App Service) Elige niveles gratuitos o básicos para entornos de menor complejidad. Se recomiendan estos niveles para su uso experimental. Quite los niveles cuando ya no los necesite. | Los niveles Gratis y Básico son asequibles en comparación con los niveles superiores. Proporcionan una solución rentable para entornos que no son de producción que no necesitan las características completas y el rendimiento de los planes Premium. |
(App Service) Aproveche los descuentos y explore los precios preferidos para: - Entornos inferiores con planes de desarrollo/prueba. - Reservas de Azure y Planes de ahorro de Azure para los recursos informáticos dedicados que aprovisiona en el nivel Premium V3 y el App Service Environment. Use instancias reservadas para cargas de trabajo estables que tengan patrones de uso predecibles. |
Los planes de desarrollo y pruebas proporcionan tarifas reducidas para los servicios de Azure, lo que les hace rentable para entornos que no son de producción. Utilice instancias reservadas para pagar por adelantado los recursos informáticos y obtener descuentos significativos. |
(Web App) Supervise los costes en los que incurren los recursos de App Service. Ejecute la herramienta de análisis de costos en Azure Portal. Crear presupuestos y alertas para notificar a las partes interesadas. |
Puede identificar los picos de costos, las ineficacias o los gastos inesperados al principio. Este enfoque proactivo le ayuda a proporcionar controles presupuestarios para evitar excesos de gastos. |
(App Service) Reduzca la escala cuando disminuya la demanda. Para escalar hacia adentro, defina reglas de escala para reducir el número de instancias en Azure Monitor. | Evite el desperdicio y reduzca los gastos innecesarios. |
Excelencia operativa
La excelencia operativa se centra principalmente en procedimientos para prácticas de desarrollo, observabilidad y administración de versiones.
Los principios de diseño de Excelencia Operativa proporcionan una estrategia de diseño de alto nivel para lograr esos objetivos hacia los requisitos operativos de la carga de trabajo.
Lista de comprobación de diseño
Inicie la estrategia de diseño utilizando la lista de comprobación de revisión de diseño para Excelencia Operativa, con el fin de definir procesos de observabilidad, prueba e implementación relacionados con aplicaciones web.
Administración de versiones: Utilice ranuras de despliegue para administrar las versiones de forma eficaz. Puede implementar la aplicación en una ranura, realizar pruebas y validar su funcionalidad. Después de la comprobación, puede mover sin problemas la aplicación a producción. Este proceso no incurre en costos adicionales porque el slot se ejecuta en el mismo entorno de máquina virtual (VM) que la instancia de producción.
Utilice Swap with Preview (intercambio multifase). Swap with Preview le permite probar la aplicación en sus ranuras de puesta en escena contra su configuración de producción y también preparar la aplicación. Después de hacer sus pruebas y preparar todas las rutas necesarias, puede completar el swap y la app empezará a recibir tráfico de producción sin reiniciarse.
Ejecutar pruebas automatizadas: antes de promover una versión de la aplicación web, pruebe exhaustivamente su rendimiento, funcionalidad e integración con otros componentes. Use Azure Load Testing, que se integra con Apache JMeter, una herramienta popular para pruebas de rendimiento. Explore herramientas automatizadas para otros tipos de pruebas, como Phantom para pruebas funcionales.
Automatizar las implementaciones: Utiliza pipelines CI/CD con Azure DevOps o GitHub Actions para automatizar las implementaciones y reducir el esfuerzo manual Implementación continua en Azure App Service.
Implementación de unidades inmutables: implemente el Patrón de marcas de implementación para compartimentar App Service en una marca inmutable. App Service admite el uso de contenedores, que son intrínsecamente inmutables. Considere contenedores personalizados para su aplicación web App Service.
Cada sello representa una unidad independiente que se puede ampliar o reducir rápidamente. Las unidades basadas en este sello son temporales y apátridas. El diseño sin estado simplifica las operaciones y el mantenimiento. Este enfoque es ideal para aplicaciones críticas. Para ver un ejemplo, consulte Línea base de misión crítica con App Service.
Utilice una tecnología de infraestructura como código (IaC), como Bicep, para estampar unidades con repetibilidad y coherencia.
Mantener seguros los entornos de producción: cree planes de App Service independientes para ejecutar entornos de producción y preproducción. No realice cambios directamente en el entorno de producción para garantizar la estabilidad y confiabilidad. Las instancias independientes permiten flexibilidad en el desarrollo y las pruebas antes de promover cambios en producción.
Use entornos bajos para explorar nuevas características y configuraciones de forma aislada. Mantenga los entornos de desarrollo y prueba efímeros.
Administrar certificados: para dominios personalizados, debe administrar certificados TLS.
Tener procesos implementados para adquirir, renovar y validar certificados. Descargue estos procesos en App Service si es posible. Si usa su propio certificado, debe administrar su renovación. Elija un enfoque que se adapte mejor a sus requisitos de seguridad.
Recomendación | Beneficio |
---|---|
(Web App) Supervisa la salud de sus instancias y active sondas de salud de instancias. Configure una ruta de acceso específica para gestionar las solicitudes de sondeo de salud. |
Puede detectar problemas rápidamente y tomar medidas necesarias para mantener la disponibilidad y el rendimiento. |
(Aplicación web) Habilitar registros de diagnóstico para la aplicación y la instancia. El registro frecuente puede ralentizar el rendimiento del sistema, agregar a los costos de almacenamiento e introducir riesgos si tiene acceso no seguro a los registros. Siga estos procedimientos recomendados: - Registre el nivel adecuado de información. - Establecer directivas de retención. - Mantener una pista de auditoría del acceso autorizado y los intentos no autorizados. - Tratar los registros como datos y aplicar controles de protección de datos. |
Los registros de diagnóstico proporcionan información valiosa sobre el comportamiento de la aplicación. Supervise los patrones de tráfico e identifique anomalías. |
(Web App) Aproveche Certificados administrados por App Service para descargar la administración de certificación a Azure. | App Service controla automáticamente procesos como la adquisición de certificados, la comprobación de certificados, la renovación de certificados y la importación de certificados desde Key Vault. Como alternativa, cargue el certificado en Key Vault y autorice al proveedor de recursos de App Service para acceder a él. |
(App Service) Valide los cambios de la app en la ranura de ensayo antes de intercambiarlo con la ranura de producción. | Evite el tiempo de inactividad y los errores. Revierta rápidamente al último estado correcto conocido si detecta un problema después de un intercambio. |
Eficiencia del rendimiento
La eficiencia del rendimiento consiste en mantener la experiencia del usuario incluso cuando hay un aumento de la carga mediante la administración de la capacidad. La estrategia incluye el escalado de recursos, la identificación y la optimización de posibles cuellos de botella y la optimización del rendimiento máximo.
Los principios de diseño eficiencia del rendimiento proporcionan una estrategia de diseño de alto nivel para lograr esos objetivos de capacidad con respecto al uso esperado.
Lista de comprobación de diseño
Inicie su estrategia de diseño basándose en la lista de comprobación de revisión de diseño para Performance Efficiency para definir una línea de base basada en indicadores clave de rendimiento para Web Apps.
Identificar y supervisar indicadores de rendimiento: establezca destinos para los indicadores clave de la aplicación, como el volumen de solicitudes entrantes, el tiempo que tarda la aplicación en responder a las solicitudes, las solicitudes pendientes y los errores en las respuestas HTTP. Considere los indicadores clave como parte de la línea base de rendimiento de la carga de trabajo.
Capture las métricas de App Service que forman la base de los indicadores de rendimiento. Recopile registros para obtener información sobre el uso y las actividades de los recursos. Use herramientas de supervisión del rendimiento de aplicaciones (APM), como Application Insights, para recopilar y analizar datos de rendimiento de la aplicación. Para más información, consulte Supervisión de referencia de datos de App Service.
Incluya instrumentación de nivel de código, seguimiento de transacciones y generación de perfiles de rendimiento.
Evaluar la capacidad: simula varios escenarios de usuario para determinar la capacidad óptima que necesita para controlar el tráfico esperado. Use Load Testing para comprender cómo se comporta la aplicación en distintos niveles de carga.
Seleccione el nivel correcto: Utilice computación dedicada para entornos de producción. Los niveles Premium V3 ofrecen SKU más grandes con mayor capacidad de memoria y CPU, más instancias y más características, como la redundancia de zona. Para obtener más información, consulte Nivel de precios Premium V3.
Optimizar la estrategia de escalado: cuando sea posible, use escalado automático en lugar de ajustar manualmente el número de instancias a medida que cambia la carga de la aplicación. Con el escalado automático, App Service ajusta la capacidad del servidor en función de las reglas o desencadenadores predefinidos. Asegúrese de realizar pruebas de rendimiento adecuadas y de establecer las reglas adecuadas para los desencadenadores adecuados.
Si prioriza la simplicidad durante la configuración inicial, use una opción de escalado automático que no requiera definir reglas y solo tiene que establecer límites.
Disponer de recursos suficientes disponibles para garantizar un rendimiento óptimo. Asigne recursos adecuadamente para mantener los objetivos de rendimiento, como el tiempo de respuesta o el rendimiento. Considere la sobreasignación de recursos cuando sea necesario.
Al definir reglas de escalado automático, tenga en cuenta el tiempo que tarda la aplicación en inicializarse. Tenga en cuenta esta sobrecarga al tomar todas las decisiones de escalado.
Usar el almacenamiento en caché: recuperar información de un recurso que no cambia con frecuencia y es costoso acceder afecta al rendimiento. Las consultas complejas, incluidas las combinaciones y varias búsquedas, contribuyen al tiempo de ejecución. Realice el almacenamiento en caché para minimizar el tiempo de procesamiento y la latencia. Almacenar en caché los resultados de la consulta para evitar recorridos de ida y vuelta repetidos a la base de datos o back-end y reducir el tiempo de procesamiento de las solicitudes posteriores.
Para obtener más información sobre el uso de la caché local y distribuida en la carga de trabajo, consulte almacenamiento en caché.
Revisa los antipatrones de rendimiento: Evita los antipatrones típicos para asegurarte de que la aplicación web funcione y escale según tus requisitos empresariales. Estos son algunos antipatrones que App Service corrige.
Antipatrón Descripción Front-end ocupado Las tareas que consumen muchos recursos pueden aumentar los tiempos de respuesta de las solicitudes de usuario y provocar una latencia alta.
Mover procesos que consumen recursos significativos a un back-end independiente. Utilice un corredor de mensajes para poner en cola tareas que consumen muchos recursos y que el back-end recoge para procesar de forma asíncrona.Sin almacenamiento en caché Atender solicitudes desde una caché intermedia delante de la base de datos back-end para reducir la latencia. vecino ruidoso Los sistemas multiinquilino comparten recursos entre inquilinos. La actividad de un inquilino puede tener un efecto negativo en el uso del sistema de otro inquilino. App Service Environment proporciona un entorno totalmente aislado y dedicado para ejecutar aplicaciones de App Service.
Recomendaciones
Recomendación | Beneficio |
---|---|
(App Service) Active la opción Siempre activado cuando las aplicaciones compartan un único plan de App Service. Las aplicaciones de App Service se descargan automáticamente cuando están inactivas para ahorrar recursos. La siguiente solicitud desencadena un arranque en frío, lo que puede causar tiempos de espera de solicitud. | La aplicación nunca se descarga con AlwaysOn habilitado. |
(Web Apps) Considere la posibilidad de usar HTTP/2 para que las aplicaciones mejoren la eficacia del protocolo. | Elija HTTP/2 en lugar de HTTP/1.1 porque HTTP/2 multiplexa totalmente, reutiliza las conexiones para reducir la sobrecarga y comprime los encabezados para minimizar la transferencia de datos. |
Compromisos
Es posible que tenga que hacer concesiones en el diseño si utiliza los enfoques de las listas de comprobación de pilares. Estos son algunos ejemplos de ventajas e inconvenientes.
densidad y aislamiento
Mayor densidad: Coloque varias aplicaciones dentro del mismo plan de App Service para minimizar los recursos. Todas las aplicaciones comparten recursos como CPU y memoria, lo que puede ahorrar dinero y reducir la complejidad operativa. Este enfoque también optimiza el uso de recursos. Las aplicaciones pueden usar recursos inactivos de otra aplicación si los patrones de carga cambian con el tiempo.
Tenga en cuenta también las desventajas, como la contención de recursos. Por ejemplo, los picos de uso o inestabilidad de una aplicación pueden afectar al rendimiento de otras aplicaciones. Los incidentes de una aplicación también pueden permear a otras aplicaciones dentro del entorno compartido, lo que puede afectar a la seguridad. Para las aplicaciones críticas que requieren alta disponibilidad y rendimiento, entornos aislados como App Service Environment V3 (ASE) proporcionar recursos dedicados, pero a un costo mayor. Considere la posibilidad de usar entornos compartidos para cargas de trabajo no críticas y entornos aislados para aplicaciones críticas.
de aislamiento superior: el aislamiento ayuda a evitar interferencias. Esta estrategia se aplica a la seguridad, el rendimiento e incluso la segregación de entornos de desarrollo, pruebas y producción.
App Service Environment proporciona un mejor control sobre la seguridad y la protección de datos, ya que cada aplicación puede tener su propia configuración de seguridad. Tu entorno puede contener brechas porque el aislamiento limita el alcance de la explosión. La contención de recursos se minimiza desde una perspectiva de rendimiento. El aislamiento permite el escalado independiente en función de la demanda específica y el planeamiento de la capacidad individual.
Como desventaja, este enfoque es más caro y requiere rigor operativo.
estrategia de escalado confiable
Una estrategia de escalado bien definida garantiza que la aplicación pueda controlar varias cargas sin poner en peligro el rendimiento. Sin embargo, hay que tener en cuenta los costes. Las operaciones de escalado tardan tiempo. Cuando se asignan nuevos recursos, la aplicación debe inicializarse correctamente para poder procesar las solicitudes de forma eficaz. Puede sobreaprovisionar recursos (preparar instancias) para proporcionar una red de seguridad. Sin esa capacidad adicional, durante la fase de inicialización, puede haber un retraso en atender las solicitudes, lo que afecta a la experiencia del usuario. Las operaciones de escalado automático pueden desencadenarse lo suficientemente pronto como para habilitar la inicialización de recursos adecuada por el momento en que los clientes usan los recursos.
Como desventaja, los recursos sobreaprovisionados cuestan más. Se le cobrará por segundo por cada instancia, incluidas las instancias activadas previamente. Los niveles superiores incluyen instancias preparadas. Determine si las funcionalidades con niveles más caros merecen la pena la inversión.
redundancia en la construcción
La redundancia ofrece resistencia, pero también conlleva costos. Los objetivos de nivel de servicio (SLO) para la carga de trabajo determinan los umbrales de rendimiento aceptables. Se convierte en un despilfarro si la redundancia supera los requisitos de SLO. Evalúe si el exceso de redundancia mejora los SLO o agrega complejidad innecesaria.
Tenga en cuenta también las desventajas. Por ejemplo, la redundancia de varias regiones proporciona alta disponibilidad, pero agrega complejidad y costo debido a la sincronización de datos, los mecanismos de conmutación por error y la comunicación entre regiones. Determine si la redundancia de zona puede cumplir sus SLO.
Directivas de Azure
Azure proporciona un amplio conjunto de directivas integradas relacionadas con App Service y sus dependencias. Un conjunto de directivas de Azure puede auditar algunas de las recomendaciones anteriores. Por ejemplo, puede comprobar si:
Los controles de red adecuados están en vigor. Por ejemplo, puede incorporar la segmentación de red colocando App Service en Azure Virtual Network a través de la inyección de red virtual para tener un mayor control sobre la configuración de red. La aplicación no tiene puntos de conexión públicos y se conecta a los servicios de Azure a través de puntos de conexión privados.
Los controles de identidad están en vigor. Por ejemplo, la aplicación usa identidades administradas para autenticarse en otros recursos. La autenticación integrada de App Service (Easy Auth) comprueba las solicitudes entrantes.
Las características como la depuración remota y la autenticación básica están deshabilitadas para reducir la superficie expuesta a ataques.
Para una gobernanza completa, revise las Definiciones integradas en Azure Policy y otras políticas que puedan afectar a la seguridad de la capa informática.
Recomendaciones de Azure Advisor
azure Advisor es un consultor en la nube personalizado que le ayuda a seguir los procedimientos recomendados para optimizar las implementaciones de Azure. Estas son algunas recomendaciones que pueden ayudarle a mejorar la confiabilidad, la seguridad, la rentabilidad, el rendimiento y la excelencia operativa de las instancias de aplicación web.
Pasos siguientes
Tenga en cuenta los siguientes artículos como recursos que muestran las recomendaciones resaltadas en este artículo.
Use estas arquitecturas de referencia como ejemplos de cómo aplicar estas recomendaciones a una carga de trabajo.
Si nunca ha implementado una aplicación web, consulte aplicación web básica.
Para obtener una arquitectura básica como punto de partida para una implementación de nivel de producción, consulte Aplicación web redundante por zonas de alta disponibilidad básica.
Use la siguiente documentación del producto para crear sus conocimientos de implementación: