プロンプトとコンテキスト
注文、ユーザー設定、または在庫サービスは、複数のリージョンでローカルな読み取りと書き込みを提供する必要があります。DynamoDB Global Tables の MREC（マルチリージョン結果整合性）と MRSC（マルチリージョン強力整合性）を比較し、ルーティング、競合、フェイルオーバー、キャパシティ、復旧について説明してください。この面接では、データベースを別の場所に単にコピーすることではなく、一貫性と運用の境界をテストします。
Global Tables はマネージドなマルチリージョン・マルチアクティブレプリケーションであり、任意のレプリカで読み取りと書き込みを処理できます。MREC はデフォルトであり、非同期にレプリケーションを行います。同じ項目が異なるリージョンでほぼ同時に変更された場合、DynamoDB は内部タイムスタンプによる Last-Writer-Wins（LWW）ルールを使用して項目単位で競合を解決します。MRSC は、書き込みの成功応答を返す前に少なくとも他の 1 つのリージョンへ同期的にレプリケーションを行い、任意のレプリカでの強力な整合性のある読み取りが最新の値を返します。MRSC には正確に 3 つのリージョン（3 つのレプリカ、または 2 つのレプリカと 1 つのウィットネス）が必要です。
面接官がテストしていること
優れた回答では、RPO、書き込みレイテンシ、読み取り保証からモードを選択する前に、ビジネスの不変条件を項目、パーティションキー、項目間トランザクションに分解します。LWW によるサイレントなデータ消失、MRSC の 3 リージョン制約、リージョン間での MREC トランザクションの可視性、フェイルバック時の順序付けに関する質問が想定されます。
単に「マルチリージョンレプリケーションを有効にする」と答えるだけでは不十分です。ローカルリージョンのエンドポイント、同一項目への二重書き込みを回避する方法、ReplicationLatency の監視方法、削除・リトライ・重複イベントの処理方法を説明してください。
最初に明確にすべき質問
不変条件と競合の形状
注文ステータスが過去の状態に戻ることが許容されるか、在庫が線形化可能である必要があるか、1 つの項目が複数のリージョンで同時に編集され得るかを確認します。個別にマージ可能なフィールドは、別々の項目やバージョニングされたサブレコードに分割できます。フィールド間のアトミック性に関しては、MREC トランザクションが呼び出し元リージョンでのみアトミックであり、単一のトランザクションとしてレプリケーションされない点に対処する必要があります。
RPO、レイテンシ、リージョン数
RPO、P99 書き込みレイテンシ、フェイルオーバー時間、および対象リージョンを明確にします。MREC は利用可能な任意の数のリージョンを使用でき、通常 1 秒以内に伝播します。MRSC はリージョン間の強力な読み取りと RPO ゼロの目標のために書き込みレイテンシをある程度犠牲にしますが、正確に 3 つのリージョンが必要です。
書き込み所有権と復旧
書き込みが真にマルチアクティブであるか、各テナントがホームリージョンを持ち、他のリージョンには読み取りレプリカを配置する構成であるかを決定します。ビジネスが LWW を許容できない場合は、IAM やルーティングを使用してライターを制限し、セマンティクスをレプリケーションに委任するのではなく、復旧中の競合判定の権限を明示的に定義します。
30秒の回答
「私はビジネスの不変条件からモードを選択します。在庫のデクリメントやリージョン間の強力な読み取りが必要な場合は MRSC を選択し、一時的な不整合を許容してローカルの書き込みレイテンシを優先するワークロードにはデフォルトの MREC を使用します。MREC は非同期かつ項目レベルの LWW であるため、各注文やテナントを 1 つのリージョンに固定（ホームリージョン化）し、条件付き書き込み、冪等性キー、明示的なバージョンを追加します。マージ不可能な状態は LWW に依存しません。すべてのリクエストはローカルエンドポイントを使用し、リージョン障害時にはアプリケーションエッジでトラフィックを切り替えます。ReplicationLatency、レプリケーションエラー、条件付き書き込みの失敗を監視し、バージョン、イベント、ビジネスルールを使用して復旧の再生と監査を行います。」
ステップごとの解決策
ステップ 1: 一貫性モードの選択
MREC はデフォルトで、任意の数のリージョンをサポートし、結果整合性を提供するため、ユーザー設定、カタログ、およびステールデータを許容する読み取りモデルに適しています。MRSC は書き込みの成功前に少なくとも他の 1 つのリージョンへ同期的にレプリケーションし、任意のレプリカでの強力な読み取りが最新の値を参照します。これには正確に 3 つのリージョンが必要で、トランザクション操作はサポートされません。モードは作成時に選択され、レプリカ間で異なるモードを混在させることはできず、後からテーブルのモードを変更することもできません。
ステップ 2: 書き込みトポロジの定義
アプリケーションはローカルリージョンの DynamoDB エンドポイントを使用する必要があります。マルチアクティブな書き込みは、ビジネス側で同時競合を解決できる場合にのみ適切です。注文や在庫などの厳格な制約があるオブジェクトは、ホームリージョンでのみ書き込みを行い他リージョンでは読み取りのみとするか、テナントや注文ごとの単一ライターパーティションを使用します。リージョン間の呼び出しはレイテンシと障害要因を増大させるため、トラフィックの切り替えはアプリケーションのエントリポイントまたはルーティングレイヤーで行うべきです。
ステップ 3: MREC での競合の抑制
MREC は、同一項目に対するほぼ同時の更新に対して内部タイムスタンプ LWW を使用します。レプリカは最終的に収束しますが、破棄されたビジネス上の変更が自動的に補償処理に変換されることはありません。バージョン管理には条件式を使用し、冪等リクエスト ID を含めます。上書きできない状態については、追記専用（append-only）イベントまたは競合レコードを永続化します。古い更新によって削除済みオブジェクトが復活しないように、削除は明示的なトゥームストーンまたはステータスとして表現します。
ステップ 4: トランザクションとリトライの処理
MREC の TransactWriteItems は呼び出し元リージョンでのみアトミックです。他のレプリカでは一時的に部分的な変更が観測される可能性があるため、リージョンを跨いだ読み取りはトランザクションの完了確認にはなりません。リトライ処理では、制限付きの指数バックオフと冪等性キーを用い、条件付きの失敗、スロットリング、レプリケーション遅延を区別する必要があります。MRSC はトランザクション操作をサポートしないため、複数項目にわたる不変条件には新しいモデルやサービス間での調整が必要です。
ステップ 5: フェイルオーバーと復旧の計画
レプリケーション遅延、レプリケーションエラー、条件付き書き込みの失敗、リクエスト元リージョン、ビジネスバージョンを監視します。障害による隔離中は、エントリトラフィックを正常なリージョンに移行します。MREC の場合、まず競合に敏感な書き込みを一時停止するか、テナントのホームリージョンを再割り当てし、切り替え時刻と最後に確認されたバージョンを記録します。復旧後は、イベントログ、バージョン、ビジネスルールを使用して整合性を検証します。レプリカ同士のデータが一致していることだけでは、在庫や注文の正しさは証明されません。
ステップ 6: キャパシティ、セキュリティ、ガバナンス
すべてのレプリカについて、読み取り/書き込みキャパシティ、オートスケーリング、クォータを評価します。新しいレプリカは作成時にソースリージョンのキャパシティ設定を継承し、その後調整できます。レプリカごとに削除保護を有効にし、IAM を使用して書き込みリージョンやテーブル操作を制限します。また、KMS 権限が失われると対応するレプリケーションが停止することに留意してください。マルチアカウントの Global Tables は MREC をサポートしますが MRSC はサポートしないため、アカウント、リージョン、監査の所有権を明確にする必要があります。
ステップ 7: 検証とリハーサル
2 つのリージョンでの同一項目への同時書き込み、条件付きリトライ、ネットワーク分断、遅延更新を伴う削除、レプリケーションのスパイク、トラフィックの切り替え、フェイルバックをリハーサルします。結果整合性の収束、完全な補償イベント、重複に対して安全なリプレイを検証し、ReplicationLatency や競合数とリクエスト ID を関連付けます。負荷テストは実際のリージョン間距離とキャパシティモードを反映させる必要があります。単一マシンでのレイテンシ測定はリージョン間の推定にはなりません。
質の高い回答例
私は不変条件に基づいてモードを選択します。リージョン間の強力な読み取りと RPO ゼロの目標を必要とする重要なデータには MRSC を採用し、正確に 3 つのリージョンが必要であること、書き込みレイテンシが高くなること、トランザクション操作が使えないことを受容します。カタログやユーザー設定には MREC を使用できます。非同期の項目レベル LWW はビジネスセマンティクスをマージできないため、注文と在庫にはテナントまたは注文ごとのホームリージョン単一書き込み、条件式、バージョン、冪等性キーを使用します。マージ可能なフィールドは独立した項目にし、マージ不可能な更新は競合イベントとして記録します。
アプリケーションはローカルエンドポイントを使用し、エントリレイヤーでリージョンフェイルオーバーを実行します。ReplicationLatency、レプリケーションおよび条件付き書き込みの失敗、バージョン差異を監視し、スロットリングや遅延に対して上限付きバックオフを適用します。復旧中は影響を受ける書き込みを凍結し、イベントログとビジネスルールから収束を検証した上で、徐々にトラフィックを再開します。レプリカごとにキャパシティ、削除保護、IAM、KMS を監査し、同時書き込み、分断、遅延削除、重複リプレイのリハーサルを実施します。
よくある間違い
- 間違い: Global Tables が無制限のマルチアクティブ書き込みを意味すると想定する。 → 失敗する理由: MREC の LWW により、マージ不可能なビジネス上の変更が破棄される可能性があるため。 → 対策: 書き込み所有権を割り当てるか、明示的なバージョン、イベント、補償処理を設計する。
- 間違い: MREC トランザクションをグローバルにアトミックなものとして扱う。 → 失敗する理由: アトミック性は呼び出し元リージョンに限定され、他のレプリカでは部分的な変更が見える可能性があるため。 → 対策: リージョンを跨ぐ不変条件を再モデリングし、イベントと冪等性で調整する。
- 間違い: タイムアウト後に盲目的に別リージョンへ切り替える。 → 失敗する理由: 二重書き込みにより競合とフェイルバック時のリスクが増大するため。 → 対策: 書き込みを一時停止または制限し、バージョンを記録した上で、テナントやビジネス境界に沿って切り替える。
- 間違い: レプリカのデータ収束を在庫の正確性と同一視する。 → 失敗する理由: LWW はレプリケーションの同期を解決するだけで、ビジネス的な意味を解決するわけではないため。 → 対策: 条件付き書き込み、イベントログ、補償処理、監査によって検証する。
フォローアップの質問と回答
フォローアップ 1: MRSC をどのような場合に選択しますか？
リージョン間の強力な読み取りと RPO ゼロの目標が、書き込みレイテンシやリージョン配置の柔軟性よりも優先される場合に MRSC を選択します。正確に 3 つのリージョン（オプションで 1 つのウィットネス）が必要であり、トランザクションはサポートされません。ワークロードに任意のレプリカ数やマルチアカウントレプリケーションが必要な場合は、MREC とサービスレベルでの調整を再検討します。
フォローアップ 2: LWW によって在庫のデクリメントが上書きされた場合はどうしますか？
LWW から数量を復旧させようとしないでください。デクリメントには条件式とバージョンを使用し、商品または在庫シャードごとに安定した書き込みオーナーを割り当て、すべてのデクリメントを冪等なイベントとして記録します。競合検出機能がイベントシーケンスを比較し、補償処理を発行するか人手による対応キューに送ります。読み取り側ではバージョンと可視化時刻の両方を確認します。
フォローアップ 3: MREC のレプリケーション遅延が増加した場合はどう対処しますか？
送信元リージョン、送信先リージョン、およびビジネスへの影響ごとにアラートをグループ化します。競合の発生を止めるため、リージョンを跨いだ書き込みを制限するか、テナントをホームリージョンに戻します。クライアントのリトライ回数を制限し、マルチアクティブな書き込みを再開する前に、バージョン、遅延イベント、削除マーカーを調整・照合します。ReplicationLatency は伝播状況を測定するものであり、ビジネス上の正しさを測定するものではありません。
フォローアップ 4: フェイルバックをどのようにテストしますか？
トラフィックの切り替え、旧リージョンの復旧、双方へのリクエスト到達、遅延削除をテストします。すべてのリクエストについてリージョン、バージョン、冪等性 ID を記録します。古いリージョンが新しい状態を上書きできないこと、競合イベントの追跡が維持されること、補償処理が再実行可能であることを検証します。RPO、RTO、競合数、人的介入の有無を報告します。
フォローアップ 5: レプリカで MREC と MRSC を混在できないのはなぜですか？
一貫性モードは作成時のテーブルレベルの設定です。レプリカごとに異なるモードを使用することはできず、テーブル作成後にモードを切り替えることもできません。要件が変更された場合は、新しいテーブルの作成、移行、制御された二重書き込みまたはリプレイ期間が必要となり、事前にキャパシティ、権限、クライアントの互換性、ロールバック手順を検証する必要があります。