Perspectiva del marco de trabajo bien diseñado de Azure en App de Azure Service (Web Apps)

Priorizar los flujos de usuario: no todos los flujos son igualmente críticos. 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, la aplicación podría incluir niveles front-end y back-end que se comunican a través de un agente 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.

Para más información, consulte Análisis del modo de error para aplicaciones de Azure.

Redundancia de compilación: cree redundancia en la aplicación y admita la infraestructura. 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.

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. A veces puede escalar verticalmente para controlar la carga. Sin embargo, si la carga sigue aumentando, escale horizontalmente a nuevas instancias. Prefiere el escalado automático a través de enfoques manuales. Mantenga siempre un búfer de capacidad adicional durante las operaciones de escalado para evitar la degradación del rendimiento.

El nivel de plan de App Service que elija afecta al escalado en términos del número de instancias y las unidades de proceso.

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 estado de escalado confiable 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. Almacenar el estado de sesión en memoria puede provocar la pérdida del estado de sesión cuando hay un problema con la aplicación o con 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 usar sellos de implementación idénticos, cada instancia de plan de App Service en ejecución con su propio punto de conexión. Es esencial que se fronten todos los stamps con un equilibrador de carga externo para distribuir el tráfico entre ellos. Use App de Azure lication 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 más información, consulte Línea base crítica con App Service.

Un plan de App Service distribuye el tráfico entre instancias y supervisa su estado. Tenga en cuenta que es posible que el equilibrador de carga externo no detecte inmediatamente si se produce un error en una instancia.

Planear la capacidad de recuperación: la redundancia es fundamental para la continuidad empresarial. Conmutar por error a otra instancia si una instancia no es accesible. 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 controlar la degradación correcta de ambos 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 la aplicación en grupos aislados para evitar que un error afecte a todo el sistema.

• El patrón de nivelación de carga basado en cola pone en cola elementos de trabajo que sirven como búfer para suavizar los picos de tráfico.

• El patrón Retry controla errores transitorios debido a problemas de red, conexione de base de datos descartados 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.

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.

Use la inyección de errores para introducir errores intencionadamente y validar los mecanismos de recuperación automática y autoconservación. Explore la biblioteca de errores 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 servicios de Microsoft Azure.

Use sondeos de estado para identificar trabajos que no responden: App Service tiene funcionalidades integradas que hacen ping periódicamente a una ruta de acceso específica de la aplicación web. Las instancias que no responden se quitan del equilibrador de carga y se reemplazan por una nueva instancia.

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 de base de seguridad de 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 garantizar una transición sin problemas a la nueva versión. App Service admite la directiva de compatibilidad de Language Runtime para actualizar las pilas existentes y retirar pilas de fin de soporte técnico.

Crear segmentación a través de límites de aislamiento para contener infracciones: aplique la segmentación de identidades. 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. Inserte aplicaciones de App Service en una red virtual de Azure para el aislamiento y defina 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 App Service Environment, obtendrá procesos y redes dedicados.

Aplicar controles de acceso a identidades: restrinja el acceso entrante a la aplicación web y 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. Use roles integrados, como un colaborador del plan web, colaborador del sitio web y un colaborador genérico, lector y propietario.

Controlar el tráfico de red hacia y desde la aplicación: no exponga los puntos de conexión de aplicación a la red pública de Internet. En su lugar, agregue un punto de conexión privado en la aplicación web que se coloca en una subred dedicada. Front your application with a reverse proxy that communicates with that private endpoint. Considere la posibilidad de usar Application Gateway o Azure Front Door para ese propósito.

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 vista completa, consulte Características de red de App Service.

Cifrado de 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 más información, consulte Cifrado en reposo mediante claves administradas por el cliente.

No use protocolos heredados como TLS 1.0 y 1.1. App Service habilita la versión 1.2 de forma predeterminada. Para más información, consulte Introducción a TLS de App Service.

Todas las instancias de App Service tienen un nombre de dominio predeterminado. Use un dominio personalizado y proteja ese dominio con certificados.

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 más información, consulte Directivas de Azure.

Implementar directivas restrictivas de uso compartido de recursos entre orígenes (CORS): use directivas DE CORS restrictivas en la aplicación web para aceptar solo las solicitudes de los dominios, encabezados y otros criterios permitidos. Aplique directivas de CORS con definiciones de directivas de Azure integradas.

Protección de 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.

Considere la posibilidad de registrar como parte del proceso de modelado de amenazas al evaluar las amenazas.

Calcule 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.

Evalúe las opciones con descuento: los niveles superiores incluyen instancias de proceso 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 más información, consulte Ahorro de costos con instancias reservadas de App Service.

Descripción de los medidores de uso: Azure cobra una tarifa por hora, prorrateada a la segunda, en función del plan de tarifa del plan de App Service. Los cargos se aplican a cada instancia escalada horizontalmente del plan, en función del tiempo que asigne la instancia de máquina virtual. Preste atención a los recursos de proceso infrautilizados que podrían aumentar los costos como resultado de la sobreasignación debido a la selección de SKU poco óptima o a la configuración de escalado deficiente.

Las características adicionales de App Service, como el registro de dominio personalizado y los certificados personalizados, pueden agregar costos. Otros recursos, como las redes virtuales, para aislar la solución o los almacenes de claves para proteger los secretos de carga de trabajo, que se integran con los recursos de App Service también pueden agregar costos. Para más información, consulte Modelo de facturación de App Services.

Tenga en cuenta los inconvenientes entre la densidad y el aislamiento: puede usar planes de App Service para hospedar varias aplicaciones en el mismo proceso, lo que ahorra costos con entornos compartidos. Para obtener más información, consulte Ventajas y desventajas.

Evalúe el efecto de la estrategia de escalado en el costo: debe diseñar, probar y configurar correctamente para el escalado horizontal y para el escalado horizontal al implementar el escalado automático. 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, desencadene el escalado en alrededor del 65 % para permitir 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 los back-end para el patrón front-end y el patrón de agregación de puerta de enlace, lo que puede minimizar el número de solicitudes y reducir los costos.

Compruebe 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 de proceso que la instancia de producción. Úselas estratégicamente para escenarios como implementaciones azul-verde que cambian entre ranuras. Este enfoque minimiza el tiempo de inactividad y garantiza transiciones suaves.

Use ranuras de implementación 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 Excelencia operativa.

Administrar versiones: use ranuras de implementación para administrar 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 conlleva costos adicionales porque la ranura se ejecuta en el mismo entorno de máquina virtual (VM) que la instancia de producción.

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 las pruebas de rendimiento. Explore herramientas automatizadas para otros tipos de pruebas, como Phantom para pruebas funcionales.

Implementar unidades inmutables: implemente el patrón De stamps de implementación para compartimentar App Service en un sello inmutable. App Service admite el uso de contenedores, que son intrínsecamente inmutables. Considere la posibilidad de usar contenedores personalizados para la aplicación web de App Service.

Cada sello representa una unidad independiente que se puede escalar horizontalmente o escalar horizontalmente rápidamente. Las unidades basadas en este sello son temporales y sin estado. El diseño sin estado simplifica las operaciones y el mantenimiento. Este enfoque es ideal para aplicaciones críticas. Para obtener un ejemplo, consulte Línea base crítica con App Service.

Use una infraestructura como tecnología de código (IaC), como Bicep, para desmarcar unidades con repetibilidad y coherencia.

Mantener seguros los entornos de producción: cree planes independientes de App Service 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.

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 Ideas, para recopilar y analizar datos de rendimiento de la aplicación. Para más información, consulte Referencia de datos de supervisión de App Service.

Incluya instrumentación de nivel de código, seguimiento de transacciones y generación de perfiles de rendimiento.

Evaluar capacidad: simule 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 derecho: Use el proceso dedicado para cargas de trabajo de producción. Los niveles Premium 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 más información, consulte Plan de tarifa Premium V3.

Optimizar la estrategia de escalado: cuando sea posible, use el 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.

Uso del almacenamiento en caché: la recuperación de información de un recurso que no cambia con frecuencia y es costosa para 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é.

Revise los antipatrones de rendimiento: para asegurarse de que la aplicación web realiza y escala según sus requisitos empresariales, evite los antipatrones típicos. Estos son algunos antipatrones que App Service corrige.