Escolha do tamanho do nó - Amazon ElastiCache
Tamanho do nó (Valkey e Redis OSS)Tamanho do nó (Memcached)

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Escolha do tamanho do nó

O tamanho do nó que você seleciona para seu ElastiCache cluster afeta os custos, o desempenho e a tolerância a falhas.

Tamanho do nó (Valkey e Redis OSS)

Para receber informações sobre os benefícios dos processadores Graviton, consulte Processador Graviton da AWS.

Responder às seguintes perguntas poderá ajudá-lo a determinar o tipo mínimo de nó de que você precisa para sua implementação do Valkey ou Redis OSS:

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

    Se for esse 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 de E/S aprimorado, quando disponível, usado para descarregar CPUs as conexões do cliente, em nome do mecanismo Redis OSS. Se você estiver executando o Redis OSS versão 7.0.4 ou posterior, além da E/S aprimorada, você obterá aceleração adicional com multiplexação de E/S aprimorada, em que cada thread de E/S de rede dedicado canaliza 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 threads de E/S aprimorada 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 acaba sendo encaminhado para o thread 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?

    Caso a resposta seja afirmativa e seu sistema esteja em execução no mecanismo Redis OSS versão 6.2 ou posterior, você pode aproveitar a classificação de dados em níveis 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 obter mais informações, consulte Hierarquização de dados em ElastiCache.

    Para obter 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 obter mais informações, consulte Tipos de nó compatíveis.

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

    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 que o processo anterior.

    Para obter mais informações, consulte:

  • 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 Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS.

  • Sua implementação será um cluster autônomo do Valkey ou Redis OSS (modo cluster desabilitado) ou um cluster do Valkey ou Redis OSS (modo cluster habilitado) com vários fragmentos?

    Cluster do Valkey ou Redis OSS (modo cluster desabilitado)

    Se você estiver implementando um cluster do Valkey ou Redis OSS (modo cluster desabilitado), seu tipo de nó deve ser capaz de acomodar todos os seus dados mais a sobrecarga necessária, conforme descrito anteriormente.

    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.

    Valkey ou Redis OSS (modo cluster habilitado) com vários fragmentos

    Se você estiver implementando um cluster do Valkey ou Redis OSS (modo cluster habilitado) com vários fragmentos, o tipo de nó deve 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:

    • Geração atual:

      Tipos de nó M5: cache.m5.large, cache.m5.xlarge, cache.m5.2xlarge, cache.m5.4xlarge, cache.m5.12xlarge, cache.m5.24xlarge

      Tipos de nó R5: cache.r5.large, cache.r5.xlarge, cache.r5.2xlarge, cache.r5.4xlarge, cache.r5.12xlarge, cache.r5.24xlarge

      Tipos de nó T3: cache.t3.micro, cache.t3.small, cache.t3.medium

Enquanto seu cluster está em execução, você pode monitorar as métricas de uso de memória, utilização do processador, acertos de cache e erros de cache que são publicadas em. CloudWatch Você pode notar que seu cluster não tem a taxa de acertos desejada ou que as chaves estão sendo removidas com muita frequência. Nesses casos, você pode escolher um tamanho de nó diferente com especificações de CPU e memória maiores.

Ao monitorar o uso da CPU, lembre-se que o Valkey e o Redis OSS são de thread único. Assim, multiplique o uso da CPU relatado pelo número de núcleos da CPU para obter esse uso real. Por exemplo, uma CPU de quatro núcleos que informa uma taxa de uso de 20% é, na verdade, o único núcleo que o Redis OSS está executando com 80% de utilização.

Tamanho do nó (Memcached)

Os clusters Memcached contêm um ou mais nós com os dados do cluster particionados entre os nós. Por isso, as necessidades de memória do cluster e de memória de um nó estão relacionadas, mas não são idênticas. Você pode obter a capacidade de memória de cluster necessária tendo alguns nós grandes ou vários nós menores. Além disso, conforme suas necessidades mudarem, você poderá adicionar ou remover nós do cluster e, assim, pagar apenas pelo que precisa.

A capacidade de memória total do cluster é calculada multiplicando o número de nós no cluster pela capacidade de RAM de cada nó, depois de deduzir as despesas gerais do sistema. A capacidade de cada nó é baseada no tipo de nó.

cluster_capacity = number_of_nodes * (node_capacity - system_overhead)

O número de nós no cluster é um fator chave na disponibilidade do seu cluster executando o Memcached. A falha de um único nó pode ter um impacto na disponibilidade da sua aplicação e na carga do seu banco de dados de backend. Nesse caso, ElastiCache provisiona um substituto para um nó com falha e ele é repovoado. Para reduzir esse impacto na disponibilidade, espalhe sua memória e capacidade de computação ao redor de um número maior de nós com menor capacidade, em vez de usar um número menor de nós de alta capacidade.

Em um cenário em que você deseja ter 35 GB de memória cache, você pode definir qualquer uma das seguintes configurações:

  • 11 nós cache.t2.medium com 3,22 GB de memória e 2 threads cada = 35,42 GB e 22 threads.

  • 6 nós cache.m4.large com 6,42 GB de memória e 2 threads cada = 38,52 GB e 12 threads.

  • 3 nós cache.r4.large com 12,3 GB de memória e 2 threads cada = 36,90 GB e 6 threads.

  • 3 nós cache.m4.xlarge com 14,28 GB de memória e 4 threads cada = 42,84 GB e 12 threads.

Comparar opções de nós
Tipo de nó Memória (em GB) Núcleos Custo horário* Nós necessários Memória total (em GB) Total de núcleos Custo mensal 
cache.t2.medium 3.22 2 0,068 USD 11 35,42 22 US$ 538,56
cache.m4.large 6,42 2 0,156 USD 6 38,52 12 US$ 673,92
cache.m4.xlarge 14,28 4 0,311 USD 3 42,84 12 671,76 USD
cache.m5.xlarge 12,93 4 0,311 USD 3 38,81 12 671,76 USD
cache.m6g.large 6,85 2 US$ 0,147 6 41.1 12 $635
cache.r4.large 12.3 2 0,228 USD 3 36,9 6 492,48 USD
cache.r5.large 13.07 2 US$ 0,216 3 39,22 6 US$ 466,56
cache.r6g.large 13.07 2 US$ 0,205 3 42,12 6 $442
* Custo horário por nó em 8 de outubro de 2020.
Custo mensal a 100% de uso por 30 dias (720 horas).

Essas opções oferecem uma capacidade de memória semelhante, mas uma capacidade e custo computacional diferentes. Para comparar os custos de suas opções específicas, consulte os ElastiCache preços da Amazon.

Para clusters executados no Memcached, algumas das memórias disponíveis em cada nó são usadas para sobrecarga de conexão. Para obter mais informações, consulte Sobrecarga de conexões do Memcached

O uso de vários nós exigirá a distribuição das chaves entre eles. Cada nó possui seu próprio endpoint. Para facilitar o gerenciamento de endpoints, você pode usar ElastiCache o recurso Auto Discovery, que permite que os programas cliente identifiquem automaticamente todos os nós em um cluster. Para obter mais informações, consulte Identificar automaticamente nós no seu cluster (Memcached).

Em alguns casos, você pode não ter certeza de quanta capacidade precisa. Em caso afirmativo, para testes recomendamos começar com um nó cache.m5.large. Em seguida, monitore o uso da memória, a utilização da CPU e a taxa de acerto do cache com ElastiCache as métricas publicadas na Amazon CloudWatch. Para obter mais informações sobre CloudWatch métricas para ElastiCache, consulteMonitorando o uso com CloudWatch métricas. Para produção e maiores workloads, os nós R5 fornecem o melhor desempenho e valor de custo de RAM.

Se o seu cluster não tiver a taxa de acerto desejada, você poderá adicionar facilmente mais nós, aumentando assim a memória total disponível no seu cluster.

Se o seu cluster for limitado por CPU, mas tiver taxa de acerto suficiente, tente configurar um novo cluster com um tipo de nó que forneça mais poder computacional.