グローバルテーブルの退避プロセス

リージョンの退避とは、アクティビティ（通常は書き込みアクティビティ、場合によっては読み取りアクティビティ）をそのリージョンから移行するプロセスです。

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

ライブリージョンを退避する理由はさまざまです。たとえば、通常のビジネス活動の一環として (たとえば、a follow-the-sun を使用している場合は 1 つのリージョンに書き込む)、現在アクティブなリージョンを変更するというビジネス上の意思決定、DynamoDB 外のソフトウェアスタックの障害への対応、リージョン内で通常よりも高いレイテンシーなどの一般的な問題が発生している場合などです。

任意のリージョンへの書き込みモードでは、ライブリージョンから簡単に退避できます。任意のルーティングシステムを使用してトラフィックを代替リージョンにルーティングし、退避したリージョンですでに行われた書き込み操作を通常どおり複製できます。

あるリージョンへの書き込みモードとリージョンへの書き込みモードでは、新しいアクティブリージョンで書き込み操作を開始する前に、アクティブリージョンへのすべての書き込み操作が完全に記録され、ストリーム処理され、グローバルに伝達されていることを確認する必要があります。これにより、future 書き込み操作が最新バージョンのデータに対して処理されるようになります。

例えば、リージョン 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で読み取りと書き込みの操作を続行できます。同じ書き込み操作を行う場合など、可能な場合は、(たとえばアップストリームのイベントソースを使用して) 最近の書き込みトラフィックをリプレイすることを検討してください。これにより、欠落している可能性のある書き込み操作のギャップを埋め、最後の書き込みが競合解決され、入力された書き込み操作の最終的な伝播が抑制されます。

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

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

別の例として、Web フォームのデータをキャプチャしているとします。オプティミスティック・コンカレンシー・コントロール (OCC) を使用してデータ項目にバージョンを割り当て、最新バージョンを隠しフィールドとして Web フォームに埋め込むことができます。送信するたびに、データベース内のバージョンがフォーム作成時のバージョンとまだ一致する場合にのみ、書き込みオペレーションが成功します。バージョンが一致しない場合、データベース内の現在のバージョンに基づいてウェブフォームを更新 (または慎重にマージ) することで、ユーザーは再度続行できます。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 のデータは非常に一時的なもので、up-to-date数分後には処理中の書き込み操作に関する十分な記録がリージョン D に蓄積され、十分に役に立ちます。リージョン B に障害が発生しても、リージョン A はリージョン C と協力して書き込みリクエストを引き続き受け入れることができます。同社は、より高いレイテンシーの書き込み (C に続けて A という 2 つのリージョンへの書き込み) をあえて受け入れ、アカウントの状態を簡潔に要約できるデータモデルを持つことができたことを喜んでいます。