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（クラスタメンバー間の死活監視・通信基盤）の組み合わせが定番。ほかにロードバランシング（複数ノードへの負荷分散）と地理的分散（拠点・リージョンをまたぐ冗長化。データセンター単位の障害にも耐える）を組み合わせます。