PR

定量化できる可用性の指標

 では,可用性とはそもそも何なのか。 「可用性」という言葉は,『広辞苑』などの日本語辞書には載っていない,コンピュータ業界用語である。冒頭では,可用性を「サービスを継続して提供する能力」と定義したが,厳密には可用性には二つある。「継続的可用性(CA:Continuous Availability)」と「高可用性(HA:High Availability)」である。

可用性を示す二つの算出式

 可用性の一つである継続的可用性とは,計画的であるか否かに関係なく,サービスが停止しない性質を示している。通常運転か縮退運転かは問わず,とにかくサービスが止まらないことを意味するわけだ。継続的可用性は,「無停止時間」と呼ばれる指標で表現する。無停止時間とは,システムが停止しなかった時間のことである。

 もっとも,長期間にわたり安定していたシステムが,急に計画外停止を繰り返すケースもある。そこで,継続的可用性を表現するのに「平均故障間隔(MTBF)」という指標を用いることも多い。平均故障間隔は停止するまでの平均時間で,計算上は「総稼働時間/総停止回数」で求められる。平均故障間隔が長いほど,サービスは安定して提供できていることになる。

 これに対して高可用性とは,サービスが停止することもあるが,稼働(通常運転と縮退運転を含む)している時間的な割合が高いという性質を示している。高可用性を表す指標として有名なのが,「稼働率」である。稼働率とは,カットオーバー後の経過時間に対して総稼働時間が占める割合を指す。計算上は,「平均故障間隔/(平均故障間隔+平均修理時間)×100」で求められる。平均修理時間(MTTR)とは,障害発生から復旧までにかかった平均時間のことで,「総停止時間/総停止回数」で算出される。

部品の故障しやすさが稼働率を左右する

 稼働率を高めるには,平均故障間隔を長く,平均修理時間を短くする必要がある。

 平均故障間隔を長くするには,故障しにくい構成要素でシステムを構築することが必要だ。例えばハードディスクの場合,インタフェース仕様としては「EIDE」と「SCSI」が有名だ。一般的に,「SCSIディスクの方が高回転で伝送速度も速いので,サーバー向き」などと説明される。実際のところベンダーが示すSCSIディスクとEIDEディスクの平均故障間隔は2倍もの開きがあり,SCSIの方が圧倒的に長い。そのため高信頼を求められるサーバー用途では,SCSIディスクが多用されている。

 このように,故障しにくい構成要素だけでシステムを構築できれば望ましいが,このアプローチだけで平均故障間隔を長くするには限界がある。駆動部品を含むハードディスクやファンの平均故障間隔を,駆動部品を含まないCPUやメモリーの平均故障間隔と同レベルに引き上げることは,現実的に不可能だ。

 そこで,平均故障間隔が相対的に短い構成要素については,単一故障個所とならないような設計上の工夫が必要になる。単一故障個所とは,万一,そこが故障すると,全体の動作に悪影響が及んでしまう個所のことである。例えばEIDEディスクを使用する場合は,同じハードディスクを複数台装着してデータを同期させるという「冗長化」のアプローチによって,単一故障個所になることを防ぐことができる( 第5回 可用性の向上・システムの信頼度を計算 参照)。単一故障個所を減らすことで平均故障間隔は長くなり,稼働率を高められる。

 一方,平均修理時間を短くするには,計画外停止をいかに素早く検知するかが大きなテーマとなる。実際に計画外停止が発生し,利用者のクレームが寄せられてから対処するのでは遅すぎる。障害などを検知する監視体制を,運用設計段階で練り上げておく必要がある。この点についての詳細は,運用についての回で説明する。

 平均修理時間を短くする具体策は,例えばバックアップ・データを確保しておく,アプリケーションにエラー・ログの取得機能を搭載しておく,待機系のバックアップ環境を用意しておく――などである。

可用性にかける妥当な費用 

 システムの利用者や担当者は,可用性について意識しているかどうかはともかく,様々な言葉で可用性に関連する希望を伝えてくる(表1)。例えば,「年間を通じてサービス停止は5回以内にしたい」「障害時の回復時間は10分以内にしたい」という具合だ。こうした希望は,漏れなく設計者が聞き取り,目標となる指標値の見積もりに生かすことが望ましい。

表1●提示された要件から求められる可用性を検討する
[画像のクリックで拡大表示]
表1●提示された要件から求められる可用性を検討する

 場合によっては,予算規模を勘案し,可用性の要件のレベルを引き下げなければならないこともある。その際にも,指標値を使って定量的に意見交換すれば,交渉はスムーズにまとまりやすい。例えば,次のような交渉が可能になる。


利用部門の担当者(ユーザー):「ビジネスの根幹にかかわるシステムなので,サービス停止などあり得ない」

設計者:「サービス停止に見えないシステムを設計することも不可能ではありませんが,費用はかなり高くなります。サービス停止で発生する損失額を明確にしてから,どこまで停止を許容できるか考えた方がよいのではないでしょうか?」

ユーザー:「そうかね? このビジネスが止まると1時間当たり約200万円の機会損失が見込まれる」

設計者:「1分当たりで見ると3.3万円ですね。つまり,復旧時間を10分程度にすれば,約33万円の損失ということになりますね」

ユーザー:「理論上はそうだな」

設計者:「年間にどのくらい停止するかを考えましょう。例えば,年に5回程度であれば,約165万円の損失と考えられます。このくらいの損失は加味していただいた方が,コスト・パフォーマンスの良いシステムを設計できると思いますが,いかがでしょうか?」

ユーザー:「165万円くらいなら許容範囲だな……。そうしてもらおうか」

 一般的に,具体的な損失額まで踏み込んで要件を聞き取り,可用性を検討している設計者はまれかもしれない。だが,こと可用性については,停止したときの損失を具体的に考慮に入れて,コスト・パフォーマンスの高い設計を検討すべきだと筆者は考える。

 可用性を高めるためにかける費用は,サービス停止によって発生するビジネス上の損失を上回るべきではない。その意味で,可用性の設計では特に,理論や理想を追うのではなく,現実を冷静に見据えて実装技術を選定することが求められる。

 
■変更履歴
当初掲載していた図1に誤解を与えかねない箇所があったため、非掲載としました。 [2017/01/24 18:00]
高安 厚思(たかやす あつし) オープンストリーム テクニカルコンピテンシーユニット 主管システムズアーキテクト
銀行系シンクタンクでオブジェクト指向技術の研究に携わった後,大手SI業者でアーキテクチャ構築やプロセス研究を担当。現職ではSOA(Service Oriented Architecture)を中心とする研究開発とアーキテクチャ構築に従事している