メニュー
Amazon ElastiCache
ユーザーガイド (API Version 2015-02-02)

障害の軽減

Amazon ElastiCache の実装を計画した場合、障害がアプリケーションやデータに及ぼす影響を最小限にとどめるように計画する必要があります。このセクションのトピックでは、アプリケーションおよびデータを障害から保護するために実行できるアプローチについて説明します。

Memcached 実行時の障害を軽減する

Memcached エンジンを実行する場合に、障害の影響を最小にするためのオプションとして次のものがあります。障害の軽減に対処する方法には、ノードの障害の軽減とアベイラビリティーゾーンの障害の軽減の 2 つのタイプがあります。

ノードの障害の軽減

ノードの障害の影響を軽減するには、キャッシュデータをより多くのノードに広げます。Memcached がレプリケーションをサポートしていないため、ノードの障害によって必ずクラスターからある程度のデータが失われます。

Memcached クラスターを作成すると、1 ~ 20 のノード、または特殊なリクエストによってそれ以上のノードを作成できます。大量のノード間でデータのパーティションを行うと、ノードで障害が発生した場合のデータの損失が小さくなります。たとえば、10 のノード間でデータのパーティションを行うと、単一のノードに約 10% のキャッシュデータが保存されることになります。この場合、ノードの障害が起きるとキャッシュの約 10% が失われ、代替ノードが作成されプロビジョニングされたときに置き換える必要があります。同じデータがより大きな 3 つのノードにキャッシュされている場合は、ノードの障害によってキャッシュされたデータの約 33% が失われます。

Memcached クラスターで 20 を超えるノードが必要な場合、またはリージョンで合計 100 を超えるノードが必要な場合は、ElastiCache 上限緩和申請 (https://aws.amazon.com/http://aws.amazon.com/contact-us/elasticache-node-limit-request/) に入力してください。

Memcached クラスターのノード数を指定する方法の詳細については、「クラスターの作成 (コンソール): Memcached」を参照してください。

アベイラビリティーゾーンの障害の軽減

アベイラビリティーゾーンの障害の影響を軽減するためには、可能な限り多くのアベイラビリティーゾーンでノードを見つけます。AZ の障害が発生した場合には、アベイラビリティーゾーンでキャッシュされたデータではなく、その AZ でキャッシュされたデータのみが失われます。

なぜ大量のノードが必要ですか。

自分のリージョンに 3 つのアベイラビリティーゾーンのみがある場合、AZ で障害が発生してデータの約 3 分の 1 を失った場合に、なぜ 3 つ以上のノードが必要になるのですか。

これはいい質問です。当社では、ノードの障害とアベイラビリティーゾーンの障害の 2 つの明確な障害を軽減しようとしてきました。ご指摘のとおり、データが各アベイラビリティーゾーンにまたがっており、ゾーンの 1 つで障害が発生した場合は、ノード数に関係なくその AZ でキャッシュされたデータのみが失われます。ただしノードで障害が発生した場合は、できるだけ多くのノードがあったほうが、失われるデータの割合が減ります。

クラスターのノード数を決定する「魔法の公式」はありません。データ損失の影響と障害が発生する可能性とコストを考慮して、個別に判断を下す必要があります。

これはいい質問です。当社では、ノードの障害とアベイラビリティーゾーンの障害の 2 つの明確な障害を軽減しようとしてきました。ご指摘のとおり、データが各アベイラビリティーゾーンにまたがっており、ゾーンの 1 つで障害が発生した場合は、ノード数に関係なくその AZ でキャッシュされたデータのみが失われます。ただしノードで障害が発生した場合は、できるだけ多くのノードがあったほうが、失われるデータの割合が減ります。

クラスターのノード数を決定する「魔法の公式」はありません。データ損失の影響と障害が発生する可能性とコストを考慮して、個別に判断を下す必要があります。

Memcached クラスターのノード数を指定する方法の詳細については、「クラスターの作成 (コンソール): Memcached」を参照してください。

リージョンとアベイラビリティーゾーンの詳細については、「リージョンとアベイラビリティーゾーンの選択」を参照してください。

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 は利用できず、データの復旧には使用できません。

詳細については、「AOF (Redis Append Only Files)」を参照してください。

障害の軽減: Redis レプリケーショングループ

Redis レプリケーショングループは、アプリケーションの読み取りと書き込みが可能な単一のプライマリノードと、1~5 個の読み取り専用のレプリカノードで構成されます。データがプライマリノードに書き込まれるときは、常にリードレプリカノードでデータが非同期的に更新されます。

リードレプリカが失敗した場合

  1. ElastiCache が、失敗したリードレプリカを検出します。

  2. ElastiCache が、障害のあるノードをオフラインにします。

  3. ElastiCache が、同じ AZ の代替のノードを起動し、プロビジョニングします。

  4. 新しいノードがプライマリノードと同期されます。

この間、アプリケーションは他のノードを使用して読み書きを続行できます。

Redis マルチ AZ と自動フェイルオーバー

Redis レプリケーショングループでマルチ AZ の自動フェイルオーバーを有効にできます。マルチ AZ と自動フェイルオーバーが有効になっているかどうかにかかわらず、障害のあるプライマリが検出され、自動的に置き換えが行われます。これを実行する方法は、マルチ AZ が有効かどうかによって異なります。

マルチ AZ と自動フェイルオーバーが有効な場合

  1. ElastiCache がプライマリノードの障害を検出します。

  2. ElastiCache が、レプリケーションの遅延が最も小さいリードレプリカノードをプライマリノードに昇格します。

  3. 他のレプリカと新しいプライマリノードを同期します。

  4. ElastiCache が、障害が発生したプライマリの AZ のリードレプリカをスピンアップします。

  5. 新しいノードが、新たに昇格されたプライマリと同期されます。

レプリカノードへのフェイルオーバーは、一般的に新しいプライマリノードを作成してプロビジョニングするよりも高速です。これは、マルチ AZ が有効でない場合よりも、アプリケーションがプライマリノードへの書き込みをすばやく再開できることを意味します。

詳細については、「レプリケーション: 自動フェイルオーバーとマルチ AZ (Redis)」を参照してください。

マルチ AZ と自動フェイルオーバーが無効な場合

  1. ElastiCache がプライマリの障害を検出します。

  2. ElastiCache がプライマリをオフラインにします。

  3. ElastiCache が新しいプライマリノードを作成、プロビジョニングし、失敗したプライマリと置き換えます。

  4. ElastiCache が、新しいプライマリを既存のレプリカのいずれと同期させます。

  5. 同期が終了すると、新しいノードはクラスターのプライマリノードとして機能します。

ステップ 1~4 のプロセス実行中、アプリケーションは、プライマリノードに書き込むことができません。ただし、アプリケーションはレプリカノードから読み込みを続けることができます。

保護を強化するために、別のアベイラビリティーゾーン (AZ) でレプリケーショングループのノードを起動することをお勧めします。これを行った場合、AZ の障害の影響をその AZ のノードのみにとどめ、他のノードには影響を与えません。

詳細については、「ElastiCache レプリケーション (Redis)」を参照してください。

アベイラビリティーゾーンの障害の軽減

アベイラビリティーゾーンの障害の影響を軽減するためには、可能な限り多くのアベイラビリティーゾーンでノードを見つけます。

ノードがいくつあったとしても、そのすべてが同じアベイラビリティーゾーンにある場合は、その AZ で壊滅的な障害が発生するとキャッシュデータのすべてが失われます。ただし、複数の AZ にノードがある場合は、いずれかの AZ で障害が発生しても失われるのはその AZ のノードのみとなります。

ノードを失った場合は、読み込みオペレーションがより少ない数のノードによって共有されるようになるため、パフォーマンスが低下します。このパフォーマンスの低下は、ノードが置き換えられるまで継続します。データが Redis ノードで仕切られないため、データ損失のリスクは、プライマリノードが失われた場合に限定されます。

Redis ノード用でアベイラビリティーゾーンを指定する方法の詳細については、「Redis (クラスターモードが無効) クラスターの作成 (コンソール)」を参照してください。

リージョンとアベイラビリティーゾーンの詳細については、「リージョンとアベイラビリティーゾーンの選択」を参照してください。

ベストプラクティス

計画を立てる必要のある障害には、個別ノードの障害と、幅広いアベイラビリティーゾーンの障害の 2 つのタイプがあります。ベストの障害軽減プランは、両方のタイプの障害に対処します。

障害の影響を最小限に抑える

ノードの障害の影響を最小限に抑えるために、各シャードに複数のノードを実装して、複数のアベイラビリティーゾーンにノードを分散することをお勧めします。

Memcached を実行してノード間でデータを仕切っている場合は、ノードの数を増やすほど 1 つのノードで障害が発生した場合のデータの損失をより小さくすることができます。

Redis を実行している場合は、レプリケーショングループでマルチ AZ を有効にして、プライマリノードで障害が発生すると ElastiCache が自動的にレプリカにフェイルオーバーを実行するようにしておくことをお勧めします。

アベイラビリティーゾーンの障害の影響を最小限に抑える

アベイラビリティーゾーンの障害の影響を最小限に抑えるには、できるだけ多くの異なるアベイラビリティーゾーンでノードを起動することをお勧めします。ノードを AZ 間に均等に分散することで、予期しない AZ の障害が発生した場合の影響を最小化します。

その他の対策

Redis を実行する場合は、上記に加えてクラスターのバックアップを定期的に取ることをお勧めします。バックアップ (スナップショット) によって、障害や破損が発生した場合にクラスターを復元するのに使用できる .rdb ファイルが作成されます。詳細については、「ElastiCache バックアップと復元の管理 (Redis)」を参照してください。