Compartir a través de

Consideraciones sobre la plataforma de aplicaciones para las cargas de trabajo críticas en Azure

  • Artículo

Azure proporciona muchos servicios de proceso para hospedar aplicaciones de alta disponibilidad. Los servicios difieren en la funcionalidad y la complejidad. Se recomienda elegir servicios en función de:

  • Requisitos no funcionales para confiabilidad, disponibilidad, rendimiento y seguridad.
  • Factores de decisión como la escalabilidad, el costo, la operabilidad y la complejidad.

La elección de una plataforma de hospedaje de aplicaciones es una decisión crítica que afecta a todas las demás áreas de diseño. Por ejemplo, es posible que el software de desarrollo heredado o propietario no se ejecute en servicios PaaS o aplicaciones en contenedor. Esta limitación influiría en la elección de la plataforma de proceso.

Una aplicación crítica puede usar más de un servicio de proceso para admitir varias cargas de trabajo compuestas y microservicios, cada una con requisitos distintos.

Este área de diseño proporciona recomendaciones relacionadas con las opciones de selección, diseño y configuración de proceso. También se recomienda familiarizarse con el árbol de decisión proceso.

Importante

Este artículo forma parte de la serie de cargas de trabajo críticas de Azure Well-Architected Framework . Si no está familiarizado con esta serie, se recomienda empezar con ¿Qué es una carga de trabajo crítica?.

Distribución global de recursos de plataforma

Un patrón típico para una carga de trabajo crítica incluye recursos globales y recursos regionales.

Los servicios de Azure, que no están restringidos a una región determinada de Azure, se implementan o configuran como recursos globales. Algunos casos de uso incluyen la distribución del tráfico entre varias regiones, el almacenamiento de estado permanente para una aplicación completa y el almacenamiento en caché de datos estáticos globales. Si necesita adaptarse tanto a una arquitectura de unidad de escalado como a una distribución global, tenga en cuenta cómo los recursos se distribuyen o replican de forma óptima entre regiones de Azure.

Otros recursos se implementan regionalmente. Estos recursos, que se implementan como parte de una marca de implementación, normalmente corresponden a una unidad de escalado. Sin embargo, una región puede tener más de un sello y un sello puede tener más de una unidad. La confiabilidad de los recursos regionales es fundamental porque son responsables de ejecutar la carga de trabajo principal.

En la imagen siguiente se muestra el diseño de alto nivel. Un usuario accede a la aplicación a través de un punto de entrada global central que, a continuación, redirige las solicitudes a una marca de implementación regional adecuada:

Diagrama que muestra una arquitectura crítica.

La metodología de diseño crítica requiere una implementación de varias regiones. Este modelo garantiza la tolerancia a errores regionales, de modo que la aplicación permanezca disponible incluso cuando una región entera deje de funcionar. Al diseñar una aplicación de varias regiones, considere diferentes estrategias de implementación, como activas, activas, activas o pasivas, junto con los requisitos de la aplicación, ya que hay importantes ventajas para cada enfoque. Para cargas de trabajo críticas, se recomienda encarecidamente el modelo activo o activo.

No todas las cargas de trabajo admiten o requieren ejecutar varias regiones simultáneamente. Debe sopesar los requisitos específicos de la aplicación con respecto a los inconvenientes para determinar una decisión de diseño óptima. Para determinados escenarios de aplicación que tienen objetivos de confiabilidad inferiores, las alternativas activas/pasivas o particionamiento pueden ser alternativas adecuadas.

Las zonas de disponibilidad pueden proporcionar implementaciones regionales de alta disponibilidad en distintos centros de datos de una región. Casi todos los servicios de Azure están disponibles en una configuración zonal, donde el servicio se delega en una zona específica o en una configuración con redundancia de zona, donde la plataforma garantiza automáticamente que el servicio abarca zonas y puede resistir una interrupción de zona. Estas configuraciones proporcionan tolerancia a errores hasta el nivel del centro de datos.

Consideraciones de diseño

  • Capacidades regionales y zonales. No todos los servicios y funcionalidades están disponibles en todas las regiones de Azure. Esta consideración podría afectar a las regiones que elija. Además, las zonas de disponibilidad no están disponibles en todas las regiones.

  • Pares regionales. Las regiones de Azure se agrupan en pares regionales que constan de dos regiones en una sola geografía. Algunos servicios de Azure usan regiones emparejadas para garantizar la continuidad empresarial y proporcionar un nivel de protección contra la pérdida de datos. Por ejemplo, el almacenamiento con redundancia geográfica (GRS) de Azure replica los datos en una región emparejada secundaria automáticamente, lo que garantiza que los datos sean duraderos si la región primaria no se puede recuperar. Si una interrupción afecta a varias regiones de Azure, al menos una región de cada par tiene prioridad para la recuperación.

  • Coherencia de datos. Para los desafíos de coherencia, considere la posibilidad de usar un almacén de datos distribuido globalmente, una arquitectura regional con marca y una implementación activa o activa parcialmente. En una implementación parcial, algunos componentes están activos en todas las regiones, mientras que otros se encuentran centralmente dentro de la región primaria.

  • Implementación segura. El marco de la práctica de implementación segura de Azure (SDP) garantiza que todos los cambios de código y configuración (mantenimiento planeado) en la plataforma Azure se someten a una implementación por fases. El estado se analiza para la degradación durante la versión. Una vez completadas correctamente las fases controladas y piloto, las actualizaciones de la plataforma se serializan entre pares regionales, por lo que solo se actualiza una región de cada par en un momento determinado.

  • Capacidad de la plataforma. Al igual que cualquier proveedor de nube, Azure tiene recursos finitos. La falta de disponibilidad puede ser el resultado de las limitaciones de capacidad en las regiones. Si hay una interrupción regional, hay un aumento de la demanda de recursos a medida que la carga de trabajo intenta recuperarse dentro de la región emparejada. La interrupción podría crear un problema de capacidad, donde el suministro temporalmente no satisface la demanda.

Recomendaciones de diseño

  • Implemente la solución en al menos dos regiones de Azure para ayudar a protegerse frente a interrupciones regionales. Impleméntelo en regiones que tengan las funcionalidades y características que requiere la carga de trabajo. Las funcionalidades deben cumplir los objetivos de rendimiento y disponibilidad a la vez que cumplen los requisitos de retención y residencia de datos.

    Por ejemplo, algunos requisitos de cumplimiento de datos pueden restringir el número de regiones disponibles y forzar potencialmente riesgos de diseño. En tales casos, se recomienda encarecidamente agregar una inversión adicional en contenedores operativos para predecir, detectar y responder a errores. Supongamos que está restringido a una geografía con dos regiones y solo una de esas regiones admite zonas de disponibilidad (3 + 1 modelo de centro de datos). Cree un patrón de implementación secundario mediante el aislamiento de dominio de error para permitir que ambas regiones se implementen en una configuración activa y asegúrese de que la región primaria alberga varias marcas de implementación.

    Si las regiones de Azure adecuadas no ofrecen todas las funcionalidades que necesita, prepárese para poner en peligro la coherencia de las marcas de implementación regionales para priorizar la distribución geográfica y maximizar la confiabilidad. Si solo una sola región de Azure es adecuada, implemente varias marcas de implementación (unidades de escalado regional) en la región seleccionada para mitigar algún riesgo y use zonas de disponibilidad para proporcionar tolerancia a errores de nivel de centro de datos. Sin embargo, un riesgo tan significativo en la distribución geográfica restringe drásticamente el Acuerdo de Nivel de Servicio compuesto alcanzable y la confiabilidad general.

    Importante

    En escenarios que tienen como destino un SLO mayor o igual que el 99,99 %, se recomienda un mínimo de tres regiones de implementación para maximizar el Acuerdo de Nivel de Servicio compuesto y la confiabilidad general. Calcule el Acuerdo de Nivel de Servicio compuesto para todos los flujos de usuario. Asegúrese de que el Acuerdo de Nivel de Servicio compuesto esté alineado con los objetivos empresariales.

  • Para escenarios de aplicaciones a gran escala que tienen volúmenes significativos de tráfico, diseñe la solución para escalar en varias regiones para navegar por posibles restricciones de capacidad dentro de una sola región. Los sellos de implementación regionales adicionales lograrán un Acuerdo de Nivel de Servicio compuesto mayor. El uso de recursos globales restringe el aumento del Acuerdo de Nivel de Servicio compuesto que logra agregando más regiones.

  • Defina y valide los objetivos de punto de recuperación (RPO) y los objetivos de tiempo de recuperación (RTO).

  • Dentro de una única geografía, dé prioridad al uso de pares regionales para beneficiarse de los lanzamientos serializados de SDP para el mantenimiento planeado y la priorización regional para el mantenimiento no planeado.

  • Coloque geográficamente los recursos de Azure con los usuarios para minimizar la latencia de red y maximizar el rendimiento de un extremo a otro.

  • Alinee la disponibilidad del servicio actual con las hojas de ruta del producto al elegir regiones de implementación. Es posible que algunos servicios no estén disponibles inmediatamente en cada región.

Inclusión en contenedores

Un contenedor incluye código de aplicación y los archivos de configuración, bibliotecas y dependencias relacionados que la aplicación necesita ejecutar. La contenedorización proporciona una capa de abstracción para el código de aplicación y sus dependencias y crea una separación de la plataforma de hospedaje subyacente. El paquete de software único es muy portátil y se puede ejecutar de forma coherente en varias plataformas de infraestructura y proveedores de nube. Los desarrolladores no necesitan volver a escribir código y pueden implementar aplicaciones de forma más rápida y confiable.

Importante

Se recomienda usar contenedores para paquetes de aplicaciones críticos. Mejoran el uso de la infraestructura porque puede hospedar varios contenedores en la misma infraestructura virtualizada. Además, dado que todo el software se incluye en el contenedor, puede mover la aplicación entre varios sistemas operativos, independientemente de los entornos de ejecución o las versiones de la biblioteca. La administración también es más fácil con los contenedores que con el hospedaje virtualizado tradicional.

Las aplicaciones críticas deben escalarse rápidamente para evitar cuellos de botella de rendimiento. Dado que las imágenes de contenedor están pregeneradas, puede limitar el inicio solo durante el arranque de la aplicación, lo que proporciona una escalabilidad rápida.

Consideraciones de diseño

  • Supervisión. Puede ser difícil que los servicios de supervisión accedan a las aplicaciones que se encuentran en contenedores. Normalmente, necesita software de terceros para recopilar y almacenar indicadores de estado de contenedor, como el uso de CPU o RAM.

  • Seguridad. El kernel del sistema operativo de la plataforma de hospedaje se comparte entre varios contenedores, lo que crea un único punto de ataque. Sin embargo, el riesgo de acceso a la máquina virtual host es limitado porque los contenedores están aislados del sistema operativo subyacente.

  • Estado. Aunque es posible almacenar datos en el sistema de archivos de un contenedor en ejecución, los datos no se conservarán cuando se vuelva a crear el contenedor. En su lugar, conserve los datos montando almacenamiento externo o usando una base de datos externa.

Recomendaciones de diseño

  • Incluir en contenedores todos los componentes de la aplicación. Use imágenes de contenedor como modelo principal para los paquetes de implementación de aplicaciones.

  • Dé prioridad a los entornos de ejecución de contenedor basados en Linux cuando sea posible. Las imágenes son más ligeras y las nuevas características de los nodos o contenedores de Linux se publican con frecuencia.

  • Haga que los contenedores sean inmutables y reemplazables, con ciclos de vida cortos.

  • Asegúrese de recopilar todos los registros y métricas pertinentes del contenedor, el host de contenedor y el clúster subyacente. Envíe los registros y métricas recopilados a un receptor de datos unificado para su posterior procesamiento y análisis.

  • Almacene imágenes de contenedor en Azure Container Registry. Use la replicación geográfica para replicar imágenes de contenedor en todas las regiones. Habilite Microsoft Defender para que los registros de contenedor proporcionen el examen de vulnerabilidades de las imágenes de contenedor. Asegúrese de que el acceso al registro se administra mediante Microsoft Entra id.

Hospedaje y orquestación de contenedores

Varias plataformas de aplicaciones de Azure pueden hospedar de forma eficaz contenedores. Hay ventajas y desventajas asociadas a cada una de estas plataformas. Compare las opciones en el contexto de los requisitos empresariales. Sin embargo, optimice siempre la confiabilidad, la escalabilidad y el rendimiento. Para obtener más información, consulte estos artículos:

Importante

Azure Kubernetes Service (AKS) y Azure Container Apps deben estar entre las primeras opciones para la administración de contenedores en función de sus requisitos. Aunque Azure App Service no es un orquestador, como una plataforma de contenedor de baja fricción, sigue siendo una alternativa factible a AKS.

Consideraciones y recomendaciones de diseño para Azure Kubernetes Service

AKS, un servicio de Kubernetes administrado, permite el aprovisionamiento rápido de clústeres sin necesidad de actividades complejas de administración de clústeres y ofrece un conjunto de características que incluye funcionalidades avanzadas de red e identidad. Para obtener un conjunto completo de recomendaciones, consulte Revisión de Azure Well-Architected Framework: AKS.

Importante

Hay algunas decisiones de configuración fundamentales que no se pueden cambiar sin volver a implementar el clúster de AKS. Entre los ejemplos se incluyen la elección entre los clústeres de AKS públicos y privados, la habilitación de Azure Network Policy, la integración Microsoft Entra y el uso de identidades administradas para AKS en lugar de entidades de servicio.

Confiabilidad

AKS administra el plano de control nativo de Kubernetes. Si el plano de control no está disponible, la carga de trabajo experimenta tiempo de inactividad. Aproveche las características de confiabilidad que ofrece AKS:

  • Implemente clústeres de AKS en diferentes regiones de Azure como una unidad de escalado para maximizar la confiabilidad y la disponibilidad. Use zonas de disponibilidad para maximizar la resistencia dentro de una región de Azure mediante la distribución de nodos de agente y plano de control de AKS entre centros de datos físicamente independientes. Sin embargo, si la latencia de coubicación es un problema, puede realizar la implementación de AKS dentro de una sola zona o usar grupos de selección de ubicación de proximidad para minimizar la latencia interno.

  • Use el Acuerdo de Nivel de Servicio de tiempo de actividad de AKS para clústeres de producción para maximizar las garantías de disponibilidad de los puntos de conexión de la API de Kubernetes.

Escalabilidad

Tenga en cuenta los límites de escala de AKS, como el número de nodos, grupos de nodos por clúster y clústeres por suscripción.

Aislamiento

Mantenga los límites entre la infraestructura utilizada por la carga de trabajo y las herramientas del sistema. El uso compartido de la infraestructura podría dar lugar a un uso elevado de recursos y a escenarios ruidosos de vecinos.

  • Use grupos de nodos independientes para los servicios de sistema y carga de trabajo. Los grupos de nodos dedicados para los componentes de carga de trabajo deben basarse en los requisitos de recursos de infraestructura especializados, como máquinas virtuales gpu de alta memoria. En general, para reducir la sobrecarga de administración innecesaria, evite implementar un gran número de grupos de nodos.

  • Use taints y tolerations para proporcionar nodos dedicados y limitar las aplicaciones que consumen muchos recursos.

  • Evalúe los requisitos de afinidad de aplicación y antiafinidad y configure la coubicación adecuada de contenedores en los nodos.

Seguridad

Kubernetes de vainilla predeterminado requiere una configuración significativa para garantizar una posición de seguridad adecuada para escenarios críticos. AKS aborda varios riesgos de seguridad de fábrica. Las características incluyen clústeres privados, auditoría e inicio de sesión en Log Analytics, imágenes de nodo protegidas e identidades administradas.

  • Aplique las instrucciones de configuración proporcionadas en la línea base de seguridad de AKS.

  • Use características de AKS para controlar la administración de identidades y accesos del clúster para reducir la sobrecarga operativa y aplicar una administración de acceso coherente.

  • Use identidades administradas en lugar de entidades de servicio para evitar la administración y la rotación de credenciales. Puede agregar identidades administradas en el nivel de clúster. En el nivel de pod, puede usar identidades administradas a través de Id. de carga de trabajo de Microsoft Entra.

  • Use Microsoft Entra integración para la administración centralizada de cuentas y contraseñas, la administración de acceso a aplicaciones y la protección mejorada de identidades. Use RBAC de Kubernetes con Microsoft Entra id. de privilegios mínimos y minimice la concesión de privilegios de administrador para ayudar a proteger la configuración y el acceso a secretos. Además, limite el acceso al archivo de configuración del clúster de Kubernetes mediante el control de acceso basado en rol de Azure. Limite el acceso a las acciones que pueden realizar los contenedores, proporcione el menor número de permisos y evite el uso de la elevación de privilegios raíz.

Actualizaciones

Los clústeres y nodos deben actualizarse periódicamente. AKS admite versiones de Kubernetes en consonancia con el ciclo de lanzamiento de Kubernetes nativo.

  • Suscríbase a la hoja de ruta y las notas de la versión públicas de AKS en GitHub para mantenerse al día de los próximos cambios, mejoras y, lo que es más importante, versiones y desusos de la versión de Kubernetes.

  • Aplique las instrucciones proporcionadas en la lista de comprobación de AKS para garantizar la alineación con los procedimientos recomendados.

  • Tenga en cuenta los distintos métodos admitidos por AKS para actualizar nodos o clústeres. Estos métodos pueden ser manuales o automatizados. Puede usar Mantenimiento planeado para definir ventanas de mantenimiento para estas operaciones. Las nuevas imágenes se publican semanalmente. AKS también admite canales de actualización automática para actualizar automáticamente los clústeres de AKS a versiones más recientes de Kubernetes o imágenes de nodo más recientes cuando estén disponibles.

Redes

Evalúe los complementos de red que mejor se adapten a su caso de uso. Determine si necesita un control granular del tráfico entre pods. Azure admite kubenet, Azure CNI y traiga su propio CNI para casos de uso específicos.

Dé prioridad al uso de Azure CNI después de evaluar los requisitos de red y el tamaño del clúster. Azure CNI permite el uso de directivas de red de Azure o Calico para controlar el tráfico dentro del clúster.

Supervisión

Las herramientas de supervisión deben poder capturar registros y métricas de pods en ejecución. También debe recopilar información de la API de métricas de Kubernetes para supervisar el estado de los recursos y las cargas de trabajo en ejecución.

Gobernanza

Use directivas para aplicar medidas de seguridad centralizadas a los clústeres de AKS de forma coherente. Aplique asignaciones de directiva en un ámbito de suscripción o superior para impulsar la coherencia entre los equipos de desarrollo.

  • Controlar qué funciones se conceden a los pods y si la ejecución de la directiva contradiga, mediante Azure Policy. Este acceso se define mediante las directivas integradas proporcionadas por el complemento de Azure Policy para AKS.

  • Establezca una base de referencia de seguridad y confiabilidad coherentes para las configuraciones de clúster y pod de AKS mediante Azure Policy.

  • Use el complemento de Azure Policy para AKS para controlar las funciones de pod, como los privilegios raíz, y para no permitir pods que no se ajusten a la directiva.

Nota:

Al implementar en una zona de aterrizaje de Azure, las directivas de Azure que le ayudarán a garantizar una confiabilidad y seguridad coherentes deben proporcionarse mediante la implementación de la zona de aterrizaje.

Las implementaciones de referencia críticas proporcionan un conjunto de directivas de línea de base para impulsar las configuraciones de seguridad y confiabilidad recomendadas.

Consideraciones y recomendaciones de diseño para Azure App Service

En el caso de escenarios de carga de trabajo basados en API y web, App Service podría ser una alternativa factible a AKS. Proporciona una plataforma de contenedor de baja fricción sin la complejidad de Kubernetes. Para obtener un conjunto completo de recomendaciones, consulte Consideraciones de confiabilidad para App Service y excelencia operativa para App Service.

Confiabilidad

Examine el uso de los puertos TCP y SNAT. Las conexiones TCP se usan para todas las conexiones salientes. Los puertos SNAT se usan para las conexiones salientes a direcciones IP públicas. El agotamiento de puertos SNAT es un escenario de error común. Debe detectar de forma predictiva este problema mediante pruebas de carga al usar Azure Diagnostics para supervisar los puertos. Si se producen errores de SNAT, debe escalar entre más o más trabajadores o implementar prácticas de codificación para ayudar a conservar y reutilizar puertos SNAT. Entre los ejemplos de prácticas de codificación que se pueden usar se incluyen la agrupación de conexiones y la carga diferida de recursos.

El agotamiento de puertos TCP es otro escenario de error. Se produce cuando la suma de conexiones salientes de un trabajo determinado supera la capacidad. El número de puertos TCP disponibles depende del tamaño del trabajo. Para obtener recomendaciones, consulte Puertos TCP y SNAT.

Escalabilidad

Planee los requisitos de escalabilidad futuros y el crecimiento de las aplicaciones para que pueda aplicar las recomendaciones adecuadas desde el principio. Al hacerlo, puede evitar la deuda técnica de migración a medida que crece la solución.

  • Habilite la escalabilidad automática para asegurarse de que los recursos adecuados están disponibles para las solicitudes de servicio. Evalúe el escalado por aplicación para el hospedaje de alta densidad en App Service.

  • Tenga en cuenta que App Service tiene un límite temporal predeterminado de instancias por plan de App Service.

  • Aplicar reglas de escalado automático. Un plan de App Service escala horizontalmente si se cumple alguna regla dentro del perfil, pero solo se escala si se cumplen todas las reglas del perfil. Use una combinación de reglas de escalabilidad horizontal y reducción horizontal para asegurarse de que la escalabilidad automática puede tomar medidas tanto para escalar horizontalmente como para escalar horizontalmente. Comprenda el comportamiento de varias reglas de escalado en un único perfil.

  • Tenga en cuenta que puede habilitar el escalado por aplicación en el nivel del plan de App Service para permitir que una aplicación se escale independientemente del plan de App Service que lo hospeda. Las aplicaciones se asignan a los nodos disponibles a través de un enfoque de mejor esfuerzo para una distribución uniforme. Aunque no se garantiza una distribución uniforme, la plataforma garantiza que dos instancias de la misma aplicación no se hospedan en la misma instancia.

Supervisión

Supervise el comportamiento de la aplicación y obtenga acceso a los registros y métricas pertinentes para asegurarse de que la aplicación funciona según lo previsto.

  • Puede usar el registro de diagnóstico para ingerir registros de nivel de aplicación y de plataforma en Log Analytics, Azure Storage o una herramienta de terceros a través de Azure Event Hubs.

  • La supervisión del rendimiento de las aplicaciones con Application Insights proporciona información detallada sobre el rendimiento de las aplicaciones.

  • Las aplicaciones críticas deben tener la capacidad de auto-sanar si hay errores. Habilite Auto Heal para reciclar automáticamente trabajos incorrectos.

  • Debe usar las comprobaciones de estado adecuadas para evaluar todas las dependencias críticas de bajada, lo que ayuda a garantizar el estado general. Se recomienda encarecidamente habilitar la comprobación de estado para identificar a los trabajadores que no responden.

Implementación

Para solucionar el límite predeterminado de instancias por plan de App Service, implemente App Service planes en varias unidades de escalado en una sola región. Implemente App Service planes en una configuración de zona de disponibilidad para asegurarse de que los nodos de trabajo se distribuyen entre zonas dentro de una región. Considere la posibilidad de abrir una incidencia de soporte técnico para aumentar el número máximo de trabajos al doble del recuento de instancias que necesita para atender la carga máxima normal.

Registro de contenedor

Los registros de contenedor hospedan imágenes que se implementan en entornos de tiempo de ejecución de contenedor como AKS. Debe configurar cuidadosamente los registros de contenedor para cargas de trabajo críticas. Una interrupción no debe provocar retrasos en la extracción de imágenes, especialmente durante las operaciones de escalado. Las siguientes consideraciones y recomendaciones se centran en Azure Container Registry y exploran los inconvenientes asociados a los modelos de implementación centralizados y federados.

Consideraciones de diseño

  • Formato. Considere la posibilidad de usar un registro de contenedor que se base en el formato proporcionado por Docker y los estándares para las operaciones de inserción y extracción. Estas soluciones son compatibles y principalmente intercambiables.

  • Modelo de implementación. Puede implementar el registro de contenedor como un servicio centralizado consumido por varias aplicaciones dentro de su organización. O bien, puede implementarlo como un componente dedicado para una carga de trabajo de aplicación específica.

  • Registros públicos. Las imágenes de contenedor se almacenan en Docker Hub u otros registros públicos que existen fuera de Azure y en una red virtual determinada. Esto no es necesariamente un problema, pero puede provocar varios problemas relacionados con la disponibilidad del servicio, la limitación y la filtración de datos. En algunos escenarios de aplicación, debe replicar imágenes de contenedor públicas en un registro de contenedor privado para limitar el tráfico de salida, aumentar la disponibilidad o evitar posibles limitaciones.

Recomendaciones de diseño

  • Use instancias de registro de contenedor dedicadas a la carga de trabajo de la aplicación. Evite crear una dependencia en un servicio centralizado a menos que los requisitos de disponibilidad y confiabilidad de la organización estén totalmente alineados con la aplicación.

    En el patrón de arquitectura principal recomendado, los registros de contenedor son recursos globales que son de larga duración. Considere la posibilidad de usar un único registro de contenedor global por entorno. Por ejemplo, use un registro de producción global.

  • Asegúrese de que el Acuerdo de Nivel de Servicio para el registro público esté alineado con los objetivos de confiabilidad y seguridad. Tome nota especial de los límites de los casos de uso que dependen de Docker Hub.

  • Priorice Azure Container Registry para hospedar imágenes de contenedor.

Consideraciones y recomendaciones de diseño para Azure Container Registry

Este servicio nativo proporciona una variedad de características, incluida la replicación geográfica, la autenticación Microsoft Entra, la creación automatizada de contenedores y la aplicación de revisiones a través de tareas de Container Registry.

Confiabilidad

Configure la replicación geográfica en todas las regiones de implementación para quitar dependencias regionales y optimizar la latencia. Container Registry admite la alta disponibilidad a través de la replicación geográfica en varias regiones configuradas, lo que proporciona resistencia frente a interrupciones regionales. Si una región deja de estar disponible, las otras regiones seguirán atendiendo las solicitudes de imagen. Cuando la región vuelve a estar en línea, Container Registry recupera y replica los cambios en ella. Esta funcionalidad también proporciona coubicación del registro en cada región configurada, lo que reduce la latencia de red y los costos de transferencia de datos entre regiones.

En las regiones de Azure que proporcionan compatibilidad con la zona de disponibilidad, el nivel Premium Container Registry admite la redundancia de zona para proporcionar protección frente a errores zonales. El nivel Premium también admite puntos de conexión privados para ayudar a evitar el acceso no autorizado al registro, lo que puede provocar problemas de confiabilidad.

Imágenes de host cercanas a los recursos de proceso que consumen, dentro de las mismas regiones de Azure.

Bloqueo de imágenes

Las imágenes se pueden eliminar, por ejemplo, como resultado de un error manual. Container Registry admite el bloqueo de una versión de imagen o un repositorio para evitar cambios o eliminaciones. Cuando se cambia una versión de imagen implementada anteriormente, las implementaciones de la misma versión pueden proporcionar resultados diferentes antes y después del cambio.

Si desea proteger la instancia de Container Registry de la eliminación, use bloqueos de recursos.

Imágenes etiquetadas

Las imágenes etiquetadas de Container Registry son mutables de forma predeterminada, lo que significa que la misma etiqueta se puede usar en varias imágenes insertadas en el registro. En escenarios de producción, esto puede provocar un comportamiento impredecible que podría afectar al tiempo de actividad de la aplicación.

Administración de identidades y acceso

Use Microsoft Entra autenticación integrada para insertar y extraer imágenes en lugar de confiar en claves de acceso. Para mejorar la seguridad, deshabilite completamente el uso de la clave de acceso de administrador.

Proceso sin servidor

La informática sin servidor proporciona recursos a petición y elimina la necesidad de administrar la infraestructura. El proveedor de nube aprovisiona, escala y administra automáticamente los recursos necesarios para ejecutar el código de aplicación implementado. Azure proporciona varias plataformas de proceso sin servidor:

  • Azure Functions. Cuando se usa Azure Functions, la lógica de la aplicación se implementa como bloques distintos de código o funciones que se ejecutan en respuesta a eventos, como una solicitud HTTP o un mensaje de cola. Cada función se escala según sea necesario para satisfacer la demanda.

  • Azure Logic Apps. Logic Apps es más adecuado para crear y ejecutar flujos de trabajo automatizados que integran varias aplicaciones, orígenes de datos, servicios y sistemas. Al igual que Azure Functions, Logic Apps usa desencadenadores integrados para el procesamiento controlado por eventos. Sin embargo, en lugar de implementar código de aplicación, puede crear aplicaciones lógicas mediante una interfaz gráfica de usuario que admita bloques de código como condicionales y bucles.

  • Azure API Management. Puede usar API Management para publicar, transformar, mantener y supervisar las API de seguridad mejorada mediante el nivel consumo.

  • Power Apps y Power Automate. Estas herramientas proporcionan una experiencia de desarrollo con poco código o sin código, con lógica de flujo de trabajo sencilla e integraciones que se pueden configurar a través de conexiones en una interfaz de usuario.

En el caso de las aplicaciones críticas, las tecnologías sin servidor proporcionan un desarrollo y operaciones simplificados, lo que puede ser útil para casos de uso empresariales sencillos. Sin embargo, esta simplicidad conlleva el costo de flexibilidad en términos de escalabilidad, confiabilidad y rendimiento, y eso no es viable para la mayoría de los escenarios de aplicación críticos.

En las secciones siguientes se proporcionan consideraciones y recomendaciones de diseño para usar Azure Functions y Logic Apps como plataformas alternativas para escenarios de flujo de trabajo no críticos.

Consideraciones y recomendaciones de diseño para Azure Functions

Las cargas de trabajo críticas tienen flujos de sistema críticos y no críticos. Azure Functions es una opción viable para los flujos que no tienen los mismos requisitos empresariales estrictos que los flujos críticos del sistema. Es adecuado para flujos controlados por eventos que tienen procesos de corta duración porque las funciones realizan operaciones distintas que se ejecutan lo más rápido posible.

Elija una opción de hospedaje Azure Functions adecuada para el nivel de confiabilidad de la aplicación. Se recomienda el plan Premium porque permite configurar el tamaño de la instancia de proceso. El plan dedicado es la opción menos sin servidor. Proporciona escalabilidad automática, pero estas operaciones de escalado son más lentas que las de los otros planes. Se recomienda usar el plan Premium para maximizar la confiabilidad y el rendimiento.

Hay algunas consideraciones de seguridad. Cuando se usa un desencadenador HTTP para exponer un punto de conexión externo, use un firewall de aplicaciones web (WAF) para proporcionar un nivel de protección para el punto de conexión HTTP frente a vectores de ataque externos comunes.

Se recomienda el uso de puntos de conexión privados para restringir el acceso a redes virtuales privadas. También pueden mitigar los riesgos de filtración de datos, como escenarios de administración malintencionados.

Debe usar herramientas de análisis de código en Azure Functions código e integrar esas herramientas con canalizaciones de CI/CD.

Consideraciones y recomendaciones de diseño para Azure Logic Apps

Al igual que Azure Functions, Logic Apps usa desencadenadores integrados para el procesamiento controlado por eventos. Sin embargo, en lugar de implementar código de aplicación, puede crear aplicaciones lógicas mediante una interfaz gráfica de usuario que admita bloques como condicionales, bucles y otras construcciones.

Hay varios modos de implementación disponibles. Se recomienda el modo Estándar para garantizar una implementación de un solo inquilino y mitigar los escenarios de vecino ruidosos. Este modo usa el entorno de ejecución de Logic Apps contenedorizado de un solo inquilino, que se basa en Azure Functions. En este modo, la aplicación lógica puede tener varios flujos de trabajo con estado y sin estado. Debe tener en cuenta los límites de configuración.

Migraciones restringidas a través de IaaS

Muchas aplicaciones que tienen implementaciones locales existentes usan tecnologías de virtualización y hardware redundante para proporcionar niveles críticos de confiabilidad. La modernización suele verse obstaculizada por las restricciones empresariales que impiden la alineación completa con el patrón de arquitectura de línea base nativa de nube (North Star) que se recomienda para cargas de trabajo críticas. Por eso muchas aplicaciones adoptan un enfoque por fases, con implementaciones iniciales en la nube mediante virtualización y Azure Virtual Machines como modelo de hospedaje de aplicaciones principal. Es posible que el uso de máquinas virtuales IaaS sea necesario en determinados escenarios:

  • Los servicios PaaS disponibles no proporcionan el rendimiento o el nivel de control necesarios.
  • La carga de trabajo requiere acceso al sistema operativo, controladores específicos o configuraciones de red y del sistema.
  • La carga de trabajo no admite la ejecución en contenedores.
  • No hay compatibilidad con el proveedor para cargas de trabajo de terceros.

Esta sección se centra en las mejores maneras de usar Azure Virtual Machines y los servicios asociados para maximizar la confiabilidad de la plataforma de aplicaciones. Destaca los aspectos clave de la metodología de diseño crítica que transponen escenarios de migración nativos de nube e IaaS.

Consideraciones de diseño

  • Los costos operativos del uso de máquinas virtuales IaaS son significativamente mayores que los costos de uso de servicios PaaS debido a los requisitos de administración de las máquinas virtuales y los sistemas operativos. La administración de máquinas virtuales requiere el lanzamiento frecuente de paquetes de software y actualizaciones.

  • Azure proporciona funcionalidades para aumentar la disponibilidad de las máquinas virtuales:

    • Los conjuntos de disponibilidad pueden ayudar a protegerse frente a errores de red, disco y energía mediante la distribución de máquinas virtuales entre dominios de error y dominios de actualización.
    • Las zonas de disponibilidad pueden ayudarle a lograr niveles aún más altos de confiabilidad mediante la distribución de máquinas virtuales entre centros de datos separados físicamente dentro de una región.
    • Virtual Machine Scale Sets proporcionar funcionalidad para escalar automáticamente el número de máquinas virtuales de un grupo. También proporcionan funcionalidades para supervisar el estado de la instancia y reparar automáticamente las instancias incorrectas.

Recomendaciones de diseño

Importante

Use los servicios y contenedores de PaaS siempre que sea posible para reducir la complejidad y el costo operativos. Use máquinas virtuales iaaS solo cuando necesite.

  • Tamaño correcto de SKU de máquina virtual para garantizar un uso eficaz de los recursos.

  • Implemente tres o más máquinas virtuales en zonas de disponibilidad para lograr tolerancia a errores de nivel de centro de datos.

    • Si va a implementar software comercial fuera del estante, consulte al proveedor de software y pruebe adecuadamente antes de implementar el software en producción.

  • En el caso de las cargas de trabajo que no se pueden implementar en zonas de disponibilidad, use conjuntos de disponibilidad que contengan tres o más máquinas virtuales.

    • Tenga en cuenta los conjuntos de disponibilidad solo si las zonas de disponibilidad no cumplen los requisitos de carga de trabajo, como las cargas de trabajo chatty con requisitos de baja latencia.

  • Priorice el uso de Virtual Machine Scale Sets para la escalabilidad y la redundancia de zona. Este punto es especialmente importante para las cargas de trabajo que tienen cargas variables. Por ejemplo, si el número de usuarios o solicitudes activos por segundo es una carga variable.

  • No acceda directamente a máquinas virtuales individuales. Use equilibradores de carga delante de ellos siempre que sea posible.

  • Para protegerse frente a interrupciones regionales, implemente máquinas virtuales de aplicaciones en varias regiones de Azure.

  • En el caso de las cargas de trabajo que no admiten implementaciones activas o activas de varias regiones, considere la posibilidad de implementar implementaciones activas o pasivas mediante máquinas virtuales en espera activa o activa para la conmutación por error regional.

  • Use imágenes estándar de Azure Marketplace en lugar de imágenes personalizadas que deben mantenerse.

  • Implemente procesos automatizados para implementar e implementar cambios en las máquinas virtuales, evitando cualquier intervención manual. Para obtener más información, consulte Consideraciones de IaaS en el área de diseño procedimientos operativos .

  • Implemente experimentos de caos para insertar errores de aplicación en componentes de máquina virtual y observe la mitigación de errores. Para obtener más información, consulte Validación y pruebas continuas.

  • Supervise las máquinas virtuales y asegúrese de que los registros de diagnóstico y las métricas se ingieren en un receptor de datos unificado.

  • Implemente prácticas de seguridad para escenarios de aplicaciones críticas, cuando corresponda, y los procedimientos recomendados de seguridad para cargas de trabajo de IaaS en Azure.

Paso siguiente

Revise las consideraciones de la plataforma de datos.

Plataforma de datos