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