DynamoDB Global Tables: la replicación multirregión explicada

Una tabla global es una sola tabla de DynamoDB replicada a través de múltiples regiones de AWS, donde cada réplica es escribible. DynamoDB las mantiene sincronizadas automáticamente — obtienes lecturas y escrituras locales de baja latencia en cada región más recuperación ante desastres entre regiones, sin ejecutar tu propia replicación.

En el escenario del registro de auditoría, un cliente de la UE requiere que sus datos vivan en eu-west-1, mientras que el resto se ejecuta en us-east-1. Y como registro crítico para el cumplimiento, necesita sobrevivir a una caída regional completa. Una tabla global responde a ambas con una sola característica.

¿Cómo funcionan las tablas globales de DynamoDB?

Las tablas globales de DynamoDB son una sola tabla replicada a través de múltiples regiones de AWS, donde cada réplica es legible y escribible. DynamoDB las sincroniza automáticamente mediante replicación asíncrona con coherencia eventual, resolviendo los conflictos por último-escritor-gana. Obtienes lecturas y escrituras locales de baja latencia por región más recuperación ante desastres entre regiones, respaldando el SLA de disponibilidad del 99,999 % de DynamoDB.

• Multirregión, activa-activa. Cada réplica es totalmente legible y escribible; las escrituras en cualquier región se propagan a las demás.
• En el modo por defecto, la replicación es asíncrona y con coherencia eventual entre regiones — típicamente en menos de un segundo, pero no instantánea. (También existe un modo de coherencia fuerte — consulta abajo.)
• Los conflictos se resuelven por último-escritor-gana. Las escrituras concurrentes al mismo elemento en dos regiones se reconcilian con la más reciente.
• Respalda el SLA de disponibilidad del 99,999 % — una tabla global multirregión es la configuración de mayor disponibilidad de DynamoDB.

El problema: una región no es suficiente

Una tabla de una sola región tiene dos límites que el registro de auditoría no puede aceptar. Primero, la residencia de datos: los eventos de un cliente de la UE deben almacenarse en la UE, pero tu aplicación se ejecuta en EE. UU. Segundo, la recuperación ante desastres: si us-east-1 tiene una caída, un registro de auditoría de una sola región queda ilegible e inescribible mientras dure — justo cuando más necesitas el registro de lo que pasó.

Construir cualquiera de las dos tú mismo — replicación entre regiones, conmutación por error, manejo de conflictos — es un proyecto grande y propenso a errores. Las tablas globales lo convierten en una opción de configuración.

Mecánica de la replicación

Añades una región de réplica a la tabla; DynamoDB crea una copia allí y mantiene todas las réplicas sincronizadas.

Dos reglas de coherencia definen el comportamiento por defecto (MREC):

• La replicación entre regiones es asíncrona. Una escritura en us-east-1 se reconoce localmente, luego se propaga a eu-west-1 — normalmente en menos de un segundo, pero una lectura en la otra región justo después de una escritura puede no verla todavía. (En el modo MREC por defecto, las lecturas con coherencia fuerte siguen funcionando, pero solo dentro de una sola región.)
• Los conflictos son por último-escritor-gana. Si el mismo elemento se escribe en dos regiones casi al mismo tiempo, DynamoDB conserva la escritura con la marca de tiempo más reciente y descarta la otra.

Un ejemplo trabajado: una réplica de la UE que también es DR

Añades eu-west-1 como réplica de la tabla del registro de auditoría. Ahora:

La aplicación del cliente de la UE escribe en y lee de la réplica local eu-west-1 — baja latencia y datos residentes en la región. La misma replicación que satisface la residencia hace las veces de recuperación ante desastres: si us-east-1 se cae, la réplica eu-west-1 aún tiene el registro completo y atiende el tráfico; conmutas por error a ella.

Como el registro de auditoría es de solo anexado y particionado por inquilino, el último-escritor- gana es esencialmente un no-problema aquí — los eventos de un inquilino dado se escriben desde una región y las claves de evento son únicas, así que dos regiones rara vez compiten por el mismo elemento. Eso no es suerte; es por qué un registro de solo anexado es uno de los encajes más limpios para las tablas globales. Un contador mutable, en cambio, necesitaría cuidado bajo escrituras concurrentes entre regiones.

Hazlo en DynoTable

Después de añadir una réplica quieres confirmar que los datos realmente aterrizaron en la nueva región y coinciden con la fuente — que la réplica de la UE realmente tiene los eventos de acme, con los atributos correctos, y no está rezagada.

DynoTable se conecta a cualquier región con sus propias credenciales, así que puedes apuntar una ventana a us-east-1 y otra a eu-west-1 y comparar los elementos del mismo inquilino lado a lado para verificar la replicación.

Puedes prototipar las consultas por región que ejecutarás contra cada réplica en el Generador de expresiones de DynamoDB.

Escollos y próximos pasos

• No leas-tu-propia-escritura entre regiones. El retardo de replicación significa que una escritura en una región puede no aparecer en otra durante ~un segundo. No escribas en EE. UU. y luego leas inmediatamente desde la UE esperando encontrarla. En el modo MREC por defecto, las lecturas con coherencia fuerte funcionan solo dentro de una sola región; MRSC extiende las lecturas fuertes entre regiones.
• El último-escritor-gana descarta datos en silencio. Para elementos mutables escritos de forma concurrente en dos regiones, el perdedor se descarta sin error. Los diseños de solo anexado o de un-solo-escritor-por-elemento (como este registro de auditoría) evitan el problema; el estado mutable compartido necesita un diseño consciente de los conflictos.
• Cada réplica cuesta. Cada región almacena una copia completa y factura su propia capacidad y almacenamiento — una réplica aproximadamente duplica el costo. Añade regiones por una necesidad real de residencia o DR, no por defecto.
• Las copias de seguridad son por réplica. Una tabla global restaurada se convierte en una tabla independiente — planifica la recuperación por región. Consulta copia de seguridad y recuperación a un momento dado.

Las tablas globales protegen contra la pérdida de una región. La última preocupación operativa es proteger contra la pérdida de datos — un despliegue defectuoso o una eliminación accidental — con copia de seguridad y recuperación a un momento dado.

Descarga DynoTable para conectarte a múltiples regiones y verificar que tus réplicas de tabla global tienen los mismos datos.