止まらなさと速さを数える

機械はいつか壊れる。そこで、どれくらい持つのかと壊れたらどれくらいで戻るのかを、それぞれ平均で持っておく。

• MTBF（平均故障間隔）… 故障から次の故障までの、動いていた時間の平均
• MTTR（平均修復時間）… 故障してから直り終わるまでの、止まっていた時間の平均

名前が長くて紛らわしいので、真ん中の1文字で覚えよう。B は Between（間隔）で、動いている側。R は Repair（修復）で、止まっている側だよ。

この2つは足すと「1周期ぶんの全時間」になる。動いていた時間と止まっていた時間を足せば、経過した時間そのものだからね。

稼働率は、全体の時間のうち動いていた時間が占める割合だよ。英語では Availability（可用性）と呼ばれる。

分子は動いていた時間、つまり MTBF。分母は全体の時間、つまり MTBF + MTTR。それだけだよ。

例を1つ。MTBF が 80 時間、MTTR が 20 時間の装置なら、1周期は 100 時間で、そのうち 80 時間動いていた。だから稼働率は 80 ÷ 100 = 0.8 になる。

答えは 0 から 1 の間の数になる。0.8 は「8割の時間は動いている」という意味で、パーセントで聞かれたら 80% だよ。

式を見れば、上げ方は2通りしかないと分かる。分子の MTBF を長くするか、分母に効いている MTTR を短くするかだよ。

• MTBF を長くする … 壊れる前に部品を交換したり点検したりする。これが 予防保守
• MTTR を短くする … 遠くからつないですぐ調べられるようにする。これが 遠隔保守

ここで気をつけたいのは、MTTR を長くすると稼働率は下がるということ。「遠隔保守で MTTR が長くなり稼働率が上がる」という文は、向きが2か所とも逆で誤りだよ。

もう1つ。装置の種類が増えるほど MTBF は短くなる。壊れる箇所が増えるのだから、次の故障までの時間は縮む。ここも逆に書いた選択肢が出るよ。

装置を2つ組み合わせたとき、両方が動いていないと使えないつなぎ方を 直列 と呼ぶ。サーバとネットワーク機器のように、どちらか欠けたら仕事にならない関係だよ。

このときの稼働率は、掛け算になる。理由は素直で、「A が動いている」ことと「B が動いている」ことが同時に起きる確率を求めたいからだよ。それぞれの割合を掛けると、両方そろっている割合が出る。

稼働率 0.8 の装置と 0.9 の装置を直列にすると、0.8 × 0.9 = 0.72。元のどちらよりも低くなるのが直列の特徴だよ。1より小さい数を掛けているのだから、必ず減る。

つまり部品を増やすほど直列は弱くなる。ここが次の並列との一番の違いだよ。

どれか1つでも動いていれば仕事が続くつなぎ方が 並列 だよ。同じ役割の装置を2台置いておく、いわゆる二重化がこれにあたる。

式が少し複雑に見えるけれど、「止まる確率」から回り込むと分かりやすい。並列が止まるのは全部が同時に止まったときだけだからね。

A が止まっている割合は 1 - A、B が止まっている割合は 1 - B。両方同時に止まっている割合はその掛け算で (1-A) × (1-B)。求めたいのはその裏なので、1 から引けばいい。

0.9 と 0.8 の装置を並列にしてみよう。止まる確率は 0.1 × 0.2 = 0.02。だから稼働率は 1 - 0.02 = 0.98。元のどちらよりも高くなるのが並列だよ。

試験に出る形は、直列と並列が混ざっている。やり方はいつも同じで、内側のかたまりを1つの装置に潰してから、外側を計算するだよ。

例で見てみよう。東京と大阪が稼働率 0.9 の回線で直につながっている。ここに、名古屋を経由する迂回路を足す。東京〜名古屋も名古屋〜大阪も 0.9 だとするよ。

まず迂回路は、2本とも通らないと届かないので直列。0.9 × 0.9 = 0.81 の1本の回線と見なせる。

次に、直の回線 0.9 とこの 0.81 は、どちらか通れば届くので並列。止まる確率は 0.1 × 0.19 = 0.019 なので、稼働率は 1 - 0.019 = 0.981 だよ。

内側が直列か並列かを先に見分けるのがコツ。潰す順番を間違えると答えが合わないよ。

MTBF には、直感に反する性質がある。同じ装置をたくさん並べると、システム全体の MTBF は短くなるんだよ。

考えてみれば当たり前で、1台なら 100 時間に1回壊れるとしても、100 台あればどこかが壊れる頻度は 100 倍になる。だから全体の MTBF は「1台の MTBF ÷ 台数」になる。

例を1つ。MTBF が 21 万時間の装置を 100 台並べると、全体の MTBF は 210000 ÷ 100 = 2100 時間。つまり平均 2100 時間ごとにどこかが壊れる。

運転時間が週 140 時間なら、2100 ÷ 140 = 15 なので、平均15週に1回の故障だよ。「時間」で出したあと「週」に直す、という2段構えの計算だね。

故障の起きやすさは、一生ずっと同じではない。時間を横軸にとって故障率を描くと、両端が高くて真ん中が低い、風呂桶のような形になる。これを バスタブ曲線 と呼ぶよ。

• 初期故障期 … 動かし始めた直後。作りこみの不備や設定漏れが次々に見つかり、故障率が高い
• 偶発故障期 … 落ち着いた後。故障がまれにしか起きず、故障率がほぼ一定になる
• 摩耗故障期 … 長く使ったあと。部品の劣化で故障率がまた上がっていく

ここから1つ大事なことが言える。稼働率を測って製品どうしを比べるなら、真ん中の偶発故障期で測るべきだよ。始めたばかりの時期は不備の分だけ悪く出るし、末期は劣化の分だけ悪く出る。どちらもそのシステムの本来の実力ではないからね。

ここから話は「止まらなさ」から「速さ」に移る。速さと言っても、何を測っているかが違う3つの指標があるので、分けて持っておこう。

• スループット … 単位時間あたりに何件さばけたか。仕事の量を測る
• 応答時間（レスポンスタイム）… 頼んでから、答えが返り始めるまでの時間
• ターンアラウンドタイム … 頼んでから、答えが全部返り終わるまでの時間

応答時間とターンアラウンドタイムの違いは終わりの取り方だけだよ。印刷を頼んだとき、プリンタが動き出すまでが応答時間、紙が全部出てくるまでがターンアラウンドタイムだね。

応答時間は、中身を足し算に分解できる。端末側の処理、回線を流れる時間、サーバ側の処理の合計だよ。だからサーバの処理時間を知りたければ、応答時間から他の2つを引けばいい。

スループットを上げるには、機械を遊ばせないのが基本だよ。ジョブの合間にオペレータの操作が入って手が空くとその分だけ落ちるし、スプーリング（印刷データを一度ディスクに書いておき、遅いプリンタを待たずに次の仕事へ進む）のような工夫は効く。

ただし、詰めすぎると別の問題が出る。行列に並ぶときと同じで、窓口の混み具合が上がるほど、待ち時間は加速して伸びるんだ。これを扱う考え方が 待ち行列 だよ。

待ち時間の伸び方は、利用率が 5割のときを1倍とすると、8割で4倍、9割で9倍、95%で19倍。利用率が 1 に近づくと待ち時間は跳ね上がる。

だから CPU 使用率と平均応答時間のグラフは、直線ではなく右端で急に立ち上がる形になる。「まだ 9 割だから大丈夫」が通じない世界だよ。

最後に、性能を測る手段と備える手順を押さえよう。

測るほうが ベンチマークテスト だよ。使う目的に合わせて選んだ標準的なプログラムを実際に走らせ、処理性能を数値にして製品どうしを比べる方法だね。実際に動かすところが肝で、机上で命令数から見積もるのも、モデルを作って模擬実験するのも、ベンチマークではないよ。

備えるほうが キャパシティプランニング。将来の量に耐えられるよう、資源をどれだけ持つか計画することだよ。順番はいつも同じで、現状を測る → 将来の量を見積もる → 限界が来る時期を出す → 足すものを決める。

ここを逆から始めてはいけない。いまを測る前に増設を決めると、何をいくつ足せばいいのか根拠が無くなるからね。