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 escalabilidad, costo, operabilidad y 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 contenedores. 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.

En este área de diseño se proporcionan 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 de 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 del estado permanente para una aplicación completa y el almacenamiento en caché de datos estáticos globales. Si necesita acomodar una arquitectura de unidad de escalado y una distribución global, tenga en cuenta cómo se distribuyen o replican los recursos 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 en varias regiones. Este modelo garantiza la tolerancia a errores regionales, de modo que la aplicación permanezca disponible incluso cuando una región completa 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. En el caso de las 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 pesar los requisitos específicos de la aplicación frente a los inconvenientes para determinar una decisión de diseño óptima. Para determinados escenarios de aplicación que tienen objetivos de confiabilidad inferiores, el particionamiento o activo/pasivo puede ser alternativas adecuadas.

Las zonas de disponibilidad pueden proporcionar implementaciones regionales de alta disponibilidad en diferentes centros de datos dentro de una región. Casi todos los servicios de Azure están disponibles en una configuración zonal, donde el servicio se delega a una zona específica o 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

  • Funcionalidades 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, se prioriza al menos una región de cada par 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 parcialmente activa o activa. 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 (SDP) de Azure 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. Implemente 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 al tiempo que cumplen los requisitos de residencia y retención de datos.

    Por ejemplo, algunos requisitos de cumplimiento de datos pueden restringir el número de regiones disponibles y forzar los 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 SLO 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. Calcule el SLO compuesto para todos los flujos de usuario. Asegúrese de que esos destinos están alineados 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 entre varias regiones para navegar por posibles restricciones de capacidad dentro de una sola región. Los sellos de implementación regionales adicionales pueden lograr un SLO compuesto mayor. Para obtener más información, consulte cómo implementar destinos de varias regiones.

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

  • Dentro de una sola geografía, priorice el 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 actual del servicio con las hojas de ruta del producto al elegir las 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 la 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 biblioteca. La administración también es más fácil con 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 para que solo se produzca durante el arranque de la aplicación, lo que proporciona una escalabilidad rápida.

Consideraciones de diseño

  • Supervisión. Puede ser difícil supervisar los servicios para acceder a las aplicaciones que están 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 paquetes de implementación de aplicaciones.

  • Priorice los tiempos de ejecución de contenedor basados en Linux siempre que 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 registros de contenedor para proporcionar el examen de vulnerabilidades de las imágenes de contenedor. Asegúrese de que microsoft Entra ID administra el acceso al registro.

Hospedaje y orquestación de contenedores

Varias plataformas de aplicaciones de Azure pueden hospedar contenedores de forma eficaz. Hay ventajas y desventajas asociadas a cada una de estas plataformas. Compare las opciones en el contexto de sus requisitos empresariales. Sin embargo, optimice siempre la confiabilidad, la escalabilidad y el rendimiento. Para obtener más información, consulta 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 App de Azure 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 redes e identidades. 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 clústeres de AKS públicos y privados, la habilitación de la directiva de red de Azure, la integración de Microsoft Entra y el uso de identidades administradas para AKS en lugar de entidades de servicio.

Fiabilidad

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.

  • Si los límites de escala son una restricción, aproveche la estrategia de unidad de escalado e implemente más unidades con clústeres.

  • Habilite el escalador automático de clústeres para ajustar automáticamente el número de nodos de agente en respuesta a las restricciones de recursos.

  • Use el escalador automático horizontal de pods para ajustar el número de pods de una implementación en función del uso de la CPU u otras métricas.

  • Para escenarios de gran escala y ráfaga, considere la posibilidad de usar nodos virtuales para una escala extensa y rápida.

  • Defina las solicitudes de recursos de pod y los límites en los manifiestos de implementación de aplicaciones. Si no lo hace, es posible que experimente problemas de rendimiento.

Aislamiento

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

  • 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 de 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 colocació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. Entre las características se 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 la integración de Microsoft Entra 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 el identificador de Entra de Microsoft para privilegios mínimos y minimice la concesión de privilegios de administrador para ayudar a proteger el acceso a la configuración y los 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 versión 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, las 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 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 ajusten a su caso de uso. Determine si necesita un control pormenorizado del tráfico entre pods. Soporte técnico de Azure s kubenet, Azure CNI y traiga su propio CNI para casos de uso específicos.

Priorice el 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.

  • Use Azure Monitor y Application Insights para recopilar métricas, registros y diagnósticos de recursos de AKS para solucionar problemas.

  • Habilite y revise los registros de recursos de Kubernetes.

  • Configure las métricas de Prometheus en Azure Monitor. Container Insights en Monitor proporciona incorporación, permite funcionalidades de supervisión integradas y habilita funcionalidades más avanzadas a través de la compatibilidad integrada con Prometheus.

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.

  • Controle las funciones que se conceden a los pods y si la ejecución de la directiva se 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ústeres y pods 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 impedir que los 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 App de Azure Service

En el caso de escenarios de carga de trabajo basados en web y API, 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.

Fiabilidad

Evalúe 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 mientras usa Azure Diagnostics para supervisar los puertos. Si se producen errores 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 de migración técnica 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 se escala horizontalmente si se cumple alguna regla dentro del perfil, pero solo se escala horizontalmente si se cumplen todas las reglas del perfil. Use una combinación de reglas de escalado horizontal y de escalado horizontal para asegurarse de que el escalado automático pueda tomar medidas para escalar horizontalmente y 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 hospede. 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 hospede 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 los 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 planes de App Service en varias unidades de escalado en una sola región. Implemente planes de App Service 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 a dos veces el 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 las ventajas y desventajas asociadas 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 y los estándares proporcionados por Docker 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 la 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 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, como la replicación geográfica, la autenticación de Microsoft Entra, la creación automatizada de contenedores y la aplicación de revisiones a través de tareas de Container Registry.

Fiabilidad

Configure la replicación geográfica en todas las regiones de implementación para quitar las dependencias regionales y optimizar la latencia. Container Registry admite 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 demás regiones seguirán sirviendo 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 zonas de disponibilidad, el nivel Premium Container Registry admite redundancia de zona para proporcionar protección contra 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 al consumo de recursos de proceso, dentro de las mismas regiones de Azure.

Bloqueo de imágenes

Las imágenes se pueden eliminar, como resultado de, por ejemplo, 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 de Container Registry etiquetadas 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 la autenticación integrada de Microsoft Entra para insertar y extraer imágenes en lugar de depender de 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 diversas 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 de poco código o sin código, con lógica de flujo de trabajo sencilla e integraciones que se pueden configurar mediante 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 la 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 de diseño y recomendaciones 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 los flujos controlados por eventos que tienen procesos de corta duración, ya que las funciones realizan operaciones distintas que se ejecutan lo más rápido posible.

Elija una opción de hospedaje de 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 el código de Azure Functions 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 vecinos ruidosos. Este modo usa el entorno de ejecución de Logic Apps de un solo inquilino en contenedor, 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. El uso de máquinas virtuales de infraestructura como servicio (IaaS) puede ser necesaria 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 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 máquinas virtuales y servicios asociados para maximizar la confiabilidad de la plataforma de aplicaciones. Resalta los aspectos clave de la metodología de diseño crítica que transponen escenarios de migración nativos de la nube e IaaS.

Consideraciones de diseño

  • Los costos operativos del uso de máquinas virtuales IaaS son significativamente mayores que los costos de usar 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:

    • 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.
    • Los conjuntos de escalado de máquinas virtuales de Azure proporcionan funcionalidad para escalar automáticamente el número de máquinas virtuales de un grupo. También proporcionan funcionalidades para supervisar el estado de las instancias y reparar automáticamente las instancias incorrectas.
    • Los conjuntos de escalado con orquestación flexible pueden ayudar a protegerse frente a errores de red, disco y energía mediante la distribución automática de máquinas virtuales entre dominios de error.

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 sea necesario.

  • Tamaño adecuado de las SKU de máquina virtual para garantizar el uso eficaz de los recursos.

  • Implemente tres o más máquinas virtuales en zonas de disponibilidad para lograr la 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 escalado de máquinas virtuales flexibles que contengan tres o más máquinas virtuales. Para obtener más información sobre cómo configurar el número correcto de dominios de error, consulte Administración de dominios de error en conjuntos de escalado.

  • 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 aplicación en varias regiones de Azure.

    • Consulte el área de diseño de redes y conectividad para obtener más información sobre cómo enrutar el tráfico de forma óptima entre las regiones de implementación activas.

  • 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/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 de 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