Fundamento multirregional 2: entender los datos

La administración de los datos no es un problema trivial cuando se adoptan arquitecturas multirregionales. La distancia geográfica entre las regiones impone una latencia inevitable que se manifiesta como el tiempo que se tarda en replicar los datos en todas las regiones. Será necesario hacer concesiones entre la disponibilidad, la coherencia de los datos y la introducción de una mayor latencia en una carga de trabajo que utilice una arquitectura multirregional. Ya sea que utilice la replicación asíncrona o sincrónica, tendrá que modificar la aplicación para que pueda gestionar los cambios de comportamiento que impone la tecnología de replicación. Los desafíos relacionados con la consistencia y la latencia de los datos hacen que sea muy difícil convertir una aplicación existente diseñada para una sola región y convertirla en multirregión. Comprender los requisitos de coherencia de los datos y los patrones de acceso a los datos para determinadas cargas de trabajo es fundamental para sopesar las desventajas.

2.a: Comprender los requisitos de coherencia de los datos

El teorema CAP proporciona una referencia para razonar sobre las compensaciones entre la consistencia de los datos, la disponibilidad y las particiones de la red. Solo se pueden cumplir dos de estos requisitos al mismo tiempo para una carga de trabajo. Por definición, una arquitectura multirregional incluye particiones de red entre regiones, por lo que debe elegir entre disponibilidad y coherencia.

Si selecciona la disponibilidad de los datos en todas las regiones, no incurrirá en una latencia significativa durante las operaciones de escritura transaccional, ya que al depender de la replicación asíncrona de los datos comprometidos entre las regiones se reduce la coherencia entre las regiones hasta que se complete la replicación. Con la replicación asíncrona, cuando se produce un error en la región principal, existe una alta probabilidad de que las operaciones de escritura estén pendientes de replicación desde la región principal. Esto lleva a una situación en la que los datos más recientes no están disponibles hasta que se reanude la replicación y se necesita un proceso de reconciliación para gestionar las transacciones en curso que no se replicaron desde la región que sufrió la interrupción. En este escenario, es necesario comprender la lógica empresarial y crear un proceso específico para reproducir la transacción o comparar los almacenes de datos entre regiones.

Para las cargas de trabajo en las que se prefiere la replicación asíncrona, puede utilizar servicios como Amazon Aurora y Amazon DynamoDB para la replicación asíncrona entre regiones. Tanto las bases de datos globales de Amazon Aurora como las tablas globales de Amazon DynamoDB tienen métricas de CloudWatchAmazon predeterminadas que ayudan a monitorizar el retraso en la replicación. Una base de datos global de Aurora consta de una región principal en la que se escriben los datos y hasta cinco regiones secundarias de solo lectura. Las tablas globales de DynamoDB constan de tablas de réplicas multiactivas en cualquier número de regiones en las que se escriben y desde las que se leen los datos.

Diseñar la carga de trabajo para aprovechar las arquitecturas basadas en eventos es una ventaja para una estrategia multirregional, ya que significa que la carga de trabajo puede incluir la replicación asíncrona de los datos y permite reconstruir el estado mediante la reproducción de los eventos. Dado que los servicios de transmisión y mensajería almacenan los datos de carga útil de los mensajes en una sola región, un proceso de conmutación por error o recuperación regional debe incluir un mecanismo para redirigir los flujos de datos de entrada del cliente. El proceso también debe conciliar las cargas útiles en vuelo o no entregadas almacenadas en la región que sufrió la interrupción.

Si elige el requisito de coherencia de la CAP y utiliza una base de datos replicada de forma sincrónica en todas las regiones para respaldar las aplicaciones que se ejecutan simultáneamente desde varias regiones, elimina el riesgo de pérdida de datos y mantiene los datos sincronizados entre las regiones. Sin embargo, esto introduce características de latencia más altas, ya que las escrituras deben asignarse a más de una región y las regiones pueden estar a cientos o miles de millas una de la otra. Debe tener en cuenta esta característica de latencia en el diseño de la aplicación. Además, la replicación sincrónica puede suponer la posibilidad de que se produzcan errores correlacionados, ya que las escrituras deberán realizarse en más de una región para que se realicen correctamente. Si hay algún impedimento en una región, tendrás que formar quórum para que las escrituras se realicen correctamente. Por lo general, esto implica configurar la base de datos en tres regiones y establecer un quórum de dos de las tres regiones. Tecnologías como Paxos pueden ayudar a replicar y almacenar datos de forma sincrónica, pero requieren una importante inversión de los desarrolladores.

Cuando las escrituras implican una replicación sincrónica en varias regiones para cumplir con estrictos requisitos de coherencia, la latencia de escritura aumenta en un orden de magnitud. Una latencia de escritura más alta no es algo que normalmente se pueda adaptar a una aplicación sin cambios significativos, como revisar el tiempo de espera y la estrategia de reintentos de la aplicación. Lo ideal es que se tenga en cuenta al diseñar la aplicación por primera vez. Para las cargas de trabajo multirregionales en las que la replicación sincrónica es una prioridad, AWS Partner las soluciones pueden ayudar.

2.b: Comprender los patrones de acceso a los datos

Los patrones de acceso a los datos de la carga de trabajo son intensivos en lectura o escritura. Comprender esta característica de una carga de trabajo concreta le ayudará a seleccionar una arquitectura multirregional adecuada.

Para cargas de trabajo de lectura intensiva, como el contenido estático que es completamente de solo lectura, puede lograr una arquitectura multirregional activa-activa que tenga menos complejidad de ingeniería en comparación con una carga de trabajo de escritura intensiva. Ofrecer contenido estático en la periferia mediante una red de entrega de contenido (CDN) garantiza la disponibilidad al almacenar en caché el contenido más cercano al usuario final; el uso de conjuntos de funciones como la conmutación por error de origen en Amazon CloudFront puede ayudar a lograrlo. Otra opción es implementar la informática sin estado en varias regiones y usar el DNS para dirigir a los usuarios a la región más cercana para leer el contenido. Para ello, puede utilizar Amazon Route 53 con una política de enrutamiento de geolocalización.

Para las cargas de trabajo de lectura intensiva que tienen un porcentaje de tráfico de lectura mayor que de tráfico de escritura, puede utilizar una estrategia de lectura local y de escritura global. Esto significa que todas las solicitudes de escritura van a una base de datos de una región específica, los datos se replican de forma asíncrona en todas las demás regiones y las lecturas se pueden realizar en cualquier región. Este enfoque requiere una carga de trabajo para lograr una coherencia final, ya que las lecturas locales pueden quedar obsoletas como resultado del aumento de la latencia para la replicación de escrituras entre regiones.

Las bases de datos globales de Aurora pueden ayudar a aprovisionar réplicas de lectura en una región en espera que solo puede gestionar todo el tráfico de lectura de forma local y a aprovisionar un único almacén de datos principal en una región específica para gestionar el tráfico de escritura. Los datos se replican de forma asíncrona desde la base de datos principal a las bases de datos en espera (réplicas de lectura), y las bases de datos en espera se pueden convertir en principales si es necesario realizar una conmutación por error de las operaciones a la región en espera. También puede utilizar DynamoDB en este enfoque. Las tablas globales de DynamoDB pueden aprovisionar tablas de réplica en todas las regiones, cada una de las cuales puede escalarse para admitir cualquier volumen de tráfico de lectura o escritura local. Cuando una aplicación escribe datos en una réplica de tabla de una región, DynamoDB propaga automáticamente la operación de escritura en el resto de las réplicas de tablas de las otras regiones de . Con esta configuración, los datos se replican de forma asíncrona desde una región principal definida a las tablas de réplica de las regiones en espera. Las réplicas de tablas de cualquier región siempre aceptan escrituras, por lo que la promoción de una región en espera a la categoría principal se gestiona a nivel de aplicación. Una vez más, la carga de trabajo tiene que ser coherente con el tiempo, por lo que podría ser necesario volver a escribirla si no se diseñó para ello desde el principio.

Para las cargas de trabajo con un uso intensivo de escritura, se debe seleccionar una región principal y se debe incorporar a la carga de trabajo la capacidad de realizar la conmutación por error a una región en espera. En comparación con un enfoque activo-activo, un enfoque de reserva primaria tiene ventajas adicionales. Esto se debe a que, en el caso de una arquitectura activa-activa, es necesario reescribir la carga de trabajo para gestionar el enrutamiento inteligente a Regions, establecer la afinidad de las sesiones, garantizar la idempotencia de las transacciones y gestionar los posibles conflictos.

La mayoría de las cargas de trabajo que utilizan un enfoque multirregional para mejorar la resiliencia no requieren un enfoque activo-activo. Puede utilizar una estrategia de fragmentación para aumentar la resiliencia al limitar el alcance del impacto de una discapacidad en la base de clientes. Si puede fragmentar una base de clientes de forma eficaz, puede seleccionar diferentes regiones principales para cada fragmento. Por ejemplo, puede dividir los clientes para que la mitad de los clientes estén alineados con la región uno y la otra mitad estén alineados con la región dos. Al tratar las regiones como células, puede crear un enfoque de células multirregionales, lo que reduce el alcance del impacto en su carga de trabajo. Para obtener más información, consulte la presentación de AWS re:Invent sobre este enfoque.

Puede combinar el enfoque de fragmentación con un enfoque principal en espera para proporcionar capacidades de conmutación por error a los fragmentos. Deberá incorporar a la carga de trabajo un proceso de conmutación por error probado, así como un proceso de reconciliación de datos, a fin de garantizar la coherencia transaccional de los almacenes de datos tras la conmutación por error. Estos aspectos se describen con mayor detalle más adelante en esta guía.

Guía clave

• Existe una alta probabilidad de que las escrituras pendientes de replicación no se envíen a la región en espera si se produce un error. Los datos no estarán disponibles hasta que se reanude la replicación (suponiendo que la replicación sea asíncrona).

• Como parte de la conmutación por error, se necesitará un proceso de reconciliación de datos para garantizar que los almacenes de datos que utilizan la replicación asincrónica mantengan un estado coherente desde el punto de vista de las transacciones. Esto requiere una lógica empresarial específica y no es algo que deba gestionar el propio almacén de datos.

• Cuando se requiere una coherencia sólida, las cargas de trabajo deberán modificarse para tolerar la latencia requerida de un almacén de datos que se replica de forma sincrónica.