グローバルテーブルを使用したリージョンからの退避

リージョンからの退避とは、リージョンから読み取り/書き込みアクティビティを移行するプロセスです。ほとんどの場合、これは書き込みアクティビティです。ときに読み取りアクティビティが含まれる場合もあります。

ライブリージョンからの退避

さまざまな理由で、ライブリージョンから退避することを決定する場合があります。退避は、1 つのリージョンへのフォローザサン書き込みモードを使用している場合など、通常のビジネス活動の一部である場合もあります。また、DynamoDB 外部のソフトウェアスタックの障害に対応して現在のアクティブなリージョンを変更するというビジネス上の決定や、リージョン内で通常よりも高いレイテンシーなどの一般的な問題が発生したことが原因で、退避を行う場合もあります。

任意のリージョンへの書き込みモードでは、ライブリージョンから簡単に退避できます。任意のルーティングシステムを介してトラフィックを代替リージョンにルーティングし、退避したリージョンで実行済みの書き込みオペレーションを通常どおりレプリケートできます。

1 つのリージョンへの書き込みモードと自分のリージョンへの書き込みモードでは、新しいアクティブなリージョンへの書き込みを開始する前に、現在のアクティブリージョンへのすべての書き込みが完全に記録されてストリーム処理され、グローバルに伝播されていることを確認する必要があります。これは、今後の書き込みが最新バージョンのデータに対して行われるようにするために必要です。

例えば、リージョン A がアクティブ、リージョン B がパッシブだとします (リージョン A をホームとするテーブル全体または項目のいずれかが対象)。退避を実行する一般的なメカニズムは、A への書き込みオペレーションを一時停止し、そのオペレーションが B に完全に伝播されるまで待ち、アーキテクチャスタックを更新して B がアクティブであることを認識してから、B への書き込みオペレーションを再開することです。リージョン A がリージョン B にデータを完全にレプリケートしたことを確実に示すメトリクスはありません。リージョン A が正常であれば、リージョン A への書き込みオペレーションを一時停止し、ReplicationLatency メトリクスの最新の最大値の 10 倍を待てば、通常はレプリケーションが完了したことを十分に確認できます。リージョン A に異常があり、他の領域でのレイテンシーの増加も示している場合は、待機時間の倍数を大きくします。

オフラインリージョンからの退避

考慮すべき特別なケースがあります。リージョン A が予告なしに完全にオフラインになった場合はどうなるでしょうか。これは非常に可能性が低いことですが、用心に越したことはありません。これが発生した場合、リージョン A でまだ伝播されていない書き込みオペレーションはすべて保持され、リージョン A がオンラインに戻った後に伝播されます。書き込みオペレーションは失われませんが、その伝播は無期限に遅延します。

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

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

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

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

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

タイムスタンプをバージョンとして使用しているとします。例えば、フォームを当初 12:00 にリージョン A に対して作成しましたが、(フェイルオーバー後に) リージョン B に書き込もうとして、データベースの最新バージョンが 11:59 であることに気付いたとします。このシナリオの場合、クライアントは 12:00 バージョンがリージョン B に伝播されるのを待ってからそのバージョンに書き込むか、11:59 バージョンに基づいて構築し、新しい 12:01 バージョンを作成することができます (書き込み後、リージョン A の回復後に着信したバージョンは抑制されます)。

最後の例として、金融サービス会社が顧客アカウントおよび金融取引に関するデータを 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 つのリージョンへの書き込み) をあえて受け入れ、アカウントの状態を簡潔に要約できるデータモデルを持つことができたことを喜んでいます。