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