7.1高可用システムの実現方式

サービスが止まれば売上や信頼を直接失います。だからこそ「止まらない」だけでなく「止まっても素早く戻る」設計、すなわち高可用性（High Availability）の考え方が運用設計の中心に据えられます。数値目標を定め、弱点を洗い出し、冗長な構成でそれを埋めるという一連の流れを理解することが本節の目的です。

7.1.1故障パターンとSPoFの排除

• 故障パターンは大きく3種＝物理障害（ハードウェア故障・電源断・ネットワーク断）・論理障害（ソフトウェアバグ・設定ミス・過負荷）・メンテナンス停止（計画的な停止。パッチ適用や機器交換）。それぞれ対策の性質が異なる点に注意します。
• SPoF（Single Point of Failure・単一障害点）＝それが壊れるとシステム全体が止まる箇所。単一のロードバランサ、単一の電源、単一のネットワーク経路などが典型。高可用設計の第一歩は、構成図を描いてSPoFを1つずつ洗い出し、冗長化で消していく作業です。
• 回復性（resiliency）＝障害が起きてもサービスとして継続・自己回復できる性質。冗長化だけでなく、フェイルオーバーの自動化や切り戻し（フェイルバック）の設計も含みます。

7.1.2可用性の指標とクラスタ技術

• MTBF（Mean Time Between Failures・平均故障間隔）＝故障から次の故障までの平均時間（壊れにくさ）。MTTR（Mean Time To Repair・平均修復時間）＝故障発生から復旧までの平均時間（直りやすさ）。稼働率＝ MTBF / (MTBF + MTTR) で計算し、SLA（Service Level Agreement）でその数値目標を契約として明文化します。
• RPO（Recovery Point Objective）＝どこまでデータ損失を許容するか（例：RPO 1時間＝直前1時間分のデータ消失まで許容）。RTO（Recovery Time Objective）＝復旧までにかけてよい時間（例：RTO 4時間＝障害から4時間以内に復旧）。両者は軸が異なる（データ量 vs 時間）ため混同しないこと。
• 冗長化の実装手段＝クラスタを組み、複数ノードで1つのサービスを提供。Linux ではPacemaker（クラスタリソースマネージャ・フェイルオーバーの判断と実行を担当）とCorosync（クラスタメンバー間の死活監視・通信基盤）の組み合わせが定番。ほかにロードバランシング（複数ノードへの負荷分散）と地理的分散（拠点・リージョンをまたぐ冗長化。データセンター単位の障害にも耐える）を組み合わせます。

実務のシナリオで整理すると理解が定着します。あるECサイトが「RPO 15分・RTO 2時間」というSLAを顧客と合意したとします。RPO 15分を満たすには、15分より短い間隔でデータをレプリケーションまたはバックアップする必要があります（例：DBの準同期レプリケーションやWALの頻繁な転送）。RTO 2時間を満たすには、障害検知から系切り替え・サービス再開までの手順を2時間以内で完結させる自動化（監視→アラート→Pacemakerによる自動フェイルオーバー、または手順書に沿った手動切り替え）が要ります。ここで両者は独立した目標であり、RPOを短くしてもRTOが自動的に短くなるわけではない点に注意します（バックアップ頻度を上げても、復旧手順が手作業だらけならRTOは長いまま）。クラスタ構成では、Corosyncがノード間で常時ハートビートを交換して「誰が生きているか」を把握し、ノード喪失を検知するとPacemakerがあらかじめ定義されたフェイルオーバーポリシー（どのリソースをどのノードに移すか、フェンシングでどう旧ノードを隔離するか）を実行してサービスを継続します。単一ノードのクラスタや単一のネットワークスイッチに全ノードが繋がっている構成は、それ自体がSPoFになりうるため、電源・ネットワーク経路・そして可能であればデータセンター（地理的分散）まで多重化することで初めて「本当に単一障害点がない」構成に近づきます。

7.1.3この節のまとめ

• SPoFの排除＋稼働率=MTBF/(MTBF+MTTR)。RPO=データ損失許容／RTO=復旧時間許容（軸が違う・独立目標）
• 冗長化の実装＝クラスタ（Pacemaker=リソース管理／Corosync=死活監視）＋ロードバランシング＋地理的分散