Patrón de nodo geográfico

El patrón de nodo geográfico implica la implementación de una colección de servicios de back-end en un conjunto de nodosgeográficos, en el que cada uno de ellos puede atender las solicitudes de cualquier cliente en cualquier región. Este patrón permite atender las solicitudes con un estilo activo-activo, mejorando la latencia y aumentando la disponibilidad al distribuir el procesamiento de las solicitudes en todo el mundo.

Contexto y problema

Muchos servicios a gran escala tienen desafíos específicos en cuanto a la disponibilidad geográfica y la escala. A menudo, los diseños clásicos traen los datos al procesamiento mediante su almacenamiento en un servidor de SQL Server remoto que actúa como nivel de proceso para esos datos, confiando en el escalado vertical para el crecimiento.

El enfoque clásico puede presentar una serie de desafíos:

• Problemas de latencia de red para los usuarios que proceden del otro lado del mundo con la conexión al punto de conexión de hospedaje
• Administración del tráfico durante los picos de demanda que puedan sobrecargar los servicios de una sola región
• El costo excesivo de la implementación de copias de la infraestructura de las aplicaciones en varias regiones para un servicio ininterrumpido

La infraestructura actual en la nube ha evolucionado para habilitar el equilibrio de carga geográfico de los servicios de front-end, a la vez que permite la replicación geográfica de los servicios de back-end. En cuanto a disponibilidad y rendimiento, es bueno tener los datos más cerca del usuario. Cuando los datos se distribuyen geográficamente entre una base de usuarios lejanos, los almacenes de datos distribuidos geográficamente también se deben situar junto con los recursos de proceso que procesan esos datos. El patrón de nodo geográfico trae el procesamiento a los datos.

Solución

Implemente el servicio en varias implementaciones satélite repartidas por todo el mundo, cada una de las cuales se llama nodo geográfico. El patrón de nodo geográfico aprovecha las características principales de Azure para enrutar el tráfico por la ruta más corta a un nodo geográfico cercano, lo que mejora la latencia y el rendimiento. Cada nodo geográfico está detrás de un equilibrador de carga global y usa un servicio de lectura y escritura con replicación geográfica como Azure Cosmos DB para hospedar el plano de datos, lo que garantiza la coherencia de los datos entre los nodos geográficos. Los servicios de replicación de datos garantizan que los almacenes de datos sean idénticos en los nodos geográficos, por lo que es posible atender todas las solicitudes desde todos los nodos geográficos.

La diferencia principal entre un stamp de implementación y un nodo geográfico es que los nodos geográficos nunca existen de forma aislada. Siempre debería haber más de un nodo geográfico en una plataforma de producción.

Los nodos geográficos tienen las siguientes características:

• Constan de una colección de tipos dispares de recursos que a menudo se definen en una plantilla.
• No tienen dependencias fuera de la superficie del nodo geográfico y son independientes. Ningún nodo geográfico depende de otro para operar y, si uno deja de funcionar, los demás continúan en funcionamiento.
• Están acoplados de forma flexible mediante una red perimetral y un backplane de replicación. Por ejemplo, puede usar Azure Traffic Manager o Azure Front Door como front-end de los nodos geográficos, mientras que Azure Cosmos DB puede actuar en el backplane de replicación. Los nodos geográficos no son lo mismo que los clústeres ya que los nodos comparten un backplane de replicación por lo que la plataforma se encarga de los problemas de cuórum.

El patrón de nodo geográfico se utiliza en arquitecturas de macrodatos que usan hardware estándar para procesar los datos localizados en la misma máquina y MapReduce para consolidar los resultados entre máquinas. Otro uso es el proceso casi perimetral, que hace que el procesamiento esté más cerca de la inteligencia perimetral de la red para reducir el tiempo de respuesta.

Los servicios pueden usar este patrón en decenas o centenares de nodos geográficos. Además, la resistencia de toda la solución aumenta con cada nodo geográfico que se agrega, ya que cualquier nodo geográfico puede asumir las solicitudes si una interrupción regional deja a uno o más nodos geográficos sin conexión.

También es posible ampliar las técnicas de disponibilidad local, como las zonas de disponibilidad o las regiones emparejadas, con el patrón de nodo geográfico para conseguir una disponibilidad global. Esto aumenta la complejidad, pero resulta útil si la arquitectura está determinada por un motor de almacenamiento como Blob Storage que solo se puede replicar en una región emparejada. Puede implementar nodos geográficos en una superficie interior a la zona, zonal o regional, teniendo en cuenta las restricciones de regulación o de latencia.

Problemas y consideraciones

Utilice las siguientes técnicas y tecnologías para implementar este patrón:

• Herramientas y procedimientos de DevOps modernos para producir e implementar rápidamente nodos geográficos idénticos en un gran número de regiones o instancias.
• Escalado automático para escalar horizontalmente las instancias de proceso y de rendimiento de base de datos dentro de un nodo geográfico. Cada nodo geográfico se escala horizontalmente de forma individual, adaptándose a las restricciones habituales del backplane.
• Un servicio de front-end como Azure Front Door, que realiza una aceleración del contenido dinámico, con división de TCP y enrutamiento de difusión por proximidad.
• Un almacén de datos con replicación, como Azure Cosmos DB, para controlar la coherencia de los datos.
• Tecnologías sin servidor siempre que sea posible, para reducir el costo de una implementación siempre activa, especialmente cuando la carga se reequilibra con frecuencia en todo el mundo. Esta estrategia permite implementar muchos nodos geográficos con una mínima inversión adicional. Las tecnologías sin servidor y la facturación basada en el consumo reducen los costos de las implementaciones duplicadas distribuidas geográficamente.
• API Management no es necesario para implementar el patrón de diseño, pero se puede agregar a cada nodo geográfico que se enfrenta a la aplicación Función de Azure de la región para proporcionar una capa de API más sólida, lo que permite la implementación de funcionalidades adicionales, como la limitación de velocidad, por ejemplo.

Tenga en cuenta los puntos siguientes al decidir cómo implementar este patrón:

• Elija si desea procesar los datos localmente en cada región o distribuir las agregaciones en un único nodo geográfico y replicar el resultado en todo el mundo. El procesador de la fuente de cambios de Azure Cosmos DB ofrece este control detallado mediante el concepto de contenedor de concesiones y el elemento leasecollectionprefix del enlace de Azure Functions correspondiente. Cada enfoque tiene distintas ventajas e inconvenientes.
• Los nodos geográficos pueden funcionar conjuntamente, mediante la fuente de cambios de Azure Cosmos DB y una plataforma de comunicación en tiempo real como SignalR. Los nodos geográficos se pueden comunicar con los usuarios remotos mediante otros nodos geográficos de un patrón de malla, sin necesidad de conocer ni de preocuparse de dónde se encuentran esos usuarios.
• Este modelo de diseño desacopla implícitamente todo, lo que da lugar a una arquitectura desacoplada y altamente distribuida. Tenga en cuenta cómo realizar un seguimiento de los distintos componentes de la misma solicitud, ya que se podrían ejecutar de forma asincrónica en distintas instancias. Una estrategia de supervisión adecuada es fundamental. Tanto Azure Front Door como Azure Cosmos DB se pueden integrar fácilmente con Log Analytics, y Azure Functions se debe implementar junto con Application Insights para proporcionar un sistema de supervisión sólido en cada componente de la arquitectura.
• Las implementaciones distribuidas tienen un mayor número de secretos y puntos de entrada que requieren medidas de seguridad de propiedades. Key Vault proporciona una capa segura para la administración de secretos, y cada capa de la arquitectura de API se debe proteger correctamente para que el único punto de entrada de la API sea el servicio front-end como Azure Front Door. Azure Cosmos DB debe restringir el tráfico a aplicaciones de funciones de Azure y las aplicaciones de funciones a Azure Front Door mediante Microsoft Entra ID o prácticas como la restricción de IP.
• El rendimiento se ve afectado drásticamente por el número de nodos geográficos que se implementan y los planes de App Service específicos que se aplican a la tecnología de API en cada nodo geográfico. La implementación de nodos geográficos adicionales o el paso a los niveles Premium conllevan mayores costos por la memoria y el proceso adicionales, pero no por transacción. Considere la posibilidad de probar la carga de la arquitectura de API una vez implementada y contrastar el aumento del número de nodos geográficos con el incremento del plan de tarifa a fin de utilizar el modelo más rentable para sus necesidades.
• Determine los requisitos de disponibilidad de los datos. Azure Cosmos DB tiene marcas opcionales para habilitar la escritura en varias regiones, las zonas de disponibilidad, etc. Estos aumentan la disponibilidad de la instancia de Azure Cosmos DB y crean una capa de datos más resistente, pero que conlleva costos adicionales.
• Azure ofrece una variedad de equilibradores de carga que proporcionan funcionalidades diferentes para la distribución del tráfico. Utilice el árbol de decisión a fin de ayudar a seleccionar la opción correcta para el front-end de la API.

Cuándo usar este patrón

Use este patrón:

• Para implementar una plataforma a gran escala con usuarios distribuidos en un área amplia.
• Para cualquier servicio que requiera características extremas de disponibilidad y resistencia, ya que los servicios basados en el patrón de nodo geográfico pueden sobrevivir a la pérdida de varias regiones de servicio al mismo tiempo.

Este patrón podría no ser adecuado en los siguientes casos:

• Arquitecturas que tienen restricciones para que todos los nodos geográficos no sean iguales en cuanto al almacenamiento de datos. Por ejemplo, puede haber requisitos de residencia de datos, una aplicación que necesite mantener el estado temporal para una sesión determinada o una ponderación pesada de las solicitudes hacia una sola región. En este caso, considere la posibilidad de usar stamps de implementación, en combinación con un plano de enrutamiento global que sea consciente del lugar en que se encuentran los datos de un usuario, como el componente de enrutamiento de tráfico descrito en el patrón de stamps de implementación.
• Situaciones en las que no se requiere ninguna distribución geográfica. En su lugar, considere las zonas de disponibilidad y las regiones emparejadas para la agrupación en clústeres.
• Situaciones en las que se necesita rediseñar una plataforma heredada. Este patrón solo funciona para el desarrollo nativo en la nube y la adaptación puede ser difícil de realizar.
• Arquitecturas y requisitos simples, en los que la redundancia geográfica y la distribución geográfica no son necesarias ni ventajosas.

Diseño de cargas de trabajo

Un arquitecto debe evaluar cómo se puede usar el patrón Geode en el diseño de su carga de trabajo para abordar los objetivos y principios descritos en los pilares del Marco de buena arquitectura 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.

Ejemplos

• Active Directory en Windows implementa una variante temprana de este patrón. La replicación principal múltiple significa que, en teoría, todas las actualizaciones y solicitudes se pueden servir desde todos los nodos con capacidad de servicio, pero los roles de operaciones de maestro único flexible (FSMO) significan que todos los nodos geográficos no son iguales.
• El acelerador de patrones de nodos geográficos de GitHub presenta este patrón de diseño en la práctica y está diseñado para ayudar a los desarrolladores a implementarlo con API del mundo real.
• Una aplicación de ejemplo de preguntas y respuestas en GitHub muestra este patrón de diseño en la práctica.