4.3可用性と災害対策

前節では単一データセンター内の冗長化（直列/並列の稼働率計算）を扱いましたが、実務ではそれだけでは対応できない大規模災害（地震・火災・広域停電）によるデータセンター全体の喪失にも備える必要があります。ここで重要になるのが、「どれだけ早く復旧させるか」「どれだけのデータ損失まで許容するか」という2つの復旧目標を、業務の重要度に応じて定量的に定めることです。この節では、HAクラスタによる可用性向上、DR/BCPの考え方、そしてRTO/RPOという2つの指標を踏まえ、目標可用性と災害対策のレベルをコストと天秤にかけてどう設計するかを判断する力を養います。

4.3.1目標可用性からの構成判断

• システムアーキテクトは、業務要件から目標可用性（例：99.9%／99.99%／99.999%）を定め、それを満たす構成を前節の直列/並列計算で逆算する。可用性が1桁（9の数）増えるごとに許容ダウンタイムは約10分の1になる（99.9%＝年間約8.76時間、99.99%＝年間約52.6分、99.999%＝年間約5.3分）ため、目標を1桁上げるだけで実現コストが跳ね上がることをステークホルダーに説明できる必要がある。
• 目標可用性を過剰に高く設定すると、並列化する構成要素の数や、後述のDR環境の常時稼働などでコストが指数的に増える。したがって設計判断としては、業務が実際に要求する可用性を見極め、過剰品質（オーバースペック）を避けつつ、単一障害点だけは残さないという優先順位で構成を選ぶことが重要である。

4.3.2HAクラスタ

• HAクラスタ（High Availability Cluster）＝複数のサーバを1つのシステムのように連携させ、稼働系（アクティブ）が故障した際に待機系（スタンバイ）へ自動的に処理を引き継ぐフェイルオーバーの仕組み。Active-Standby（待機冗長）＝平常時は1台のみ処理し、もう1台は待機専用（切替に多少の時間を要するがシンプルでコストが低い）。Active-Active（多重系）＝複数台が同時に処理を分担し、1台故障時も残りが処理を継続（切替が速く処理能力も活かせるが構成が複雑）。
• フェイルオーバーの判断で重要なのは、切替に要する時間（フェイルオーバー時間）が業務の許容ダウンタイムに収まるかである。Active-Standbyはコストを抑えられる一方、待機系の起動や状態同期に時間がかかりダウンタイムが生じやすい。Active-Activeはこの切替時間をほぼゼロに近づけられるが、常時2台以上を稼働させるコストと、データ整合性を保つための同期機構の複雑さを伴う。

4.3.3DR/BCPとRTO/RPO

• DR（ディザスタリカバリ）＝地震・火災・広域停電などデータセンター単位の被災を想定し、地理的に離れた別拠点（遠隔地）でシステムを復旧させるための備え。BCP（事業継続計画）＝ITシステムに限らず、災害時に事業そのものを継続・早期復旧させるための全社的な計画（要員・拠点・業務プロセスを含む）で、DRはBCPを実現するIT面の一手段という位置づけになる。
• RTO（目標復旧時間、Recovery Time Objective）＝障害発生からシステムが復旧するまでに許容される時間の目標値（「止まっていてよい時間の上限」）。RPO（目標復旧時点、Recovery Point Objective）＝復旧時に許容できるデータ損失の範囲を、障害発生からどれだけ遡った時点のデータまでなら失ってよいかで示す目標値（「失ってよいデータ量の上限」）。RTOは時間軸（いつまでに戻すか）、RPOはデータ軸（どこまで戻すか）という別の軸であり、混同してはならない。

ある地方銀行の基幹システムのシステムアーキテクトが、本番データセンターが地震で完全に停止した場合の災害対策を設計しているとします。業務要件のヒアリングにより、経営層から「口座残高の更新データは1分以上失ってはならない（RPO ≤ 1分）」「システム停止は最大でも4時間以内に復旧させる（RTO ≤ 4時間）」という2つの目標が示されました。まずRPO ≤ 1分という要件から、バックアップを定期的に取得する方式（例えば日次バックアップ）では、被災直前の最大24時間分のデータが失われうるため要件を満たせないと判断できます。RPOを1分以内に抑えるには、遠隔地のDRサイトへほぼリアルタイムでデータを複製する同期／準同期レプリケーションが必須です。次にRTO ≤ 4時間という要件から、DRサイトを平常時は停止させておき被災後に一から環境を構築するコールドスタンバイでは、環境構築だけで4時間を超えかねないため不十分と判断できます。RTOを4時間以内に収めるには、DRサイトのシステムを常時起動させておき、切替のみで復旧できるウォームスタンバイ以上の構成が必要です。ここでの典型的な誤判断は、「バックアップを取得していればRPOもRTOも問題ない」という思い込みです——バックアップの取得頻度はRPOに、バックアップからの復旧（環境再構築）にかかる時間はRTOに、それぞれ別々に効いてくるため、両方の目標値を個別に満たす構成（レプリケーション方式とDRサイトの起動状態の両方）を選定する必要があります。また、DRサイトを常時稼働させるコストは高いため、業務の重要度がRTO/RPOほど厳しくない周辺システムでは、コールドスタンバイやより緩やかなバックアップ方式を選び、全システムに一律で最高水準のDR構成を適用しないというコスト最適化も、アーキテクトの重要な判断である。

4.3.4この節のまとめ

• 目標可用性は9が1つ増えるごとに許容ダウンタイムが約10分の1になり、実現コストが跳ね上がる——過剰品質を避けつつ単一障害点は残さない
• HAクラスタはActive-Standby（低コスト・切替に時間）とActive-Active（高コスト・即時切替）を業務の許容ダウンタイムで選ぶ
• RTO（時間軸・復旧までの時間）とRPO（データ軸・許容データ損失）は別の目標で、両方を満たすレプリケーション方式とDRサイトの起動状態を個別に選ぶ