障害の軽減
Amazon ElastiCache の実装を計画した場合、障害がアプリケーションやデータに及ぼす影響を最小限にとどめるように計画する必要があります。このセクションのトピックでは、アプリケーションおよびデータを障害から保護するために実行できるアプローチについて説明します。
Redis 実行時の障害の軽減
Redis エンジンを実行する場合に、ノードまたはアベイラビリティーゾーンの障害の影響を最小限にする方法として、次のオプションがあります。
ノードの障害の軽減
Redis ノードの障害の影響を軽減するには、次のオプションがあります。
障害の軽減: Redis Append Only Files (AOF)
Redis で AOF が有効になっている場合、データが Redis クラスターに書き込まれるときは、常に対応するトランザクションレコードが AOF に書き込まれます。Redis プロセスが再起動されると、ElastiCache が代替のクラスターを作成しプロビジョニングします。次に、クラスターに対して AOF を実行して、データを再入力します。
クラスターの障害を軽減するための AOF を使用するショートカットには次のものがあります。
-
これには時間がかかります。
クラスターの作成とプロビジョニングには数分かかります。AOF のサイズに応じて、クラスターに対して実行すると、アプリケーションがクラスターのデータにアクセスできないため、より多くの時間がかかります。この結果、アプリケーションがデータベースに強制的に直接アクセスしようとします。
-
AOF は大きくなりえます。
クラスターへのすべての書き込みはトランザクションレコードに書き込まれるため、問題のデータセットの .rdb ファイルよりも AOF のサイズがはるかに大きくなる場合があります。ElastiCache は、サイズに制限があるローカルインスタンスストアを利用するため、AOF を有効にすると、ディスク容量不足の問題が発生する可能性があります。ディスク容量不足の問題は、マルチ AZ を有効にしたのレプリケーショングループを使用することで回避できます。
-
AOF を使用してもすべての障害シナリオからデータを保護することはできません。
たとえば、基になる物理サーバーでハードウェア障害が発生したためノードでエラーが発生した場合、ElastiCache は別のサーバーで新しいノードをプロビジョニングします。この場合、AOF は利用できず、データの復旧には使用できません。
詳細については、「ElastiCache for Redis でファイルのみを追加する (AOF)」を参照してください。
障害の軽減: Redis レプリケーショングループ
Redis レプリケーショングループは、アプリケーションの読み取りと書き込みが可能な単一のプライマリノードと、1～5 個の読み取り専用のレプリカノードで構成されます。データがプライマリノードに書き込まれるときは、常にリードレプリカノードでデータが非同期的に更新されます。
リードレプリカが失敗した場合
ElastiCache が、失敗したリードレプリカを検出します。
ElastiCache が、障害のあるノードをオフラインにします。
ElastiCache が、同じ AZ の代替のノードを起動し、プロビジョニングします。
新しいノードがプライマリノードと同期されます。
この間、アプリケーションは他のノードを使用して読み書きを続行できます。
Redis のマルチ AZ
Redis レプリケーショングループでマルチ AZ を有効にすることができます。マルチ AZ を有効にするかどうかにかかわらず、失敗したプライマリが検出され、自動的に置き換えられます。これを実行する方法は、マルチ AZ が有効かどうかによって異なります。
マルチ AZ が有効な場合
ElastiCache がプライマリノードの失敗を検出します。
ElastiCache が、レプリケーションの遅延が最も小さいリードレプリカノードをプライマリノードに昇格します。
他のレプリカと新しいプライマリノードを同期します。
ElastiCache が、障害が発生したプライマリの AZ のリードレプリカをスピンアップします。
新しいノードが、新たに昇格されたプライマリと同期されます。
レプリカノードへのフェイルオーバーは、通常、新しいプライマリノードを作成してプロビジョニングするより高速です。つまり、マルチ AZ が有効でない場合と比べて、アプリケーションはプライマリノードへの書き込みをすばやく再開できます。
詳細については、「マルチ AZ による ElastiCache for Redis のダウンタイムの最小化」を参照してください。
マルチ AZ が無効な場合
ElastiCache がプライマリの失敗を検出します。
ElastiCache がプライマリをオフラインにします。
ElastiCache が新しいプライマリノードを作成してプロビジョニングし、失敗したプライマリと置き換えます。
ElastiCache が、新しいプライマリを既存のレプリカのいずれかと同期させます。
同期が終了すると、新しいノードはクラスターのプライマリノードとなります。
このプロセスのステップ 1～4 が終了するまで、アプリケーションはプライマリノードに書き込めません。ただし、アプリケーションはレプリカノードから読み込みを続けることができます。
保護を強化するために、別のアベイラビリティーゾーン (AZ) でレプリケーショングループのノードを起動することをお勧めします。これを行った場合、AZ の障害の影響をその AZ のノードのみにとどめ、他のノードには影響を与えません。
詳細については、「レプリケーショングループを使用する高可用性」を参照してください。
アベイラビリティーゾーンの障害の軽減
アベイラビリティーゾーンの障害の影響を軽減するためには、可能な限り多くのアベイラビリティーゾーンでノードを見つけます。
ノードがいくつあったとしても、そのすべてが同じアベイラビリティーゾーンにある場合は、その AZ で壊滅的な障害が発生するとキャッシュデータのすべてが失われます。ただし、複数の AZ にノードがある場合は、いずれかの AZ で障害が発生しても失われるのはその AZ のノードのみとなります。
ノードを失った場合は、読み込みオペレーションがより少ない数のノードによって共有されるようになるため、パフォーマンスが低下します。このパフォーマンスの低下は、ノードが置き換えられるまで継続します。データが Redis ノードで仕切られないため、データ損失のリスクは、プライマリノードが失われた場合に限定されます。
Redis ノードのアベイラビリティーゾーンを指定する方法の詳細については、「Redis (クラスターモードが無効) クラスターの作成 (コンソール)」を参照してください。
リージョンとアベイラビリティーゾーンの詳細については、「リージョンとアベイラビリティーゾーンの選択」を参照してください。
レコメンデーション
計画を立てる必要のある障害には、個別ノードの障害と、幅広いアベイラビリティーゾーンの障害の 2 つのタイプがあります。ベストの障害軽減プランは、両方のタイプの障害に対処します。
障害の影響を最小限に抑える
ノードの障害の影響を最小限に抑えるために、各シャードに複数のノードを実装して、複数のアベイラビリティーゾーンにノードを分散することをお勧めします。
Redis を実行している場合は、レプリケーショングループでマルチ AZ を有効にして、プライマリノードで障害が発生すると ElastiCache が自動的にレプリカにフェイルオーバーを実行するようにしておくことをお勧めします。
アベイラビリティーゾーンの障害の影響を最小限に抑える
アベイラビリティーゾーンの障害の影響を最小限に抑えるには、できるだけ多くの異なるアベイラビリティーゾーンでノードを起動することをお勧めします。ノードを AZ 間に均等に分散することで、予期しない AZ の障害が発生した場合の影響を最小化します。
その他の対策
Redis を実行する場合は、上記に加えてクラスターのバックアップを定期的に取ることをお勧めします。バックアップ (スナップショット) によって、障害や破損が発生した場合にクラスターを復元するのに使用できる .rdb ファイルが作成されます。詳細については、「ElastiCache for Redis のバックアップと復元 」を参照してください。
