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á.

Resiliência na Amazon ElastiCache

A infraestrutura AWS global é construída em torno de AWS regiões e zonas de disponibilidade. AWS As regiões fornecem várias zonas de disponibilidade fisicamente separadas e isoladas, conectadas a redes de baixa latência, alta taxa de transferência e alta redundância. Com as Zonas de Disponibilidade, é possível projetar e operar aplicações e bancos de dados que executem 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 AWS regiões e zonas de disponibilidade, consulte Infraestrutura AWS global.

Além da infraestrutura AWS global, a Amazon ElastiCache oferece vários recursos para ajudar a suportar suas necessidades de resiliência e backup de dados.

Atenuar falhas

Ao planejar sua ElastiCache implementação na Amazon, você deve planejar de forma que as falhas tenham um impacto mínimo em seus aplicativos e dados. Os tópicos nesta seção discutem as abordagens que você pode tomar para proteger seu aplicativo e dados contra falhas.

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 autoprojetado, espalhe seus dados em cache por mais nós. Como os clusters autoprojetados 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 Memcached, você pode criá-lo com 1 a 60 nós, ou mais, mediante 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 autoprojetado, localize seus nós no maior número possível de zonas de disponibilidade. No caso improvável de uma falha de AZ, você perderá os dados armazenados em cache nessa AZ, não os dados em cache na outra. 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 Regiões e zonas de disponibilidade.

Mitigando falhas ao executar Valkey ou Redis OSS

Ao executar um OSS mecanismo Valkey ou Redis, você tem as seguintes opções para minimizar o impacto de uma falha no nó ou 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. Os clusters autoprojetados devem ser devidamente configurados para mitigar a falha de um nó individual.

Para mitigar o impacto das falhas dos OSS nós Valkey ou Redis em clusters autoprojetados, você tem as seguintes opções:

Atenuando falhas: grupos de replicação Valkey ou Redis OSS

Um grupo de OSS replicação Valkey ou Redis é composto por um único nó primário do qual seu aplicativo pode ler e gravar, e de 1 a 5 nós de réplica somente para 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.

Durante esse período, seu aplicativo pode continuar lendo e gravando usando os outros nós.

Valkey ou Redis OSS Multi-AZ

Você pode habilitar o Multi-AZ em seus grupos de replicação Valkey ou RedisOSS. 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.

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 Minimizando o tempo de inatividade ElastiCache usando o Multi-AZ com Valkey e Redis OSS.

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 maior proteção, recomendamos que você inicie os nós do 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 autoprojetado, 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áriosAZs, uma falha em qualquer AZ resultará na perda somente 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 os OSS nós Valkey ou Redis, consulte. Criação de um cluster Valkey (modo de cluster desativado) (console)

Para obter mais informações sobre regiões e zonas de disponibilidade, consulte Escolhendo regiões e zonas de disponibilidade para ElastiCache.

Recomendações

É recomendável criar caches sem servidor em clusters autoprojetados, pois você obtém automaticamente uma melhor tolerância a falhas sem configuração adicional. No entanto, durante a criação de um cluster autoprojetado, 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 Valkey ou RedisOSS, 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 autoprojetados no Valkey ou no RedisOSS, recomendamos que você habilite o Multi-AZ em seu grupo de replicação para que ele ElastiCache faça o failover automático 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. Distribuir seus nós uniformemente AZs minimizará o impacto no caso improvável de uma falha no AZ. Isso é feito automaticamente para caches sem servidor.

Outras precauções

Se você estiver executando o Valkey ou o RedisOSS, além do acima, recomendamos que você agende 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.