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 stamp. En ocasiones, también se conoce como unidad de servicio, unidad de escalado o 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 escalado. 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.

Solución

Para evitar estos problemas, considere la posibilidad de agrupar recursos en unidades de escalado y aprovisionar varias copias de los stamps. Cada unidad de escalado hospedará y atenderá un subconjunto de los inquilinos. 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.

Los stamps 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 por separado, los datos se particionan de forma implícita. Además, un solo stamp puede particionarse más para facilitar su escalabilidad y elasticidad.

El patrón de stamps de implementación se usa internamente en muchos servicios de Azure, como App Service, Azure Stack y Azure Storage.

Los stamps de implementación están relacionados con los nodos geográficos, pero son conceptos diferentes. 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.

Implementación

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. Valore la posibilidad de describir la infraestructura como código (por ejemplo, mediante Bicep, plantillas de Azure Resource Manager, 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).

Las actualizaciones se pueden implementar de forma automática y simultánea en todos los stamps. En este caso, puede utilizar tecnologías como Bicep o las plantillas de Resource Manager para coordinar la implementación de la infraestructura y las 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 administración de versiones como Azure Pipelines o Acciones de GitHub para organizar las implementaciones en cada stamp. 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.

Planificación de 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 del tráfico puede hacer esto mediante una instancia del patrón de nodos geográficos.

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. El servicio Front Door puede configurarse con un grupo de back-end, lo que permite dirigir las solicitudes a la instancia de API Management más próxima que esté 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 las instancias de Azure Load Balancer regionales. 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 del tráfico en la solución, tenga en cuenta si funciona como puerta de enlace y, por tanto, puede efectuar la descarga de puerta de enlace para otros servicios como la validación de tokens, la limitación de ancho de banda 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. Valore la posibilidad de utilizar Bicep, plantillas de Resource Manager o módulos de Terraform para definir los stamps mediante declaración y mantener coherentes las definiciones.
• Operaciones entre stamps. 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.
• El costo. 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 una sola página compartida para todos los inquilinos, puede 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 en los casos siguientes:

• 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. Tenga en cuenta el patrón de nodos geográficos en 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. Puede almacenar dicho contenido en una cuenta de almacenamiento y utilizar 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 de apoyo

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

Ejemplo

En el ejemplo siguiente se implementan varios stamps de una solución PaaS sencilla, junto con un servicio de aplicaciones y SQL Database en cada stamp. Aunque los stamps se pueden configurar en cualquier región que admita los servicios implementados en la plantilla, con fines ilustrativos, esta plantilla implementa dos stamps en la región Oeste de EE. UU. 2 y un stamp adicional en la región Oeste de Europa. Dentro de un stamp, el servicio de aplicaciones recibe su propio nombre de host de DNS público y puede recibir conexiones al margen de los demás stamps.

Haga clic en el vínculo siguiente para implementar la solución.

Ejemplo de enfoque de enrutamiento del tráfico

El ejemplo siguiente muestra una implementación de una solución de enrutamiento del tráfico que se podría usar con un conjunto de stamps de implementación para una hipotética aplicación de API. Para permitir la distribución geográfica de las solicitudes entrantes, Front Door se implementa junto con varias instancias de API Management en el nivel de consumo. Cada instancia de API Management lee el identificador de inquilino de la dirección URL de solicitud y, a continuación, busca el stamp pertinente para la solicitud de un almacén de datos de Azure Cosmos DB distribuido geográficamente. A continuación, la solicitud se reenvía al stamp de back-end pertinente.

Haga clic en el vínculo siguiente para implementar la solución.

Colaboradores

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

Autor principal:

• John Downs | Administrador principal del programa

Otros colaboradores:

• Daniel Larsen | Ingeniero de clientes principal, FastTrack for Azure
• Angel Lopez | Ingeniero de software sénior, Patrones y prácticas de Azure
• Paolo Salvatori | Ingeniero de clientes principal, FastTrack for Azure
• Arsen Vladimirskiy | Principal Customer Engineer, 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 particionan implícitamente sus datos, pero el particionamiento no requiere un stamp de implementación. Para más información, consulte el Sharding pattern(Patrón de particionamiento).
• Si se implementa un servicio de enrutamiento del tráfico, los patrones de enrutamiento de puerta de enlace y descarga de puerta de enlace se pueden usar juntos para optimizar el uso de este componente.