4. 金融に必須のクラウド設計：冗長化と BCP

金融におけるクラウド設計は、一般的な IT システムとは根本的に思想が異なります。

「念のための保険」ではなく、 冗長化と BCP（事業継続計画）は“システムそのもの” です。

金融インフラでは障害は“例外”ではなく“前提”であり、 壊れることを前提として動き続ける構造を作ることが設計の中心に据えられます。

4-1. 冗長化は「保険」ではなく“前提条件”

一般的なシステムでは、冗長化は「あれば安心」の追加対策と捉えられがちです。

しかし金融インフラでは、冗長化は “あるべき前提” であり、 実装されていなければそもそもシステムが成立しません。

金融システムでは、以下の事象はすべて「起きるもの」として扱われます。

• データセンター障害
• ネットワーク断
• ハードウェア故障
• 外部 API の停止

金融インフラの設計思想：

「障害をなくす」のではなく「障害が起きても動き続ける構造を作る」

4-2. マルチ AZ は“最低ライン”である

クラウドにおける基本的な冗長化手法であるマルチ AZ（Availability Zone）構成は、 金融では “推奨”ではなく 最低条件 です。

マルチ AZ のポイント：

• データの同期レプリケーション
• 自動フェイルオーバーの実装
• フェイルオーバー動作の定期検証
• 手動切替の排除（“切り替わるつもり”は設計ではない）

単一 AZ で本番運用することは金融では即アウト。 1AZ 障害＝全停止となり、重大事故につながります。

4-3. マルチリージョン：真の BCP はここから始まる

マルチ AZ は必須ですが、AZ は同一地域内に存在するため、 地震・大停電など“地域障害”には耐えられません。

そこで必要になるのが マルチリージョン構成 です。

マルチリージョンの種類

• Active–Active：複数リージョンを常時稼働し即時切替（市場系向け）
• Active–Standby：片系稼働＋障害時切替（決済系向け）

BCP 設計の本質は、 「どこまで止められないか」というリスク判断 にあります。

4-4. 「クラウド＝BCP」の誤解を捨てる

「クラウドを使っているから安全」 「クラウド事業者が守ってくれる」

これらは金融における典型的な誤解です。

クラウドが保証しているのはインフラの可用性であり、 冗長化構成・フェイルオーバー・データ整合性・外部依存管理 は利用者の責任です。

つまり、クラウドを使うだけでは BCP は成立せず、 「金融リスク管理の責任は委託できない」 のです。

4-5. BCP 設計の本質：シナリオベースで設計する

金融の BCP では「手順書」ではなく 「設計」 が重要です。

BCP は“紙”ではなく、 “動く構造” でなければ意味がありません。

障害シナリオと設計例

• AZ 障害 → マルチ AZ ＋ 自動フェイルオーバー
• リージョン障害 → マルチリージョン ＋ DNS 切替
• ネットワーク断 → 回線二重化 ＋ 経路分散
• 外部 API 停止 → 代替 API ＋ リトライ設計

BCP 設計は、 「何が壊れるか」「どこまで影響するか」「どれくらいで復旧するか」 を常に問い続けながら作るべきものです。

4-6. RTO と RPO：金融における“時間の設計”

金融では、 時間＝リスク です。

重要指標

• RTO：復旧まで許容される時間
  • 市場系：数秒〜数分
  • 決済系：数分以内
• RPO：どこまでデータを失ってよいか
  • 市場系・決済系：ほぼゼロ（データロス不可）

RTO/RPO は金融インフラ設計の根幹となる “時間の金融リスク” そのものです。

4-7. 外部接続の冗長化：最も壊れやすいポイント

金融システムで最も脆弱なのは 「外部依存」 です。

（取引所 API、決済ネットワーク、他行システムなど）

必要な設計

• 回線の二重化
• 異キャリア利用
• 多重経路の確保
• 複数 API の確保
• 自動フェイルオーバー
• フォールバック処理（サーキットブレーカー）

外部が止まると自社も止まるため、 外部依存の設計こそ BCP の最重要ポイント です。

4-8. 失敗パターンから学ぶ：事故は“設計の鏡”

金融クラウド設計の失敗はパターン化されています。

• 単一 AZ で運用 → 即全停止
• フェイルオーバー未検証 → 切替不能
• 外部 API 単一依存 → 連鎖停止
• 手動運用前提 → 人的ミスによる障害
• ドキュメント上だけの BCP → 実際には機能せず

根本原因：

• 「壊れない」前提で設計している
• 人に依存した運用を前提にしている
• 説明可能性（検証可能性）を軽視している

4-9. まとめ：冗長化と BCP は“金融そのもの”

本章の結論：

• 冗長化と BCP はシステムの追加要素ではなく、“本体そのもの”
• マルチ AZ は最低条件、マルチリージョンで真の BCP を実現
• BCP はクラウドに“付いてくるもの”ではなく、設計しなければ成立しない
• 外部接続は最大のリスクであり、最優先で冗長化すべき
• すべては「どう止めないか」という金融リスク管理の思想から逆算される

冗長化と BCP は、金融システムが社会の信頼を背負って稼働し続けるための “必須構造” なのです。