# Toward a Cost Model for System Administration > [!abstract] 概要(abstract の日本語訳) > システム管理の核心は、コストを最小化しつつ価値を最大化する「ベストプラクティス」を活用することにあるが、システム管理の真のコストについてはほとんど知られていない。本論文では、システム管理のコストを決定する問題を定義する。予算が固定された支援組織にとって、支配的な変動コストはサービスを待つ時間によって失われる作業と価値である。我々は、white-box分析・black-box分析・離散事象シミュレーションを含む様々な手法を通じて、このコストの測定・分析方法を研究する。単純なコストモデルは、なぜある種の実務慣行が予想以上にコストがかかるのか、そしてある種の実務慣行から別の実務慣行への移行がなぜコストを伴うのかについての洞察を与える。 ## 論文情報 - タイトル: *Toward a Cost Model for System Administration* - 著者: [[Alva L. Couch]]・[[Ning Wu]]・[[Hengky Susanto]](いずれも[[wiki/entities/Tufts University|Tufts University]]) - 会議: 19th Large Installation System Administration Conference (LISA '05)、2005年12月、サンディエゴ。Proceedings pp. 125-141。 - URL(PDF): https://www.usenix.org/legacy/events/lisa05/tech/couch/couch.pdf - 会議ページ(HTML版): https://www.usenix.org/legacy/events/lisa05/tech/couch/couch_html/index.html - 原本: `.raw/papers/couch.pdf`(17ページ) ## 概要 システム管理者が採用する「ベストプラクティス」を、コストと価値の比という定量的な尺度で評価するための理論的基盤を提案する論文である。従来、システム管理の実務は「作業が楽になる」といった弱い正当化(著者らのいう「マイクロエコノミック」モデル)で語られてきたが、本論文はこれを待ち行列理論・ソフトウェア工学のコストモデル・離散事象シミュレーションを組み合わせた定量モデルへ置き換える第一歩を示す。著者のAlva Couchが前年のLISA 2004招待講演で提起した「構成管理導入の障壁は導入コストである」という主張を、初めて定量的に検証しようとする試みでもある。 ## 問題設定 システム管理の総コストを、実際の運用データやマネジメント判断から予測できるモデルが存在しない。多くの管理者・経営者は完全なコストモデルを不可能とみなしている。理由は (1) システム管理コストは多くのITプロジェクトで一括固定費として扱われ、要素分解が技術的に困難である、(2) 詳細なタイムシートのような記録メカニズムは、それが節約しうる金額より管理コストのほうが高くつく、(3) 監査要件で詳細な原価データを保持する組織でも、そのデータは機密であり組織外の研究者には利用できない、という3点にある。著者らは、前年のLISA 2004でAlva Couchが行った「構成管理(configuration management)自動化の普及を阻む本質的な障壁は『導入コスト(cost of adoption)』である」という主張(当時は定量的モデルなしの提起にとどまった)を出発点とし、これを定量化する最初の一歩として本論文を位置づける。 ## 提案手法 ### システム管理の待ち行列モデル システム管理を待ち行列システムとしてモデル化する(図1)。リクエストは複数の発生源(ユーザー、経営層、管理者自身のメモ)から到着し、キューに入れられ、いずれ処理・完了する。各クラスのリクエストは固有の到着率と、その逆数であるサービス率を持つ。典型的なヘルプデスクのチケットシステムより複雑なのは、内部リクエスト(チケット化されないセキュリティインシデント対応など)も同じキューに含める点、そしてシステム管理者どうしが独立に動く「積形式(product)システム」ではなく相互にコミュニケーションしながらスループットに影響し合う「非積形式(non-product)システム」である点である(図2)。 到着過程はポアソン分布(パスワードリセットなど独立母集団からの到着)、サービス時間は指数分布(明文化・スクリプト化された定型対応)に従うケースが多いと仮定し、到着率λ・サービス率µ・管理者数cを持つM/M/cモデルを主要な分析対象とする。M/M/cの平均待ち時間の式(式2、Erlangの待ち行列公式に基づく)から、管理者数cを増やしても応答時間問題が解消しない条件が導ける。 ### Tufts ECE/CS実データによる仮定の検証 Tufts大学ECE/CSの1年分(2004年7月〜2005年7月)のRequest Trackerチケットデータを分析した。データは分析対象になると事前に知られていなかったため、多くのサンプリングバイアスを免れているが、チケットのクローズタイミングが不正確(学生スタッフが問題解決後しばらく経ってからクローズする)という限界がある。分析の結果、次が判明した。 - リクエストは大多数(1か月未満で解決)が中央値約3.6日の短時間クラスと、解決時間が不定で長期化する少数の非定型クラスの2クラスに分かれる(図4)。 - 到着間隔はポアソン分布に従わない。標準偏差(約2.65時間)が平均(約1.94時間)の1.37倍あり、活動が停滞する期間の存在を示唆する。夏時間補正を施すと、到着率は24時間周期で正弦波的に変動し(図5)、9時〜17時に活発、昼休みにわずかな谷がある。クローズ数は15時にホットスポットを持つ別パターンを示す(図6)。これは学生管理者がその時刻から勤務を始めチケットをまとめてクローズすることに起因すると解釈される。 - 1か月以上滞留したリクエストを除外すると、残るリクエストの滞留時間分布は指数分布に近い形状を示す(図7のヒストグラム)。ただしこれはサービス時間+待ち時間の合算であり、正確なサービス率の算出には使えない。 - チケット到着率は時間とともに緩やかに増加しており、新規教員採用が一因と見られる。 ### コストのシンプルなモデル Patterson(LISA 2002)の「ダウンタイムのコスト」モデルを一般化し、コストを「運用コスト(cost of operations、給与・契約・設備投資などの相対的に一定なコスト)」と「待機コスト(cost of waiting、変更やダウンタイム解消を待つことによるコスト)」の和として定式化する。各リクエストrに対する瞬間コスト関数c_r(t)を、有形損失(作業・収益の逸失)crm(t)と無形損失(偶発事象由来)cri(t)の和として定義し(式6)、偶発事象がポアソン到着かつ統計的に独立であれば、待機コストは待機時間に比例するという結論(式11〜13、比例定数α_r)に到達する。この単純化には「偶発事象がポアソン到着」「偶発事象が統計的に独立」「偶発事象の影響が時間変化しない」という3つの強い仮定が伴う。 ### サービス率の推定: white-box分析とblack-box分析 待機コストを算出するにはサービス率µの推定が必要だが直接測定はできないため、ソフトウェア工学の複雑度推定手法を借用する。 - **white-box分析**: トラブルシューティングフローチャート(図8)を、分岐ノードのみを表現するフローグラフ(図9)に変換し、複数の入辺を持つノードを複製してフロー木(図10)にする。各枝に(その枝を選んだ場合の親ノードのサービス率、その枝が選ばれる確率)を付与し(図11)、子ノードのサービス率から親ノードのサービス率を再帰的に計算する(図12、式14)。分岐確率は条件付き確率P(B|A)ではなく「時間条件付き(temporo-conditional)」な事後確率であり、手順内の分岐順序を変えるとそれ以降のすべての分岐確率のサンプルが変化するという非ベイズ的な性質を指摘する。 - **black-box分析**: ソフトウェア工学のCOCOMOのfunction point手法を応用し、ネットワークサービスの依存関係・相互関係に重みを割り当てて「サービスポイント」を見積もり、管理スタッフの能力(能力ポイント)で割ることでサービス率を推定する(式15)。COCOMOと同様、重みは既知の成果を持つプロジェクト集合に対する回帰でサイト固有にチューニングする必要があり、そのための詳細データ収集自体が課題として残る。 ### M/M/cシミュレータによる実験 C++で実装したM/M/cキューシミュレータ(非積形式の振る舞いも表現可能)を用い、24時間365日稼働する同一サービス率のc人の管理者と、1・3・8・24時間平均のサービス時間を持つ4クラスのリクエストを想定した実験を行う。 - **収穫逓減**: 2・3・4人の管理者で同一条件をシミュレートすると、3人から4人への増員は待ち時間をほとんど改善しない(図13)。 - **飽和**: 1人の管理者を加えた条件(図14・図15)は変動が大きく「破滅の淵」にあるが、平均としては制御不能ではない。全リクエストの到着率を4倍にして真に飽和させると(図16・図17)、1〜2人の管理者ではキュー長が時間に比例して線形増加し、累積待ち時間は経過時間の2乗に比例して増大する。 - **瀬戸際戦略(brinksmanship)**: λ/cµが1に近い(ほぼ飽和した)系に100件のリクエストの「大量流入」が短時間に発生すると待ち時間が急増するが(図18)、同じ100件を長期間に分散して投入すると、単独の管理者を除き待ち時間の悪化を大幅に抑えられる(図19)。 ## 新規性 - システム管理のコストを、待ち行列理論・ソフトウェア工学の複雑度推定(COCOMO・white-box/black-box分析)・離散事象シミュレーションという3つの既存分野の道具立てを組み合わせて定量化しようとした、当時としては初めての体系的な試み。 - 実運用のチケットデータを用いて、システム管理リクエストの到着・サービス時間がポアソン分布・指数分布という古典的な待ち行列理論の仮定に厳密には従わない(24時間周期の正弦波的到着、定型/非定型の2クラス構造)ことを実証的に示した点。 - ソフトウェア工学のwhite-box/black-box複雑度推定手法を、トラブルシューティング手順のフロー木・COCOMOのfunction point法という具体的な形でシステム管理のサービス率推定に応用する枠組みを提示した点。 - シミュレーションにより、「自動化によるスケール」が管理コストを線形にではなく劇的に増大させうる(飽和近傍での小さな負荷増加が破局的な遅延を招く)ことを示し、大規模一括自動化展開より段階的展開が望ましいという具体的な実務指針を導出した点。 ## 実験設定 (1) Tufts大学ECE/CSの実チケットデータ(Request Tracker、2004年7月〜2005年7月の1年分、スパム除去済み)の統計分析。(2) C++で実装したM/M/cキューの離散事象シミュレータによる、2〜4人の管理者・4クラスのリクエスト(平均サービス時間1・3・8・24時間、到着率はサービス率の半分)を用いた複数シナリオ(通常負荷、単独管理者、到着率4倍の飽和状態、大量流入の集中/分散投入)の比較。 ## 実験結果 - Tuftsの実データでは、平均滞留時間約3.6日の短時間クラスと、滞留時間が不定で長い非定型クラスの2クラス構造が観測された(詳細は「提案手法」節参照)。 - 管理者を2人から4人に増やすと収穫逓減が働き、3人から4人への増員はほとんど待ち時間を改善しない。 - 到着率を4倍にして飽和させると、1〜2人の管理者では待ち時間が経過時間の2乗に比例して増大する。 - 飽和寸前の系に大量のリクエストを一度に投入するより、同じ量を長期間に分散して投入するほうが待ち時間の悪化を抑えられる(単独管理者を除く)。 ## 考察 著者らは本モデルが多くの単純化(偶発事象のポアソン性・統計的独立性・時間不変性など)に依存しており、現実のシステム管理の複雑さ(ピアメンタリング、ユーザーの学習・慣れ、障害の伝播、リクエストのバースト性)を捨象していることを明確に認めている。それでもなお、「大まかな推定でも無いよりはまし」というソフトウェア工学からの教訓を引き、実際のデータ収集と継続的なチューニングによって推定精度を高めていく方向性を提案する。また、コスト測定を実務そのものに統合するツール(作業時間を自動記録する「スマートトラブルシューティングガイド」)のアイデアを提示しつつ、プライバシーへの懸念(個人のパフォーマンス記録の悪用リスク)を明示的に論じている。最後に、自律コンピューティング(autonomic computing)がシステム管理者不要論の根拠として持ち出されがちな中、コストの正確な理解こそが人手中心の運用とマシン中心の自動化を公平に比較する基盤になると位置づけている。 ## 強み / 弱点・課題 - 強み: 待ち行列理論・ソフトウェア工学の複雑度推定・離散事象シミュレーションという異分野の道具立てを組み合わせ、システム管理コストという従来定性的にしか語られてこなかった問題に定量的な足がかりを与えた点。実データによる古典的仮定(ポアソン到着・指数サービス時間)の検証と反証を伴っており、単なる理論提案に終わっていない点。「飽和近傍での段階的展開が有利」という具体的で反直感的な実務指針を導出した点。 - 弱点・課題(著者ら自身が明記): モデルは偶発事象の独立性・時間不変性など多くの単純化に依存しており、ピアメンタリング・ユーザーの学習・障害の伝播といった主要な効果を組み込んでいない。実データは単一サイト(Tufts ECE/CS)のみであり、チケットクローズタイミングの不正確さという既知のバイアスを抱える。black-box分析(COCOMO応用)のチューニングには、現時点では入手困難な詳細な実測データが必要であり、実用化への障壁として残る。著者ら自身が「この論文はシミュレーションが実測に取って代わるものではないと明言し、始めた時より多くの問いを抱えて終わる」と結んでいる。