Solução de problemas de latência no Amazon DynamoDB - Amazon DynamoDB

Solução de problemas de latência no Amazon DynamoDB

Se a workload parecer estar com alta latência, você poderá analisar a métrica SuccessfulRequestLatency do CloudWatch e conferir a latência média para ver se ela está relacionada ao DynamoDB. Alguma variabilidade na SuccessfulRequestLatency relatada é normal, e picos ocasionais (particularmente na estatística Maximum) não devem ser motivo de preocupação. No entanto, se a estatística Average mostrar um aumento acentuado e persistir, você deve verificar o AWS Service Health Dashboard e o Personal Health Dashboard para obter mais informações. Algumas causas possíveis incluem o tamanho do item na tabela (um item de 1 KB e um item de 400 KB variam em latência) ou o tamanho da consulta (10 itens em comparação com 100 itens).

Se necessário, considere abrir um caso de suporte com o AWS Support e continue a avaliar todas as opções alternativas disponíveis para sua aplicação (como a evacuação de uma região, se você tiver uma arquitetura multirregional) de acordo com seus runbooks. É necessário registrar em log os IDs de solicitação para solicitações lentas a fim de fornecer esses IDs para AWS Support ao abrir um caso de suporte.

A métrica SuccessfulRequestLatency mede apenas a latência interna ao serviço do DynamoDB. A atividade do lado do cliente e os tempos de viagem da rede não estão incluídos. Para saber mais sobre a latência geral das chamadas do seu cliente para o serviço DynamoDB, é possível habilitar o registro de métricas de latência no AWS SDK.

nota

Para a maioria das operações de um único item (operações que se aplicam a um único item por meio da especificação do valor total da chave primária), o DynamoDB fornece Average SuccessfulRequestLatency de milissegundos de um dígito. Esse valor não inclui a sobrecarga de transporte do código do chamador que acessa o endpoint do DynamoDB. Para operações de dados com vários itens, a latência variará com base em fatores como o tamanho do conjunto de resultados, a complexidade das estruturas de dados retornadas e as expressões de condição e de filtro aplicadas. Para operações repetidas de vários itens no mesmo conjunto de dados com os mesmos parâmetros, o DynamoDB fornecerá Average SuccessfulRequestLatency altamente consistente.

Considere uma ou mais das seguintes estratégias para reduzir a latência:

  • Ajuste o tempo limite da solicitação e o comportamento de repetição: o caminho do cliente até o DynamoDB atravessa muitos componentes, cada um deles projetado com a redundância em mente. Pense no escopo da resiliência da rede, nos tempos limite dos pacotes TCP e na arquitetura distribuída do próprio DynamoDB. Os comportamentos padrão do SDK foram projetados para encontrar o equilíbrio certo para a maioria das aplicações. Se a melhor latência possível for sua maior prioridade, considere ajustar o tempo limite padrão da solicitação e as configurações de repetição do SDK para acompanhar de perto a latência típica de uma solicitação bem-sucedida medida pelo cliente. Uma solicitação que está demorando muito mais que o normal tem menor probabilidade de ser bem-sucedida. Se você antecipar-se à falha e fizer uma nova solicitação, é provável que ela siga um caminho diferente e seja concluída com êxito rapidamente. Lembre-se de que uma configuração muito agressiva pode apresentar desvantagens. Uma discussão útil sobre esse tópico pode ser encontrada em Ajuste das configurações de solicitação HTTP do AWS SDK Java para aplicações do Amazon DynamoDB com reconhecimento de latência.

  • Reduza a distância entre o cliente e o endpoint do DynamoDB: se você tiver usuários dispersos globalmente, considere usar Tabelas globais: replicação em várias regiões para o DynamoDB. Ao criar tabelas globais, é possível especificar as regiões da AWS em que deseja que a tabela esteja disponível. A leitura de dados de uma réplica de tabela global local pode reduzir significativamente a latência para os usuários. Além disso, considere usar um endpoint de gateway do DynamoDB para manter o tráfego do cliente na VPC.

  • Use o armazenamento em cache: se o tráfego tiver muita leitura, considere usar um serviço de armazenamento em cache, como Aceleração em memória com o DynamoDB Accelerator (DAX). O DAX é um cache na memória totalmente gerenciado e altamente disponível para o DynamoDB que proporciona uma performance até dez vezes melhor, de milissegundos para microssegundos, mesmo com milhões de solicitações por segundo.

  • Reutilize conexões: as solicitações do DynamoDB são feitas por meio de uma sessão autenticada cujo padrão é HTTPS. Iniciar a conexão leva tempo, então a latência da primeira solicitação é maior que o normal. As solicitações por meio de uma conexão já inicializada oferecem baixa latência consistente do DynamoDB. Por esse motivo, talvez você queira fazer uma solicitação de “keep-alive” a cada 30 segundos se nenhuma outra solicitação GetItem for feita, para evitar a latência do estabelecimento de uma nova conexão.

  • Use leituras finais consistentes: se a aplicação não exigir leituras altamente consistentes, considere usar as leituras finais consistentes comuns. As leituras finais consistentes custam menos e também apresentam menor probabilidade de sofrer aumentos transitórios na latência. Para ter mais informações, consulte Consistência de leitura do DynamoDB.