Escolha do tamanho do nó

Você espera workloads limitadas ao throughput com várias conexões de clientes?

Se esse for o caso e você estiver executando o Redis OSS versão 5.0.6 ou superior, você pode obter melhor taxa de transferência e latência com nosso recurso aprimorado de E/S, em que as CPUs disponíveis são usadas para descarregar as conexões do cliente, em nome do mecanismo Redis OSS. Se você estiver executando o Redis OSS versão 7.0.4 ou superior, além da E/S aprimorada, você obterá aceleração adicional com a multiplexação de E/S aprimorada, em que cada thread de E/S de rede dedicada envia comandos de vários clientes para o mecanismo Redis OSS, aproveitando a capacidade do Redis OSS de processar comandos em lotes com eficiência. No ElastiCache (Redis OSS) v7.1 e versões posteriores, ampliamos a funcionalidade aprimorada de threads de E/S para também lidar com a lógica da camada de apresentação. Por camada de apresentação, o que queremos dizer é que os encadeamentos de E/S aprimorados agora não estão apenas lendo a entrada do cliente, mas também analisando a entrada no formato de comando binário do Redis OSS, que é então encaminhado para o encadeamento principal para execução, proporcionando ganho de desempenho. Consulte a publicação do blog e a página de versões compatíveis para obter detalhes adicionais.

Você tem workloads que acessam regularmente um pequeno percentual de seus dados?

Se esse for o caso e você estiver executando a versão 6.2 ou posterior do mecanismo Redis OSS, você pode aproveitar a hierarquização de dados escolhendo o tipo de nó r6gd. Com a classificação de dados em níveis, os dados usados menos recentemente são armazenados em SSD. Quando eles são recuperados, há um pequeno custo de latência, que é equilibrado pela economia de custos. Para ter mais informações, consulte Classificação de dados em níveis.

Para ter mais informações, consulte Tipos de nó compatíveis.

Quanto de memória total você precisa para seus dados?

Para obter uma estimativa geral, tome o tamanho dos itens que você deseja armazenar em cache. Multiplique esse tamanho pelo número de itens que deseja manter no cache ao mesmo tempo. Para obter uma estimativa razoável do tamanho dos itens, primeiro serialize seus itens de cache, e depois conte os caracteres. Em seguida, divida isso pelo número de fragmentos no cluster.

Para ter mais informações, consulte Tipos de nó compatíveis.

Qual versão do Redis OSS você está executando?

As versões do Redis OSS anteriores à 2.8.22 exigem que você reserve mais memória para failover, snapshot, sincronização e promoção de uma réplica para operações primárias. Esse requisito é importante porque você deve ter memória suficiente disponível para todas as gravações que ocorrem durante o processo.

O Redis OSS versão 2.8.22 e posteriores usam um processo de salvamento sem bifurcação que requer menos memória disponível do que o processo anterior.

Para obter mais informações, consulte as informações a seguir.

Qual é a intensidade de gravação do seu aplicativo?

Gravar aplicativos pesados pode exigir significativamente mais memória disponível, memória não utilizada por dados, ao tirar snapshots ou fazer failover. Sempre que o processo BGSAVE for executado, você deve ter memória suficiente que não é usada pelos dados para acomodar todas as gravações que transpirem durante o processo BGSAVE. Exemplos são ao tirar um snapshot, ao sincronizar um cluster primário com uma réplica em um cluster e ao ativar o recurso de arquivo somente anexado (AOF). Outro exemplo acontece ao promover uma réplica para primária (se você tiver o Multi-AZ habilitado). O pior caso é quando todos os seus dados são reescritos durante o processo. Nesse caso, você precisa de um tamanho de instância de nó com o dobro da memória que é necessária para os dados isoladamente.

Para obter mais informações detalhadas, consulte Garantindo que você tenha memória suficiente para criar um instantâneo do Redis OSS.

Sua implementação será um cluster autônomo do Redis OSS (modo de cluster desativado) ou um cluster do Redis OSS (modo de cluster ativado) com vários fragmentos?

Cluster Redis OSS (modo de cluster desativado)

Se você estiver implementando um cluster Redis OSS (modo de cluster desativado), seu tipo de nó deve ser capaz de acomodar todos os seus dados, além da sobrecarga necessária, conforme descrito no bullet anterior.

Por exemplo, suponha que você estime que o tamanho total de todos os seus itens é de 12 GB. Nesse caso, você pode usar um nó cache.m3.xlarge com 13,3 GB de memória ou um nó cache.r3.large com 13,5 GB de memória. No entanto, talvez você precise de mais memória para operações BGSAVE. Se a sua aplicação for de escrita pesada, duplique os requisitos de memória para pelo menos 24 GB. Assim, use ou cache.m3.2xlarge com 27,9 GB de memória ou um cache.r3.xlarge com 30,5 GB de memória.

Redis OSS (modo de cluster ativado) com vários fragmentos

Se você estiver implementando um cluster Redis OSS (modo de cluster ativado) com vários fragmentos, o tipo de nó deverá ser capaz de acomodar bytes-for-data-and-overhead / number-of-shards bytes de dados.

Por exemplo, suponha que você estime que o tamanho total de todos os seus itens é de 12 GB e você tem dois fragmentos. Nesse caso, você pode usar um nó cache.m3.large com 6,05 GB de memória (12 GB/2). No entanto, talvez você precise de mais memória para operações BGSAVE. Se a sua aplicação for de escrita pesada, duplique os requisitos de memória para pelo menos 12 GB por fragmento. Assim, use ou cache.m3.xlarge com 13,3 GB de memória ou um cache.r3.large com 13,5 GB de memória.

Você está usando Local Zones?

As Zonas Locais permitem que você coloque recursos, como um ElastiCache cluster, em vários locais próximos aos seus usuários. Mas, ao escolher o tamanho do nó, esteja ciente de que os tamanhos de nó disponíveis estão limitados ao seguinte no momento, independentemente dos requisitos de capacidade: