Avaliar o uso de fluxos do DynamoDB

Esta seção apresenta uma visão geral de como avaliar o uso do DynamoDB Streams. Existem certos padrões de uso que não são ideais para o DynamoDB e permitem a otimização tanto do ponto de vista do desempenho quanto do custo.

Você tem duas integrações nativas de streaming para casos de uso de streaming e orientados por eventos:

Esta página se concentrará apenas nas estratégias de otimização de custos para essas opções. Se você quiser, em vez disso, descobrir como escolher entre as duas opções, consulte Opções de streaming para captura de dados de alteração.

Otimizar custos para o DynamoDB Streams

Conforme mencionado na página de definição de preço do DynamoDB Streams, independentemente do modo de capacidade de throughput da tabela, o DynamoDB cobra pelo número de solicitações de leitura feitas ao DynamoDB Stream da tabela. As solicitações de leitura feitas para um DynamoDB Stream são diferentes das solicitações de leitura feitas para uma tabela do DynamoDB.

Cada solicitação de leitura em termos de fluxo está na forma de uma chamada à API GetRecords que pode retornar até 1.000 registros ou 1 MB de registros na resposta, o que for atingido primeiro. Nenhuma das outras APIs do DynamoDB Stream é cobrada e os DynamoDB Streams não são cobrados por estarem ociosos. Em outras palavras, se nenhuma solicitação de leitura for feita para um DynamoDB Stream, nenhuma cobrança será cobrada por ter um DynamoDB Stream habilitado em uma tabela.

Veja algumas aplicações de consumidor do DynamoDB Streams:

As solicitações de leitura feitas por consumidores baseados no AWS Lambda são gratuitas, enquanto as chamadas feitas por consumidores de qualquer outro tipo são cobradas. Todos os meses, os primeiros 2,5 milhões de solicitações de leitura feitas por consumidores não pertencentes ao Lambda também são gratuitas. Isso se aplica a todas as solicitações de leitura feitas a qualquer DynamoDB Streams em uma conta da AWS para cada região da AWS.

Monitorar seu uso do DynamoDB Streams

As cobranças do DynamoDB Streams no console de cobrança são agrupadas para todos os DynamoDB Streams na região da AWS em uma conta da AWS. No momento, a marcação de DynamoDB Streams não é compatível, portanto, não é possível usar as tags de alocação de custos para identificar custos granulares dos DynamoDB Streams. O volume de chamadas GetRecords pode ser obtido no nível do DynamoDB Stream para calcular as cobranças por fluxo. O volume é representado pela métrica SuccessfulRequestLatency do CloudWatch do DynamoDB Stream e sua estatística SampleCount. Essa métrica também incluirá chamadas GetRecords feitas por tabelas globais para realizar a replicação contínua, bem como chamadas feitas por consumidores do AWS Lambda, ambas sem cobrança. Para obter informações sobre outras métricas do CloudWatch publicadas pelo DynamoDB Streams, consulte Métricas e dimensões do DynamoDB.

Usar o AWS Lambda como consumidor

Avalie se é possível usar as funções do AWS Lambda como consumidores dos DynamoDB Streams, pois isso pode eliminar os custos associados à leitura do DynamoDB Stream. Por outro lado, os aplicativos de consumo baseados no DynamoDB Streams Kinesis Adapter ou SDK serão cobrados pelo número de chamadas GetRecords feitas ao DynamoDB Stream.

As invocações de funções do Lambda serão cobradas com base no preço padrão do Lambda, mas nenhuma cobrança será cobrada pelo DynamoDB Streams. O Lambda sonda os fragmentos em sua transmissão do DynamoDB em busca de registros a uma taxa básica de 4 vezes por segundo. Quando os registros estão disponíveis, o Lambda invoca a função e aguarda o resultado. Se o processamento for bem-sucedido, o Lambda continua a sondagem até que ela receba mais registros.

Ajustar aplicações de consumidor baseadas no DynamoDB Streams Kinesis Adapter

Como as solicitações de leitura feitas por consumidores não baseados no Lambda são cobradas por DynamoDB Stream, é importante encontrar um equilíbrio entre a exigência quase em tempo real e o número de vezes que a aplicação de consumidor deve sondar o DynamoDB Stream.

A frequência da sondagem de DynamoDB Streams usando uma aplicação baseada no DynamoDB Streams Kinesis Adapter é definida pelo valor idleTimeBetweenReadsInMillis configurado. Esse parâmetro determina a quantidade de tempo em milissegundos que o consumidor deve esperar antes de processar um fragmento, caso a chamada GetRecords anterior feita para o mesmo fragmento não tenha retornado nenhum registro. Por padrão, o valor desse parâmetro é 1.000 ms. Se o processamento quase em tempo real não for necessário, esse parâmetro poderá ser aumentado para que o aplicativo consumidor faça menos chamadas GetRecords e otimize as chamadas do DynamoDB Streams.

Otimizar os custos para Kinesis Data Streams

Quando um Kinesis Data Stream é definido como o destino para fornecer eventos de captura de dados de alteração para uma tabela do DynamoDB, o Kinesis Data Stream pode precisar de um gerenciamento de dimensionamento separado, o que afetará os custos gerais. O DynamoDB cobra em termos de unidades de captura de dados de alteração (CDUs), em que cada unidade é composta por um tamanho de item do DynamoDB de até 1 KB tentado pelo serviço do DynamoDB até o Kinesis Data Stream de destino.

Além das cobranças do serviço DynamoDB, serão cobradas taxas padrão do Kinesis Data Stream. Conforme mencionado na página de definição de preço, o preço do serviço difere com base no modo de capacidade, provisionado e sob demanda, que são distintos dos modos de capacidade da tabela do DynamoDB e são definidos pelo usuário. Em um nível alto, o Kinesis Data Streams cobra uma taxa por hora com base no modo de capacidade, bem como na ingestão de dados do fluxo pelo serviço DynamoDB. Pode haver cobranças adicionais, como recuperação de dados (para o modo sob demanda), retenção estendida de dados (além das 24 horas padrão) e recuperações avançadas do consumidor, dependendo da configuração do usuário para o Kinesis Data Stream.

Monitorar seu uso Kinesis Data Streams

O Kinesis Data Streams for DynamoDB publica métricas do DynamoDB, além das métricas padrão do CloudWatch do Kinesis Data Stream. Talvez uma tentativa Put do serviço DynamoDB seja limitada pelo serviço Kinesis devido à capacidade insuficiente de Kinesis Data Streams ou por componentes dependentes, como um serviço AWS KMS que possa ser configurado para criptografar os dados do Kinesis Data Stream em repouso.

Para saber mais sobre as métricas do CloudWatch publicadas pelo serviço DynamoDB para o Kinesis Data Stream, consulte Monitorar a captura de dados de alterações com o Kinesis Data Streams. Para evitar custos adicionais de novas tentativas de serviço devido a limitações, é importante dimensionar corretamente o Kinesis Data Stream no caso de Modo provisionado.

Como escolher o modo de capacidade certo para Kinesis Data Streams

O Kinesis Data Streams é compatível com dois modos de capacidade: modo provisionado e modo sob demanda.

Uma prática recomendada para otimizar os custos é avaliar se a tabela do DynamoDB associada ao Kinesis Data Stream tem um padrão de tráfego previsível que possa aproveitar o modo provisionado do Kinesis Data Streams. Se a workload for nova, você poderá usar o modo sob demanda para o Kinesis Data Streams por algumas semanas iniciais, analisar as métricas do CloudWatch para entender os padrões de tráfego e, em seguida, mudar o mesmo fluxo para o modo provisionado com base na natureza da workload. No caso do modo provisionado, a estimativa do número de fragmentos pode ser feita seguindo as considerações de gerenciamento de fragmentos para o Kinesis Data Streams.

Avaliar suas aplicações de consumidor do Kinesis Data Streams para DynamoDB

Como o Kinesis Data Streams não cobra pelo número de chamadas GetRecords, como o DynamoDB Streams, as aplicações de consumidor podem fazer o maior número possível de chamadas, desde que a frequência esteja abaixo dos limites de controle de utilização de GetRecords. Em termos de modo sob demanda para o Kinesis Data Streams, as leituras de dados são cobradas por GB. No modo provisionado de Kinesis Data Streams, as leituras não são cobradas se os dados tiverem menos de sete dias. No caso de funções do Lambda que consumam Kinesis Data Streams, o Lambda sonda cada fragmento em seu Kinesis Stream para identificar registros a uma taxa básica de uma vez por segundo.

Estratégias de otimização de custos para os dois tipos de uso do Streams

Filtragem de eventos para consumidores do AWS Lambda

A filtragem de eventos do Lambda permite que você descarte eventos com base em um critério de filtro para que não estejam disponíveis no lote de invocação da função do Lambda. Isso otimiza os custos do Lambda para processar ou descartar registros de fluxo indesejados dentro da lógica de funções do consumidor. Para saber mais sobre como configurar a filtragem de eventos e escrever seus critérios de filtragem, consulte Filtragem de eventos do Lambda.

Ajustando os consumidores do AWS Lambda

Os custos podem ser otimizados ainda mais ajustando os parâmetros de configuração do Lambda, como aumentar o BatchSize para processar mais por invocação, permitindo que BisectBatchOnFunctionError evite o processamento de duplicatas (o que gera custos adicionais) e configurando MaximumRetryAttempts para não executar muitas tentativas. Por padrão, as invocações do Lambda do consumidor que tiveram falha são repetidas infinitamente até que o registro expire do fluxo, o que dura cerca de 24 horas para o DynamoDB Streams e pode ser configurado de 24 horas a até 1 ano para o Kinesis Data Streams. As opções adicionais de configuração do Lambda disponíveis, incluindo as mencionadas acima para consumidores do DynamoDB Stream, estão no Guia do desenvolvedor do AWS Lambda.