DynamoDB Streams y tablas globales

DynamoDB Streams captura una secuencia ordenada cronológicamente de modificaciones a nivel de elemento en una tabla de DynamoDB. Cada vez que se crea, actualiza o elimina un elemento, DynamoDB escribe un registro de stream que describe el cambio. Los registros del stream están disponibles durante 24 horas después de su escritura.

Los Streams son la base de las arquitecturas basadas en eventos con DynamoDB. Entre sus usos habituales se incluyen activar funciones de Lambda para el procesamiento en tiempo real, mantener un registro de auditoría, replicar datos en otro almacén o invalidar una caché cuando cambian los datos.

Al habilitar un stream, se elige un StreamViewType que determina qué datos contiene cada registro del stream:

• KEYS_ONLY: solo los atributos de clave principal del elemento modificado
• NEW_IMAGE: el elemento completo tal como aparece después del cambio
• OLD_IMAGE: el elemento completo tal como aparecía antes del cambio
• NEW_AND_OLD_IMAGES: tanto el estado anterior como el posterior del elemento

Elija NEW_AND_OLD_IMAGES para auditorías (para ver qué cambió), NEW_IMAGE para replicaciones o actualizaciones de caché y KEYS_ONLY cuando solo necesite saber qué elemento cambió y vaya a obtener su estado actual por separado.

La forma más habitual de consumir un DynamoDB Stream es mediante AWS Lambda. Lambda sondea el stream e invoca su función con un lote de registros del stream. Lambda gestiona automáticamente el sondeo, los puntos de control y los reintentos.

Parámetros de configuración clave: tamaño del lote (número de registros por invocación, hasta 10.000), bisect on error (divide un lote fallido para aislar el registro problemático) y destination on failure (SQS o SNS para los registros que no se puedan procesar). Lambda lee de cada shard en paralelo, por lo que el paralelismo equivale al número de shards del stream.

Casos de uso prácticos de DynamoDB Streams en el examen SAA-C03:

• Replicación entre regiones: Lambda lee el stream y escribe los cambios en una tabla de otra región (antes de que existieran las Global Tables, este era el patrón habitual)
• Invalidación de ElastiCache: cuando cambia un elemento de DynamoDB, Lambda invalida o actualiza la clave de caché correspondiente
• Sincronización del índice de búsqueda: envía los cambios de los elementos a OpenSearch Service para habilitar la búsqueda de texto completo sobre los datos de DynamoDB
• Registro de auditoría: escribe cada cambio en S3 o en un almacén de cumplimiento normativo con fines regulatorios
• Microservicios basados en eventos: activa servicios posteriores cuando cambian elementos específicos

DynamoDB Global Tables proporcionan una replicación multi-región y multi-activa totalmente administrada. Cada región obtiene una copia completa de la tabla y todas las copias admiten escrituras simultáneamente. Las escrituras realizadas en cualquier región se replican de forma asíncrona en las demás regiones en aproximadamente 1 segundo.

Global Tables permiten dos escenarios fundamentales: lecturas y escrituras de baja latencia para usuarios distribuidos por todo el mundo (cada usuario escribe y lee desde la región más cercana) y recuperación ante desastres multi-región activa-activa (la aplicación sigue funcionando en cualquier región superviviente, sin pérdida de datos posteriores a la última replicación).

Para crear una Global Table, primero cree una tabla con DynamoDB Streams habilitado (NEW_AND_OLD_IMAGES es necesario internamente para Global Tables). Después, añada las regiones réplica. AWS crea una tabla réplica en cada región añadida y comienza a sincronizar los datos bidireccionalmente.

Global Tables (versión 2019.11.21) son el estándar actual y admiten capacidad On-Demand o Provisioned con Auto Scaling. Cada réplica regional debe tener el mismo nombre de tabla. Puede añadir o eliminar regiones de una Global Table en cualquier momento.

Dado que Global Tables permiten escribir simultáneamente en varias regiones, pueden producirse conflictos de escritura si dos regiones actualizan el mismo elemento casi al mismo tiempo. DynamoDB resuelve los conflictos mediante un enfoque de last-writer-wins basado en las marcas de tiempo almacenadas en los registros del stream.

En la práctica, esto significa que, ante dos actualizaciones en conflicto casi simultáneas, una prevalecerá y la otra se sobrescribirá. Las aplicaciones deben diseñarse para evitar escrituras simultáneas en el mismo elemento desde distintas regiones. Cuando los conflictos sean frecuentes, considere dirigir todas las escrituras de un usuario o entidad específicos a una única región principal.

Con Global Tables, las escrituras realizadas en una región se replican automáticamente en todas las demás regiones. Cada escritura replicada consume WCUs en las regiones de destino; si tiene 3 regiones, una sola escritura cuesta aproximadamente 3× las WCUs en el conjunto de las regiones. Planifique la capacidad en consecuencia.

Las lecturas de cada región consumen las RCUs de la réplica local. Las lecturas con coherencia eventual (la opción predeterminada) utilizan los datos locales, mientras que las lecturas con coherencia fuerte no son compatibles entre regiones. Para la mayoría de las aplicaciones globales, la coherencia eventual entre regiones en aproximadamente 1 segundo es aceptable.

Una distinción clave del examen SAA-C03: las Global Tables de DynamoDB son multi-activas (todas las regiones aceptan lecturas Y escrituras), mientras que las réplicas de lectura de RDS entre regiones son de solo lectura (solo puede promover una réplica para hacerla editable, lo que interrumpe la replicación).

Utilice DynamoDB Global Tables cuando necesite: escrituras activas-activas en varias regiones, acceso global inferior a 100 ms o recuperación ante desastres multi-región con RPO cero para datos NoSQL. Utilice réplicas de RDS entre regiones cuando necesite: escalabilidad de lectura global para una base de datos relacional o un recurso de recuperación ante desastres en espera que pueda promover para realizar una conmutación por error.

Patrones de arquitectura habituales que combinan Streams y Lambda:

• Distribución ramificada: Lambda lee el stream y publica en SNS, que distribuye los mensajes a varias colas de SQS para consumidores independientes
• Agregación: Lambda acumula los cambios y actualiza los totales agregados en una tabla de DynamoDB independiente (por ejemplo, el número diario de pedidos)
• Caché write-behind: con cada evento del stream, Lambda actualiza ElastiCache para que las lecturas puedan atenderse desde la caché
• Notificación: el stream activa Lambda, que envía un correo electrónico mediante SES o una notificación push mediante SNS cuando cambia una condición específica

Como alternativa a DynamoDB Streams, puede dirigir los cambios a nivel de elemento a un Amazon Kinesis Data Stream. Esto resulta útil cuando necesita una retención más prolongada (hasta 1 año frente a 24 horas en DynamoDB Streams nativo), más consumidores o integración con servicios que leen de Kinesis.

La integración con Kinesis Data Streams se habilita por tabla y no reemplaza DynamoDB Streams; puede tener ambos habilitados simultáneamente. Es una función más reciente (de 2021) que amplía la canalización de eventos de cambio de DynamoDB sin requerir lógica de replicación personalizada.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que DynamoDB Streams captura los cambios a nivel de elemento durante 24 horas y se integra con Lambda para el procesamiento basado en eventos; Global Tables proporciona replicación multiactiva y multirregional con resolución de conflictos según el último escritor; y la integración con Kinesis Data Streams amplía la retención más allá de la ventana de 24 horas del flujo. A continuación, exploraremos las zonas alojadas de Route 53 y los tipos de registros DNS.