翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
障害の軽減
Amazon ElastiCache の実装を計画するときは、障害がアプリケーションやデータに与える影響を最小限に抑えるように計画する必要があります。このセクションのトピックでは、アプリケーションおよびデータを障害から保護するために実行できるアプローチについて説明します。
Redis OSS 実行時の障害の軽減
Redis OSS エンジンを実行する場合、ノードまたはアベイラビリティーゾーンの障害の影響を最小限に抑えるために、次のオプションがあります。
ノードの障害の軽減
サーバーレスキャッシュは、マルチ AZ アーキテクチャでノード障害を自動的に軽減するため、ノード障害はアプリケーションにとって透過的です。個々のノードの障害を軽減するには、独自設計型クラスターを適切に設定する必要があります。
Redis OSS ノード障害が独自設計型クラスターに与える影響を軽減するには、次のオプションがあります。
障害の軽減: Redis OSS レプリケーショングループ
Redis OSS レプリケーショングループは、アプリケーションが読み書きできる 1 つのプライマリノードと、1～5 個の読み取り専用レプリカノードで構成されます。データがプライマリノードに書き込まれるときは、常にリードレプリカノードでデータが非同期的に更新されます。
リードレプリカが失敗した場合
ElastiCache は、失敗したリードレプリカを検出します。
ElastiCache は、障害が発生したノードをオフラインにします。
ElastiCache は、同じ AZ で代替ノードを起動してプロビジョニングします。
新しいノードがプライマリノードと同期されます。
この間、アプリケーションは他のノードを使用して読み書きを続行できます。
Redis OSS マルチ AZ
Redis OSS レプリケーショングループでマルチ AZ を有効にできます。マルチ AZ を有効にするかどうかにかかわらず、失敗したプライマリが検出され、自動的に置き換えられます。これを実行する方法は、マルチ AZ が有効かどうかによって異なります。
マルチ AZ が有効な場合
ElastiCache はプライマリノードの障害を検出します。
ElastiCache は、レプリケーションラグが最も少ないリードレプリカノードをプライマリノードに昇格させます。
他のレプリカと新しいプライマリノードを同期します。
ElastiCache は、障害が発生したプライマリの AZ でリードレプリカをスピンアップします。
新しいノードが、新たに昇格されたプライマリと同期されます。
レプリカノードへのフェイルオーバーは、通常、新しいプライマリノードを作成してプロビジョニングするより高速です。つまり、マルチ AZ が有効でない場合と比べて、アプリケーションはプライマリノードへの書き込みをすばやく再開できます。
詳細については、「マルチ AZ による ElastiCache (Redis OSS) のダウンタイムの最小化」を参照してください。
マルチ AZ が無効な場合
ElastiCache はプライマリ障害を検出します。
ElastiCache はプライマリをオフラインにします。
ElastiCache は、障害が発生したプライマリを置き換えるために、新しいプライマリノードを作成してプロビジョニングします。
ElastiCache は、新しいプライマリを既存のレプリカの 1 つと同期します。
同期が終了すると、新しいノードはクラスターのプライマリノードとなります。
このプロセスのステップ 1～4 が終了するまで、アプリケーションはプライマリノードに書き込めません。ただし、アプリケーションはレプリカノードから読み込みを続けることができます。
保護を強化するために、別のアベイラビリティーゾーン (AZ) でレプリケーショングループのノードを起動することをお勧めします。これを行った場合、AZ の障害の影響をその AZ のノードのみにとどめ、他のノードには影響を与えません。
詳細については、「レプリケーショングループを使用する高可用性」を参照してください。
アベイラビリティーゾーンの障害の軽減
サーバーレスキャッシュは、レプリケートされたマルチ AZ アーキテクチャでアベイラビリティーゾーンの障害を自動的に軽減するため、AZ 障害はアプリケーションにとって透過的です。
独自設計型クラスターにおけるアベイラビリティーゾーンの障害の影響を軽減するためには、各シャードのノードを可能な限り多くのアベイラビリティーゾーンにノードを配置します。
シャードにノードがいくつあったとしても、そのすべてが同じアベイラビリティーゾーンにある場合は、その AZ で壊滅的な障害が発生するとシャードのデータのすべてが失われます。ただし、複数の AZ にノードがある場合は、いずれかの AZ で障害が発生しても失われるのはその AZ のノードのみとなります。
ノードを失った場合は、読み込みオペレーションがより少ない数のノードによって共有されるようになるため、パフォーマンスが低下します。このパフォーマンスの低下は、ノードが置き換えられるまで継続します。
Redis OSS ノードのアベイラビリティーゾーンの指定については、「」を参照してくださいRedis OSS (クラスターモードが無効) クラスターの作成 (コンソール）。
リージョンとアベイラビリティーゾーンの詳細については、「リージョンとアベイラビリティーゾーンの選択」を参照してください。
レコメンデーション
追加の設定をしなくても自動的に耐障害性が向上するため、独自設計型クラスターよりもサーバーレスキャッシュを作成することをお勧めします。ただし、独自設計型クラスターを作成する場合は、個別ノードの障害と、幅広いアベイラビリティーゾーンの障害の 2 種類の障害を想定する必要があります。ベストの障害軽減プランは、両方のタイプの障害に対処します。
ノード障害の影響を最小限に抑える
ノードの障害の影響を最小限に抑えるために、各シャードに複数のノードを実装して、複数のアベイラビリティーゾーンにノードを分散することをお勧めします。これはサーバーレスキャッシュでは自動的に行われます。
独自設計型クラスターでは、レプリケーショングループでマルチ AZ を有効にして、プライマリノードに障害が発生した場合 ElastiCache に がレプリカに自動的にフェイルオーバーするようにすることをお勧めします。
アベイラビリティーゾーンの障害の影響を最小限に抑える
アベイラビリティーゾーンの障害の影響を最小限に抑えるには、できるだけ多くの異なるアベイラビリティーゾーンでノードを起動することをお勧めします。ノードを AZ 間に均等に分散することで、予期しない AZ の障害が発生した場合の影響を最小化します。これはサーバーレスキャッシュでは自動的に行われます。
その他の対策
Redis OSS を実行している場合は、上記に加えて、クラスターの定期的なバックアップをスケジュールすることをお勧めします。バックアップ (スナップショット) によって、障害や破損が発生した場合にキャッシュを復元するのに使用できる .rdb ファイルが作成されます。詳細については、「スナップショットおよび復元」を参照してください。
