マルチリージョン構成

DR 戦略で Pilot Light / Warm Standby / Multi-site Active を選択した場合、地理的に離れた複数の拠点にインフラを配置する必要があります。ここでは、各レイヤーをどう冗長化するかを学びます。

用語: このドキュメントでは「リージョン」はクラウドプロバイダーの地理的拠点を指します。オンプレミスでは「DR サイト」「遠隔拠点」に相当します。クラウドでは API 一つで別リージョンにインフラを構築できるため、マルチリージョン構成のハードルがオンプレミスに比べて大幅に低くなっています。

---

Active-Passive vs Active-Active

Active-Passive（Pilot Light / Warm Standby）:
  Region A (Primary):  トラフィック 100% → [アプリ] → [DB Writer]
  Region B (Standby):  トラフィック 0%  → [アプリ（最小 or 停止）] → [DB Reader]
                                                                      ↑ レプリケーション

  障害時: Region B をアクティブに → DNS 切替

Active-Active:
  Region A:  トラフィック 50% → [アプリ] → [DB Writer/Reader]
  Region B:  トラフィック 50% → [アプリ] → [DB Writer/Reader]
                                             ↑ 双方向レプリケーション

  障害時: 片方のリージョンに全トラフィックを寄せる

---

レイヤー別のマルチリージョン設計

DNS（トラフィックの振り分け）

通常時:
  api.example.com
    ├── Region A: 重み 100（Primary）
    └── Region B: 重み 0（Standby）

障害時:
  api.example.com
    ├── Region A: 重み 0（障害中）
    └── Region B: 重み 100（Active）

方式:
  ・重み付きルーティング（手動切替）
  ・ヘルスチェック + フェイルオーバー（自動切替）
  ・レイテンシベース（Active-Active 時）

アプリ

戦略	Region A	Region B
Pilot Light	フル稼働（例: 4台）	停止（イメージだけ準備）
Warm Standby	フル稼働（例: 4台）	最小稼働（例: 1台）
Active-Active	フル稼働（例: 4台）	フル稼働（例: 4台）

DB

Active-Passive（推奨）:
  Region A: Writer + Reader
       │
       │ 非同期レプリケーション（数秒のラグ）
       ▼
  Region B: Reader（昇格可能）

  障害時: Region B の Reader を Writer に昇格
  → RPO: レプリカラグ分（通常1秒未満）
  → RTO: 昇格 + DNS 切替（数分）

Active-Active（高度）:
  Region A: Writer ←→ Writer :Region B
              双方向レプリケーション

  → コンフリクト解決が必要（同じ行を両方で更新した場合）
  → 認証サービスでは Active-Passive が推奨
    （ユーザー登録は低頻度、読み取りが中心）

キャッシュ（セッションストア）

問題:
  ユーザーが Region A でログイン → セッションは Region A の Redis に
  → Region B にフェイルオーバー → セッションがない → 再ログイン

選択肢:
  ① 再ログインを許容（最もシンプル）
     → DR 時のユーザー影響として受け入れる
     → セッション TTL が短ければ影響限定的

  ② Redis のクロスリージョンレプリケーション
     → Global Datastore 等で Region 間同期
     → コスト増、レイテンシ増

  ③ DB にセッションを保存
     → DB レプリケーションで自動的にマルチリージョン化
     → パフォーマンスはキャッシュより劣る

認証サービスの場合:
  → ① が現実的。DR はめったに起きない。
  → 再ログインで復旧可能なので、セッション同期のコストは不要。

静的コンテンツ / アセット

CDN（CloudFront / CloudFlare 等）:
  → グローバルに分散済み → マルチリージョン対応不要

S3 等のオブジェクトストレージ:
  → クロスリージョンレプリケーションで DR リージョンにもコピー
  → 監査ログ、バックアップ等

---

フェイルオーバーの判断基準

「いつ DR に切り替えるか」の判断は難しい。早すぎる切り替えは不要な混乱を招き、遅すぎる切り替えは影響を拡大させる。

自動フェイルオーバーの条件（DNS ヘルスチェック）:
  ・ヘルスチェックが3回連続失敗
  ・評価間隔: 10秒 → 30秒で判断
  → 明確なダウン（全 endpoint 応答なし）は自動で切り替え

手動判断が必要な場合:
  ・部分的な障害（一部 AZ のみ影響）
  ・性能劣化だがダウンではない
  ・クラウドプロバイダーが「復旧中」と発表している
  → IC が判断：待つか、DR に切り替えるか

判断の原則:
  「30分以内に復旧の見込みがない場合、DR に切り替える」
  → 見込みが立たないなら、切り替えた方がリスクが低い

---

マルチリージョン固有の課題

データの整合性

レプリケーションラグ:
  Region A に書き込み → Region B に反映されるまで数秒

  ユーザーが Region A で登録 → 即座に Region B にフェイルオーバー
  → Region B にまだユーザーデータがない可能性（数秒のラグ）

対策:
  ・RPO として受け入れる（数秒のデータ損失は許容）
  ・同期レプリケーション（ラグ 0、ただしレイテンシ増加）

設定の同期

アプリの設定、テナント設定、クライアント設定:
  → DB に保存されているものは DB レプリケーションで同期
  → 環境変数や ConfigMap は IaC で両リージョンに適用
  → 「Region A で設定変更したのに Region B に反映されてない」を防ぐ

証明書

TLS 証明書は両リージョンに配置が必要:
  → マネージド証明書（ACM / Let's Encrypt）なら自動
  → 自己署名証明書の場合は手動で同期

クロスリージョンレイテンシ

フェイルオーバー後、ユーザーは DR リージョンにアクセスする。
DR リージョンが地理的に遠い場合、レイテンシが増加する。

例:
  Primary: 東京 (ap-northeast-1) → 日本のユーザー: RTT 数ms
  DR:      米国西部 (us-west-2)  → 日本のユーザー: RTT 100〜150ms

  → 認証リクエスト全体のレイテンシが 100ms+ 増加
  → ユーザー体感に影響（ログインが遅く感じる）

対策:
  ・DR リージョンはなるべく Primary に近い場所を選ぶ
    （東京 → 大阪 or ソウル が理想だが、サービス提供状況による）
  ・CDN（CloudFront 等）で静的コンテンツのレイテンシを軽減
  ・DR 時のレイテンシ増加はユーザーに事前告知
    （「DR 中はレスポンスが通常より遅くなる場合があります」）

---

まとめ

マルチリージョン設計のポイント:

  1. DB のレプリケーションが核（データが復旧の鍵）
  2. アプリは DR 戦略に応じて停止 / 最小 / フル稼働
  3. セッションは再ログインで対応（DR 時は許容）
  4. フェイルオーバーの判断基準を事前に決めておく
  5. 設定・証明書の同期を忘れない

次のステップ

• バックアップと復元: 何を・どこに・どの頻度でバックアップするか