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 parece estar com alta latência, você poderá analisar a métrica SuccessfulRequestLatency do CloudWatch e conferir a latência média e a latência mediana por meio de métricas de percentil (p50) para ver se ela está relacionada ao DynamoDB. Alguma variabilidade na SuccessfulRequestLatency relatada é normal, e picos ocasionais (particularmente na estatística Maximum e nos percentis altos) não devem ser motivo de preocupação. No entanto, se a estatística Average ou p50 (mediana) mostrar um aumento acentuado e persistir, você deverá conferir o AWS Service Health Dashboard e o Personal Health Dashboard para ter mais informações. Algumas causas possíveis são 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 (dez itens em comparação a cem itens).

As métricas de percentil (p99, p90 etc.) podem ajudar você a entender melhor sua distribuição de latência. Por exemplo:

  • p50 (mediana) mostra a latência típica da workload.

  • p90 mostra que 90% das solicitações são mais rápidas do que esse valor.

  • p99 ajuda a identificar o pior caso de latência que afeta 1% das solicitações.

Valores altos de p99 com valores normais de p50 podem indicar problemas esporádicos que afetam uma pequena parte das solicitações, enquanto valores de p50 consistentemente elevados podem sugerir alguma degradação da performance.

nota

Para analisar valores de percentis personalizados (como p99,9), você pode inserir manualmente o percentil desejado (p. ex., p99,9) no campo de estatística de métrica do CloudWatch. Isso permite avaliar as distribuições de latência que transcendem os percentis padrão listados no menu suspenso.

Algumas variações nas métricas de latência, especialmente em percentis mais altos, são esperadas e podem ser vistas como resultado de problemas transitórios de infraestrutura ou de operações em segundo plano orientadas pelo DynamoDB que ajudam a manter a alta disponibilidade e durabilidade dos dados armazenados nas tabelas do DynamoDB.

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 ida e volta 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:

  • Reutilize conexões: as solicitações do DynamoDB são feitas por meio de uma sessão autenticada por HTTPS por padrão. Para iniciar a conexão, são necessárias várias idas e voltas, e isso toma tempo; por isso, a latência da primeira solicitação é maior do que a das solicitações subsequentes que reutilizam a conexão. As solicitações por meio de uma conexão já inicializada oferecem baixa latência consistente do DynamoDB. Para evitar a sobrecarga de latência do estabelecimento de novas conexões, é aconselhável implementar um mecanismo de “keep-alive” enviando uma solicitação GetItem a cada 30 segundos se nenhuma outra solicitação for feita.

  • 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 têm um custo menor e podem vir de várias zonas de disponibilidade, permitindo a seleção de uma zona de disponibilidade na mesma localização do solicitante, o que diminui a latência. Para obter mais informações, consulte Consistência de leitura do DynamoDB.

  • Implemente o hedging de solicitações: para requisitos de latência p99 muito baixos, considere a possibilidade de implementar o hedging de solicitações. Com o hedging de solicitações, se a solicitação inicial não receber uma resposta rápida o suficiente, envie uma segunda solicitação equivalente e deixe-as competir. A primeira resposta vence. Isso melhora a latência de cauda às custas de algumas solicitações extras. Você pode decidir quanto tempo esperar antes de enviar a segunda solicitação. O hedging é mais fácil para leituras. No caso de gravações, use ordenação baseada em carimbo de data/hora para garantir que as solicitações com hedging sejam tratadas como se estivessem ocorrendo no momento da primeira tentativa, evitando atualizações fora de ordem. Essa abordagem foi discutida em Timestamp writes for write hedging in Amazon DynamoDB.

  • 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 projetado com a redundância em mente. Considere os seguintes aspectos:

    • Resiliência de rede

    • Tempos limite de pacotes TCP

    • Arquitetura distribuída do DynamoDB

    Os comportamentos padrão do SDK são otimizados para a maioria das aplicações. No entanto, você pode implementar uma estratégia para antecipar-se à falha e ajustar as configurações de tempo limite. As solicitações que demoram bem mais que o normal têm menor probabilidade de serem bem-sucedidas. Ao antecipar-se à falha e tentar novamente, você pode ter êxito rapidamente por um caminho diferente. Isso é semelhante ao hedging de solicitações, mas encerra a primeira solicitação em vez de permitir que ela prossiga.

    Evite definir um valor de tempo limite muito alto. Tempos limite excessivamente baixos podem gerar problemas de disponibilidade induzidos pelo cliente. Por exemplo, um tempo limite de soquete de 50 milissegundos pode causar erros de conexão durante picos de latência da rede, como quando se chega próximo aos limites de largura de banda da instância do Amazon EC2 para tráfego de fluxo único. Avalie cuidadosamente os benefícios de um tempo limite mais baixo em relação aos possíveis riscos à disponibilidade da aplicação e prefira o hedging aos tempos limite curtos.

    Para ver uma discussão útil sobre esse problema, consulte Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications.

  • 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 replicar a tabela para as regiões da AWS especificadas em que você deseja que ela esteja disponível. Você pode colocar uma cópia dos dados mais perto do usuário final para reduzir a latência de rede durante operações de leitura e gravação. Para ter mais informações sobre o uso eficaz das tabelas globais do DynamoDB, consulte Using Amazon DynamoDB global tables em “Recomendações da AWS”.

  • Use o armazenamento em cache: se houver muitas operações de leitura no tráfego, considere usar um serviço de armazenamento em cache:

    • O DynamoDB Accelerator (DAX) é um cache em memória totalmente gerenciado e altamente disponível para o DynamoDB que oferece um desempenho até dez vezes melhor, de milissegundos para microssegundos, mesmo com milhões de solicitações por segundo. Para ter mais informações sobre o DAX, consulte Aceleração em memória com o DynamoDB Accelerator (DAX).

    • Amazon ElastiCache: um serviço de armazenamento em cache em memória totalmente gerenciado que pode ser integrado ao DynamoDB para melhorar o desempenho de leitura usando o padrão de carregamento lento (cache-aside). Para ter mais informações, consulte Integrating Amazon DynamoDB and Amazon ElastiCache by using read-through caching em “Recomendações da AWS”.