Transmissão de dados com DynamoDB

Desenvolvendo Aplicações na AWS

Ricardo Sueiras

Principal Technologist

Fundamentos do DynamoDB Streams

 

• Reaja a mudanças no banco quase em tempo real.
• Baseado em padrões orientados a eventos.
• Cada insert, modify ou delete gera um registro no stream.
• Crie apps reativos sem fazer polling na tabela.
• Desativado por padrão: ative com StreamSpecification.
• Cada stream tem seu próprio ARN, distinto do ARN da tabela.

Período de retenção

 

• Registros do stream ficam retidos por 24 horas.
  • A retenção é fixa e não pode ser configurada.
• Mudar o tipo de visualização exige recriar o stream.
  • Um novo stream gera um novo ARN de stream.

Streams e unidades de capacidade de leitura do DynamoDB

 

• Leituras do stream NÃO consomem suas RCUs (read capacity units).
• Ativar streams não impacta o throughput provisionado.

Registros do stream

• Cada registro de stream traz metadados descrevendo a mudança.
• Streams capturam três tipos de evento:
  • INSERT
  • MODIFY
  • REMOVE

 

• Tipos de visualização controlam quais dados vão para cada registro.
  • KEYS_ONLY: apenas as chaves de partição e ordenação.
  • NEW_IMAGE: o item completo após a mudança.
  • OLD_IMAGE: o item completo antes da mudança.
  • NEW_AND_OLD_IMAGES: o item antes e depois.
• NEW_AND_OLD_IMAGES é o padrão para auditoria.
• Obrigatório para DynamoDB Global Tables.

• Streams preservam a ordem por chave de partição.
• Lambda processa registros em lotes.
  • Faz checkpoint do progresso após cada lote bem-sucedido.
  • Lotes com falha são reprocessados.
  • As tentativas continuam até sucesso ou expirar.

 

 

• Lambda é o consumidor de stream mais comum.
• Usa um mapeamento de fonte de eventos baseado em polling.
• Lê registros do stream.
• Invoca sua função com lotes de registros.

Padrão arquitetural

 

• Um padrão ponta a ponta comum:
  • Uma atualização de item chega ao DynamoDB.
  • A mudança gera um registro no stream.
  • O registro aciona o Lambda para processamento.

Escalabilidade

 

• Streams são divididos internamente em shards.
  • Semelhante ao Kinesis Data Streams.
• Cada shard permite até dois consumidores simultâneos.
  • Ultrapassar esse limite causa throttling de leitura.

• A simultaneidade do Lambda escala com a contagem de shards.
• Faça tuning do processamento com:
  • BatchSize: máx. de registros por invocação.
  • MaximumBatchingWindow: espera antes de um lote parcial.
  • MaximumRetryAttempts: tentativas antes do destino de falhas.
  • MaximumRecordAgeInSeconds: descarta registros após essa idade.
  • ParallelizationFactor: processamento concorrente por shard (máx. 10).

Filtragem e tumbling windows

• Lambda oferece critérios de filtragem.
  • Descarte registros antes de invocar a função.
  • Reduz invocações desnecessárias e custo.
• Lambda oferece tumbling windows.
  • Agregue estado entre lotes em um shard.

 

Gerenciando registros duplicados

• Streams capturam cada mudança exatamente uma vez.
• O Lambda processa com semântica at-least-once.
  • Repetições podem reprocessar o mesmo registro.
• Projete consumidores idempotentes.
• Padrão comum: armazenar eventID ou SequenceNumber processados.
  • Pule registros já tratados.
  • Ambos ficam estáveis em novas tentativas.
  • Chaves de idempotência confiáveis.

 

Tratando falhas

 

• ReportBatchItemFailures tenta novamente só os registros com falha.
• Trate falhas no Lambda com:
  • BisectBatchOnFunctionError para bissetar o lote.
  • Controles de repetição.
  • Destinos de falha para lotes problemáticos que esgotam as tentativas.

Integração de DynamoDB com Kinesis

 

• Tabelas podem enviar mudanças direto para Kinesis Data Streams.
  • Via o recurso Kinesis Data Streams for DynamoDB.
  • Capacidade separada e paralela, não encadeada.
  • Eventos NÃO passam pelo DynamoDB Streams.
• Ambos podem rodar na mesma tabela ao mesmo tempo.
  • Operam de forma independente.
  • Alimenta arquiteturas mais amplas de streaming e analytics.

Monitoramento: problemas comuns

 

• Problemas operacionais comuns para observar:
  • Partições quentes.
  • Repetições com falha.
  • Processamento duplicado.
  • Throttling e atraso do consumidor.

Monitoramento: métricas do CloudWatch

• Principais métricas do CloudWatch para monitorar:
  • Lambda Errors: expõem falhas de código ou downstream.
  • IteratorAge: valores altos indicam consumidores lentos.
  • Métricas de throttling: limites de leitura excedidos.
  • Falhas em processamento de lotes: registros enviados a uma DLQ.

 

Segurança

• O acesso aos streams é controlado por permissões IAM.
• Streams herdam as configurações de criptografia da tabela.
  • Inclui criptografia no servidor em repouso com KMS.
• Aplique políticas de menor privilégio a consumidores e processadores downstream.

 

Vamos praticar!

Desenvolvendo Aplicações na AWS