リファレンスアーキテクチャ: マルチリージョン / グローバル

ユーザーが地理的に分散している場合や、リージョン規模の災害への耐性が必要な場合、データは複数のリージョンに分散される。このツリーは、読み取りの局所性 (各リージョンのリードレプリカ)、書き込みのトポロジー (シングルリーダー vs マルチリーダー vs クォーラム)、データ所在地/コンプライアンス (GDPR)、競合解決、RPO/RTO とレイテンシのトレードオフを段階的に説明する。基本的な真実: 物理法則により、低レイテンシ、強い一貫性、マルチリージョン書き込みのすべてを同時に完全に実現することはできない。意図的なトレードオフが必須。

なぜマルチリージョンにするのか: 読み取りの局所性、書き込み/耐障害性、それともコンプライアンスか?

マルチリージョンアーキテクチャはコストが高く複雑。動機を明確にする。遠隔地のユーザーに低い読み取りレイテンシを提供したいのか、リージョン間の書き込み/災害耐性が必要なのか、それとも本当の要件はデータを特定の国に留めること (法的な所在地) なのか?

• 遠隔地のユーザー向けの高速な読み取り。書き込みは 1 つのリージョンでよい
• リージョン間の書き込み / リージョン喪失への耐性が必要
• データは法的に特定の国/リージョンに留める必要がある

書き込みのトポロジーはどうすべきか: シングルリーダー、マルチリーダー、クォーラム?

リージョン間の書き込みにおける重要な判断はリーダーシップモデル。すべての書き込みを単一のリージョンに送るのか (シンプルで一貫しているが、遠隔からの書き込みは遅い)、すべてのリージョンが書き込めるのか (書き込みレイテンシは低いが競合が発生する)、それとも過半数のリージョンの確認応答で書き込みを受け付けるのか (クォーラム: 一貫しているがレイテンシが加わる)?

• 1 つのリージョンが書き込み、他は読み取る (シンプルで一貫している)
• すべてのリージョンがローカルに書き込める (低い書き込みレイテンシ)
• 過半数の確認応答で書き込む。一貫性が最優先

推奨: リージョンごとのリードレプリカ (読み取りの局所性)

書き込みは単一のプライマリリージョンにとどめ、各ユーザーリージョンにそこから供給されるリードレプリカを配置する。ユーザーは最寄りのレプリカから読み取るため読み取りレイテンシが下がり、書き込みは引き続き単一の拠点に送られるため一貫性モデルはシンプルなまま。

推奨: シングルリーダーの書き込み

すべての書き込みは単一のリーダーリージョンに送られ、他のリージョンはそのリーダーから非同期に供給されるリードレプリカ。最もシンプルで最も一貫性の強いモデルであり、書き込み地点が 1 つなので競合はない。代償は遠隔リージョンからの高い書き込みレイテンシ。

推奨: マルチリーダーの書き込み + 競合解決

すべてのリージョンがローカルに書き込めるため書き込みレイテンシは低く、1 つのリージョンが切断されても他のリージョンは書き込みを続けられる。代償は大きい: 2 つのリージョンが同じレコードを異なる内容で更新する可能性があり、競合解決を設計する必要がある。

推奨: クォーラムベースの書き込み (過半数の確認応答)

書き込みは、リージョン/レプリカの過半数 (クォーラム) が確認応答したときに受け付けられる。読み取りも過半数に対して行えば、最新の値が保証される。リージョンの喪失に強く一貫性も強い。代償は、すべての書き込みが過半数に到達するまでのレイテンシ。

推奨: データ所在地 / コンプライアンス (GDPR)

一部のデータ (個人、医療、金融) は、法的に特定の国/リージョンの境界内にとどめる必要がある (例: GDPR)。この場合、アーキテクチャは「どこにでもコピーする」ではなく、データが地理的に固定されるように設計する。