Streams do DynamoDB e tabelas globais

DynamoDB Streams captura uma sequência ordenada no tempo de modificações em nível de item em uma tabela do DynamoDB. Sempre que um item é criado, atualizado ou excluído, o DynamoDB grava um registro de stream descrevendo a alteração. Os registros do stream ficam disponíveis por 24 horas após serem gravados.

Streams são a base de arquiteturas orientadas a eventos com o DynamoDB. Os usos comuns incluem acionar funções Lambda para processamento em tempo real, manter um registro de auditoria, replicar dados para outro armazenamento ou invalidar um cache quando os dados forem alterados.

Ao ativar um stream, você escolhe um tipo de visualização do stream que determina quais dados cada registro do stream contém:

• KEYS_ONLY: somente os atributos da chave primária do item modificado
• NEW_IMAGE: o item inteiro como aparece após a alteração
• OLD_IMAGE: o item inteiro como aparecia antes da alteração
• NEW_AND_OLD_IMAGES: os estados anterior e posterior do item

Escolha NEW_AND_OLD_IMAGES para auditoria (para ver o que mudou), NEW_IMAGE para replicação ou atualização de cache e KEYS_ONLY quando você só precisar saber qual item mudou e for buscar o estado atual separadamente.

A forma mais comum de consumir um DynamoDB Stream é usando o AWS Lambda. O Lambda consulta o stream e invoca sua função com um lote de registros do stream. O Lambda gerencia automaticamente a consulta, o registro de pontos de verificação e as novas tentativas.

Principais parâmetros de configuração: tamanho do lote (número de registros por invocação, até 10.000), dividir em caso de erro (divide um lote com falha para isolar o registro problemático) e destino em caso de falha (SQS ou SNS para registros que não podem ser processados). O Lambda lê de cada fragmento em paralelo, portanto o paralelismo é igual ao número de fragmentos no stream.

Casos práticos de uso do DynamoDB Streams no exame SAA-C03:

• Replicação entre regiões: o Lambda lê o stream e grava as alterações em uma tabela em outra Region (antes da existência de Global Tables, esse era o padrão)
• Invalidação do ElastiCache: quando um item do DynamoDB muda, o Lambda invalida ou atualiza a chave de cache correspondente
• Sincronização do índice de pesquisa: envia alterações dos itens para o OpenSearch Service para habilitar a pesquisa de texto completo nos dados do DynamoDB
• Registro de auditoria: grava cada alteração no S3 ou em um armazenamento de conformidade para fins regulatórios
• Microsserviços orientados a eventos: aciona serviços posteriores quando itens específicos são alterados

DynamoDB Global Tables fornecem replicação totalmente gerenciada, multirregional e multiativa. Cada Region recebe uma cópia completa da tabela, e todas as cópias podem receber gravações simultaneamente. As gravações em qualquer Region são replicadas de forma assíncrona para todas as outras Regions em aproximadamente 1 segundo.

Global Tables habilitam dois cenários críticos: leituras e gravações de baixa latência para usuários distribuídos globalmente (cada usuário grava e lê na Region mais próxima) e recuperação de desastres multiativa entre regiões (a aplicação continua funcionando em qualquer Region sobrevivente, sem perda de dados após a última replicação).

Para criar uma Global Table, primeiro crie uma tabela com o DynamoDB Streams ativado (NEW_AND_OLD_IMAGES é necessário internamente para Global Tables). Em seguida, adicione Regions de réplica. A AWS cria uma tabela de réplica em cada Region adicionada e começa a sincronizar os dados bidirecionalmente.

Global Tables (versão 2019.11.21) são o padrão atual e oferecem suporte à capacidade sob demanda ou provisionada com Auto Scaling. Cada réplica em uma Region deve ter o mesmo nome de tabela. Você pode adicionar ou remover Regions de uma Global Table a qualquer momento.

Como Global Tables permite gravações simultâneas em várias Regions, podem ocorrer conflitos de gravação se duas Regions atualizarem o mesmo item quase ao mesmo tempo. O DynamoDB resolve conflitos usando uma abordagem de última gravação vence, com base nos carimbos de data e hora armazenados nos registros do stream.

Na prática, isso significa que duas atualizações conflitantes quase simultâneas resultarão em uma atualização vencedora e outra sendo sobrescrita. As aplicações devem ser projetadas para evitar gravações simultâneas no mesmo item a partir de Regions diferentes. Para casos de uso em que os conflitos são comuns, considere encaminhar todas as gravações de um usuário ou entidade específica para uma única Region principal.

Com Global Tables, as gravações em uma Region são replicadas automaticamente para todas as outras Regions. Cada gravação replicada consome WCUs nas Regions de destino — se você tiver 3 Regions, uma única gravação custará aproximadamente 3× as WCUs em todas as Regions. Planeje a capacidade adequadamente.

As leituras em cada Region consomem as RCUs da réplica local. Leituras com consistência eventual (o padrão) usam dados locais, enquanto leituras fortemente consistentes não são compatíveis entre Regions. Para a maioria das aplicações globais, a consistência eventual em aproximadamente 1 segundo entre Regions é aceitável.

Uma distinção importante no exame SAA-C03: Global Tables do DynamoDB são multiativas (todas as Regions aceitam leituras E gravações), enquanto as réplicas de leitura entre regiões do RDS são somente leitura (você só pode promover uma réplica para torná-la gravável, interrompendo a replicação).

Use Global Tables do DynamoDB quando precisar de: gravações multiativas entre regiões, acesso global inferior a 100 ms ou recuperação de desastres multi-regional com RPO zero para dados NoSQL. Use réplicas entre regiões do RDS quando precisar de: escalabilidade global de leitura para um banco de dados relacional ou de uma instância de recuperação de desastres em espera que possa ser promovida durante o failover.

Padrões comuns de arquitetura que combinam Streams e Lambda:

• Distribuição: o Lambda lê o stream e publica no SNS, que distribui as mensagens para várias filas SQS destinadas a consumidores independentes
• Agregação: o Lambda acumula alterações e atualiza totais agregados em uma tabela separada do DynamoDB (por exemplo, a quantidade diária de pedidos)
• Cache com gravação posterior: a cada evento do stream, o Lambda atualiza o ElastiCache para que as leituras possam ser atendidas pelo cache
• Notificação: o stream aciona o Lambda, que envia um e-mail pelo SES ou uma notificação push pelo SNS quando uma condição específica muda

Como alternativa ao DynamoDB Streams, você pode direcionar as alterações no nível dos itens para um Amazon Kinesis Data Stream. Isso é útil quando você precisa de uma retenção mais longa (até 1 ano, em comparação com 24 horas no DynamoDB Streams nativo), de mais consumidores ou de integração com serviços que leem do Kinesis.

A integração com Kinesis Data Streams é habilitada por tabela e não substitui o DynamoDB Streams — você pode manter ambos habilitados simultaneamente. Esse é um recurso mais recente (de 2021) que estende o pipeline de eventos de alterações do DynamoDB sem exigir uma lógica de replicação personalizada.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, você aprendeu que: o DynamoDB Streams captura alterações no nível dos itens por 24 horas e integra-se ao Lambda para processamento orientado a eventos; as Global Tables fornecem replicação multiativa e multirregional com resolução de conflitos pelo último gravador; e a integração com Kinesis Data Streams estende a retenção para além da janela de 24 horas do fluxo. Em seguida, exploraremos as zonas hospedadas do Route 53 e os tipos de registros DNS.