退避プロセス

そのような状況が MRSC テーブルで発生した場合、特別な操作は必要ありません。MRSC グローバルテーブルでは、目標復旧時点 (RPO) ゼロがサポートされています。オフラインリージョンの MRSC テーブルに実行され成功したすべての書き込みオペレーションは、他のすべてのリージョンテーブルに適用されるため、リージョンが予告なしに完全にオフラインになっても、データに差が生じる可能性はありません。他のリージョンにあるレプリカを業務に引き続き使用できます。

そのような状況が MREC テーブルで発生した場合、リージョン A でまだ伝播されていない書き込みオペレーションはすべて保持され、リージョン A がオンラインに戻った後に伝播されます。書き込みオペレーションは失われませんが、その伝播は無期限に遅延します。

このイベントの処理方法は、アプリケーションの決定によります。ビジネスの継続性を確保するために、書き込みオペレーションを新しいプライマリリージョン B に移行することが必要になる場合があります。ただし、リージョン A の項目に対する書き込みオペレーションの伝播が保留されているときに、リージョン B でその項目が更新を受け取ると、最終書き込み者優先モデルに従ってその伝播は抑制されます。リージョン B での更新は、着信する書き込みリクエストを抑制する可能性があります。

任意のリージョンへの書き込みモードでは、リージョン A の項目が最終的にリージョン B に伝播されることを信頼し、リージョン A がオンラインに戻るまで項目が欠落する可能性を認識しながら、リージョン B で読み取りおよび書き込みオペレーションを続行できます。可能であれば、べき等書き込みオペレーションなどでは、最近の書き込みトラフィックを (アップストリームのイベントソースを使用するなどして) 再生することを検討してください。これにより、欠落している可能性のある書き込みオペレーションのギャップを埋め、最終書き込み者優先の競合解決により、着信する書き込みオペレーションの最終的な伝播を抑制します。

他の書き込みモードでは、どの程度の作業を継続できるかを、少し時代遅れの方法で考慮する必要があります。リージョン A がオンラインに戻るまで、ReplicationLatency で追跡する書き込みオペレーションの一部の短い期間は失われます。ビジネスを継続できるでしょうか。一部のユースケースでは可能ですが、他のユースケースでは追加の緩和メカニズムがないと難しい場合があります。

例えば、あるリージョン全体で障害が発生した後でも、利用可能なクレジット残高を中断することなく維持する必要があるとします。残高を 2 つの異なる項目に分割し、1 つはリージョン A に、もう 1 つはリージョン B に置き、それぞれ利用可能な残高を半分にして開始できます。この場合は、自分のリージョンへの書き込みモードを使用します。各リージョンで処理されたトランザクションの更新は、残高のローカルコピーに対して書き込まれます。リージョン A が完全にオフラインになっても、リージョン B でトランザクション処理を続行でき、書き込みオペレーションはリージョン B に保持されている残高部分に制限されます。このように残高を分割すると、残高が少なくなった場合やクレジットの再調整が必要になった場合に複雑になりますが、保留中の書き込みオペレーションが不安定でも安全にビジネスを回復できる一例となります。

別の例として、ウェブフォームのデータをキャプチャするとします。オプティミスティック同時実行制御 (OCC) (OCC) を使用してデータ項目にバージョンを割り当て、最新バージョンを非表示フィールドとしてウェブフォームに埋め込むことができます。送信するたびに、データベース内のバージョンがフォーム作成時のバージョンとまだ一致する場合にのみ、書き込みオペレーションが成功します。バージョンが一致しない場合、データベース内の現在のバージョンに基づいてウェブフォームを更新 (または慎重にマージ) することで、ユーザーは再度続行できます。OCC モデルは通常、別のクライアントがデータを上書きして新しいバージョンを生成するのを防ぎますが、フェイルオーバー中にクライアントが古いバージョンのデータに遭遇する可能性がある場合にも役立ちます。タイムスタンプをバージョンとして使用しているとします。フォームを当初 12:00 にリージョン A に対して作成しましたが、(フェイルオーバー後に) リージョン B に書き込もうとして、データベースの最新バージョンが 11:59 であることに気付いたとします。このシナリオの場合、クライアントは 12:00 バージョンがリージョン B に伝播されるのを待ってからそのバージョンに書き込むか、11:59 バージョンに基づいて構築し、新しい 12:01 バージョンを作成することができます (書き込み後、リージョン A の回復後に着信したバージョンは抑制されます)。

3 つ目の例として、金融サービス会社が顧客アカウントおよび金融取引に関するデータを DynamoDB データベースに保持しているとします。同社は、リージョン A が完全に停止した場合、アカウントに関連する書き込みアクティビティのすべてがリージョン B で完全に利用可能であることを確認するか、リージョン A がオンラインに戻るまでアカウントを部分的なものとして隔離したいと考えていました。すべての業務を一時停止するのではなく、伝播されていないトランザクションがあると判断したごく一部のアカウントに対してのみ業務を一時停止することにしました。これを実現するために、同社は 3 番目のリージョン (リージョン C と呼びます) を使用しました。リージョン A で書き込みオペレーションを処理する前に、保留中のオペレーション (アカウントの新規トランザクション数など) の簡潔な要約をリージョン C に配置しました。この要約は、リージョン B のビューが完全に最新であるかどうかを判断するのに十分でした。このアクションにより、リージョン C での書き込み時点から、リージョン A が書き込みオペレーションを受け入れてリージョン B がそれを受け取るまでの間、アカウントは事実上ロックされました。リージョン C のデータは、フェイルオーバープロセスの一部として以外は使用されませんでした。その後、リージョン B はリージョン C とデータを相互チェックして、古いアカウントがないかどうかを確認できました。これらのアカウントは、リージョン A リカバリによって部分的なデータがリージョン B に伝播されるまで隔離済みとしてマークされます。リージョン C に障害が発生した場合は、代わりに新しいリージョン D をスピンアップして使用できます。リージョン C のデータはごく一時的なもので、数分後には処理中の書き込みオペレーションの最新の記録がリージョン D に反映されて十分に役立つようになります。リージョン B に障害が発生しても、リージョン A はリージョン C と協力して書き込みリクエストを引き続き受け入れることができます。同社は、より高いレイテンシーの書き込み (C に続けて A という 2 つのリージョンへの書き込み) をあえて受け入れ、アカウントの状態を簡潔に要約できるデータモデルを持つことができたことを喜んでいます。