マルチ AZ による MemoryDB のダウンタイムの最小化 - Amazon MemoryDB
障害シナリオとマルチ AZ のレスポンス自動フェイルオーバーのテスト

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

マルチ AZ による MemoryDB のダウンタイムの最小化

MemoryDB がプライマリノードを置き換える必要があるインスタンスが多数あります。これには、特定のタイプの計画されたメンテナンスや、プライマリノードまたはアベイラビリティーゾーンの予期できない障害などが含まれます。

ノード障害への対応は、どのノードに障害が発生したかによって異なります。ただし、いずれの場合も、MemoryDB はノードの交換やフェイルオーバー中にデータが失われないようにします。例えば、レプリカに障害が発生した場合、障害が発生したノードは交換され、データがトランザクションログから同期されます。プライマリノードに障害が発生すると、整合性のとれたレプリカへのフェイルオーバーがトリガーされ、フェイルオーバー中にデータが失われることはありません。これで、書き込みは新しいプライマリノードから処理されます。その後、古いプライマリノードが置き換えられ、トランザクションログから同期されます。

1 つのノードシャード (レプリカなし) でプライマリノードに障害が発生した場合、MemoryDB は、プライマリノードが交換されてトランザクションログと同期されるまで、書き込みを受け付けなくなります。

ノードの交換により、クラスターのダウンタイムが発生しますが、マルチ AZ が有効になっている場合、ダウンタイムは最小限に抑えられます。プライマリノードのロールは、リードレプリカの1つに自動的にフェイルオーバーされます。MemoryDB ではこれを透過的に処理するため、新しいプライマリノードを作成してプロビジョニングする必要はありません。このフェイルオーバーとレプリカの昇格により、昇格が完了したらすぐに新しいプライマリへの書き込みを再開できます。

メンテナンス更新またはサービス更新により計画されたノード置換が開始された場合、クラスターが着信した書き込みリクエストを処理している間に、計画されたノード置換が完了することに注意してください。

MemoryDB クラスターのマルチ AZ を使用すると、耐障害性が向上します。これは特に、クラスターのプライマリノードが到達できなくなった場合、または何らかの理由で障害が発生した場合に当てはまります。MemoryDB クラスターのマルチ AZ では、各シャードに複数のノードが必要で、自動的に有効になります。

障害シナリオとマルチ AZ のレスポンス

マルチ AZ がアクティブな場合、障害が発生したプライマリノードは使用可能なレプリカにフェイルオーバーします。レプリカは自動的にトランザクションログと同期され、プライマリノードになります。これは、新しいプライマリノードを作成して再プロビジョニングするよりもはるかに高速です。通常は数秒で、クラスターへの書き込みが再び可能になります。

マルチ AZ を有効にすると、MemoryDB はプライマリノードの状態を継続的にモニタリングします。プライマリノードが失敗すると、失敗のタイプに応じて次のいずれかのアクションが実行されます。

プライマリノードのみが失敗した場合の障害シナリオ

プライマリノードのみが失敗した場合、レプリカは自動的にプライマリノードになります。次に、障害の発生したプライマリと同じアベイラビリティーゾーンに代替のリードレプリカが作成されてプロビジョニングされます。

プライマリノードのみが失敗した場合、MemoryDB のマルチ AZ は次の処理を行います。

  1. 失敗したプライマリノードがオフラインになります。

  2. up-to-date レプリカは自動的にプライマリになります。

    書き込みは、フェイルオーバープロセスが完了すると通常は数秒で再開できます。

  3. 代替のリードレプリカが起動され、プロビジョニングされます。

    代替のレプリカは、障害が発生したプライマリノードが属していたアベイラビリティーゾーンで起動され、ノードの分散が維持されます。

  4. レプリカはトランザクションログと同期します。

クラスターのエンドポイントの検索については、以下のトピックを参照してください。

 

プライマリノードと一部のリードレプリカが失敗した場合の障害シナリオ

プライマリレプリカと少なくとも 1 つのレプリカが失敗すると、 up-to-dateレプリカはプライマリクラスターに昇格されます。新しいレプリカも作成され、障害が発生したノードと同じアベイラビリティーゾーンにプロビジョニングされます。

プライマリノードと一部のリードレプリカが失敗すると、MemoryDB Multi-AZは次の処理を行います。

  1. 障害が発生したプライマリノードと故障したレプリカがオフラインになります。

  2. 使用可能なレプリカがプライマリノードになります。

    フェイルオーバーが完了すると、書き込みは、通常は数秒で 再開できます。

  3. 複数の置き換えレプリカを作成してプロビジョニングします。

    ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。

  4. すべてのノードがトランザクションログと同期します。

クラスターのエンドポイントの検索については、以下のトピックを参照してください。

 

クラスター全体が失敗した場合の障害シナリオ

すべてに障害が発生した場合、すべてのノードは、元のノードと同じアベイラビリティーゾーンで再作成され、プロビジョニングされます。

このシナリオでは、データはトランザクションログに保持されているため、データが失われることはありません。

クラスター全体が失敗すると、MemoryDB のマルチ AZ は次の処理を行います。

  1. 障害が発生したプライマリノードとレプリカがオフラインになります。

  2. 代わりのプライマリノードが作成され、トランザクションログと同期してプロビジョニングされます。

  3. 代替レプリカはトランザクションログと同期して作成され、プロビジョニングされます。

    ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。

クラスターのエンドポイントの検索については、以下のトピックを参照してください。

自動フェイルオーバーのテスト

MemoryDB コンソール、、 AWS CLI MemoryDB を使用して自動フェイルオーバーをテストできますAPI。

テストを行う場合、以下の点に注意してください。

  • この操作は、24 時間に最大 5 回まで使用できます。

  • 別のクラスターのシャードでこのオペレーションを呼び出す場合、同時に呼び出しを行うことができます。

  • 場合によっては、同じ MemoryDBクラスター内の異なるシャードに対して、このオペレーションを複数回呼び出すことがあります。このような場合、後続の呼び出しを行う前に、最初のノードの置換が完了する必要があります。

  • ノードの交換が完了したかどうかを判断するには、MemoryDB コンソール、、 AWS CLIまたは MemoryDB を使用してイベントを確認しますAPI。FailoverShard‬に関連する以下のイベントは、発生すると思われる順に一覧表示されます。‬

    1. クラスターメッセージ: FailoverShard API called for shard <shard-id>

    2. クラスターメッセージ: Failover from primary node <primary-node-id> to replica node <node-id> completed

    3. クラスターメッセージ: Recovering nodes <node-id>

    4. クラスターメッセージ: Finished recovery for nodes <node-id>

    詳細については、次を参照してください。

  • これはAPI、MemoryDB フェイルオーバーが発生した場合のアプリケーションの動作をテストするように設計されています。クラスターの問題に対処するためにフェイルオーバーを開始するための運用ツールとしては設計されていません。さらに、大規模な運用イベントなどの特定の条件下では、この をブロック AWS することがありますAPI。

を使用した自動フェイルオーバーのテスト AWS Management Console

コンソールで自動フェイルオーバーをテストするには、次の手順に従います。

  1. にサインイン AWS Management Console し、 で MemoryDB コンソールを開きますhttps://console.aws.amazon.com/memorydb/。

  2. テストしたいクラスターの左側にあるラジオボタンを選択します。このクラスターには、少なくとも 1 つのレプリカノードが必要です。

  3. Details エリアで、このクラスターでマルチ AZ が有効になっていることを確認します。クラスターでマルチ AZ が有効になっていない場合は、別のクラスターを選択するか、このクラスターを変更してマルチ AZ を有効にします。詳細については、「MemoryDB クラスターの変更」を参照してください。

  4. クラスターの名前を選択します。

  5. [シャードとノード] ページで、フェイルオーバーをテストするシャード (API および CLI ではノードグループと呼ばれます) のシャード名を選択します。

  6. ノード ページで [フェイルオーバープライマリ] を選択します。

  7. Continue を選択してプライマリをフェイルオーバーするか、Cancel を選択してプライマリノードへのフェイルオーバーをキャンセルします。

    フェイルオーバープロセス中は、コンソールでノードのステータスが 使用可能 と継続して表示されます。フェイルオーバーテストの進捗状況を追跡するには、コンソールのナビゲーションペインから Events を選択します。Events タブで、フェイルオーバーの開始FailoverShard API calledと完了Recovery completedを示すイベントを監視します。

 

を使用した自動フェイルオーバーのテスト AWS CLI

AWS CLI オペレーション failover-shard を使用して、マルチ AZ 対応クラスターで自動フェイルオーバーをテストできます。

パラメータ

  • --cluster-name – 必須。テスト対象のクラスター。

  • --shard-name – 必須。自動フェイルオーバーをテストするシャードの名前。24 時間以内に、最大 5 つのシャードをテストできます。

次の例では AWS CLI 、 を使用してMemoryDB クラスターfailover-shardのシャード 0001を呼び出しますmy-cluster。

Linux、macOS、Unix の場合:

aws memorydb failover-shard \
   --cluster-name my-cluster \
   --shard-name 0001

Windows の場合:

aws memorydb failover-shard ^
   --cluster-name my-cluster ^
   --shard-name 0001

フェイルオーバーの進行状況を追跡するには、 AWS CLI describe-eventsオペレーションを使用します。

次のJSONレスポンスが返されます。

{
    "Events": [
        {
            "SourceName": "my-cluster",
            "SourceType": "cluster",
            "Message": "Failover to replica node my-cluster-0001-002 completed",
            "Date": "2021-08-22T12:39:37.568000-07:00"
        },
        {
            "SourceName": "my-cluster",
            "SourceType": "cluster",
            "Message": "Starting failover for shard 0001",
            "Date": "2021-08-22T12:39:10.173000-07:00"
        }
    ]
}

詳細については、次を参照してください。

 

MemoryDB を使用した自動フェイルオーバーのテスト API

次の例では、クラスター memorydb00 内のシャード 0003 で FailoverShard を呼び出します。

例 自動フェイルオーバーのテスト
https://memory-db.us-east-1.amazonaws.com/
    ?Action=FailoverShard
    &ShardName=0003
    &ClusterName=memorydb00
    &Version=2021-01-01
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20210801T192317Z
    &X-Amz-Credential=<credential>

フェイルオーバーの進行状況を追跡するには、MemoryDB DescribeEventsAPIオペレーションを使用します。

詳細については、次を参照してください。