マルチクラウドとは？メリット・デメリットと、障害対策・データ・運用の設計判断

2026年10月26日 · 約12分で読めます

AWS・Google Cloud・Azureを複数使うべきか。マルチリージョンやハイブリッドクラウドとの違いから、業務別の使い分けと災害復旧、データの正本、RTO・RPO、転送費、認証、退出計画まで、受注サービスの例で採用条件を考えます。

マルチクラウドとは？マルチリージョン・ハイブリッドとの違い

マルチクラウド（multicloud）は、AWS・Google Cloud・Azureなど、二つ以上のクラウド事業者のサービスを利用する構成や運用を指します。会社の部門ごとに別のクラウドを使う場合も、同じサービスを二つのクラウドに配置する場合も含みます。どちらも、すべてのアプリを相互に切り替えられることまでは意味しません。

用語	何を分けるか	分かったこと・まだ決まらないこと
マルチクラウド	クラウド事業者	複数事業者を利用する。業務の冗長化や自動切り替えは別途設計
マルチリージョン	地理的な配置	複数地域を使う。単一事業者でも構成できる
ハイブリッドクラウド	オンプレミス・プライベート環境とパブリッククラウド	既存環境とクラウドを組み合わせる。複数事業者も併用できる
マルチAZ・マルチゾーン	一つのリージョン内のゾーン	ゾーン障害に備える。リージョン全体の停止は別の障害範囲

たとえばAWSの二つのリージョンに受注サービスを配置する構成はマルチリージョンです。AWSで受注し、Google Cloudで分析する構成はマルチクラウドです。後者でAWSの受注が止まったとき、分析基盤が動いていても受注を再開できるとは限りません。

メリットとデメリット：増やすクラウドごとに、満たす要件を決める

期待できる価値には、固有サービスの利用、必要な地域への配置、組織統合、事業者への依存の分散があります。一方でIAM、ネットワーク、監視、契約、当番の習熟範囲は増えます。AWSの導入指針も、追加投資を上回る価値と運用能力を評価するよう求めています。「複数なら安心」だけでは採用条件になりません。

目的	得たい価値	採用前に確かめること
固有サービスを利用	分析などの必要な機能を使う	データ連携が主業務の応答・継続を妨げないか
必要な地域へ配置	指定された地域内で処理する	DBだけでなくバックアップ・ログ・外部連携の配置も適合するか
事業者の広範な障害へ備える	別事業者で重要業務を再開する	別リージョン案より必要な分離を得られ、復旧目標を満たせるか
乗り換え能力を保つ	条件が変わったときに退出できる	データの再取り込みと業務の切り替えを予行できるか

要件を満たす単一クラウドの案と、同じ対象業務・障害範囲・運用責任で比較します。クラウドを二つ契約しても、移行可能性の証明にはなりません。逆に、普段は一つのクラウドでも、退出手順を試しておく価値はあります。

受注サービスの例：分析の使い分けと、受注の災害復旧を分ける

まず、Bの分析機能を使いたいという要望があります。分析用データは30分の遅れを許容し、分析停止中も受注は続けたい。この要件では、受注のDBと処理をAにまとめ、確定済みデータを再送可能な非同期経路でBへ渡す案を評価します。重複は転送先で排除し、削除やスキーマ変更の扱い、転送停止中にAで保持できる量も決めます。

分析連携の案。矢印はデータの流れで、受注成功はBの応答を待たない

A：受注APIと正本DBで確定 → A：耐久性のある変更記録を保持 → 非同期転送・再送・重複排除 → B：分析用コピーを更新

別の要望として「Aが広範に使えない場合でも、受注を30分以内に再開し、失う更新の時間幅を60秒以内にしたい」が加わったとします。前者がRTO（復旧時間の目標）、後者がRPO（復旧時に許容するデータ損失の時間幅）です。分析用コピーには、注文の状態遷移や必要な履歴が欠けているかもしれません。分析連携とは別に、受注そのものの復旧案を検証します。

構成の選び方：業務分割、アクティブ・パッシブ、アクティブ・アクティブ

構成	主な使いどころ	データと運用の課題
業務ごとに分割	受注はA、分析はB	各業務の正本と連携契約を決める。受注の待機系にはならない
アクティブ・パッシブ	通常はAで受注し、障害時にBへ切り替える	Bのデータ・容量・設定を維持し、書き込みの切り替えと復帰を試す
アクティブ・アクティブ	通常時からAとBで業務を提供	同じデータへの競合、担当領域の分割、全量を引き受ける容量を決める

アクティブ・アクティブでも、テナントごとに書き込み先を一つにする案と、同じ注文を両側で更新する案では難しさが違います。在庫や決済を同時更新するなら、競合を検出・解決する仕組みや合意の方式まで必要です。二つのAPIを起動してロードバランサーを置くだけでは、この問題は解けません。

Google Cloudの設計パターンも、異なる業務を配置する構成と、同じ業務を冗長に配置する構成を扱っています。今回の受注の復旧では、最初に単一事業者の別リージョン案と、Bに待機系を置く案を比較します。対象とする障害がどちらで分離できるかを先に決めます。

データ設計：正本を一つにし、複製遅延と二重書き込みを扱う

Bに待機系を置く案を具体化するため、ここでは両側のVMで自分たちが管理するPostgreSQL 17を使い、互換なビルド・設定の間で非同期ストリーミング複製する想定に限定します。特定のマネージドDB同士を、そのまま物理レプリカとして接続できるという例ではありません。拡張、OS、照合順序、復旧ツールを含めた組み合わせの確認が必要です。

Aを唯一の書き込み元にし、Bは復旧するまで読み取り専用にします。PostgreSQLの非同期複製では、Aで成功した更新がまだBに届いていない時間があります。Aを失えば、その未転送部分を復旧できない可能性があります。平常時の遅延が20秒でも、回線断後もAが更新を受け続ければ差は広がるため、RPO 60秒の達成は証明できません。

Aの受注確定記録と、Bで耐久化・適用できた位置を対応付ける。最終複製時刻だけでなく、復旧した注文ID・状態・履歴を照合して損失幅を確認する。
RPOが危ういときの判断を事前に決める。更新を続けるか、受注を止めるか、別の同期方式を採るかを業務側と合意する。監視値には観測遅延もある。
更新直後の確認画面は、現在の正本か、その更新まで追いついたコピーから読む。分析用コピーを、そのまま注文確定の根拠に使わない。
誤削除も複製されうるので、履歴を持つバックアップを別に残す。Bでの復元と復号を試し、Aの鍵サービスだけに依存しない。

切り替えでは、Aが停止したのか、AとBの間だけ通信できないのかを区別します。BからAが見えないだけでBを書き込み可能にすると、Aも更新を続けるスプリットブレインが起こりえます。旧書き込み元の停止・隔離を確認するフェンシングが必要です。DNSの変更は既存接続や内部ジョブを止めないため、書き込みの排他にはなりません。

RTOはDBの昇格時間だけでは決まらない

仮に次の工程を直列に行い、それぞれの時間で完了すると、受注再開まで2 + 3 + 4 + 6 + 4 + 3 = 22分です。RTO 30分に対して残りは8分ですが、これは計画上の余白です。再試行、担当者の不在、接続の再確立、容量不足で伸びる時間を含めて測る必要があります。

独自の仮定：直列の復旧工程の所要時間（分）。合計22分、目標30分

障害検知: 2分
復旧の判断: 3分
旧書き込み元の隔離: 4分
データ確認とDB昇格: 6分
アプリ・接続先の切り替え: 4分
業務の正常性確認: 3分

復旧の終了は、BのVMが起動した時点ではなく、合意した負荷で注文の作成と確認ができる時点にします。DNSキャッシュ、既存接続、認証情報の更新、DB接続プールも確認対象です。待機系が小さい場合は、ピーク200req/sまで増やせる枠と、増強が完了する時間も測ります。

Aが戻っても即座にトラフィックを戻しません。Bを現在の正本としてAを再同期し、分岐した更新や外部の決済結果を照合してから、計画的に書き込みを切り替えます。Aへの復帰も、逆方向のデータ転送、権限、負荷、作業時間を持つ一つの移行です。

通信と費用：クラウド境界を越える回数と転送量を減らす

たとえば一つの要求がクラウド間を直列に3往復し、各往復の通信待ちが30msという仮定なら、通信待ちだけで90msを使います。これは説明用の足し算で、p99の予測ではありません。処理を細かく分けるほど、相手クラウドの停止や回線断も受注の成功に影響します。分析への転送を非同期にする案では、受注の成功経路からこの待ちを外せます。

接続方式では、帯域と遅延に加え、IP範囲の重複、DNS、BGPの経路、ファイアウォール、経路の独立性を確認します。専用接続という名前だけで暗号化を満たすとは扱いません。Google Cloudの接続資料も、Interconnect上の暗号化としてHA VPN over Cloud Interconnectなどの構成を説明しています。必要な保護を接続の区間ごとに確かめます。

総保有コストには、二つ目の計算資源だけでなく、待機DB、監視・監査、サポート、教育、当番、復旧演習の時間を含めます。正常時は少量でも、全量コピーや障害からの復帰で転送が集中することがあります。定常運用と復旧作業の両方について、量と費用の上限を決めます。

認証と運用：共通化する基準と、独立させる復旧経路

二つのクラウドの権限モデルは同じではありません。共通にするのは、誰がどの環境の何を操作できるかという基準です。実際のロール・ポリシーはそれぞれで設定し、本番と検証、デプロイとデータ閲覧の主体を分けます。監査には、実行主体、対象、結果、関連する注文や作業の識別子を残し、各環境で調査できるようにします。

たとえばA上の処理からGoogle Cloudの分析先へアクセスするなら、対応する外部IDをWorkload Identity Federationで短命な認証情報に交換する案があります。長期のサービスアカウント鍵の配布を減らせますが、権限は別途限定します。OIDCでは発行元・audience・組織や実行元の属性条件を確かめ、許可外の主体が拒否されることも試します。

一方、Bでの受注再開がA上のID発行、CI、コンテナレジストリ、KMSの応答を必須にすると、Aの障害時に復旧できません。共通のID基盤やDNSを使う場合も、その停止を対象障害に含めて考えます。Bに必要な成果物・設定・鍵へのアクセスと、監査可能な緊急操作経路を用意し、認証情報の期限が切れた状態から試験します。

両クラウドで担当者と副担当者を決め、受注のSLOから通知する。片側の管理画面や監視転送が止まっても、障害と対応状況を把握できるようにする。
配布するバージョン、設定、スキーマの対応を管理し、待機系にも変更を適用する。復旧時に初めて新しい設定を取得する依存を減らす。
通信や複製が切れた場合は期限と再試行上限を設ける。受注と分析の連携では、保持量が限界に近づく前の縮退・停止条件を決める。

ロックイン対策：KubernetesやTerraformだけで移行は完了しない

コンテナや共通の構成管理ツールは、持ち運べる部分を増やします。ただし、データやサービスの意味まで同じにはなりません。GOV.UKの指針も、クラウドへの依存が生む価値と、切り替えに必要な時間・費用を比べています。すべてを共通機能に合わせる前に、退出に必要な能力を決めます。

対象	持ち運びやすくするもの	退出の予行で確認すること
アプリ	コンテナ、明示した外部APIの境界	CPU・実行環境、ボリューム、ロードバランサー、秘密情報の差
データ	スキーマ・履歴・データ出力の契約	SQLや拡張の互換性、変換、再取り込み、削除と権限の意味
インフラ	Terraformなどの変更・レビュー手順	事業者ごとのリソース定義、状態管理、クォータ、適用権限
運用	SLO、手順、監査の基準	認証、通知、障害調査、当番が移行先でも機能するか

退出を数か月かけて行う能力と、災害時に30分で再開する能力は異なります。普段はマネージドDBの価値を使い、データの出力・変換・復元を定期的に試す案もあります。二つのクラウドで常時同じ基盤を自主管理する案と、得られる復旧能力と維持負担を比べます。

採用前の検証：どちらのクラウドを止め、何ができれば合格か

試す条件	確認する結果	採用を見直す兆候
Bの分析と転送を停止	Aで受注を継続し、再開後は保持した変更を重複なく反映	受注がBを待つ、または未転送の変更を失う
AとBの間だけを切断し、Aは稼働	Bが勝手に書き込みを開始せず、複製の遅れを検知	両側で同じ注文を更新できる
Aの管理APIとデータ経路を使えなくする	独立した手順で排他を確立して受注を再開、または安全に停止	排他の確認ができないままBへ昇格する
認証情報の期限切れ・Aの成果物取得不能	Bで認証を更新し、配布・復号・調査を実施	AのID・レジストリ・鍵が復旧の必須条件
ピーク負荷でBへ復旧	注文と履歴を照合し、損失幅60秒以内・業務再開30分以内を確認	DB昇格だけ計測し、データ損失や容量が未確認
Bで更新後、Aへ復帰	正本を一つに保ち、注文・決済を照合して再同期・切り替え	Aの古い状態でBの更新を上書きする

試験で合格しても、すべての障害に対する保証にはなりません。対象障害、負荷、データ量、バージョン、計測開始・終了、実測RTOと損失幅を記録し、構成変更後に再試験します。隔離できず停止した場合は安全性の確認にはなっても、受注再開のRTOを満たしたとは扱いません。