Datos en streaming con DynamoDB

Desarrollo de aplicaciones en AWS

Ricardo Sueiras

Principal Technologist

Fundamentos de DynamoDB Streams

 

• Reacciona a cambios en la base de datos casi en tiempo real.
• Basado en patrones dirigidos por eventos.
• Cada inserción, modificación o borrado genera un registro de stream.
• Crea apps reactivas sin consultar la tabla.
• Desactivado por defecto: actívalo con StreamSpecification.
• Cada stream tiene su propio ARN, distinto del ARN de la tabla.

Período de retención

 

• Los registros del stream se conservan 24 horas.
  • La retención es fija y no se puede configurar.
• Cambiar el tipo de vista implica recrear el stream.
  • Un stream nuevo genera un ARN de stream nuevo.

Streams y unidades de capacidad de lectura de DynamoDB

 

• Las lecturas del stream NO consumen tus RCUs (read capacity units).
• Activar streams no afecta al rendimiento aprovisionado.

Registros del stream

• Cada registro incluye metadatos que describen el cambio.
• Los streams capturan tres tipos de evento:
  • INSERT
  • MODIFY
  • REMOVE

 

• Los tipos de vista controlan qué datos hay en cada registro.
  • KEYS_ONLY: solo la clave de partición y de ordenación.
  • NEW_IMAGE: el ítem completo tras el cambio.
  • OLD_IMAGE: el ítem completo antes del cambio.
  • NEW_AND_OLD_IMAGES: el ítem antes y después.
• NEW_AND_OLD_IMAGES es la opción habitual para auditoría.
• Requerido para DynamoDB Global Tables.

• Los streams preservan el orden por clave de partición.
• Lambda procesa registros en lotes.
  • Marca el progreso tras cada lote correcto.
  • Los lotes fallidos se reintentan.
  • Los reintentos siguen hasta éxito o caducidad.

 

 

• Lambda es el consumidor de streams más común.
• Usa un mapeo de origen de eventos basado en sondeo.
• Lee registros del stream.
• Invoca tu función con lotes de registros.

Patrón arquitectónico

 

• Patrón de extremo a extremo común:
  • Una actualización de ítem llega a DynamoDB.
  • El cambio genera un registro de stream.
  • El registro activa Lambda para su procesamiento.

Escalado

 

• Los streams se dividen internamente en shards.
  • Similar a Kinesis Data Streams.
• Cada shard permite hasta dos consumidores simultáneos.
  • Superar este límite suele causar limitación de lectura.

• La concurrencia de Lambda escala con el número de shards.
• Ajusta el procesamiento con:
  • BatchSize: máx. de registros por invocación.
  • MaximumBatchingWindow: espera antes de un lote parcial.
  • MaximumRetryAttempts: reintentos antes del destino de fallos.
  • MaximumRecordAgeInSeconds: descarta registros más antiguos.
  • ParallelizationFactor: procesamiento concurrente por shard (máx. 10).

Filtrado y tumbling windows

• Lambda admite criterios de filtrado.
  • Descarta registros antes de invocar la función.
  • Reduce invocaciones innecesarias y coste.
• Lambda admite tumbling windows.
  • Agrega estado entre lotes en un shard.

 

Gestión de registros duplicados

• Los streams capturan cada cambio exactamente una vez.
• Lambda procesa con semántica de al menos una vez.
  • Los reintentos pueden reprocesar el mismo registro.
• Diseña consumidores idempotentes.
• Patrón común: guardar eventID o SequenceNumber procesado.
  • Omite los registros ya gestionados.
  • Ambos se mantienen estables en reintentos.
  • Claves de idempotencia fiables.

 

Gestión de fallos

 

• ReportBatchItemFailures reintenta solo los registros fallidos.
• Gestiona fallos de Lambda con:
  • BisectBatchOnFunctionError para bisecar lotes.
  • Controles de reintento.
  • Destinos de fallos para lotes «venenosos» que agotan reintentos.

Integración de DynamoDB con Kinesis

 

• Las tablas pueden enviar cambios directamente a Kinesis Data Streams.
  • Mediante la función Kinesis Data Streams for DynamoDB.
  • Es una capacidad separada y paralela, no encadenada.
  • Los eventos NO pasan por DynamoDB Streams.
• Ambas pueden ejecutarse a la vez en la misma tabla.
  • Operan de forma independiente.
  • Alimenta arquitecturas de streaming y analítica más amplias.

Supervisión: problemas comunes

 

• Problemas operativos habituales a vigilar:
  • Particiones calientes.
  • Reintentos fallidos.
  • Procesamiento duplicado.
  • Limitaciones y retraso del consumidor.

Supervisión: métricas de CloudWatch

• Métricas clave de CloudWatch para monitorizar:
  • Lambda Errors: muestran fallos de código o dependencias.
  • IteratorAge: valores altos indican consumidores lentos.
  • Métricas de Throttling: se superan límites de lectura.
  • Fallos de procesamiento por lotes: registros enviados a una DLQ.

 

Seguridad

• El acceso a los streams se controla con permisos IAM.
• Los streams heredan la configuración de cifrado de la tabla.
  • Incluye cifrado del lado del servidor en reposo con KMS.
• Aplica políticas de mínimo privilegio a consumidores y procesadores posteriores.

 

¡Vamos a practicar!

Desarrollo de aplicaciones en AWS