Escolha do tamanho do nó - Amazon ElastiCache
Tamanho do nó (Valkey e RedisOSS)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 RedisOSS)

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

Responder às perguntas a seguir pode ajudá-lo a determinar o tipo mínimo de nó necessário para sua implementação do Valkey ou do RedisOSS:

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

    Se esse for o caso e você estiver executando a OSS versão 5.0.6 ou superior do Redis, 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 do Redis. OSS Se você estiver executando a OSS versão 7.0.4 ou superior do Redis, 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 dedicado envia comandos de vários clientes para o OSS mecanismo do Redis, aproveitando a capacidade do Redis de processar comandos em lotes com eficiência. OSS No ElastiCache (RedisOSS) 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 OSS binário do Redis, 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 OSS do mecanismo Redis, você pode aproveitar a hierarquização de dados escolhendo o tipo de nó r6gd. Com o armazenamento de dados em camadas, 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 você OSS está executando?

    OSSAs versões do Redis 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.

    A OSS versão 2.8.22 e posterior do Redis usa 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 a captura de um instantâneo, a sincronização de um cluster primário com uma réplica em um cluster e a ativação do recurso append-only file (). 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 Valkey ou do Redis OSS.

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

    Cluster Valkey ou Redis OSS (modo de cluster desativado)

    Se você estiver implementando um cluster Valkey ou 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.

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

    Se você estiver implementando um cluster Valkey ou 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:

    • 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 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 maiores CPU e de memória.

Ao monitorar o CPU uso, lembre-se de que o Valkey e o Redis OSS são de um único thread. Assim, multiplique o CPU uso relatado pelo número de CPU núcleos para obter esse uso real. Por exemplo, um CPU relatório de quatro núcleos com uma taxa de uso de 20% é, na verdade, o único núcleo que o Redis OSS está funcionando 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 total de memória do seu cluster é calculada multiplicando o número de nós no cluster pela RAM capacidade de cada nó após deduzir a sobrecarga 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 Identifique automaticamente os nós em 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, CPU a utilização 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 cargas de trabalho maiores, os nós R5 oferecem o melhor desempenho e a melhor relação RAM custo-benefício.

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 seu cluster estiver limitado, CPU mas tiver uma taxa de acerto suficiente, configure um novo cluster com um tipo de nó que forneça mais potência computacional.