Resiliência no Amazon ElastiCache
A infraestrutura global da AWS é criada com base em regiões da AWS e zonas de disponibilidade. As regiões da AWS As regiões fornecem várias zonas de disponibilidade separadas e isoladas fisicamente, as quais são conectadas com baixa latência, alto throughput e redes altamente redundantes. Com as zonas de disponibilidade, é possível projetar e operar aplicações e bancos de dados que executam o failover automaticamente entre as zonas de disponibilidade sem interrupção. As zonas de disponibilidade são mais altamente disponíveis, tolerantes a falhas e escaláveis que uma ou várias infraestruturas de data center tradicionais.
Para obter mais informações sobre regiões e zonas de disponibilidade da AWS, consulte Infraestrutura global da AWS
Além da infraestrutura global da AWS, o Amazon ElastiCache oferece vários recursos para ajudar a dar suporte às necessidades de resiliência de dados e backup.
Tópicos
Atenuar falhas
Ao planejar sua implementação do Amazon ElastiCache, você deve planejar para que as falhas tenham um impacto mínimo sobre sua aplicação e seus dados. Os tópicos nesta seção discutem as abordagens que você pode tomar para proteger seu aplicativo e dados contra falhas.
Tópicos
Mitigar falhas ao executar o Memcached
Ao executar o mecanismo Memcached, você tem as seguintes opções para minimizar o impacto de uma falha. Há dois tipos de falhas que devem ser resolvidas em seus planos de mitigação de falhas: falhas de nó e falhas na zona de disponibilidade.
Mitigar falhas de nós
Os caches sem servidor mitigam automaticamente falhas em nó com uma arquitetura multi-AZ, de maneira que as falhas no nó sejam transparentes para a aplicação. Para mitigar o impacto de uma falha de nó em um cluster baseado em nós, espalhe seus dados em cache por mais nós. Como os clusters baseados em nós não oferecem suporte para replicação, uma falha de nó sempre resultará em uma certa perda de dados do seu cluster.
Ao criar seu cluster do Memcached, você pode criá-lo com 1 a 60 nós, ou mais, por solicitação especial. Particionar seus dados em um número maior de nós significa que você perderá menos dados se um nó falhar. Por exemplo, se você particionar seus dados em 10 nós, um único nó armazenará aproximadamente 10% dos seus dados em cache. Nesse caso, uma falha de nó perde aproximadamente 10% do seu cache, que precisa ser substituído quando um nó de substituição é criado e provisionado. Se os mesmos dados tiverem sido armazenados em cache em 3 nós maiores, a falha de um nó perderia aproximadamente 33% dos seus dados em cache.
Para obter informações sobre como especificar o número de nós em um cluster Memcached, consulte Criação de um cluster do Memcached (console).
Mitigar falhas de zonas de disponibilidade
Os caches sem servidor mitigam automaticamente falhas em zona de disponibilidade com uma arquitetura multi-AZ replicada, de maneira que as falhas em AZ sejam transparentes para a aplicação.
Para mitigar o impacto de uma falha na zona de disponibilidade em um cluster baseado em nós, localize seus nós no maior número possível de zonas de disponibilidade. No caso improvável de uma falha do AZ, você perderá os dados armazenados em cache nessa AZ, e não os dados armazenados em cache nas outras AZs.
Por que tantos nós?
Se a minha região tem apenas três zonas de disponibilidade, por que preciso de mais de três nós, já que, se uma AZ falhar, perco aproximadamente um terço dos meus dados?
Esta é uma excelente pergunta. Lembre-se de que estamos tentando mitigar dois tipos distintos de falhas: de nó e de zona de disponibilidade. Você está certo. Se os seus dados estiverem espalhados por zonas de disponibilidade e uma delas falhar, você perderá apenas os dados armazenados em cache naquela AZ, independentemente do número de nós que tem. No entanto, se um nó falhar, ter mais nós reduzirá a proporção de dados perdidos.
Não há uma "fórmula mágica" para determinar quantos nós você tem no seu cluster. Você deve ponderar o impacto da perda de dados versus a probabilidade de uma falha versus custo e chegar à sua própria conclusão.
Para obter informações sobre como especificar o número de nós em um cluster Memcached, consulte Criação de um cluster do Memcached (console).
Para obter mais informações sobre regiões e zonas de disponibilidade, consulte Seleção de regiões e zonas de disponibilidade para o ElastiCache.
Mitigar falhas ao executar o Valkey ou Redis OSS
Ao executar um mecanismo Valkey ou Redis OSS, você tem as opções a seguir para minimizar o impacto de um nó ou falha da zona de disponibilidade.
Mitigar falhas de nós
Os caches sem servidor mitigam automaticamente falhas em nó com uma arquitetura multi-AZ, de maneira que as falhas no nó sejam transparentes para a aplicação. Os clusters baseados em nós devem ser devidamente configurados para mitigar a falha de um nó individual.
Para mitigar o impacto de falhas em nós do Valkey ou Redis OSS em clusters baseados em nós, você tem as seguintes opções:
Mitigar falhas: grupos de replicação do Valkey ou Redis OSS
Um grupo de replicação do Valkey ou Redis OSS é composto por um único nó primário no/do qual sua aplicação pode ler e gravar e de 1 a 5 nós de réplica somente leitura. Sempre que os dados são gravados no nó primário, eles também são atualizados de maneira assíncrona nos nós de réplica de leitura.
Quando uma réplica de leitura falha
O ElastiCache detecta a réplica de leitura com falha.
O ElastiCache coloca o nó com falha offline.
O ElastiCache executa e provisiona um nó de substituição na mesma AZ.
O novo nó é sincronizado com o nó primário.
Durante esse período, seu aplicativo pode continuar lendo e gravando usando os outros nós.
Multi-AZ do Valkey ou do Redis OSS
É possível habilitar o Multi-AZ em seus grupos de replicação do Valkey ou Redis OSS. Independentemente de você habilitar o Multi-AZ, uma falha primária será detectada e substituída automaticamente. Como isso acontece depende de o recurso Multi-AZ estar ou não habilitado.
Quando Multi-AZ está habilitado
O ElastiCache detecta a falha do nó primário.
O ElastiCache promove o nó de réplica de leitura com o menor atraso de replicação para o nó primário.
As outras réplicas se sincronizam com o novo nó primário.
O ElastiCache gira uma réplica de leitura na AZ do primário com falha.
O novo nó é sincronizado com o primário recém-promovido.
O failover em um nó de réplica geralmente é mais rápido do que criar e provisionar um novo nó primário. Isso significa que seu aplicativo pode retomar a gravação no nó primário mais cedo do que se o Multi-AZ não estivesse habilitado.
Para obter mais informações, consulte Minimizar o tempo de inatividade no ElastiCache usando o Multi-AZ com Valkey e Redis OSS.
Quando o Multi-AZ está desabilitado
O ElastiCache detecta a falha do primário.
O ElastiCache coloca o primário offline.
O ElastiCache cria e provisiona um novo nó primário para substituir o nó primário com falha.
O ElastiCache sincroniza o novo nó primário com uma das réplicas existentes.
Quando a sincronização é concluída, o novo nó funciona como nó primário do cluster.
Durante as etapas de 1 a 4 desse processo, seu aplicativo não pode gravar no nó primário. No entanto, seu aplicativo pode continuar a ler dos seus nós de réplica.
Para proteção adicional, recomendamos que você inicie os nós no seu grupo de replicação em diferentes zonas de disponibilidade (AZs). Se você fizer isso, uma falha de AZ afetará apenas os nós nessa AZ, e não os outros.
Para obter mais informações, consulte Alta disponibilidade com o uso de grupos de replicação.
Mitigar falhas de zonas de disponibilidade
Os caches sem servidor mitigam automaticamente falhas em zona de disponibilidade com uma arquitetura multi-AZ replicada, de maneira que as falhas em AZ sejam transparentes para a aplicação.
Para mitigar o impacto de uma falha na zona de disponibilidade em um cluster baseado em nós, localize seus nós para cada fragmento no maior número possível de zonas de disponibilidade.
Não importa quantos nós você tenha em um fragmento, se todos estiverem localizados na mesma zona de disponibilidade, uma falha catastrófica dessa AZ resultará na perda de todos os dados do fragmento. No entanto, se você localizar seus nós em várias AZs, uma falha de qualquer AZ resultará apenas na perda dos nós nessa AZ.
Sempre que você perde um nó, pode passar por uma degradação do desempenho, pois as operações de leitura são compartilhadas por menos nós. Essa degradação do desempenho continuará até que os nós sejam substituídos.
Para obter informações sobre como especificar as zonas de disponibilidade para nós do Valkey ou do Redis OSS, consulte Criação de um cluster do Valkey (modo cluster desabilitado) (console).
Para obter mais informações sobre regiões e zonas de disponibilidade, consulte Seleção de regiões e zonas de disponibilidade para o ElastiCache.
Recomendações
É recomendável criar caches com tecnologia sem servidor em clusters baseados em nós, pois você obtém automaticamente uma melhor tolerância a falhas sem configuração adicional. No entanto, durante a criação de um cluster baseado em nós, existem dois tipos de falhas para as quais você precisa se planejar: falhas de nós individuais e falhas amplas de zona de disponibilidade. O melhor plano de mitigação de falhas abordará ambos os tipos de falhas.
Minimizar o impacto das falhas em nó
Para minimizar o impacto de uma falha de nó ao usar o Valkey ou o Redis OSS, recomendamos que sua implementação use vários nós em cada fragmento e distribua os nós em várias zonas de disponibilidade. Isso é feito automaticamente para caches sem servidor.
Para clusters baseados em nós no Valkey ou Redis OSS, recomendamos que você habilite o Multi-AZ em seu grupo de replicação para que o ElastiCache faça failover automaticamente para uma réplica se o nó primário falhar.
Quando estiver executando o Memcached e particionando seus dados entre nós, quanto mais nós usar, menor será a perda de dados se qualquer um dos nós falhar.
Minimizar o impacto das falhas na zona de disponibilidade
Para minimizar o impacto de uma falha na zona de disponibilidade, nós recomendamos a execução dos nós em quantas zonas de disponibilidade diferentes forem disponíveis. Espalhar nós de forma uniforme em AZs minimizará o impacto no evento improvável de uma falha de AZ. Isso é feito automaticamente para caches sem servidor.
Outras precauções
Se você estiver executando o Valkey ou o Redis OSS, além da precaução acima, recomendamos que você programe backups regulares do seu cluster. Backups (snapshots) criam um arquivo .rdb que você pode usar para restaurar seu cache em caso de falha ou corrupção. Para obter mais informações, consulte Snapshots e restauração.
