前提

シャード数2、レプリカ数3、同リージョン内で、下図のような構成のfailoverを考える。

Shard #1, Shard #2それぞれでReplica Node-1が死んだらどうなる？

単純に死んだAZ内にもう一度Replica Nodeを再生成します。

• Shard #1のReplica Node-1が死んだ場合

Shard #2のReplica Node-1が死んだ場合やReplica Node-2が死んだ場合も同様です。

Shard #1のPrimary Nodeが死んだらどうなる？

AWS公式より引用。

プライマリノードのみが失敗した場合、レプリケーションの遅延が最も小さいリードレプリカがプライマリに昇格されます。次に、失敗したプライマリと同じアベイラビリティーゾーンに置換リードレプリカが作成されてプロビジョニングされます。

なお、Shard #2のPrimary Nodeが死んだ場合も同様に考えれば、以下のように考えられます。

以上の動きを数十秒以内で完了するのが自動フェイルオーバーです。

Shard #1のPrimary NodeとReplica Nodeが死んだらどうなる？

AWS公式より。

プライマリおよび少なくとも 1 つのリードレプリカで障害が発生した場合、利用可能でレプリケーションの遅延が最も少ないレプリカが、プライマリクラスターに昇格されます。また、障害が発生したノードおよびプライマリに昇格されたレプリカと同じアベイラビリティーゾーンで、新しいリードレプリカが作成およびプロビジョニングされます。

ap-northeast-1a全体が障害となった場合この構成はどうなる？

PrimaryとReplicaを持つShard #1がap-northeast-1a側を使えなくなった場合、結構苦しいと思われるが、こんな状況でも自動フェイルオーバー機能でElastiCacheはなんとかしてくれる。

今までの考え方を組み合わせて考えます。

AZ全体が障害になった場合はPrimary Nodeが生きてるAZに全て移るというイメージですね。

ap-northeast-1a, 1c全体が障害となった場合この構成はどうなる？

流石のマルチAZ配置でもこの場合のフェイルオーバー処理は無理です。

すべてに障害が発生した場合、すべてのノードは、元のノードと同じアベイラビリティーゾーンで再作成され、プロビジョニングされます。
このシナリオでは、クラスター内のすべてのデータがクラスター内のすべてのノードの障害のために失われます。これはまれにしか発生しません。

クラスター全体が失敗すると、ElastiCache のマルチ AZ は次の処理を行います。
1. 障害が発生したプライマリノードとリードレプリカがオフラインになります。
2. 置き換えプライマリノードが作成され、プロビジョニングされます。
3. 複数の置き換えレプリカを作成してプロビジョニングします。ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。

クラスター全体に障害が発生したため、データが失われ、すべての新しいノードがコールド起動されます。
置換先の各ノードと置換元のノードはエンドポイントが同じであるため、アプリケーションでエンドポイントを変更する必要はありません。

一回全部作り直すイメージですが、エンドポイントの変更はないというところがポイントかと思います。

これでもクリティカルな場合は、この構成をCloudFormationに書いておいた上で定期的にバックアップをS3に取り別リージョンで再deployしつつバックアップしたデータをredis-py-clusterなどを使って載せ直すなどさらなる工夫が必要です。

参考記事

・https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/AutoFailover.html