P: O que é o Amazon ElastiCache para Redis?

Amazon ElastiCache para Redis é um serviço web que facilita a implementação e a execução de nós de servidor compatíveis com o protocolo Redis na nuvem. O serviço possibilita o gerenciamento, monitoramento e operação de um nó do Redis; a criação, exclusão e modificação do nó pode ser realizada por meio do console do ElastiCache, da interface de linha de comando ou das APIs do serviço web. O Amazon ElastiCache para Redis fornece suporte para replicação mestre/subordinado do Redis.

P: O Amazon ElastiCache para Redis apresenta compatibilidade de protocolo com o Redis de código aberto?

Sim, o Amazon ElastiCache para Redis apresenta compatibilidade de protocolo com o Redis de código aberto. Código, aplicativos, drivers e ferramentas que um cliente usa atualmente com seu armazenamento de dados do Redis independente continuarão a funcionar com o ElastiCache para Redis, sem necessidade de alterações de código para implementações do Redis existentes que estiverem migrando para o ElastiCache para Redis, exceto onde se observar o contrário. No momento, aceitamos as seguintes versões do Redis: 2.6.13, 2.8.6, 2.8.19, 2.8.21, 2.8.22, 2.8.23, 2.8.24, 3.2.4, 3.2.6 e 3.2.10.

P: Quanto custa o Amazon ElastiCache for Redis?

Consulte a nossa página de definição de preço para obter informações atualizadas.

P: Quais são os nós, clusters e grupos de replicação do Amazon ElastiCache para Redis?

Um nó do ElastiCache para Redis é o menor componente de uma implementação do Amazon ElastiCache para Redis. Cada nó do ElastiCache para Redis é compatível com o protocolo Redis e tem sua porta e nome de DNS próprios. Há suporte para vários tipos de nós do ElastiCache para Redis, cada um com uma quantidade variada de capacidade de CPU e memória associada. Um nó do ElastiCache para Redis pode assumir uma função principal ou de réplica de leitura. Um nó principal pode ser replicado para vários nós de réplica de leitura. Um cluster do ElastiCache para Redis é um conjunto de um ou mais nós do ElastiCache para Redis com a mesma função; o nó principal estará no cluster principal e o nó de réplica de leitura estará em um cluster de réplica de leitura. Atualmente, um cluster só pode ter um nó. No futuro, aumentaremos esse limite. Um cluster gerencia um espaço de chave lógico, onde cada nó é responsável por uma parte do espaço de chave. A maioria de suas operações de gerenciamento será desempenhada no nível do cluster. Um grupo de replicação do ElastiCache para Redis encapsula os clusters principal e de réplica de leitura para uma instalação do Redis. Um grupo de replicação terá apenas um cluster principal e nenhum ou muitos clusters de réplica de leitura. Todos os nós dentro de um grupo de replicação (e consequentemente do cluster) serão do mesmo tipo e terão as mesmas configurações de parâmetro e grupo de segurança.

P: O Amazon ElastiCache para Redis é compatível com a persistência do Redis?

Sim, você pode obter persistência ao fazer um snapshot dos dados do Redis usando o recurso de backup e restauração. Clique aqui para obter mais detalhes.

P: Como eu posso migrar do Amazon ElastiCache para Memcached para o Amazon ElastiCache para Redis e vice-versa?

Atualmente não fornecemos suporte para a migração automática do Memcached para o Redis e vice-versa. Você pode, porém, usar um cliente Memcached para ler de um cluster do Memcached e usar um cliente Redis para gravar em um cluster do Redis. De maneira semelhante, você pode ler de um cluster do Redis usando um cliente Redis e usar um cliente Memcached para gravar em um cluster do Memcached. Lembre-se de considerar as diferenças no formato dos dados e na configuração do cluster entre os dois mecanismos.

P: O Amazon ElastiCache para Redis fornece suporte para operação Multi-AZ?

Sim, com o Amazon ElastiCache para Redis, você pode criar uma réplica de leitura em outra Zona de disponibilidade da AWS. Na falha do nó principal, provisionaremos um novo nó principal. Em cenários onde o nó principal não possa ser provisionado, você pode decidir qual réplica de leitura promoverá para ser o novo nó principal. Para obter mais detalhes sobre como lidar com falhas de nó, consulte aqui.

P: Quais opções o Amazon ElastiCache para Redis oferece para falhas de nó?

O Amazon ElastiCache para Redis reparará o nó obtendo novos recursos de serviços e depois redirecionará o nome de DNS existente do nó para que aponte para os novos recursos de serviços. Desse modo, o nome de DNS para um nó do Redis permanece constante, mas o endereço IP de um nó do Redis pode mudar com o tempo. Se você tem um grupo de replicação com uma ou mais réplicas de leitura e o Multi-AZ está ativado, caso ocorra uma falha de nó principal, o ElastiCache automaticamente detecta a falha, seleciona uma réplica e a promove para o novo nó principal. Além disso, o DNS é propagado para que você continue a usar o endpoint principal e, após a promoção, o DNS aponte para o nó principal recém-promovido. Para obter mais detalhes, consulte a seção Multi-AZ destas perguntas frequentes. Quando a opção de replicação do Redis é marcada e o Multi-AZ está desativado, se o nó principal falhar, você poderá optar por iniciar um failover para um nó de réplica de leitura. O destino do failover pode estar na mesma zona ou em outra. Para fazer o failback para a zona original, promova a réplica de leitura na zona original a principal. Você pode optar por projetar seu aplicativo de forma a forçar a biblioteca do cliente Redis a se reconectar ao nó de servidor do Redis reparado. Isso pode ajudar, pois algumas bibliotecas do Redis param de usar um servidor indefinidamente quando encontram erros de comunicação ou atingem o tempo limite.

P: Como funciona o failover?

Para grupos de replicação com Multi-AZ ativado, o comportamento de failover é descrito na seção Multi-AZ destas perguntas frequentes.

Se você prefere não ativar o Multi-AZ, e se o Amazon ElastiCache monitora o nó principal, e se este fica indisponível ou deixa de responder, o Amazon ElastiCache for Redis corrige o nó adquirindo novos recursos de serviço e redirecionando o nome DNS atual do nó para os novos recursos de serviços. Desse modo, o nome de DNS para um nó do Redis permanece constante, mas o endereço IP de um nó do Redis pode mudar com o tempo. Entretanto, se não for possível corrigir o nó principal (e Multi-AZ estiver desativado), você poderá optar por promover uma das réplicas de leitura para nó principal. Veja aqui como selecionar um novo nó principal. O registro DNS do endpoint do primário será atualizado para indicar o nó de réplica de leitura promovido. Um nó de réplica de leitura no AZ do nó principal original será criado para ser uma réplica de leitura no grupo de replicação e seguirá o novo nó principal. 

P: Minhas réplicas de leitura ficam disponíveis durante uma falha do nó principal?

Sim, durante uma falha do nó principal, as réplicas de leitura continuam a atender às solicitações. Depois que o nó principal é restaurado, seja como um nó corrigido ou como uma réplica de leitura promovida, há um breve período durante o qual as réplicas de leitura não atendem a nenhuma solicitação enquanto sincronizam as informações de cache do nó principal.

P: Como eu configuro os parâmetros dos meus nós do Amazon ElastiCache para Redis?

Você pode configurar sua instalação do Redis usando um grupo de parâmetros de cache, que deve ser especificado para um cluster do Redis. Todos os clusters de réplica de leitura usam o grupo de parâmetros de seu cluster principal. Um grupo de parâmetros do Redis age como um "contêiner" para valores de configuração do Redis que podem ser aplicados a um ou mais clusters principais do Redis. Se você criar um cluster principal do Redis sem especificar um grupo de parâmetros de cache, um grupo de parâmetros padrão será usado. Esse grupo padrão contém padrões para o tipo de nó que você planeja executar. Contudo, se você quer que seu cluster principal do Redis seja executado com valores de configuração especificados, basta criar um novo grupo de parâmetros de cache, modificar os parâmetros desejados e modificar o cluster do Redis principal para utilizar o novo grupo de parâmetros.

P: Eu posso acessar o Redis por meio do console do Amazon ElastiCache?

Sim, o Redis aparece como uma opção de mecanismo no console do ElastiCache. Você pode criar um novo cluster de cache do Redis com o Assistente de execução, escolhendo o mecanismo do Redis. Também é possível modificar ou excluir um cluster do Redis existente usando o console do ElastiCache.

P: É possível criar clusters do Amazon ElastiCache para Redis em uma Amazon VPC?

Sim. Se a sua conta for uma VPC por padrão, seus clusters do Redis serão criados na VPC padrão associada à sua conta. Usando o console do ElastiCache, é possível especificar uma VPC diferente quando você cria seu cluster.

P: A funcionalidade de senha do Redis tem suporte no Amazon ElastiCache para Redis?

Não, o Amazon ElastiCache para Redis não fornece suporte para senhas do Redis. Isso ocorre devido às limitações inerentes das senhas armazenadas em um arquivo de configuração. Em vez de depender das senhas do Redis, os clusters do ElastiCache para Redis são associados a um grupo de segurança do EC2, e somente clientes nesse grupo de segurança têm acesso ao servidor Redis.

P: Como fazer o upgrade para uma versão de mecanismo mais recente?

Você pode fazer o upgrade facilmente para uma versão mais recente ao usar as APIs ModifyCacheCluster ou ModifyReplicationGroup, e ao especificar sua versão de mecanismo preferencial para o parâmetro EngineVersion. No console do ElastiCache, é possível selecionar um cluster de cache ou um grupo de replicação e clicar em "Modify". Na janela "Modify Cache Cluster" ou "Modify Replication Group", selecione sua versão de mecanismo preferencial por meio das opções disponíveis. O processo de upgrade do mecanismo foi concebido para melhorar os esforços de retenção dos seus dados atuais e exige que a replicação do Redis seja bem-sucedida. Obtenha mais detalhes sobre isso aqui.

P: Posso fazer o downgrade para uma versão de mecanismo anterior?

Não. O downgrade para uma versão de mecanismo anterior não é sustentado.

P: Como faço para expandir para um tipo de nó maior?

Você pode expandir facilmente para um tipo de nó maior ao usar as APIs ModifyCacheCluster ou ModifyReplicationGroup, e ao especificar seu tipo de nó preferencial para o parâmetro CacheNodeType. No console do ElastiCache, é possível selecionar um cluster de cache ou um grupo de replicação e clicar em "Modify". Na janela "Modify Cache Cluster" ou "Modify Replication Group", selecione seu tipo de nó preferencial usando as opções disponíveis. O processo de expansão foi concebido para melhorar os esforços de retenção dos seus dados atuais e exige que a replicação do Redis seja bem-sucedida. Obtenha mais detalhes sobre isso aqui.

P: Posso reduzir para um tipo de nó menor?

No momento, a redução para um tipo de nó menor não é sustentada.


P: O que significa executar um nó de cache do Redis como uma réplica de leitura?

As réplicas de leitura têm duas finalidades no Redis:

  • Processamento de falhas
  • Escalabilidade de leitura

Quando você executa um nó de cache com uma réplica de leitura, o nó "principal" atende a solicitações de gravações e leituras. A réplica de leitura funciona como "espera", que é "promovida" em cenários de failover. Após um failover, o nó em espera se torna o principal e aceita suas operações de cache. As réplicas de leitura também facilitam a expansão elástica além das restrições de capacidade de um único nó de cache, para cargas de trabalho de cache com uso intenso de leitura.

P: Quando seria interessante considerar o uso de uma réplica de leitura do Redis?

Há inúmeros casos em que implementar uma ou mais réplicas de leitura para um determinado nó principal pode fazer sentido. Razões comuns para implementar uma réplica de leitura incluem:

  • Expandir além da capacidade computacional ou de E/S de um único nó principal para cargas de trabalho com uso intenso de leitura. Esse tráfego de leitura excessivo pode ser direcionado a uma ou mais réplicas de leitura.
  • Atender ao tráfego de leitura enquanto o nó principal está indisponível. Se seu nó principal não consegue atender às solicitações de E/S (por exemplo, devido à suspensão de E/S para backups ou manutenção programada), é possível direcionar o tráfego de leitura para suas réplicas de leitura. Para esse tipo de uso, lembre-se de que os dados na réplica de leitura podem estar "desatualizados", já que a instância principal está indisponível. A réplica de leitura também pode ser usada no preparo para reiniciar um nó principal com falha.
  • Cenários de proteção de dados: na hipótese improvável de falha do nó primário ou da indisponibilidade da zona de disponibilidade onde reside o nó primário, você pode promover uma réplica de leitura em uma outra zona de disponibilidade para que ela se torne o novo nó primário.

P: Como eu implanto um nó de réplica de leitura para um determinado nó de cache principal?

É possível criar uma réplica de leitura em alguns minutos utilizando uma API CreateReplicationGroup ou com alguns cliques no Amazon ElastiCache Management Console. Ao criar um grupo de replicação, você especifica o MasterCacheClusterIdentifier. O MasterCacheClusterIdentifier é o Identificador do cluster de cache "principal" do qual você deseja replicar. Então, você cria o cluster de réplica de leitura no grupo de replicação chamando a API CreateCacheCluster e especificando o ReplicationGroupIdentifier e o CacheClusterIdentifier do cluster mestre. Como no caso de um cluster de cache padrão, você também pode especificar a Zona de disponibilidade. Ao iniciar a criação de uma réplica de leitura, o Amazon ElastiCache faz um snapshot do seu cluster de cache principal e inicia a replicação. Como resultado, ocorrerá uma breve suspensão de E/S em seu cluster de cache principal à medida que ocorrer o snapshot. A suspensão de E/S geralmente dura em torno de um minuto.

As réplicas de leitura são tão fáceis de excluir quanto de criar; basta utilizar o Amazon ElastiCache Management Console ou chamar a API DeleteCacheCluster (especificando o CacheClusterIdentifier da réplica de leitura que você deseja excluir).

P: Posso criar um primário e réplicas de leitura ao mesmo tempo?

Sim. Você pode criar um novo cluster de cache juntamente com réplicas de leitura em minutos usando a API CreateReplicationGroup ou usando o assistente "Launch Cache Cluster" no Amazon ElastiCache Management Console selecionando "Multi-AZ Replication". Na criação do grupo de replicação, especifique um identificador para o grupo de replicação, o número total de clusters desejados no grupo de replicação e parâmetros de criação de cache, como tipo de nó de cache, versão de mecanismo de cache, etc. Você também pode especificar a zona de disponibilidade para cada cluster no grupo de replicação.

P: Como posso me conectar às minhas réplicas de leitura?

É possível se conectar a uma réplica de leitura da mesma maneira que a um nó de cache principal, utilizando a API DescribeCacheClusters ou o AWS Management Console para recuperar um ou mais endpoints para suas réplicas de leitura. Se você tem várias réplicas de leitura, seu aplicativo terá de determinar como o tráfego de leitura será distribuído entre elas.

P: Quantas réplicas de leitura eu posso criar para um determinado nó de cache principal?

Atualmente, o Amazon ElastiCache permite criar até 5 (cinco) réplicas de leitura para um determinado nó de cache principal.

P: O que acontece com as réplicas de leitura na ocorrência de failover?

Caso ocorra um failover, todas as réplicas de leitura associadas e disponíveis devem automaticamente retomar a replicação após a conclusão do failover (recebendo atualizações da réplica de leitura recém-promovida).

P: Posso criar uma réplica de leitura de outra réplica de leitura?

Não há suporte para criar uma réplica de leitura de outra Réplica de leitura.

P: Posso promover minha réplica de leitura para que se torne um nó de cache principal "independente"?

Não, essa opção não é compatível no momento. Em vez disso, você obter um snapshot do nó do ElastiCache para Redis (selecionando o nó principal ou qualquer réplica de leitura). Você pode utilizar o snapshot para criar um novo nó primário no ElastiCache para Redis.

P: Minha réplica de leitura se manterá atualizada com relação a seu nó de cache principal?

As atualizações para um nó de cache principal serão automaticamente replicadas a qualquer réplica de leitura associada. Contudo, com a tecnologia de replicação assíncrona do Redis, uma réplica de leitura pode ficar defasada em relação a seu nó de cache principal por vários motivos. Os principais motivos incluem:

  • O volume de E/S de gravação para o nó de cache principal excede a taxa na qual as alterações podem ser aplicadas à réplica de leitura
  • Partições de rede ou latência entre o nó de cache principal e uma réplica de leitura

As réplicas de leitura estão sujeitas aos pontos fortes e fracos da replicação do Redis. Se você está usando réplicas de leitura, deve estar ciente do potencial de defasagem entre uma réplica de leitura e seu nó de cache principal, ou "inconsistência". Clique aqui para ver orientações sobre como descobrir a "inconsistência" da sua réplica de leitura.

P: Como obtenho visibilidade das réplicas de leitura ativas?

Você pode utilizar a API DescribeCacheClusters padrão para retornar uma lista de todos os clusters de cache implementados (incluindo réplicas de leitura) ou simplesmente clicar na guia "Cache Clusters" do Amazon ElastiCache Management Console.

O Amazon ElastiCache monitora o status da replicação das suas réplicas de leitura e atualiza o campo Replication State com "Error" se a replicação é interrompida por qualquer motivo. É possível examinar os detalhes do erro associado gerado pelo mecanismo do Redis visualizando o campo Replication Error e executar as ações adequadas para recuperação. Você pode saber mais sobre a resolução de erros de replicação na seção Troubleshooting a Read Replica problem do Amazon ElastiCache User Guide. Se o erro de replicação é corrigido, o campo Replication State muda para Replicating.

O Amazon ElastiCache permite que você tenha visibilidade da defasagem de uma réplica de leitura em relação a seu nó principal por meio da métrica do Amazon CloudWatch ("Replica Lag"), disponível através do AWS Management Console ou das APIs do Amazon CloudWatch.

P: Minha réplica de leitura ficou significativamente defasada em relação a seu nó de cache principal. O que devo fazer?

Como abordado em perguntas anteriores, a "inconsistência" ou defasagem entre uma réplica de leitura e seu nó de cache principal é comum na replicação assíncrona do Redis. Se uma réplica de leitura existente ficou defasada demais para atender aos seus requisitos, você pode reinicializá-la. Lembre-se de que a defasagem da réplica pode aumentar e diminuir naturalmente ao longo do tempo, dependendo do padrão de uso de estado estável do seu nó de cache principal.

P: Como posso excluir uma réplica de leitura? Ela será excluída automaticamente se seu nó de cache principal for excluído?

Você pode facilmente excluir uma réplica de leitura com apenas alguns cliques no AWS Management Console ou ao passar seu identificador de cluster de cache para a API DeleteCacheCluster. Se desejar excluir a réplica de leitura além do nó de cache principal, você deverá usar a API DeleteReplicationGroup API ou o AWS Management Console.

P: Qual é o custo das réplicas de leitura? Quando começa e termina a cobrança?

Uma réplica de leitura é cobrada como um nó de cache padrão e com as mesmas taxas. Assim como um nó de cache padrão, a taxa por "hora de nó de cache" de uma réplica de leitura é determinada pela classe do nó de cache da réplica de leitura – visite a página de detalhes do Amazon ElastiCache para ver preços atualizados. Você não será cobrado pela transferência de dados que ocorrer na replicação de dados entre seu nó de cache principal e a réplica de leitura. A cobrança por uma réplica de leitura é iniciada assim que a réplica de leitura é criada com êxito (ou seja, quando o status for listado como "ativo"). A réplica de leitura continuará sendo cobrada com taxas por hora de nó de cache do Amazon ElastiCache padrão, até que você emita um comando para excluí-la.

P: O que acontece durante o failover e quanto tempo leva?

O failover iniciado é suportado pelo Amazon ElastiCache, para que você possa retomar as operações de cache o mais rápido possível. Ao ocorrer um failover, o Amazon ElastiCache simplesmente inverte o registro DNS do seu nó de cache para apontar para a réplica de leitura, que, por sua vez, é promovida e se torna o novo nó principal. Recomendamos que você siga as práticas recomendadas e implemente a repetição da conexão do nó de cache na camada de aplicativo. Do início ao fim, o failover geralmente é concluído em três minutos a seis minutos.

P: Posso criar uma réplica de leitura em outra região como meu nó principal?

Não. Sua réplica de leitura só pode ser provisionada em uma Zona de disponibilidade igual ou diferente da mesma Região do seu nó de cache principal.

P: É possível ver em qual zona de disponibilidade minha principal está situada atualmente?

Sim, é possível ter visibilidade da localização do nó principal atual utilizando o AWS Management Console ou a API DescribeCacheClusters.

Após o failover, minha principal agora está localizada em uma zona de disponibilidade diferente do que meus outros recursos AWS (por exemplo, instâncias EC2).

P: Devo me preocupar com a latência?

As zonas de disponibilidade são projetadas para fornecer conectividade de rede de baixa latência para outras zonas de disponibilidade na mesma região. Além disso, você tem a opção de criar seu aplicativo e outros recursos da AWS com redundância por meio de múltiplas zonas de disponibilidade para que seu aplicativo seja resistente no caso de uma falha de zona de disponibilidade.


P: O que é o Multi-AZ para um grupo de replicação do ElastiCache para Redis?

Um grupo de replicação do ElastiCache para Redis consiste em um primário e até cinco réplicas de leitura. O Redis replica os dados do primário para as réplicas de leitura de forma assíncrona. Durante determinados tipos de manutenção planejada, ou no improvável evento de uma falha no nó ElastiCache ou na zona de disponibilidade, o Amazon ElastiCache detectará automaticamente a falha de um primário, selecionará uma réplica de leitura e a promoverá para o novo primário. O ElastiCache também propaga as alterações de DNS da réplica de leitura promovida. Assim, se o seu aplicativo gravar no endpoint do nó primário, nenhuma alteração de endpoint será necessária.

P: Quais são os benefícios do uso do Multi-AZ?

Os principais benefícios da execução do ElastiCache para Redis no modo Multi-AZ são maior disponibilidade e menor necessidade de administração. Se ocorrer uma falha de nó primário do ElastiCache para Redis, o impacto na capacidade de ler/gravar no primário será limitado ao tempo necessário para a conclusão do failover automático. Quando o Multi-AZ é ativado, o failover do nó do ElastiCache é automático e não requer administração. Não é mais necessário monitorar os nós do Redis e iniciar manualmente uma recuperação no caso de uma falha do nó primário.

P: Como funciona o Multi-AZ?

Você pode usar o Multi-AZ se utiliza o ElastiCache para Redis e tem um grupo de replicação consistindo em um nó primário e uma ou mais réplicas de leitura. Se o nó primário falhar, o ElastiCache detectará automaticamente a falha, selecionará uma das réplicas de leitura disponíveis e a promoverá para o novo primário. O ElastiCache propagará as alterações de DNS da réplica promovida. Portanto, o seu aplicativo poderá continuar a gravar no endpoint primário. Além disso, o ElastiCache gerará um novo nó para substituir a réplica de leitura promovida na mesma zona de disponibilidade do primário que apresentou falha. Caso a falha do primário tenha sido motivada por uma falha temporária na zona de disponibilidade, a nova réplica será executada assim que a zona de disponibilidade for recuperada.

P: Posso ter réplicas na mesma zona de disponibilidade que o primário?

Sim. Observe que o posicionamento do primário e das réplicas na mesma zona de disponibilidade não tornará o grupo de replicação do ElastiCache para Redis resiliente a uma falha na zona de disponibilidade.

P: Que ventos podem causar o failover do Amazon ElastiCache para uma réplica de leitura?

O Amazon ElastiCache executará um failover para uma réplica de leitura caso ocorra um dos seguintes eventos:

  • Perda de disponibilidade na zona de disponibilidade principal
  • Perda de conectividade de rede para principal
  • Falha de unidade computacional na principal

P: Quando devo usar o Multi-AZ?

O uso da replicação do Redis juntamente com o Multi-AZ oferece maior disponibilidade e tolerância a falhas. Essas implementações são particularmente adequadas para uso em ambientes de produção.

P: Como posso criar um grupo de replicação do ElastiCache para Redis com o Multi-AZ ativado?

Você pode criar o primário e as réplicas de leitura do ElastiCache for Redis clicando em Launch Cache Cluster no ElastiCache Management Console. Além disso, você também pode chamar a API CreateReplicationGroup. Para os grupos de replicação atuais (Redis 2.8.6, 2.8.19, 2.8.21, 2.8.22, 2.8.23 e 2.8.24), você pode ativar o Multi-AZ escolhendo um grupo de replicação e clicando em Modify no Console de Gerenciamento do ElastiCache ou usando a API ModifyReplicationGroup. A alternância de um grupo de replicação para o Multi-AZ não causa falha nos dados do Redis e não interfere com a capacidade de atendimento de solicitações dos nós.

P: Qual réplica de leitura será promovida caso ocorra uma falha no nó primário?

Se houver mais que uma réplica de leitura, será promovida a que tiver a menor diferença de replicação assíncrona em relação ao primário.

P: Quanto custa usar o Multi-AZ?

O Multi-AZ é gratuito. Você pagará apenas pelos nós ElastiCache que utilizar.

P: Quais são as implicações de desempenho do Multi-AZ?

No momento, o ElastiCache usa o mecanismo de replicação nativa assíncrona do Redis e está sujeito a seus pontos fortes e limitações. Especificamente, quando uma réplica de leitura se conecta a um nó principal pela primeira vez, ou quando o nó principal é alterado, a réplica de leitura executa uma sincronização completa dos dados do nó primário, impondo uma carga sobre si mesma e sobre o mestre. Para obter detalhes adicionas a respeito da replicação do Redis, veja aqui

P: Quais os tipos de nó de cache compatíveis com o Multi-AZ?

Todos os tipos de nó de cache do ElastiCache disponíveis são compatíveis com o Multi-AZ, exceto as famílias T1 e T2.

P: Serei alertado quando ocorrer um failover automático?

Sim, o Amazon ElastiCache criará um evento para informá-lo da ocorrência de um failover automático. Você pode usar a API DescribeEvents para retornar informações sobre eventos relacionados ao seu nó do ElastiCache, ou clicar na seção Events do ElastiCache Management Console.

P: Após o failover, o primário passa a estar localizado em uma zona de disponibilidade diferente da dos meus outros recursos da AWS (por exemplo, instâncias do EC2). Devo preocupar-me com a latência?

As zonas de disponibilidade são projetadas para fornecer conectividade de rede de baixa latência para outras zonas de disponibilidade na mesma região. Você pode considerar a definição da arquitetura do seu aplicativo e de outros recursos da AWS com redundância em várias zonas de disponibilidade para que seu aplicativo seja resiliente no caso de uma falha de zona de disponibilidade.

P: Onde posso obter mais informações sobre o Multi-AZ?

Para obter mais informações sobre o Multi-AZ, consulte a documentação do ElastiCache.


P: O que é o Backup e Restore?

O Backup e Restore é um recurso que permite aos clientes criarem snapshots dos seus clusters do ElastiCache para Redis. O ElastiCache armazena os snapshots, permitindo que o usuário os utilize para restaurar clusters do Redis.

P: O que é um snapshot?

Um snapshot é uma cópia de todo o seu cluster do Redis em um determinado momento.

P: Por que preciso de snapshots?

A criação de snapshots pode ser útil no caso de perda de dados por falha nos nós ou também no caso improvável de ocorrência de uma falha de hardware. Outro motivo comum para utilizar backups é para fins de arquivamento. Os snapshots são armazenados no Amazon S3, que é um meio durável de armazenamento, o que significa que até mesmo um corte de energia não apagará os dados.

P: O que posso fazer com um snapshot?

Os snapshots podem ser usados para pré-carregar um cluster do ElastiCache para Redis com dados predefinidos.

P: Como o Backup e Restore funciona?

Quando um backup é iniciado, o ElastiCache cria um snapshot do cluster do Redis que pode ser utilizado mais tarde para recuperação ou arquivamento. O backup pode ser iniciado a qualquer momento ou pode ser configurado com frequência diária e um período de retenção de até 35 dias.

Ao escolher um snapshot para restaurar, um novo cluster do ElastiCache para Redis é criado e preenchido com os dados do snapshot. Dessa forma, é possível criar múltiplos clusters do ElastiCache para Redis a partir de um snapshot.

Atualmente, o ElastiCache usa o mecanismo nativo do Redis para criar e armazenar o snapshot na forma de um arquivo RDB.

P: Onde os meus snapshots são armazenados?

Os snapshots são armazenados no S3.

P: Como começar com o Backup e Restore?

Você pode optar pelo recurso de Backup e Restore pelo AWS Management Console, pelas APIs do ElastiCache (CreateCacheCluster, ModifyCacheCluster e ModifyReplicationGroup) ou pela CLI. O recurso pode ser ativado e desativado quando quiser.

P: Como especifico de qual cluster e nó do Redis quero fazer backup?

O Backup e Restore cria snapshots de clusters. O usuário pode especificar de qual cluster do ElastiCache para Redis o backup deve ser feito pelo AWS Management Console, CLI ou pela API CreateSnapshot. Em um grupo de replicação, é possível escolher o cluster primário ou qualquer uma das réplicas de leitura para fazer o backup. Recomendamos que os usuários ativem o backup em uma das suas réplicas de leitura para reduzir os efeitos da latência no nó principal do Redis.

P: Como posso especificar quando um backup deverá ser executado?

É possível especificar quando iniciar um backup individual ou recorrente através do AWS Management Console, CLI ou APIs. O usuário pode:

  • Criar um snapshot instantâneo (pelo botão do console “Create Snapshot” ou a API CreateSnapshot)
  • Configurar um backup diário automático. O backup será executado durante a sua janela de backups preferencial. Isso pode ser configurado pela criação ou modificação de um cluster pelo console ou pelas APIs CreateCacheCluster, ModifyCacheCluster ou ModifyReplicationGroup.

P: O que é uma janela de backup e por que ela é necessária?

O janela de backup preferencial é o período de tempo, definido pelo usuário, durante o qual o backup do cluster do ElastiCache para Redis será iniciado. Isso é útil para fazer backup em um momento específico durante o dia, ou não fazer backups durante um período de alta utilização.

P: Qual é o impacto no desempenho ao criar um snapshot?

Enquanto cria um snapshot, você pode verificar latências maiores no nó durante um breve período de tempo. Os snapshots usam o BGSAVE nativo do Redis e estão sujeitos aos seus pontos fortes e limitações. Em especial, o processo do Redis se divide e o pai continua servindo requisições enquanto o filho salva os dados no disco, e então termina. Essa divisão aumenta o uso de memória enquanto o snapshot é gerado. Quando este uso de memória ultrapassa a quantidade de memória disponível no nó de cache, a gravação da memória em disco (swapping) pode ser acionada, diminuindo mais o desempenho no nó. Por esse motivo, recomendamos a geração de snapshots em uma das réplicas de leitura (em vez do nó principal). Também sugerimos configurar parâmetro de memória reservada para minimizar a gravação de memória em disco. Clique aqui para obter mais detalhes.

P: Posso criar um snapshot a partir de uma réplica de leitura do ElastiCache para Redis?

Sim. A criação do snapshot a partir de uma réplica de leitura é a melhor forma de fazer backup dos dados minimizando o impacto no desempenho.

P: Em que regiões o recurso de Backup e Restore está disponível?

O recurso de Backup e Restore está disponível em todas as regiões em que o serviço de ElastiCache está disponível.

P: Posso exportar para um bucket do S3 de minha propriedade snapshots do ElastiCache para Redis?

Sim. Você pode exportar para um bucket autorizado do S3 na mesma região que o seu cluster snapshots do ElastiCache para Redis. Para obter mais detalhes sobre a exportação de snapshots e a definição de permissões exigidas, consulte aqui.

P: Posso copiar snapshots de uma região para outra?

Sim. Primeiro você deve copiar o snapshot em um bucket autorizado do S3 de sua escolha na mesma região e, então, usar a API de cópia do objeto PUT do S3 para copiá-lo em um bucket em outra região. Para obter mais detalhes sobre a cópia de objetos do S3, consulte aqui.

P: Tenho múltiplas contas da AWS utilizando o ElastiCache para Redis. Posso utilizar snapshots do ElastiCache de uma conta para pré-carregar um cluster do ElastiCache para Redis em outra conta?

Sim. Primeiro você deve copiar o snapshot em um bucket autorizado do S3 de sua escolha na mesma região e, então, conceder permissões de bucket entre contas para a outra conta. Para obter mais detalhes sobre permissões entre contas do S3, consulte aqui. Finalmente, especifique onde seu arquivo RDB está localizado no S3 durante a criação do cluster pelo Launch Cache Cluster Wizard no console ou pela API CreateCacheCluster.

P: Quando custa utilizar o Backup e Restore?

O Amazon ElastiCache oferece espaço de armazenamento para um snapshot gratuitamente para cada cluster ativo do ElastiCache para Redis. O armazenamento adicional será cobrado com base no espaço consumido pelos snapshots, com 0,085 USD/GB por mês (mesmo preço em todas as regiões). A transferência de dados para uso dos snapshots é gratuita.

P: O que é o período de retenção?

O período de retenção é o período de tempo durante o qual os snapshots automáticos ficam retidos. Por exemplo, se o período de retenção é configurado em 5, um snapshot criado hoje será retido por 5 dias antes de ser excluído. Você pode optar por copiar um ou mais snapshots para armazená-los manualmente para que não sejam excluídos ao final do período de retenção.

P: Como posso gerenciar a retenção dos meus snapshots automatizados?

Você pode utilizar o AWS Management Console ou a API ModifyCluster para gerenciar por quanto tempo seus backups automatizados serão mantidos, modificando o parâmetro RetentionPeriod. Se você deseja desativar completamente os backups automatizados, isso é possível ao configurar o período de retenção para 0 (não recomendado).

P: O que acontece com os meus snapshots se eu excluir o cluster do ElastiCache para Redis?

Ao excluir um cluster do ElastiCache para Redis, os seus snapshots manuais serão retidos. Você também poderá criar um snapshot final antes da exclusão do cluster. Os snapshots de cache automáticos não são retidos.

P: Quais tipos de nós de cache oferecem suporte ao recurso de Backup e Restore?

Todos os tipos de nós de instância do ElastiCache para Redis além do t1.micro e da família t2 oferecem suporte para backup e restauração:

Nós de cache da geração atual:

  • cache.m3.medium
  • cache.m3.large
  • cache.m3.xlarge
  • cache.m3.2xlarge
  • cache.r3.large
  • cache.r3.xlarge
  • cache.r3.2xlarge
  • cache.r3.4xlarge
  • cache.r3.8xlarge

Nós de cache da geração anterior:

  • cache.m1.small
  • cache.m1.medium
  • cache.m1.large
  • cache.m1.xlarge
  • cache.m2.xlarge
  • cache.m2.2xlarge
  • cache.m2.4xlarge
  • cache.c1.xlarge

P: Posso utilizar os meus próprios snapshots RDB armazenados no S3 para pré-carregar um cluster do ElastiCache para Redis?

Sim. Você pode especificar o local no S3 do seu arquivo RDB durante a criação do cluster pelo Launch Cache Cluster Wizard no console ou pela API CreateCacheCluster.

P: Posso utilizar o recurso Backup e Restore caso esteja executando o ElastiCache em uma VPC?

Sim.


P: O que é o redimensionamento online de clusters?

O Amazon ElastiCache para Redis possibilita adicionar e remover estilhaços de um cluster em execução. Você pode aumentar ou diminuir de modo dinâmico a escala horizontal das cargas de trabalho de clusters Redis para adaptar-se a mudanças na demanda. O ElastiCache redimensionará o cluster ao adicionar ou remover estilhaços e redistribuir hash slots de modo uniforme na nova configuração de estilhaço. O serviço faz tudo isso enquanto o cluster permanece online e atendendo a solicitações.

P: Quais são os benefícios do uso do redimensionamento online de clusters?

A capacidade de aumentar e diminuir a escala horizontal de modo dinâmico de um cluster pode ajudar você a gerenciar a variação de aplicativos e cumprir demandas flutuantes. Você pode dimensionar corretamente clusters ao adicionar ou remover estilhaços para ajustar a escala da performance e a capacidade na memória. O recurso elimina a necessidade de provisionar clusters em excesso com base nos picos da demanda, ajuda a melhorar a eficiência e reduz os custos.

P: Como posso usar o redimensionamento de clusters online?

O redimensionamento online de clusters está disponível na versão 3.2.10 do mecanismo Redis. Para reconfigurar os estilhaços do cluster, selecione-o e especifique se deseja adicionar ou remover estilhaços. Ao redimensionar o cluster para aumentar a escala horizontal do cluster, o ElastiCache adiciona estilhaços e migra slots de estilhaços atuais para novos estilhaços, de modo que os slots sejam distribuídos de maneira uniforme (de acordo com a quantidade) entre os estilhaços. De modo similar, ao redimensionar o cluster para diminuir a escala horizontal, o ElastiCache migra os slots para os estilhaços restantes, para distribuir de maneira uniforme os slots, e exclui estilhaços especificados.

P: Qual é o tempo necessário para o redimensionamento online de clusters?

O tempo necessário para redimensionar um cluster depende de vários fatores, como o número de slots que devem ser migrados entre os estilhaços, o tamanho dos dados e a taxa de solicitações de entrada no cluster. No entanto, a carga de trabalho é otimizada para paralelizar a migração de slots, o que acelera o processo, pois você adiciona mais estilhaços para aumentar a escala horizontal do cluster.

P: O cluster pode ser usado enquanto ocorre o redimensionamento de clusters?

Sim. O cluster permanece online e atende a solicitações de entrada, enquanto ocorre a reconfiguração de estilhaços. No entanto, não aceitamos a criação de snapshots do cluster durante a reconfiguração de estilhaços para evitar o aumento da carga no cluster.

P: Existe algum impacto na performance desta operação no cluster?

Embora o redimensionamento online de clusters ofereça benefícios para aumentar/diminuir a escala horizontal, sem tempo de inatividade, é uma operação com uso intenso da computação e pode aumentar a latência da conexão do seu cliente. Para reduzir a carga no cluster durante a operação, recomendamos seguir as melhores práticas (descritas na documentação).

P: Como posso rastrear o andamento de uma operação online de reconfiguração de estilhaços?

É possível rastrear o andamento da operação ao observar o status do cluster, dos estilhaços e dos nós. Durante a operação, o cluster, os estilhaços e os nós permanecerão no status "em modificação". De modo similar, quando os estilhaços estiverem sendo criados, excluídos, ou participando de uma migração de slots, o status individual do estilhaço refletirá esses status para demonstrar o andamento da operação. Além disso, o status da operação completa também poderá ser rastreado usando o indicador de andamento da operação de reconfiguração de estilhaços, que indica a porcentagem concluída e disponibiliza informações sobre o tempo restante para o término da operação. Por fim, as mensagens de evento indicam o andamento ao descrever as ações tomadas (criação de estilhaços, migração de slots, etc.) durante a operação.

P: O que é a operação de rebalanceamento do cluster do ElastiCache para Redis?

A operação de rebalanceamento pode ser usada para redistribuir slots entre estilhaços atuais para obter uma distribuição uniforme. Esse recurso pode ser muito útil quando um cluster for criado com uma distribuição de slots desigual especificada manualmente, ou uma operação de aumento/diminuição de escala horizontal deixar o cluster com uma distribuição desigual. Pressupondo que os slots sejam idênticos na memória deles e nos requisitos de E/S, a distribuição uniforme de slots de acordo com a quantidade é uma maneira fácil de balancear a carga entre os estilhaços.

P: Como a aplicação de tags funciona durante o aumento da escala horizontal de um cluster?

Quando os novos nós são adicionados para aumentar a escala horizontal de um cluster, os nós assumem o mesmo conjunto de tags comuns em todos os nós atuais. Além disso, os usuários podem modificar as tags em todos os nós e continuar a usar a aplicação de tags anterior.

P: O cliente ou o aplicativo precisa fazer alterações com relação ao uso do redimensionamento online de clusters?

Não. A distribuição otimizada de slots usada na carga de trabalho de redimensionamento de clusters é compatível com o comportamento do cliente de cluster Redis e não exige nenhuma alteração no aplicativo. O ElastiCache mantém os endpoints do cluster, o que permite que você continue usando clientes atuais sem que seja necessário fazer nenhuma alteração.

P: Quanto custa o uso do mecanismo Redis otimizado?

Não há cobrança adicional para o uso do mecanismo Redis otimizado. Como sempre, só serão cobrados os nós que você utilizar.

 


P: Quais os benefícios da criptografia de dados em trânsito do ElastiCache para Redis?

O recurso de criptografia de dados em trânsito permite criptografar todas as comunicações entre clientes e um servidor do Redis, bem como entre os servidores do Redis (nó principal e nós de réplicas de leitura).

P: Quais os benefícios da criptografia de dados ociosos do ElastiCache para Redis?

A criptografia de dados ociosos permite criptografar dados durante backups e restaurações. Os dados de backups e restaurações em disco e por meio do Amazon S3 são criptografados.

P: Como posso usar criptografia de dados em trânsito e ociosos, bem como o AUTH do Redis?

Os recursos de criptografia de dados em trânsito e ociosos, bem como o AUTH do Redis, são opcionais. Quando cria um cluster do Redis por meio do console ou da interface da linha de comando, você pode especificar se quer habilitar a criptografia e o AUTH do Redis e, em seguida fornecer um token de autenticação para comunicação com o cluster do Redis. Após a configuração do cluster com criptografia habilitada, o ElastiCache gerencia de forma transparente a expiração e a renovação de certificados, sem necessidade de nenhuma ação adicional do aplicativo. Além disso, os clientes do Redis precisam oferecer suporte ao TLS para usar a criptografia de dados em trânsito.

P: Preciso de um cliente do Amazon ElastiCache para Redis a fim de criptografar dados em trânsito ou ociosos?

Não. A criptografia de dados em trânsito exige que os clientes ofereçam suporte ao TLS. A maioria dos clientes do Redis (como Lettuce, Predis e go-Redis) oferece suporte ao TLS com algumas definições de configuração. Verifique se o cliente do Redis escolhido está configurado para oferecer suporte ao TLS e continue a usar o ElastiCache para Redis da mesma forma que antes.

P: Posso habilitar a criptografia de dados em trânsito e ociosos em clusters do ElastiCache para Redis já existentes?

Não. A criptografia de dados em trânsito e ociosos somente está disponível para novos clusters e não está disponível em clusters do ElastiCache para Redis já existentes. O suporte a esses recursos foi disponibilizado no ElastiCache para Redis a partir da versão 3.2.6.

P: É necessária alguma ação para renovar certificados?

Não. O ElastiCache gerencia internamente a expiração e a renovação de certificados. Nenhuma ação de usuário é necessária para a manutenção contínua de certificados.

P: Posso usar meus certificados para criptografia?

Não. No momento, o ElastiCache não permite que você use seus próprios certificados. O ElastiCache gerencia os certificados para você de forma transparente.

P: Para quais tipos de instância a criptografia de dados em trânsito e ociosos oferece suporte?

A criptografia de dados em trânsito e ociosos oferece suporte a todas as gerações atuais de instâncias.

P: Há custos adicionais para usar a criptografia?

Não há custo adicional para usar a criptografia.

 


P: O Amazon ElastiCache para Redis é qualificado pela HIPAA?

Sim, o Amazon ElastiCache para Redis é um serviço qualificado pela HIPAA e foi adicionado ao Adendo de associado comercial da AWS (BAA). Isso significa que você pode usar o ElastiCache para Redis como ajuda para processar, manter e armazenar informações de saúde protegidas (PHI) e como base para aplicativos de healthcare.

P: O que devo fazer para usar o ElastiCache para Redis qualificado pela HIPAA?

Se você assinou um Business Associate Agreement (BAA – Acordo de associado comercial) com a AWS, poderá usar o ElastiCache para Redis a fim de criar aplicativos em conformidade com a HIPAA. Se você não tiver um BAA ou tiver outras dúvidas sobre o uso da AWS para aplicativos em conformidade com a HIPAA, entre em contato conosco para obter mais informações. Consulte Como definir a arquitetura para segurança e conformidade da HIPAA na Amazon Web Services para obter informações sobre como configurar serviços da Amazon qualificados pela HIPAA para armazenar, processar e transmitir PHI.

P: Para quais programas de conformidade o ElastiCache para Redis oferece suporte?

O ElastiCache para Redis oferece suporte a programas de conformidade como SOC 1, SOC 2, SOC 3, ISO, MTCS, C5 e HIPAA. Consulte Serviços da AWS no escopo pelo programa de conformidade para ver uma lista dos programas de conformidade atuais com suporte.

P: Há um custo adicionar para usar os recursos de conformidade?

Não existe custo adicional para usar os recursos de conformidade.