変更要約: 初版
4.2可用性管理（稼働率・冗長・単一障害点）
サービスがどれだけ使える状態にあるかを表す稼働率をMTBF÷(MTBF+MTTR)で求め、故障間隔（信頼性＝MTBF）と修復時間（保守性＝MTTR）の別を理解し、直列構成は稼働率の積、並列冗長は1−(1−a)ⁿで全体可用性を見積もり、単一障害点（SPOF）を冗長化で解消する判断力を養います。
サービスマネージャが可用性を上げたいとき、闇雲に高価な機器を並べても効果は出ません。可用性は「壊れにくさ（信頼性）」と「直りやすさ（保守性）」の2つの要素で決まり、システム全体の可用性は各構成要素のつなぎ方（直列か並列冗長か）で大きく変わります。この節では、稼働率をMTBF÷(MTBF+MTTR)で数値化し、その値を手掛かりにどこが弱点（単一障害点）で、冗長化・修復時間短縮のどちらが効くかを診断・設計する判断軸を養います。計算は「値そのもの」より「その値から何を改善すべきか」を核にします。
4.2.1稼働率・MTBF（信頼性）・MTTR（保守性）
- MTBF（平均故障間隔）＝故障から次の故障までの平均稼働時間で、信頼性（壊れにくさ）を表す。MTTR（平均修復時間）＝故障してから修復完了までの平均時間で、保守性（直りやすさ）を表す。稼働率（可用性）＝MTBF÷(MTBF＋MTTR)——全時間のうちサービスが正常に使えた時間の割合を意味する。
- 可用性を上げる方策は2方向ある。MTBFを延ばす（高信頼な部品採用・予防保守・負荷低減で故障そのものを減らす）か、MTTRを縮める（監視・自動復旧・予備品・保守要員の即応で直りを速くする）か。例えばMTBF=990時間・MTTR=10時間なら稼働率は
990÷(990+10)=990÷1000=0.99（99%）。ここでMTTRを10→5時間に半減すると990÷995≒0.995となり、故障頻度を変えずとも修復の速さだけで可用性が改善する——どちらを改善するのが費用対効果が高いかを状況で判断する。
4.2.2直列構成と並列冗長の全体可用性
- 直列構成＝どれか1つでも故障すると全体が停止する構成（構成要素が全て正常でないとサービスが成立しない）。全体可用性は各要素の稼働率の積：
a1 × a2 × …。例えば稼働率0.99の要素を2つ直列につなぐと0.99 × 0.99 = 0.9801（約98.01%）——要素を直列に増やすほど全体可用性は下がる。ここで最も稼働率の低い要素が全体の足を引っ張る単一障害点になりやすい。 - 並列冗長＝同じ機能の要素を複数用意し、どれか1つでも生きていればサービスが継続する構成。全体可用性は
1−(1−a)ⁿ（a＝各要素の稼働率、n＝並列数）で、全要素が同時に故障する確率を1から引く形。例えば稼働率0.9の要素を2つ並列にすると1−(1−0.9)² = 1−0.1² = 1−0.01 = 0.99（99%）。稼働率0.99の要素なら2並列で1−0.01² = 1−0.0001 = 0.9999（99.99%）——冗長化は全体可用性を大きく引き上げるが、機器・保守が二重になりコストが増す。
「稼働率＝MTBF÷(MTBF+MTTR)」「MTBF＝信頼性・MTTR＝保守性」「直列＝各稼働率の積（増やすほど下がる）」「並列冗長＝1−(1−a)ⁿ（増やすほど上がる）」が最頻出です。直列と並列で式が真逆になる点、および単一障害点は直列上の最弱要素で冗長化により解消する点を確実に。稼働率の値は「その値から冗長化すべきか修復を速めるべきか」の判断材料として問われます。
4.2.3単一障害点（SPOF）の診断と解消
- 単一障害点（SPOF：Single Point Of Failure）＝その1点が故障するとシステム全体が停止してしまう箇所。サーバを2台に冗長化しても、両者が単一の電源・単一のネットワークスイッチ・単一のロードバランサを共有していれば、その共有部分がSPOFとして残る。冗長化は「見かけ上二重にする」ことではなく、故障が全体停止に波及する経路を1本残らず二重化することで初めて意味を持つ。
- SPOFの解消は「全部を冗長化する」のではなく、事業影響の大きい経路から優先して行うのが費用対効果の観点で重要。可用性計算（直列の積で全体を見積もる）でどの要素が全体可用性を最も引き下げているかを特定し、そこを並列冗長化すれば投資効果が高い。逆に全体可用性への寄与が小さい要素を過剰冗長化してもコストばかりかさむ。
あるECサイトのサービスマネージャが、SLAで定めた稼働率99.9%（年間ダウンタイム約8.76時間）を安定して満たせず、月に数回の短時間停止が続いている状況を診断しているとします。構成を直列で分解すると、Webサーバ（稼働率0.999）・アプリサーバ（0.999）・データベース（0.995）・共有ストレージ（0.99）が直列につながっており、全体可用性は0.999 × 0.999 × 0.995 × 0.99と各稼働率の積で見積もられます。この積を概算すると約0.983まで下がり、最も低い共有ストレージ（0.99）とデータベース（0.995）が全体の足を引っ張っている——つまりこれらが単一障害点だと分かります。ここで「全サーバを一律に2台へ増やす」と判断するのは効率が悪い誤りです。Webサーバやアプリサーバ（すでに0.999）を冗長化しても全体可用性の改善幅は小さく、投資が無駄になります。正しい判断は、最も稼働率の低い共有ストレージを並列冗長化することです。稼働率0.99のストレージを2台の並列冗長にすれば、その部分の可用性は1−(1−0.99)² = 1−0.0001 = 0.9999まで跳ね上がり、全体可用性のボトルネックが解消されます。あわせて、故障頻度（MTBF）を下げられないならMTTRを縮める——監視強化と自動フェイルオーバで検知から切替までを短縮する——手も併用できます。ここでのひっかけは「サーバを2台に冗長化したのに可用性が上がらない」という状況で、実は2台が単一の電源・単一のストレージを共有しており、共有部分がSPOFとして残っていたというものです。サービスマネージャは、可用性の数値をボトルネック特定の道具として使い、事業影響の大きい最弱経路から優先して冗長化する判断を行います。
| 構成 | 全体可用性の式 | 傾向 |
|---|---|---|
| 直列（全要素が必要） | a1 × a2 × … （各稼働率の積） | 要素を増やすほど全体は下がる |
| 並列冗長（1つ生きれば継続） | 1 − (1 − a)ⁿ | 要素を増やすほど全体は上がる |
ひっかけ： 「直列構成の全体可用性は各稼働率の平均（または和）で求める」は誤りです——直列は積（a1×a2×…）で、要素を増やすほど下がります。また「サーバを2台に冗長化すれば必ず可用性は上がる」も誤り＝両者が単一の電源・スイッチ・ストレージを共有していればそこがSPOFとして残り、可用性は上がりません。冗長化は障害波及経路を1本残らず二重化して初めて効きます。
4.2.4この節のまとめ
- 稼働率＝MTBF÷(MTBF+MTTR)、MTBFは信頼性（壊れにくさ）・MTTRは保守性（直りやすさ）を表す
- 直列の全体可用性は稼働率の積（増やすほど下がる）、並列冗長は1−(1−a)ⁿ（増やすほど上がる）
- 単一障害点は直列上の最弱要素・共有部分に残る——事業影響の大きい経路から優先して冗長化する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. あるサーバの平均故障間隔（MTBF）が990時間、平均修復時間（MTTR）が10時間である。このサーバの稼働率と、可用性を高める打ち手の理解として最も適切なものはどれか。
Q2. 稼働率0.99の同一機能サーバを2台、どちらか1台でも稼働していればサービスが継続する並列冗長構成にした。この構成全体の可用性として最も適切なものはどれか。
Q3. Webサーバ・アプリサーバ・DB・共有ストレージが直列に連なるシステムで、SLAの稼働率目標を安定して満たせない。各要素の稼働率はWeb0.999・アプリ0.999・DB0.995・共有ストレージ0.99であった。全体可用性を最も費用対効果よく引き上げる打ち手はどれか。