導入：マルチクラウドDB構成の「落とし穴」
マルチクラウド戦略は、ベンダーロックインを回避し、システムの可用性を最大化する理想的なアプローチです。しかし、異なるクラウド環境間で データベースのデータ一貫性（RPO）と即時復旧（RTO） を両立させることは、技術的な複雑さと運用コストの観点から非常に困難です。
本記事では、この課題に対し、PostgreSQLの標準機能をベースにビジネス要件とリスク許容度に応じた4つの明確なインフラ構成レベルを提案します。そして、電子カルテシステムを例に、最も現実的で効果的な「ハイブリッドDR戦略」を紹介します。
1. マルチクラウドDB構成：戦略的な4つのレベル
データベースのHA/DR（高可用性・災害復旧）戦略は、「コストをかけてもRPO=0を達成するか」、 「停止時間を許容しシンプルさを取るか」 という判断に集約されます。
レベル 4：極限のHA/DR (RPO=0、即時復旧)
これはミッションクリティカル（金融決済、コア取引など）なシステム向けです。
- 目標: データロストゼロ（RPO=0）、自動フェイルオーバーによる秒単位のRTO。
- 技術: 同期レプリケーション (PostgreSQL) + HAツール (Patroniなど) + 専用線。
- トレードオフ: 高コスト、極めて高い運用難易度、ネットワーク遅延による書き込み性能の低下を許容。
レベル 3：高い参照可用性/迅速なDR (現実的なマルチクラウドDR)
多くの重要度の高いシステムが取るべきバランスの取れた戦略です。
- 目標: データロスト許容（RPO > 0）、セカンダリの参照継続性、数分〜数十分での業務再開（RTO）。
- 技術: 非同期レプリケーション (PostgreSQL)。セカンダリは参照専用。障害時手動昇格。
- メリット: 低遅延で書き込み性能を維持しつつ、運用複雑性とHAツールのコストを大幅に削減。
レベル 2：アプリケーションの可用性 (DB障害時は停止許容)
データベースよりもアプリケーションの冗長性を優先する戦略です。
- 目標: DB障害時はサービス停止を許容。他サービスへの影響分散。
- 技術: DBはプライマリクラウドのみに配置。アプリケーション層は両クラウドに展開し、セカンダリのアプリもプライマリDBにアクセス。
- メリット: DB構成がシンプル。アプリケーションのHA/負荷分散は実現。
レベル 1：単一クラウド集中 (業務停止を許容)
マルチクラウド戦略を取らず、シンプルさと低コストを最優先します。
- 目標: プライマリクラウドの可用性（AZ冗長など）に依存。クラウド障害時は業務停止を許容。
- 技術: シングルクラウドのマネージドDBまたは自前構築。
- メリット: 最も安価で管理が容易。
2. ケーススタディ：電子カルテシステムの「最適解」
電子カルテシステム（EHR）は、 「参照（過去の診察記録）」の継続が極めて重要であり、「書き込み（新たな診察記録）」 は一時的に遅延しても許容される特性を持ちます。
この特性にレベル3の戦略をさらに進化させたものが、 「ハイブリッドDR戦略」 です。
採用戦略：レベル3の進化系（参照継続 ＋ 書き込み保全）
- データベース構成:
- クラウドA（プライマリ）：PostgreSQL（書き込み担当）
- クラウドB（セカンダリ）：PostgreSQLの非同期リードレプリカ（参照担当）
- 平常時: アプリケーションはクラウドAに書き込み、クラウドBから読み込み（負荷分散）。
- プライマリ障害時（クラウドAダウン）の動作:
| 業務の種類 | 動作 | RPO/RTOへの貢献 |
|---|---|---|
| 参照業務 | クラウドBのリードレプリカから継続。 | 業務継続性（参照RTOの最小化） を実現。 |
| 書き込み業務 | DBへの書き込みを中止し、データをJSON形式で一時ファイル（キュー）としてクラウドBのオブジェクトストレージに格納。 | 書き込みデータの保全（RPOのゼロ化） を実現。 |
復旧の仕組み（JSONキューの活用）
クラウドAが復旧した後、アプリケーションは以下の手順でデータを復旧します。
- クラウドBのアプリケーションがオブジェクトストレージの一時ファイル（キュー）を読み込む。
- 各JSONデータに冪等性（べきとう性）を担保した形で（二重登録を防ぎながら）クラウドAの復旧したプライマリDBに再登録する。
- 全てのデータ登録が完了したら、一時ファイルを削除。
このハイブリッド戦略は、 「参照継続性」と「書き込みデータの保全」 という2つの要件を、複雑な同期レプリケーションやHAツールに頼ることなく、PostgreSQLの標準機能とオブジェクトストレージだけで同時に達成できる、非常に現実的かつスマートな解決策と言えます。
結論：戦略的な割り切りが成功の鍵
マルチクラウドでのデータベース構成は、全てを最高レベルで実現しようとすると失敗します。
あなたのプロジェクトのRPOとRTOの要件を正確に把握し、レベル1から4の中で 「最適な割り切りポイント」 を見つけることが、インフラエンジニアの真の腕の見せ所です。PostgreSQLの標準機能は、その柔軟性によって、上記のどのレベルの構成にも対応できる強力な土台となります。