Como o ElastiCache funciona - Amazon ElastiCache

Como o ElastiCache funciona

Aqui você pode encontrar uma visão geral dos principais componentes de uma implantação do ElastiCache.

Cache e mecanismos de cache

Um cache é um armazenamento de dados na memória que é possível usar para armazenar dados em cache. Normalmente, a aplicação vai armazenar em cache os dados mais acessados em um cache para otimizar os tempos de resposta. O ElastiCache oferece duas opções de implantação: caches de tecnologia sem servidor e clusters baseados em nós. Consulte Escolha entre opções de implantação.

nota

O Amazon ElastiCache funciona com os mecanismos Valkey, Memcached e Redis OSS. Se não souber qual mecanismo deseja usar, consulte Comparação de clusters Valkey, Memcached e Redis OSS baseados em nós neste guia.

Como o ElastiCache funciona

ElastiCache Sem Servidor

O ElastiCache sem servidor permite a você criar um cache sem se preocupar com planejamento de capacidade, gerenciamento de hardware ou projeto de cluster. Basta fornecer um nome para o cache, e você receberá um único endpoint que pode ser configurado no cliente do Valkey, Memcached, Redis OSS para começar a acessar o cache.

nota
  • O ElastiCache com tecnologia sem servidor executa Valkey, Memcached ou Redis OSS em modo de cluster e é compatível apenas com clientes compatíveis com TLS.

Benefícios principais

  • Sem planejamento de capacidade: o ElastiCache Sem Servidor elimina a necessidade de você planejar a capacidade. O ElastiCache Sem Servidor monitora continuamente a utilização de memória, computação e largura de banda de rede do cache e escala vertical e horizontalmente. Ele permite que um nó de cache cresça e, paralelamente, inicia uma operação de aumento de escala horizontal para garantir que o cache possa escalar para atender aos requisitos da aplicação em todos os momentos.

  • Pagamento por uso: com o ElastiCache Sem Servidor, você paga pelos dados armazenados e pela computação utilizadas pela workload no cache. Consulte Dimensões de preço.

  • Alta disponibilidade: o ElastiCache Sem Servidor replica automaticamente os dados em várias zonas de disponibilidade (AZ) para obter alta disponibilidade. Ele monitora automaticamente os nós de cache subjacentes e os substitui em caso de falhas. Ele oferece um SLA de disponibilidade de 99,99% para cada cache.

  • Atualizações de software automáticas: o ElastiCache Sem Servidor atualiza automaticamente o cache para a versão secundária mais recente e de software de patch sem nenhum impacto sobre a disponibilidade da aplicação. Quando uma nova versão principal estiver disponível, o ElastiCache vai enviar uma notificação para você.

  • Segurança: o ElastiCache Sem Servidor sempre criptografa os dados em trânsito e em repouso. É possível usar uma chave gerenciada pelo serviço ou usar a própria chave gerenciada pelo cliente para criptografar dados em repouso.

O diagrama a seguir mostra como o ElastiCache Sem Servidor funciona.

Um diagrama da operação de cache do ElastiCache Sem Servidor, das zonas de disponibilidade até a VPC do cliente e, em seguida, até a VPC do serviço.

Quando você cria um novo cache sem servidor, o ElastiCache cria um endpoint da nuvem privada virtual (VPC) nas sub-redes de sua preferência na VPC. A aplicação pode se conectar ao cache por meio desses endpoints da VPC.

Com o ElastiCache Sem Servidor, você recebe um único endpoint de DNS ao qual a aplicação se conecta. Quando você solicitar uma nova conexão com o endpoint, o ElastiCache Sem Servidor processará todas as conexões de cache por meio de uma camada de proxy. A camada proxy ajuda a reduzir a configuração do cliente complexa, porque o cliente não precisa redescobrir a topologia do cluster em caso de alterações no cluster subjacente. A camada proxy é um conjunto de nós proxy que processam conexões usando um balanceador de carga da rede.

Quando a aplicação cria uma nova conexão de cache, a solicitação é enviada para um nó proxy pelo balanceador de carga da rede. Quando a aplicação executa comandos de cache, o nó proxy conectado à aplicação executa as solicitações em um nó de cache no cache. A camada proxy abstrai a topologia do cluster e os nós do cliente. Isso permite que o ElastiCache balanceie a carga, aumente a escala horizontalmente e adicione novos nós de cache de maneira inteligente, substitua os nós de cache em caso de falha e atualize o software nos nós de cache, tudo sem afetar a disponibilidade da aplicação ou precisar redefinir as conexões.

Clusters baseados em nós

Você pode criar um cluster do ElastiCache baseado em nós escolhendo uma família de nós de cache, tamanho e número de nós para o cluster. Criar um cluster baseado em nós proporciona um controle mais refinado e permite a você escolher o número de fragmentos no cache e o número de nós (primário e réplica) em cada fragmento. Você pode optar por operar o Valkey ou Redis OSS em modo de cluster criando um cluster com vários fragmentos ou em modo sem cluster com um único fragmento.

Benefícios principais

  • Crie um cluster baseado em nós: com o ElastiCache, é possível criar um cluster baseado em nós e escolher onde deseja colocar os nós de cache. Por exemplo, se tiver uma aplicação que deseja trocar a alta disponibilidade pela baixa latência, você poderá optar por implantar os nós de cache em uma única AZ. Como alternativa, é possível criar um cluster baseado em nós em várias AZs para obter alta disponibilidade.

  • Controle refinado: ao criar um cluster baseado em nós, você tem mais controle sobre o ajuste fino das configurações no cache. Por exemplo, é possível usar Parâmetros do Valkey e do Redis OSS or Parâmetros específicos do Memcached para configurar o mecanismo de cache.

  • Escalar vertical e horizontalmente: você pode optar por escalar manualmente o cluster aumentando ou diminuindo o tamanho do nó de cache quando necessário. Você também pode escalar horizontalmente ao adicionar novos fragmentos ou adicionar mais réplicas aos fragmentos. Também é possível usar o recurso ajuste de escala automático para configurar o escalonamento com base em uma programação ou o escalonamento com base em métricas como uso de CPU e memória no cache.

O diagrama a seguir ilustra como funcionam os clusters baseados em nós do ElastiCache.

Um diagrama da operação de clusters baseados em nós do ElastiCache, das zonas de disponibilidade até a VPC do cliente e, em seguida, até os nós de cache gerenciados pelo ElastiCache.

Dimensões de preço

É possível implantar o ElastiCache em duas opções de implantação. Ao implantar o ElastiCache Sem Servidor, você paga pelo uso de dados armazenados em GB/hora e pela computação nas unidades de processamento do ElastiCache (ECPU). Ao criar um cluster baseado em nós, você paga por hora de uso do nó de cache. Consulte detalhes de preço aqui.

Armazenamento de dados

Você paga pelos dados armazenados no ElastiCache Sem Servidor cobrados em gigabytes por hora (GB-h). O ElastiCache Sem Servidor monitora continuamente os dados armazenados no cache, fazendo amostragens várias vezes por minuto, e calcula uma média horária para determinar o uso do armazenamento de dados do cache em GB-h. Cada cache do ElastiCache Sem Servidor é medido por pelo menos 1 GB de dados armazenados.

Unidades de processamento do ElastiCache (ECPUs)

Você paga pelas solicitações executadas pela aplicação no ElastiCache Sem Servidor em unidades de processamento do ElastiCache (eCPUs), uma unidade que inclui o tempo de vCPU e os dados transferidos.

  • Leituras e gravações simples exigem um ECPU para cada quilobyte (KB) de dados transferidos. Por exemplo, um comando GET que transfere até 1 KB de dados consome uma ECPU. Uma solicitação SET que transfere 3,2 KB de dados vai consumir 3,2 eCPUs.

  • Com Valkey e Redis OSS, comandos que consomem mais tempo de vCPU e transferem mais dados consomem eCPUs com base na maior das duas dimensões. Por exemplo, se usar o comando HMGET e consumir três vezes mais tempo de vCPU do que um simples comando SET/GET e transferir 3,2 KB de dados, a aplicação consumirá 3,2 eCPUs. Como alternativa, se só transferir 2 KB de dados, ela consumirá três eCPUs.

  • Com Valkey e Redis OSS, comandos que exigem tempo de vCPU adicional consumirão proporcionalmente mais eCPUs. Por exemplo, se usar o comando HMGET do Valkey ou Redis OSS e consumir três vezes mais tempo de vCPU do que um simples comando SET/GET, a aplicação consumirá três eCPUs.

  • Com o Memcached, comandos que atuam em vários itens vão consumir proporcionalmente mais eCPUs. Por exemplo, se realizar um multiget em três itens, a aplicação vai consumir três eCPUs.

  • Com o Memcached, comandos que atuam em mais itens e transferem mais dados consomem eCPUs com base na maior das duas dimensões. Por exemplo, se a aplicação usar o comando GET, recuperar três itens e transferir 3,2 KB de dados, ela consumirá 3,2 ECPU. Como alternativa, se só transferir 2 KB de dados, ela consumirá três eCPUs.

O ElastiCache Sem Servidor emite uma nova métrica chamada ElastiCacheProcessingUnits que ajuda você a entender as eCPUs consumidas pela workload.

Horas de nó

Você pode criar um cluster baseado em nós escolhendo a família de nós do EC2, o tamanho, o número de nós e o posicionamento nas zonas de disponibilidade. Ao criar um cluster baseado em nós, você paga por hora para cada nó de cache.

Backups do ElastiCache

Um backup é uma cópia pontual de um cache com tecnologia sem servidor ou de um cluster baseado em nós pelo Valkey ou Redis OSS. O ElastiCache permite a você fazer um backup dos dados a qualquer momento ou configurar backups automáticos. Backups podem ser usados para restaurar um cache existente ou para propagar um novo cache. Backups consistem em todos os dados de um cache mais alguns metadados. Para obter mais informações, consulte Snapshots e restauração.