Como solucionar problemas de alta latência em clusters do DynamoDB Accelerator (DAX)?

Resolução

Há vários motivos pelos quais você pode receber latência nas suas solicitações. Consulte cada um dos possíveis problemas abaixo para solucionar sua latência.

O cluster ou nó está com alta carga

A latência geralmente é causada por um cluster ou nó que está passando por uma alta carga no cluster do DAX. Essa latência pode ser afetada ainda mais se você tiver seu cliente configurado para um URL de nó único em vez do URL do cluster. Nesse caso, se o nó estiver sofrendo algum problema durante uma carga alta, as solicitações do cliente sofrerão latência ou limitação.

Para resolver a latência e a limitação causadas por uma alta carga em clusters ou nós únicos, use a escalabilidade horizontal ou a escalabilidade vertical.

Configuração incorreta no cliente DAX

Se você diminuir o parâmetro withMinIdleConnectionSize, é provável que a latência no cluster do DAX aumente. Esse parâmetro define o número mínimo de conexões ociosas com o cluster do DAX. Para cada solicitação, o cliente usará uma conexão ociosa disponível. Se uma conexão não estiver disponível, o cliente estabelecerá uma nova. Por exemplo, se o parâmetro estiver definido como 20, haverá um mínimo de 20 conexões ociosas com o cluster do DAX.

O cliente mantém um grupo de conexões. Quando uma aplicação faz uma chamada de API para o DynamoDB ou DAX, o cliente concede uma conexão do grupo de conexões. Em seguida, o cliente faz a chamada de API e retorna a conexão com o grupo. No entanto, o grupo de conexões tem um limite superior. Se você fizer muitas chamadas de API para o DAX de uma só vez, elas poderão exceder o limite do grupo de conexões. Nesse caso, algumas solicitações devem aguardar a conclusão de outras solicitações antes de obter concessões do grupo de conexões. Isso resulta em solicitações enfileiradas no nível do grupo de conexões. Como resultado, a aplicação passa por um aumento na latência de ida e volta.

Portanto, para diminuir os picos de tráfego periódicos na sua aplicação, ajuste os parâmetros setMinIdleConnectionSize, getMinIdleConnectionSize e withMinIdleConnectionSize. Esses parâmetros desempenham um papel fundamental na latência de um cluster do DAX. Configure-os para suas chamadas de API de forma que o DAX use um número apropriado de conexões ociosas sem a necessidade de restabelecer novas conexões.

Itens perdidos no cache

Se uma solicitação de leitura perder um item, o DAX enviará essa solicitação ao DynamoDB. O DynamoDB processa as solicitações usando leituras finais consistentes e, em seguida, retorna os itens ao DAX. O DAX os armazena no cache do item e depois os retorna à aplicação. A latência na tabela subjacente do DynamoDB pode causar latência na solicitação.

Falhas de cache geralmente acontecem por dois motivos:

1.    Leituras altamente consistentes: leituras: leituras altamente consistentes do mesmo item não são armazenadas em cache pelo DAX. Isso resulta em uma perda de cache, pois as entradas ignoram o DAX e são recuperadas da própria tabela do DynamoDB. Você pode usar leituras finais consistentes para resolver esse problema, mas observe que o DynamoDB deve primeiro ler os dados para que os dados sejam armazenados em cache.

2.    Política de remoção no DAX: dados consultados que já foram removidos do cache resultam em uma falha. O DAX usa três valores diferentes para determinar as remoções de cache:

• Os clusters do DAX usam um algoritmo LRU (Least Recently Used) para priorizar itens. Os itens com a prioridade mais baixa serão removidos quando o cache ficar cheio.
• O DAX usa um valor de tempo de vida útil (TTL) para o período em que os itens estão disponíveis no cache. Depois que o valor TTL de um item é excedido, o item é removido.
  Observação: se você estiver usando o valor TTL padrão de cinco minutos, verifique se você está consultando os dados após o tempo de TTL.
• O DAX usa a a funcionalidade de gravação para eliminar valores antigos à medida que novos valores são gravados. Isso ajuda a manter o cache do item do DAX consistente com o datastore subjacente usando uma única chamada de API.

Para estender o valor TTL dos seus itens, consulte Definir configurações de TTL.
Observação: você não pode modificar um grupo de parâmetros enquanto ele estiver em uso em uma instância do DAX em execução.

Falhas de cache também podem ocorrer quando os patches de manutenção são aplicados a um cluster do DAX. Use vários clusters de nós para reduzir esse tempo de inatividade.

Janelas de manutenção

Pode ocorrer latência durante a janela de manutenção semanal, especialmente se houver atualizações de software, patches ou alterações de sistema nos nós do cluster. Na maioria dos casos, as solicitações são tratadas com êxito por outros nós disponíveis que não estão em manutenção. Um cluster com muitas solicitações durante uma manutenção pesada pode apresentar falhas.

Para reduzir as chances de latência ou falha, configure a janela de manutenção para seu horário fora de pico. Isso permite que o cluster seja atualizado durante um período de menor carga de solicitações.

Latência na tabela do DynamoDB

Com operações de gravação, os dados são gravados primeiro na tabela do DynamoDB e depois no cluster do DAX. A operação é bem-sucedida somente se os dados são gravados com êxito na tabela e no DAX. A latência na tabela subjacente do DynamoDB pode causar latência na solicitação. Para reduzir essa latência, consulte Como solucionar problemas de alta latência em uma tabela do Amazon DynamoDB?

Para configurar ainda mais o DynamoDB de acordo com os requisitos de latência da sua aplicação, consulte Ajustar configurações de solicitação HTTP do AWS Java SDK para aplicações do Amazon DynamoDB com reconhecimento de latência.

Período limite da solicitação

O parâmetro setIdleConnectionTimeout determina o período de tempo limite para conexões ociosas e setConnectTimeout determina o período de tempo limite para conexões com o cluster do DAX. Esses dois parâmetros lidam com os tempos limite dos grupos de conexão, o que pode afetar a latência do seu cluster.

Configure o tempo limite da solicitação para conexões com o cluster do DAX ajustando o parâmetro setRequestTimeout. Para obter mais informações, consulte setRequestTimeout na documentação do DAX.

Também é uma boa prática usar novas tentativas de recuo exponencial, que reduzem os erros de solicitação e também os custos operacionais.

Observação: o DAX não oferece suporte à latência do cluster no CloudWatch Metrics.

---