Patrón de stamps de implementación

El patrón de stamp de implementación implica el aprovisionamiento, la administración y la supervisión de un grupo heterogéneo de recursos para hospedar y operar varias cargas de trabajo o inquilinos. Cada copia individual se denomina marca o, a veces, una unidad de servicio, una unidad de escalado o una celda. En un entorno multiinquilino, cada stamp o unidad de escalado puede atender un número predefinido de inquilinos. Se pueden implementar varios stamps para escalar la solución casi linealmente y atender un número creciente de inquilinos. Este enfoque puede mejorar la escalabilidad de su solución al permitirle implementar instancias en varias regiones y separar los datos de los clientes.

Contexto y problema

Al hospedar una aplicación en la nube, es importante tener en cuenta el rendimiento y la confiabilidad de la aplicación. Si hospeda una sola instancia de su solución, puede que le afecten las siguientes limitaciones:

• Límites de escala. La implementación de una sola instancia de su aplicación podría dar lugar a límites de escalado naturales. Por ejemplo, podría utilizar servicios que establezcan límites con respecto al número de conexiones entrantes, los nombres de host, los sockets TCP u otros recursos.
• Escalado o costos no lineales. Es posible que algunos de los componentes de la solución no proporcionen escalabilidad lineal con respecto al número de solicitudes o a la cantidad de datos. En lugar de ello, puede producirse una disminución repentina del rendimiento o un aumento de los costos una vez que se haya alcanzado un umbral determinado. Por ejemplo, tal vez utilice una base de datos y observe que el costo marginal de agregar capacidad (escalabilidad vertical) se vuelve prohibitivo y que la escalabilidad horizontal es una estrategia más rentable.
• Separación de los clientes. En ocasiones, puede que necesite mantener los datos de algunos clientes separados de los de otros. También es posible que algunos clientes requieran más recursos del sistema que otros para atender sus solicitudes y que se plantee agruparlos en diferentes conjuntos de infraestructura.
• Administración de instancias de inquilino único y multiinquilino. Tal vez tenga clientes de gran tamaño que necesiten sus propias instancias independientes de la solución. Además, es posible que tenga un grupo de clientes más pequeño que pueden compartir una implementación multiinquilino.
• Requisitos complejos de implementación. En ocasiones, puede ser necesario actualizar el servicio de forma controlada e implementar actualizaciones en diferentes subconjuntos de la base de clientes en distintos momentos.
• Frecuencia de actualización. Quizás tenga clientes que acepten de buen grado las actualizaciones frecuentes del sistema, mientras que otros pueden ser reticentes al riesgo y preferir que el sistema que atiende sus solicitudes se actualice con poca frecuencia. En este caso, tendría sentido implementar esos clientes en entornos aislados.
• Restricciones geográficas o geopolíticas. Para diseñar una arquitectura de baja latencia o a fin de cumplir los requisitos de soberanía de datos, puede implementar algunos de sus clientes en regiones específicas.

Estas limitaciones suelen aplicarse a proveedores de software independientes (ISV) que crean software como servicio (SaaS), que se diseñan con frecuencia para ser multiinquilino. Sin embargo, también se pueden aplicar las mismas limitaciones a otros escenarios.

Solution

Para evitar estos problemas, considere la posibilidad de agrupar recursos en unidades de escalado y aprovisionar varias copias de los sellos. Cada unidad de escalado hospedará y servirá un subconjunto de los clientes. Los stamps funcionan de forma independiente entre sí y se pueden implementar y actualizar por separado. Una sola región geográfica puede contener un solo stamp, o bien varios stamps para proporcionar escalabilidad horizontal en la región. Los stamps contienen un subconjunto de clientes.

Los stamps de implementación resultan idóneos si su solución utiliza una infraestructura como servicio (IaaS), una plataforma como servicio (PaaS) o una combinación de ambos. Normalmente, las cargas de trabajo de IaaS requieren más intervención del administrador para obtener escalabilidad, por lo que este patrón puede ser útil para administrar un número elevado de cargas de trabajo de IaaS con el fin de facilitar la escalabilidad horizontal.

Las etiquetas se pueden usar para implementar anillos de implementación. Si diferentes clientes desean recibir actualizaciones del servicio con una frecuencia diferente, se pueden agrupar en stamps diferentes. De este modo, cada stamp se podría actualizar con una frecuencia diferente.

Dado que los stamps se ejecutan independientemente entre sí, los datos se particionan implícitamente. Además, un solo stamp puede particionarse más para facilitar su escalabilidad y elasticidad.

Muchos servicios de Azure usan internamente el patrón de estampillado de implementación, incluidos App Service, Azure Stack y Azure Storage.

Los sellos de implementación están relacionados con, pero son distintos de los geodes. En una arquitectura de stamps de implementación, se implementan múltiples instancias independientes del sistema que contienen un subconjunto de los clientes y usuarios. En los nodos geográficos, todas las instancias pueden atender las solicitudes de cualquier usuario, pero esta arquitectura suele ser más compleja de diseñar y compilar. También puede integrar los dos patrones en una misma solución. El enfoque de enrutamiento del tráfico que se describe a continuación en este artículo es un ejemplo de este escenario híbrido.

Deployment

Dada la complejidad de implementar copias idénticas de los mismos componentes, es fundamental seguir los procedimientos recomendados de DevOps para garantizar unos resultados óptimos al utilizar este patrón. Considere la posibilidad de describir la infraestructura como código, como el uso de Bicep, plantillas json de Azure Resource Manager (plantillas de ARM),Terraform y scripts. Con este enfoque, podrá garantizar una implementación predecible y repetible de los stamps. El enfoque también reduce la posibilidad de cometer errores humanos (por ejemplo, discrepancias imprevistas en la configuración de los stamps).

Puede implementar actualizaciones automáticamente en todas las instancias en paralelo, en cuyo caso puede considerar tecnologías como Bicep o plantillas de Resource Manager para coordinar la implementación de su infraestructura y de sus aplicaciones. Como alternativa, puede optar por implementar las actualizaciones de forma gradual. Primero en algunos stamps y, posteriormente, en otros. Considere la posibilidad de usar una herramienta de gestión de lanzamientos como Azure Pipelines o GitHub Actions para organizar las implementaciones en cada instancia. Para más información, consulte:

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

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

• Una suscripción suele contener todos los recursos de una sola solución, por lo que en general debería plantearse utilizar una sola suscripción para todos los stamps. Sin embargo, algunos servicios de Azure imponen cuotas para todas las suscripciones. Por lo tanto, si usa este patrón para permitir un grado elevado de escalabilidad horizontal, considere la posibilidad de implementar stamps en diferentes suscripciones.
• Para implementar componentes que tienen el mismo ciclo de vida, suelen utilizarse grupos de recursos. Si tiene previsto implementar actualizaciones para todos sus stamps al mismo tiempo, puede utilizar un solo grupo de recursos que contenga todos los componentes de todos los stamps, además de emplear etiquetas y convenciones de nomenclatura de recursos para identificar los componentes pertenecientes a cada stamp. Como alternativa, si tiene previsto implementar actualizaciones para cada stamp por separado, implemente cada stamp dentro de su propio grupo de recursos.

Planeamiento de la capacidad

Utilice pruebas de carga y rendimiento para determinar la carga aproximada que un stamp específico puede admitir. Las métricas de carga pueden basarse en el número de clientes o inquilinos que un solo stamp admite, o bien en las métricas de los servicios que los componentes del stamp generan. Asegúrese de que dispone de herramientas suficientes para determinar el momento en que un stamp concreto está llegando a su límite de capacidad para poder implementar nuevos stamps rápidamente a fin de responder a la demanda.

Enrutamiento del tráfico

El patrón de stamps de implementación funciona bien cuando cada stamp se trata de forma independiente. Por ejemplo, si Contoso implementa la misma aplicación de API en varios stamps, podrían utilizar DNS para enrutar el tráfico al stamp pertinente:

• unit1.aus.myapi.contoso.com enruta el tráfico al stamp unit1 en una región de Australia.
• unit2.aus.myapi.contoso.com enruta el tráfico al stamp unit2 en una región de Australia.
• unit1.eu.myapi.contoso.com enruta el tráfico al stamp unit1 en una región de Europa.

Los clientes son responsables de conectarse al stamp adecuado.

Si se requiere un único punto de entrada para todo el tráfico, es posible usar un servicio de enrutamiento del tráfico para resolver el stamp asociado a una solicitud, un cliente o un inquilino determinados. El servicio de enrutamiento del tráfico dirige el cliente a la dirección URL pertinente para el stamp (por ejemplo, mediante un código de estado de respuesta HTTP 302) o puede funcionar como un proxy inverso y reenviar el tráfico al stamp pertinente sin que el cliente sea consciente.

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. Considere la posibilidad de implementar el servicio de enrutamiento del tráfico en varias regiones (incluidas todas las regiones en las que se hayan implementado los stamps) y, posteriormente, comprobar que el almacén de datos (la asignación de inquilinos a stamps) esté sincronizado. El componente de enrutamiento de tráfico podría ser una instancia del patrón geode.

Por ejemplo, Azure API Management se puede implementar para adoptar el rol de servicio de enrutamiento del tráfico. API Management puede determinar el stamp adecuado para una solicitud al examinar los datos de una colección de Azure Cosmos DB que almacena la asignación entre inquilinos y stamps. Posteriormente, API Management puede establecer de forma dinámica la dirección URL de back-end en el servicio de API del stamp pertinente.

Para habilitar la distribución geográfica de solicitudes y la redundancia geográfica del servicio de enrutamiento del tráfico, API Management se puede implementar en varias regiones. También se puede usar Azure Front Door para dirigir el tráfico a la instancia más próxima. Front Door se puede configurar con un grupo de back-end, lo que permite que las solicitudes se dirijan a la instancia de API Management más cercana disponible. Si la aplicación no se expone a través de HTTP/S, puede usar una instancia de Azure Load Balancer entre regiones para distribuir las llamadas entrantes a instancias regionales de Azure Load Balancer. Las características de distribución global de Azure Cosmos DB se pueden utilizar para mantener actualizada la información de asignación en cada región.

Si se incluye un servicio de enrutamiento de tráfico en la solución, considere si actúa como puerta de enlace y, por tanto, podría realizar la descarga de la puerta de enlace para los demás servicios, como la validación de tokens, la limitación y la autorización.

Ejemplo de arquitectura de enrutamiento del tráfico

Considere la siguiente arquitectura de enrutamiento de tráfico de ejemplo, que usa Azure Front Door, Azure API Management y Azure Cosmos DB para el enrutamiento del tráfico global y, a continuación, una serie de marcas específicas de la región:

Supongamos que un usuario reside normalmente en Nueva York. Sus datos se almacenan en el stamp 3, en la región Este de EE. UU.

Si el usuario viaja a California y, a continuación, accede al sistema, es probable que su conexión se enruta a través de la región Oeste de EE. UU. 2, ya que es lo más cercano a su ubicación geográfica cuando realiza la solicitud. Sin embargo, la solicitud tiene que ser atendida en última instancia por el stamp 3, ya que es donde se almacenan sus datos. El sistema de enrutamiento del tráfico garantiza que la solicitud se enruta a la marca correcta.

Problemas y consideraciones

A la hora de decidir cómo implementar este patrón, debe considerar los siguientes puntos:

• Proceso de implementación. Al implementar varios stamps, es muy recomendable utilizar procesos de implementación automatizados y completamente repetibles. Considere la posibilidad de usar bicep, plantillas de ARM JSON o módulos de Terraform para definir mediante declaración los stamps y para mantener las definiciones coherentes.
• Operaciones de estampado cruzado. Cuando la solución se implementa por separado en varios stamps, responder a preguntas como "¿cuántos clientes tenemos en todos los stamps?" puede ser difícil. Tal vez sea necesario ejecutar consultas en cada stamp y en los resultados agregados. Como alternativa, puede hacer que todos los stamps publiquen datos en un almacén de datos centralizado para crear informes consolidados.
• Especificación de directivas de escalabilidad horizontal. Los stamps tienen una capacidad limitada, que se puede definir con ayuda de una métrica de proxy, como el número de inquilinos que se pueden implementar en el stamp. Es importante supervisar la capacidad disponible y la capacidad en uso para cada stamp, además de implementar proactivamente otros stamps para dirigirles nuevos inquilinos.
• Número mínimo de stamps. Al usar el patrón de stamp de implementación, es aconsejable implementar al menos dos stamps de la solución. Si implementa un único stamp, es fácil codificar de forma rígida y accidental suposiciones en el código o la configuración que no se aplicarán al escalar horizontalmente.
• Cost. El patrón de stamps de implementación permite implementar varias copias del componente de infraestructura, lo que probablemente implicará un aumento sustancial del costo de administración de la solución.
• Mover inquilinos entre stamps. A medida que cada stamp se implemente y administre de forma independiente, puede resultar complicado mover inquilinos de un stamp a otro. La aplicación necesitará lógica personalizada para enviar la información sobre un cliente determinado a otro stamp. Después, hay que quitar la información del inquilino del stamp original. Este proceso puede requerir un backplane para la comunicación entre stamps, lo cual aumentará aún más la complejidad de la solución global.
• Enrutamiento del tráfico. Como se describió anteriormente en este artículo, enrutar el tráfico al stamp adecuado para una solicitud determinada puede exigir un componente adicional para resolver los inquilinos en los stamps. Es posible que este componente, a su vez, tenga que ofrecer una alta disponibilidad.
• Componentes compartidos. Tal vez tenga algunos componentes que se pueden compartir entre stamps. Por ejemplo, si tiene una aplicación de página única compartida para todos los inquilinos, considere la posibilidad de implementarla en una región y usar Azure CDN para replicarla globalmente.

Cuándo usar este patrón

Este patrón es útil en los casos siguientes:

• Límites naturales de escalabilidad. Por ejemplo, si algunos componentes no pueden o no deben escalarse por encima de un número determinado de clientes o solicitudes, considere la posibilidad de obtener escalabilidad horizontal por medio de stamps.
• Necesidad de separar unos inquilinos de otros. Si tiene clientes que no se pueden implementar en un stamp multiinquilino con otros clientes por motivos de seguridad, se pueden implementar en su propio stamp aislado.
• Necesidad de mantener simultáneamente algunos inquilinos en diferentes versiones de la solución.
• Aplicaciones de varias regiones en las que los datos y el tráfico de cada inquilino deben dirigirse a una región específica.
• Objetivo de lograr resistencia frente a las interrupciones. Dado que los stamps son independientes, si una interrupción afecta a un solo stamp, los inquilinos implementados en otros stamps no deberían verse afectados. Este aislamiento contribuye a limitar el alcance de un incidente o una interrupción.

Este patrón no es adecuado para:

• Soluciones sencillas que no requieren un grado elevado de escalabilidad.
• Sistemas que facilitan la escalabilidad horizontal o vertical en una sola instancia. Por ejemplo, al aumentar el tamaño de la capa de la aplicación o aumentar la capacidad reservada para las bases de datos y la capa de almacenamiento.
• Soluciones en las que los datos se deben replicar para todas las instancias implementadas. Considere el patrón de geode para este escenario.
• Soluciones en las que solo es necesario escalar algunos componentes, no todos. Por ejemplo, valore si su solución se puede escalar mediante el particionamiento del almacén de datos, en lugar de implementar una nueva copia de todos los componentes de la solución.
• Soluciones que únicamente constan de contenido estático, como una aplicación front-end de JavaScript. Considere la posibilidad de almacenar este contenido en una cuenta de almacenamiento y usar Azure CDN.

Diseño de cargas de trabajo

El arquitecto debe evaluar cómo se puede usar el patrón de las marcas de implementación en el diseño de su carga de trabajo para abordar los objetivos y principios tratados en los pilares del Marco de la Well-Architected de Azure. Por ejemplo:

Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.

Tecnologías auxiliares

• Infraestructura como código. Por ejemplo, Bicep, plantillas de Resource Manager, CLI de Azure, Terraform, PowerShell o Bash.
• Azure Front Door, que enruta el tráfico a un stamp concreto o a un servicio de enrutamiento del tráfico.

Contributors

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• John Downs | Ingeniero principal de software, Patrones y prácticas de Azure

Otros colaboradores:

• 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

• El particionamiento es un enfoque más sencillo que se puede usar para escalar horizontalmente la capa de datos. Los stamps fragmentan implícitamente sus datos, pero la fragmentación no requiere un Sello de Despliegue. Para obtener más información, consulte el patrón de particionamiento.
• Si se implementa un servicio de enrutamiento de tráfico, los patrones enrutamiento de puerta de enlace y enrutamiento de descarga se pueden usar juntos para aprovechar al máximo este componente.