Patrón de stamps de implementación

Implemente varias copias independientes de los componentes de la aplicación, incluidos los almacenes de datos, como un único grupo de recursos. Cada copia se denomina marca o, a veces, una unidad de servicio, una unidad de escalado o una celda. En un entorno multitenant, cada stamp da servicio a un número predefinido de clientes. Implemente más sellos para escalar la solución de forma casi lineal, dar servicio a un número creciente de inquilinos, desplegar instancias en varias regiones y separar los datos de sus clientes.

Note

Para más información, consulte Arquitectura de soluciones multiinquilino en Azure.

Contexto y problema

Al hospedar una aplicación en la nube, tenga en cuenta el rendimiento y la confiabilidad de la aplicación. Si hospeda una única instancia de la solución, se pueden aplicar las siguientes limitaciones:

• Límites de escala: Una sola instancia de la aplicación podría alcanzar límites de escalado natural. Por ejemplo, los servicios que use pueden limitar el número de conexiones entrantes, nombres de host, sockets del Protocolo de control de transmisión (TCP) u otros recursos.

• Escalado o costo no lineal: Es posible que algunos de los componentes de la solución no se escalen linealmente con el número de solicitudes o la cantidad de datos. En su lugar, el rendimiento puede reducirse o el costo puede aumentar después de alcanzar un umbral. Por ejemplo, es posible que encuentre que agregar más capacidad a una base de datos o escalar verticalmente se vuelve prohibitivamente costoso y que escalar horizontalmente es más rentable.

• Separación de clientes: Es posible que tenga que aislar los datos de un cliente de los datos de otro cliente. Es posible que también tenga clientes que consuman más recursos del sistema que otros. Puede agruparlos en diferentes conjuntos de infraestructura.

• Instancias de un solo inquilino y multiinquilino: Es posible que algunos clientes de gran tamaño necesiten sus propias instancias independientes de la solución. Los clientes más pequeños pueden compartir una implementación multiusuario.

• Requisitos de implementación complejos: Es posible que tenga que implementar actualizaciones en el servicio de forma controlada e implementar en diferentes subconjuntos de la base de clientes en momentos diferentes.

• Frecuencia de actualización: Algunos clientes toleran actualizaciones frecuentes, mientras que los clientes con problemas de riesgo quieren actualizaciones poco frecuentes al sistema que atiende sus solicitudes. Puede implementar estos clientes en entornos aislados.

• Restricciones geográficas o geopolíticas: Para lograr una latencia baja o cumplir los requisitos de soberanía de datos, puede implementar algunos clientes en regiones específicas.

Estas limitaciones suelen aplicarse a las empresas de desarrollo de software que crean software como servicio (SaaS), que normalmente diseñan como multiinquilino. Las mismas limitaciones también se pueden aplicar a otros escenarios.

Solución

Para evitar estos problemas, considere agrupar recursos en unidades de escalabilidad y aprovisionar varias copias de sus stamps. Cada unidad de escala aloja y sirve un subconjunto de tus clientes. Los stamps se ejecutan de forma independiente entre sí, y se pueden implementar y actualizar de forma independiente. Una misma región geográfica puede contener un stamp o varios stamps que se escalan horizontalmente dentro de la región. Cada sello sirve a un subconjunto de sus clientes.

En el diagrama se muestran cinco filas apiladas. Cada fila representa un sello de implementación. Cada fila tiene una etiqueta en la parte superior izquierda que denomina la marca y su región de Azure, una etiqueta en la esquina superior derecha que enumera los inquilinos a los que sirve la marca y dos componentes debajo de las etiquetas, Azure App Service a la izquierda y una base de datos SQL a la derecha. De arriba hacia abajo, los sellos son Sello 1 en el Oeste de Estados Unidos 2, que atiende a los inquilinos A, B y C; Sello 2 en el Oeste de Estados Unidos 2, que atiende al inquilino D; Sello 3 en el Este de Estados Unidos, que atiende a los inquilinos E, F y G; Sello 4 en el Oeste de Europa, que atiende a los inquilinos H, I y J; y Sello 5 en el Este de Australia, que atiende a los inquilinos K, L y M. Los cinco sellos comparten la misma composición interna, pero difieren en la región y en el conjunto de inquilinos asignados a ellos, y la región Oeste de Estados Unidos 2 contiene dos sellos independientes, mientras que cada una de las otras regiones contiene un sello.

Las marcas de implementación pueden aplicar si la solución usa componentes de infraestructura como servicio (IaaS) o plataforma como servicio (PaaS) o una combinación de ambos. Las cargas de trabajo de IaaS suelen requerir más intervención para escalar, por lo que este patrón puede ayudar a que las cargas de trabajo con un uso intensivo de IaaS se escalen horizontalmente.

Puede usar "stamps" para implementar anillos de implementación. Si los distintos clientes quieren actualizaciones de servicio en diferentes frecuencias, agrupe en diferentes sellos e implemente actualizaciones en cada sello a una cadencia diferente.

Los sellos funcionan de manera independiente, por lo que fragmentan implícitamente tus datos. Un único stamp también puede utilizar una fragmentación adicional a nivel interno para escalar y mantener su elasticidad.

La implementación de copias idénticas de los mismos componentes es compleja, por lo que las buenas prácticas de DevOps son críticas. Describa la infraestructura como código para que la implementación de cada sello sea predecible y repetible.

Los stamps de implementación están relacionados con los geodes, pero se diferencian de ellos. En una arquitectura de sello de implementación, cada instancia independiente de tu sistema atiende a un subconjunto de tus clientes y usuarios. En una arquitectura de geode, cada instancia puede atender solicitudes de cualquier usuario, pero este enfoque suele ser más complejo para diseñar y compilar. También puede combinar los dos patrones dentro de una solución. El enfoque de enrutamiento de tráfico descrito más adelante en este artículo es un ejemplo de este escenario híbrido.

Problemas y consideraciones

Tenga en cuenta los siguientes puntos a medida que decida cómo implementar este patrón:

• Proceso de implementación: Al implementar varios stamps, automatice por completo y repita los procesos de implementación. Utilice los módulos de Bicep o Terraform para definir sus configuraciones de manera declarativa y mantener las definiciones coherentes.

• Operaciones entre stamps: Cuando se implementa una solución de forma independiente en varios stamps, puede resultar complicado determinar cuántos clientes hay en el conjunto de todos los stamps. Es posible que sea necesario consultar cada stamp y agregar los resultados. Como alternativa, puede hacer que todos los sellos publiquen datos en un almacén de datos centralizado para los informes consolidados.

• Políticas de escalabilidad horizontal: Los stamps tienen una capacidad finita, que puede definirse mediante una métrica proxy, como el número de inquilinos que se pueden implementar en el stamp. Supervise la capacidad disponible y usada para cada sello e implemente de forma proactiva más sellos para dirigir a ellos nuevos inquilinos.

• Número mínimo de sellos: Al usar el patrón de sellos de implementación, implemente al menos dos sellos de la solución. Si solo se implementa un único stamp, es fácil codificar de forma rígida en el código o la configuración supuestos que no se cumplen al escalar horizontalmente.

• Costo: El patrón de Estampillas de Despliegue implementa varias copias de los componentes de infraestructura, lo que incrementa considerablemente el costo operativo de su solución.

• Traslado entre stamps: Cada stamp se ejecuta de forma independiente, por lo que trasladar inquilinos entre ellos puede resultar complicado. La aplicación necesita lógica personalizada para transmitir la información de un cliente a una marca diferente y, a continuación, quitar la información del inquilino del sello original. Este proceso podría requerir una placa base para la comunicación entre stamps, lo que aumenta aún más la complejidad de su solución.

• Enrutamiento del tráfico: Tal y como se ha descrito anteriormente en este artículo, enrutar el tráfico al stamp correcto para una solicitud determinada puede requerir un componente adicional que asigne los inquilinos a los stamps. Es posible que este componente también tenga que estar altamente disponible.

• Observabilidad entre stamps: A medida que aumenta el número de stamps, resulta más difícil comprender el estado general y detectar incidentes rápidamente. Usa Azure Monitor para recopilar y correlacionar métricas, registros, seguimientos y alertas en todos los entornos. Utilice estos datos para identificar sellos defectuosos y diagnosticar problemas.

• Repercusión de los fallos regionales: Los stamps funcionan de forma independiente, pero no son intrínsecamente redundantes entre regiones. Si una región que hospeda uno o más stamps deja de estar disponible, los inquilinos de esos stamps pierden el acceso hasta que la región se recupere o se migren los inquilinos a stamps de otra región. Para prepararse ante este escenario, documente sus procedimientos de recuperación, establezca las expectativas de los inquilinos y considere si los inquilinos críticos necesitan una ubicación georedundante de los stamps.

• Componentes compartidos: Es posible que tenga componentes que pueda compartir entre sellos. Por ejemplo, si tiene una aplicación de página única compartida para todos los inquilinos, impleméntela en una región y use Azure Front Door almacenamiento en caché perimetral para replicarlo globalmente.

• Gobernanza y desviación de la configuración: A medida que aumenta el número de stamps, resulta más difícil mantener la coherencia de las directivas de seguridad, las asignaciones de control de acceso basado en roles (RBAC), los controles de red, los ajustes de observabilidad y las configuraciones de los servicios. Utilice Azure Policy para tratar la gobernanza como código y valide continuamente cada stamp en busca de desviaciones para evitar comportamientos incoherentes y brechas de cumplimiento.

Cuándo usar este patrón

Use este patrón en los siguientes supuestos:

• La solución tiene límites naturales sobre la escalabilidad. Por ejemplo, si algunos componentes no pueden o no deben escalar más allá de un determinado número de clientes o solicitudes, utilice stamps para escalar horizontalmente.

• Es necesario separar determinados inquilinos de los demás. Si las preocupaciones de seguridad le impiden implementar a algunos clientes en un sello multitenant, impleméntelos en su propio sello aislado.

• Debe hospedar algunos inquilinos en distintas versiones de la solución al mismo tiempo.

• Estás construyendo aplicaciones multirregionales que necesitan dirigir los datos y el tráfico de cada cliente a una región específica.

• Usted quiere lograr resiliencia durante las interrupciones. Los sellos se ejecutan de forma independiente, por lo que, si una interrupción afecta a un solo sello, los inquilinos de otros sellos no se ven afectados. Este aislamiento limita el radio de impacto de un incidente o una interrupción.

Este patrón podría no ser adecuado cuando:

• La solución es sencilla y no es necesario escalar a un grado alto.

• ** Puede escalar su sistema horizontalmente o verticalmente dentro de una sola instancia, por ejemplo, aumentando el tamaño de la capa de aplicación o aumentando la capacidad reservada para las bases de datos y el nivel de almacenamiento.

• Necesitas replicar los datos en todas las instancias implementadas. Considere el patrón Geode para este escenario.

• Solo tiene que escalar algunos componentes y no otros. Por ejemplo, considere si puede escalar la solución particionando el almacén de datos en lugar de implementar una nueva copia de todos los componentes de la solución.

• La solución consta únicamente de contenido estático, como una aplicación de JavaScript de front-end. Entrega este contenido por una red de entrega de contenido.

Diseño de cargas de trabajo

Evalúa cómo utilizar el patrón de sellos de implementación en el diseño de una carga de trabajo para cumplir los objetivos y principios recogidos en los pilares del Marco de Arquitectura Optimizada de Azure. En la tabla siguiente se proporciona una guía sobre cómo este patrón apoya los objetivos de cada pilar.

Fundamento	Cómo apoya este patrón los objetivos de los pilares
Las decisiones de diseño de fiabilidad ayudan a que su carga de trabajo sea resiliente a fallos y garantizan que se recupere a un estado de pleno funcionamiento después de que se produzca un fallo.	Los sellos funcionan de forma independiente, por lo que un fallo en un sello está aislado y no afecta a los usuarios en otros sellos. La implementación de varios sellos en distintas regiones también proporciona una base para la planificación de la redundancia y la recuperación, lo que reduce el radio de impacto de las interrupciones regionales. - RE:05 Redundancia - RE:07 Autopreservación
La excelencia operativa ayuda a ofrecer calidad de carga de trabajo a través de procesos estandarizados y cohesión de equipos.	Este patrón admite objetivos de infraestructura inmutables, modelos de implementación avanzados y puede facilitar prácticas de implementación seguras. - OE:05 Infraestructura como código - OE:11 Procedimientos de implementación seguros
Eficiencia del rendimiento ayuda a su carga de trabajo a satisfacer eficientemente las demandas mediante optimizaciones en el escalado, los datos y el código.	Este patrón suele alinearse con las unidades de escalado definidas en la carga de trabajo. Cuando se necesita más capacidad de la que ofrece una sola unidad de escalado, se implementa otro stamp para ampliar la capacidad. - PE:05 Escalado y particionamiento

Si este patrón introduce concesiones dentro de un pilar, considérelas en relación con los objetivos de los otros pilares.

Ejemplo

En el siguiente ejemplo de arquitectura se utilizan Azure Front Door, Azure API Management y Azure Cosmos DB para dirigir el tráfico globalmente hacia una serie de ubicaciones específicas de la región.

En el extremo izquierdo, Azure Front Door (global) representa el punto de entrada. A su derecha, el centro del diagrama contiene tres niveles de enrutamiento de tráfico regional apilados verticalmente, uno para Oeste de EE. UU. 2, Este de EE. UU. y Este de Australia. En cada nivel, hay una instancia de API Management a la izquierda y una instancia de Azure Cosmos DB a la derecha, y una flecha de doble punta con la etiqueta consulta para el stamp del inquilino las conecta. Las flechas verticales de doble punta están etiquetadas con "replicación geográfica" y vinculan las tres instancias de Azure Cosmos DB. Azure Front Door se conecta mediante flechas de doble punta a las tres instancias de API Management. En el extremo derecho, cinco sellos se apilan verticalmente. Cada sello muestra su nombre y región, los inquilinos que sirve y una instancia de App Service que está emparejada con una base de datos SQL. Los sellos son Sello 1 (Oeste de EE. UU. 2) para los inquilinos A, B y C; Sello 2 (Oeste de EE. UU. 2) para el inquilino D; Sello 3 (Este de EE. UU.) para los inquilinos E, F y G; Sello 4 (Oeste de Europa) para los inquilinos H, I y J; y Sello 5 (Este de Australia) para los inquilinos K, L y M. Las flechas curvadas conducen desde las instancias de API Management a los sellos adecuados a la derecha.

Supongamos que un usuario reside en Nueva York. Stamp 3, en la región Este de EE. UU., almacena sus datos.

Si el usuario viaja a California y accede al sistema, el sistema enruta su conexión a través de la región Oeste de EE. UU. 2 porque esa región está más cercana cuando realiza la solicitud. Sin embargo, el stamp 3 debe atender la solicitud en última instancia, ya que es donde se almacenan los datos. El sistema de enrutamiento de tráfico dirige la solicitud al sello correcto.

Despliegue

Describa la infraestructura como código mediante Bicep o Terraform. Este enfoque garantiza que la implementación de cada sello sea predecible y repetible. El enfoque también reduce la posibilidad de errores humanos, como desajustes accidentales en la configuración entre los sellos.

Puede implementar actualizaciones automáticamente en todos los stamps de forma paralela. Tecnologías como Bicep pueden coordinar la implementación de la infraestructura y las aplicaciones. Como alternativa, puede decidir implementar gradualmente las actualizaciones en algunos sellos primero y, después, progresivamente a otros sellos. Considere la posibilidad de usar una herramienta de gestión de lanzamientos como Azure Pipelines o Acciones de GitHub para organizar las implementaciones en cada instancia.

Es necesario que analice cuidadosamente la topología de las suscripciones y los grupos de recursos de Azure para sus implementaciones:

• Normalmente, una suscripción contiene todos los recursos de una única solución, por lo que conviene considerar el uso de una única suscripción para todos los stamps. Sin embargo, algunos servicios de Azure imponen cuotas de toda la suscripción. Si usa este patrón para permitir un alto grado de escalado horizontal, es posible que tenga que implementar stamps en distintas suscripciones.

• Los grupos de recursos generalmente contienen componentes que comparten el mismo ciclo de vida. Si tiene previsto implementar actualizaciones en todos los stamps al mismo tiempo, puede usar un único grupo de recursos que contenga todos los componentes de todos los stamps. Usa las convenciones de nomenclatura y las etiquetas de recursos para identificar los componentes que pertenecen a cada sello. Como alternativa, si tiene previsto implementar actualizaciones en cada stamp de forma independiente, puede implementar cada stamp en su propio grupo de recursos.

Planificación de capacidad

Utilice pruebas de carga y rendimiento para determinar la carga aproximada que un sello específico puede soportar. Las métricas de carga pueden basarse en el número de clientes o inquilinos que puede hospedar un único stamp, o en las métricas que emiten los servicios del stamp. Instrumente cada sello para que pueda medir cuándo se aproxima a su capacidad y asegúrese de que puede implementar nuevos sellos rápidamente para responder a la demanda.

Enrutamiento del tráfico

El patrón Sellos de implementación funciona bien cuando se administra cada sello de forma independiente. Por ejemplo, si Contoso implementa la misma aplicación de API en varios sellos, podría utilizar el Sistema de Nombres de Dominio (DNS) para enrutar el tráfico al sello correspondiente:

• unit1.aus.myapi.contoso.com enruta el tráfico al sello unit1 dentro de una región australiana.
• unit2.aus.myapi.contoso.com enruta el tráfico al sello unit2 dentro de una región australiana.
• unit1.eu.myapi.contoso.com redirige el tráfico al stamp unit1 dentro de una región europea.

En Azure, puede hospedar estos registros en Azure DNS y usar una convención de subdominio coherente para cada región y marca. Este enfoque mantiene el enrutamiento y las operaciones predecibles.

Los clientes son responsables de conectarse al stamp correcto.

Si tu solución requiere un único punto de entrada para todo el tráfico, puedes utilizar un servicio de enrutamiento de tráfico para determinar el sello correspondiente a una solicitud, un cliente o un inquilino concretos. El servicio de enrutamiento de tráfico dirige al cliente a la dirección URL pertinente para la marca (por ejemplo, devolviendo un código de estado de respuesta HTTP 302), o actúa como proxy inverso y reenvía el tráfico a la marca pertinente sin que el cliente tenga en cuenta.

Un servicio centralizado de enrutamiento del tráfico puede ser un componente complejo de diseñar, especialmente cuando una solución se ejecuta en varias regiones. Considera la posibilidad de implementar el servicio de enrutamiento de tráfico en varias regiones, incluyendo, en su caso, todas las regiones que hospedan sellos, y sincronizar el almacén de datos que asocia a los inquilinos con los sellos. El componente de enrutamiento de tráfico podría ser una instancia del patrón Geode.

Por ejemplo, puede implementar API Management para que actúe como servicio de enrutamiento de tráfico. API Management determina el sello adecuado para una solicitud consultando los datos de una colección de Azure Cosmos DB que almacena la correspondencia entre inquilinos y sellos. A continuación, API Management establece dinámicamente la URL de back-end al servicio de API del sello correspondiente.

Para distribuir geográficamente las solicitudes y proporcionar redundancia geográfica para el servicio de enrutamiento de tráfico, implementar API Management en varias regiones y usar Azure Front Door para dirigir el tráfico a la puerta de enlace de API Management más cercana. En esta topología, Azure Front Door utiliza grupos de origen, sondeos de estado y un método de enrutamiento adecuado para redirigir las solicitudes alejándose de puertas de enlace regionales de API Management no saludables. Después, API Management enruta hacia el sello adecuado utilizando la asignación de inquilino a sello y su configuración de back-end (o grupos de back-end), incluidas las reglas de conmutación por error entre los puntos de conexión de los sellos, según sea necesario. Si su aplicación no se expone a través de HTTP o HTTPS, puede usar un equilibrador de carga de Azure entre regiones para distribuir llamadas entrantes a equilibradores de carga regionales de Azure. Use la característica de distribución global del Azure Cosmos DB para mantener actualizada la información de asignación en cada región.

Si su solución incluye un servicio de enrutamiento de tráfico, considere si actúa como una puerta de enlace y puede realizar la descarga de la puerta de enlace para los demás servicios, como la validación de tokens, la limitación de ancho de banda y la autorización.

Pasos siguientes

• Azure Front Door
• Integración de Bicep con Azure Pipelines
• Integración de plantillas de ARM para JSON con Azure Pipelines

Contributors

Microsoft mantiene este artículo. Los siguientes colaboradores escribieron este artículo.

Autor principal:

• John Downs | Ingeniero Principal de Software, Azure Patterns & Practices

Otros colaboradores:

• Federico Arambarri | Desarrollador sénior de software, Clarius Consulting
• Daniel Larsen | Ingeniero principal de clientes, FastTrack para Azure
• Ángel López | Ingeniero sénior de software, patrones y prácticas de Azure
• Paolo Salvatori | Ingeniero de clientes principal, FastTrack for Azure
• Arsen Vladimirskiy | Ingeniero de clientes principal, FastTrack for Azure

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Recursos relacionados

• Puede usar la fragmentación como una estrategia más sencilla para escalar horizontalmente la capa de datos. Los sellos fragmentan sus datos de forma implícita, pero el particionamiento no requiere un sello de implementación. Para obtener más información, consulte Patrón de particionamiento.
• Si su solución implementa un servicio de enrutamiento de tráfico, puede combinar los patrones de enrutamiento de pasarela y descarga de pasarela para aprovechar al máximo este componente.