Patrón de geoda

Implemente una colección de servicios de back-end en un conjunto de nodos geográficos, cada uno de los cuales puede atender cualquier solicitud de cualquier cliente de cualquier región. Este enfoque activo-activo distribuye el procesamiento de solicitudes en todo el mundo para mejorar la latencia y aumentar la disponibilidad.

Ocho geodas se distribuyen a través de un mapa mundial: dos en Norteamérica, dos en Asia y una en cada uno de estos lugares: América del Sur, Europa, África meridional y Australia. La leyenda distingue los nodos geográficos de los centros de datos, representados con puntos azules, y las ubicaciones perimetrales, representadas con puntos naranjas. Las líneas de red discontinuas conectan ubicaciones a través de continentes y océanos, formando una red global alrededor de los nodos geográficos.

Contexto y problema

Muchos servicios a gran escala se enfrentan a desafíos con la disponibilidad geográfica y la escala. Los diseños clásicos suelen llevar los datos al cómputo almacenando datos en un servidor SQL remoto que también procesa los datos. Dependen de ampliar la capacidad para hacer frente al crecimiento.

El enfoque clásico podría causar los siguientes problemas:

• Los usuarios de regiones distantes pueden experimentar latencia de red cuando se conectan al punto de conexión de hospedaje.
• Las ráfagas de demanda pueden sobrecargar los servicios en una sola región.
• La implementación de copias de la infraestructura de aplicaciones en varias regiones para un servicio ininterrumpido puede agregar complejidad y costo.

La infraestructura en la nube admite el enrutamiento global y la replicación de datos geográficos. Para reducir la latencia de una base de usuarios distribuida geográficamente, coloque los recursos de proceso junto a las réplicas de datos regionales que procesan. El patrón de geoda lleva la computación a los datos.

Solution

Implemente el servicio en varias ubicaciones geográficas. Cada despliegue se denomina geode. Utilice un servicio de enrutamiento global para distribuir las solicitudes según las directivas de enrutamiento y las comprobaciones de estado. Cada geode tiene acceso a un almacén de datos replicado geográficamente.

Configure la capa de datos de modo que cada nodo geográfico pueda realizar las mismas operaciones de la aplicación y cumplir los requisitos de coherencia final de la carga de trabajo. Los nodos geográficos pueden observar distintas versiones de un elemento mientras la replicación está en curso. La aplicación debe tener en cuenta el retraso de la replicación y las escrituras simultáneas, especialmente cuando las solicitudes se trasladan entre nodos geográficos.

Por ejemplo, una cuenta de Azure Cosmos DB for NoSQL configurada con varias regiones de escritura puede servir lecturas y escrituras en la región de cada nodo geográfico. Las escrituras multirregión de Azure Cosmos DB replican los datos de forma asincrónica.

En una arquitectura de stamp de implementación, cada stamp sirve a un subconjunto asignado de usuarios o inquilinos. En una arquitectura de nodos geográficos, cada nodo geográfico puede realizar las mismas operaciones de la aplicación para cualquier usuario y acceder a los datos necesarios para dichas operaciones. Ambos patrones usan varias implementaciones; elija entre ellos en función de la idoneidad de la solicitud y la ubicación de los datos.

Cada geode contiene un componente de entrada que apunta a una pila de componentes de procesamiento. Las flechas conectan la pila de procesamiento a tres componentes auxiliares y una base de datos. Las conexiones entre el procesamiento y la base de datos son bidireccionales en Geodes B, C y D y apuntan hacia la base de datos en Geode A. Un backplane de replicación gris grueso recorre la parte inferior, con flechas hasta cada base de datos y una flecha de retorno de Geode A. Los símbolos de cadena marcan Geodes A y B como emparejados y Geodes C y D como emparejados.

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

• Cada nodo geográfico consta de un conjunto de tipos de recursos, que suelen definirse en una plantilla de implementación.
• Cada geode contiene los recursos regionales necesarios para atender solicitudes sin depender del nivel de aplicación de otro geode. El enrutamiento compartido y los servicios de datos todavía pueden existir en la arquitectura.
• Las geodes están débilmente acopladas a través del enrutamiento global y un backplane de replicación. El nivel de enrutamiento dirige las solicitudes a las geodes disponibles y el nivel de datos replica las actualizaciones entre estas. La aplicación todavía necesita un modelo de consistencia adecuado y una estrategia de gestión de conflictos.

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 la computación near-edge, lo que acerca la computación al perímetro de red para reducir el tiempo de respuesta.

Elija el número y la ubicación de los nodos geográficos en función de los errores regionales que deba tolerar la carga de trabajo. La disponibilidad depende del correcto funcionamiento de las dependencias compartidas y de que los nodos geográficos restantes tengan suficiente capacidad de proceso y de base de datos para gestionar el tráfico redirigido.

Problemas y consideraciones

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

• Utilice prácticas y herramientas de DevOps para crear e implementar nodos geográficos idénticos en distintas regiones o instancias.
• Utilice el escalado automático para escalar horizontalmente la capacidad de proceso y el rendimiento de la base de datos dentro de cada nodo geográfico, teniendo en cuenta las limitaciones de backplane compartidas.
• Para una implementación de la API HTTP, Azure Front Door proporciona aceleración del tráfico a través de su red perimetral y conexiones TCP divididas.
• Utilice un almacén de datos con replicación geográfica para controlar la coherencia de los datos. En el ejemplo de escritura en varias regiones de Cosmos DB, configure el enrutamiento regional del SDK para que cada geode lea y escriba en su región de base de datos local y pueda usar regiones de reserva configuradas.
• Considere la posibilidad de utilizar recursos de proceso basados en el consumo para reducir los costos de la capacidad inactiva cuando la carga se desplaza entre nodos geográficos. Esta estrategia podría permitir la implementación de muchas geodes con una inversión adicional mínima. El ahorro depende de la carga de trabajo y el plan de hospedaje.
• Azure API Management es opcional. Colóquelo delante de las Function App de cada geode cuando necesite funcionalidades de administración de API, como la limitación de velocidad.

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

• Elija un nivel de coherencia que cumpla los requisitos de lectura cuando las solicitudes se muevan entre nodos geográficos.

  Con la coherencia de sesión de Azure Cosmos DB, devuelva el token de sesión al cliente y haga que el cliente lo incluya con solicitudes de lectura posteriores para que las garantías de leer sus propias escrituras se mantengan cuando las solicitudes se enruten a otro nodo geográfico. En las cuentas de escritura en varias regiones, use estos tokens compartidos solo para las solicitudes de lectura.

  Seleccione una directiva de resolución de conflictos para escrituras simultáneas.

• Defina los modos de fallo que la carga de trabajo debe tolerar, incluidas las interrupciones regionales y los errores de dependencia compartida. Dimensione los nodos geográficos restantes para soportar la carga máxima redirigida.

• Pruebe la conmutación por error regional y la recuperación bajo carga representativa en un entorno controlado. Incluir fallos de dependencias compartidas y failback.

• Elija si procesar datos localmente en cada región o calcular agregaciones en una geode y replicar los resultados globalmente. El procesador de la fuente de cambios de Azure Cosmos DB ofrece este control detallado mediante el concepto de contenedor de concesiones y LeaseContainerPrefix en el enlace correspondiente de Azure Functions. Cada enfoque tiene distintas ventajas e inconvenientes.

• Las geodes pueden trabajar conjuntamente mediante la fuente de cambios de Azure Cosmos DB y una plataforma de comunicación en tiempo real como SignalR. Pueden comunicarse con usuarios remotos a través de otros nodos geográficos en una topología de malla, sin necesidad de conocer ni tener en cuenta la ubicación de dichos usuarios.

• Realice un seguimiento de los componentes de la misma solicitud que se ejecutan de forma asincrónica en diferentes instancias o geodes. Supervise las dependencias compartidas, así como los recursos regionales para que pueda identificar errores correlacionados. Tanto Azure Front Door como Azure Cosmos DB se pueden integrar con Log Analytics y Azure Functions pueden usar Application Insights para la supervisión de aplicaciones.

• Proteja los puntos de entrada en cada capa de la implementación distribuida.

  • Restrinja el acceso a Azure Cosmos DB de las aplicaciones de funciones.
  • Para los orígenes públicos de aplicaciones de funciones detrás de Azure Front Door, configure restricciones de acceso que combinen la etiqueta de servicio AzureFrontDoor.Backend y un filtro de encabezado X-Azure-FDID que coincida con el identificador de su perfil de Front Door en la misma regla de permiso. Deniegue las solicitudes sin coincidencia.

  Mantenga la autenticación del cliente de la API independiente de estos controles de acceso al origen.

• Asegúrese de que cada geode puede acceder a los secretos que requiere desde Key Vault y coordinar el aprovisionamiento y la rotación de secretos compartidos.

• El rendimiento depende del número de nodos geográficos y del modelo de hospedaje de los recursos de proceso utilizado para la API de cada nodo geográfico. Debe evaluar la diferencia de costos entre agregar geodes y aumentar la capacidad de cada geode.

• Utilice recursos con redundancia de zona cuando se admitan para reducir el impacto de los errores de las zonas de disponibilidad dentro de la región de cada nodo geográfico. Elija regiones en función de la latencia, la residencia de datos, la disponibilidad del servicio y los requisitos de recuperación.

• Utiliza el árbol de decisión de equilibrio de carga para seleccionar un front-end para la API.

• En Front Door, configure la selección de origen para que coincida con el diseño activo-activo. Asigne a los geodes activos simultáneamente la misma prioridad y, a continuación, configure la sensibilidad de latencia y los pesos.

Cuándo usar este patrón

Use este patrón en los escenarios siguientes:

• Necesita una plataforma a gran escala para los usuarios distribuidos en un área geográfica amplia.
• La carga de trabajo debe seguir sirviendo solicitudes críticas durante las interrupciones regionales incluidas en su modelo de fallos.

Es posible que este patrón no sea adecuado en los escenarios siguientes:

• Su arquitectura restringe los datos o los usuarios a implementaciones concretas, por ejemplo, para cumplir los requisitos regionales de residencia de datos. Considere la posibilidad de usar stamps de implementación con enrutamiento con reconocimiento de datos cuando solo algunas implementaciones pueden servir a un usuario determinado.
• La carga de trabajo puede satisfacer sus requisitos en una sola región. Considere la posibilidad de realizar implementaciones con redundancia de zona cuando se admitan y evalúe por separado la recuperación ante desastres regional.
• El estado de sesión de la aplicación o las dependencias de datos enlazan solicitudes a una región. Es posible que las aplicaciones existentes necesiten cambios en la administración de estados, la replicación de datos y la automatización de la implementación antes de que sus implementaciones regionales puedan atender las mismas operaciones.
• Los requisitos de disponibilidad y latencia no justifican la distribución geográfica, por ejemplo, cuando la mayoría de los usuarios y datos están en una región.

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:

Fundamento	Cómo apoya este patrón los objetivos de los pilares
Las decisiones de diseño de la fiabilidad ayudan a que la carga de trabajo sea resistente a los errores y a garantizar que se recupere a un estado de pleno funcionamiento después de que se produzca un error.	Las implementaciones regionales y la replicación de datos pueden ayudar a la carga de trabajo a tolerar una o varias interrupciones regionales. - RE:05 Redundancia - Regiones y zonas de disponibilidad
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.	El procesamiento local y el acceso a datos pueden reducir la latencia de solicitudes para una base de usuarios distribuida. De este modo se reduce la latencia al eliminar el tráfico de larga distancia y porque solo se comparte la infraestructura entre los usuarios que están utilizando el mismo nodo geográfico. - PE:03 Selección de servicios

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.

Examples

• Active Directory Domain Services (AD DS) en Windows Server ilustra una variante parcial de este patrón. Los controladores de dominio grabables usan la replicación multimaestro para las particiones de directorio que hospedan. Algunas operaciones requieren un titular de roles designado de operaciones de maestro único flexible (FSMO), por lo que los controladores de dominio no son intercambiables para cada operación.

• Los siguientes servicios Azure ilustran la intercambiabilidad de solicitudes geográficas:

  • Azure Cosmos DB para NoSQL: con escrituras en varias regiones habilitadas, cada región configurada contiene todas las particiones de datos de un contenedor y puede servir lecturas y escrituras. Estas implementaciones regionales de servicio de datos ilustran los nodos geográficos de esa cuenta.
  • Azure Managed Redis: con la replicación geográfica activa, cada instancia regional vinculada puede aceptar lecturas y escrituras en la misma caché lógica.
  • Azure Front Door: cada punto de presencia de Front Door puede atender cualquier solicitud. Estas ubicaciones de borde muestran controladores de solicitudes HTTP intercambiables geográficamente.

Paso siguiente

Revise la Línea base de AKS para clústeres de varias regiones para obtener instrucciones relacionadas sobre el proceso regional activo-activo y el enrutamiento global.