> [!abstract] 概要(USENIX abstract の日本語訳) > オペレータのミスは、現代のインターネットサービスにおける可用性低下の重要な原因である。本論文では、まず人間のオペレータと現実的な三層構成のオークションサービスを用いた大規模な実験を通じて、これらのミスを特性化する。観測されたミスは、ソフトウェアの設定ミスから障害の誤診断、誤ったソフトウェア再起動まで多岐にわたる。次に、オペレータのアクションをシステムの他部分に対して可視化する前に検証することを提案する。オンラインシステムの拡張である検証環境を作成し、コンポーネントを実運用サービスに移行する前に実際のワークロードを用いて検証する方法を実演する。プロトタイプの検証システムが、観測したオペレータミスの66%を検知できることを示す。 ## 論文情報 - タイトル: Understanding and Dealing with Operator Mistakes in Internet Services - 著者・所属: Kiran Nagaraja、Fábio Oliveira、Ricardo Bianchini、Richard P. Martin、Thu D. Nguyen(いずれも Rutgers University, Department of Computer Science) - 媒体・発表年: OSDI '04(6th Symposium on Operating Systems Design and Implementation)、2004年12月、San Francisco, CA - PDF: `.raw/papers/naragaraja.pdf`(USENIX proceedings 版、16ページ) ## 概要 オペレータのミス(運用ミス)がインターネットサービスの可用性を損なう主要因であるという先行研究([[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]])の知見を受け、本論文は21人の被験者オペレータによる43回のライブ実験でミスの実態を詳細に特性化し、さらにオペレータのアクションを本番サービスへ反映する前に「検証(validation)」する仕組みを提案・実装・評価する。 ## 問題設定 入力は、三層構成(Web層・アプリケーション層・データベース層)の Ebay 型オークションサービスに対して、スケジュールされた保守タスクまたは障害診断・修復タスクを人間オペレータに実行させる、というものである(Table 1)。 | Task Category | Subcategory | |---|---| | Scheduled maintenance | Node addition | | | Data migration | | | Software upgrade | | Diagnose-and-repair | Software misconfiguration | | | Application crash/hang | | | Hardware fault | (Table 1. Categories of experiments.) 前提条件として、Apache(1.3.27)・Tomcat(4.1.18)・MySQL(4.12)の三層構成をLinux(kernel 2.4.18-14)上に構築し、クライアントエミュレータで200リクエスト/秒(最大スループットの約35%)の負荷を与える。必要なデータは、操作を行うオペレータへの口頭説明・システム構成のグラフィカルな表現・タスクごとの詳細な指示書と、オペレータの全コマンドとその結果をタイムスタンプ付きで記録するシェルベースの監視基盤である。 ## 提案手法 - **アーキテクチャ**: クラスタを「オンラインスライス(online slice)」と「検証スライス(validation slice)」の2つの論理スライスに分割する(Figure 3)。両スライス間には隔離バリアを設けつつ、コンポーネントのインターフェースを通過するリクエスト・レスポンスを複製する一方向ポータルである「シャント(shunt)」を導入する。シャントはリクエスト/レスポンスをログするか検証スライスへ転送する。検証スライス側には、マスクされたコンポーネント(validation対象コンポーネント)を取り囲む「プロキシ(proxy)」からなる検証ハーネスを構築し、現実的なワークロード下でマスクされたコンポーネントを検証できるようにする。 - **Figure 3: 検証を伴う三層オークションサービスのアーキテクチャ** ![[_attachments/naragaraja/fig03-validation-architecture.png]] (Figure 3. オンラインスライス側の Web サーバに付随する Shunt が、HTTP リクエスト/レスポンス(A)と JK リクエスト/レスポンス(B)を複製し、検証スライス側の Client proxy・Application Server proxy へ転送(または一度 Logged Requests & Replies に記録してから再生)する。転送・再生されたリクエストは検証対象の Web Server(masked component)に流れ込み、Client proxy・Application Server proxy が返信を live 側の複製結果と比較する。Production Database はオンラインスライス側にのみ存在する。Source: 論文 Figure 3.) - **アルゴリズム/手法の詳細**: 検証戦略は2種類ある。**トレースベース検証(trace-based validation)**は、シャントで記録した実リクエスト・応答のトレースを周期的に収集し、後で再生してマスクされたコンポーネントの応答を比較する。**レプリカベース検証(replica-based validation)**は、マスクされたコンポーネントを稼働中の対応コンポーネントの「ミラー」として位置づけ、稼働コンポーネントへのすべてのリクエストを複製してマスクされたコンポーネントにもリアルタイムで送信し、両者の応答を比較する。比較には**比較関数(comparator function)**を用い、スループットベース(平均スループットが期待値の閾値内か)、フローベース(想定される接続間でリクエスト/応答が実際に流れているか)、データマッチング(リクエスト/応答の実際の内容を突き合わせる)の3種類を実装した。マスクされたコンポーネントが全比較を一定期間通過すると「検証済み」と判定され、オペレータが移行関数(migration function)を呼び出して本番サービスへ統合する。 - 状態管理: マスクされたコンポーネントの初期化はトレースベースでは記録済み状態から、レプリカベースでは対応する稼働コンポーネントの状態コピーから行う。ソフト状態のみを持つコンポーネントは再起動によりオンラインスライスへ移行できるが、ハード状態を持つコンポーネント(データベース等)はアプリケーション自身が新規コンポーネントの統合方法を知っているか、オペレータが適切な状態を持たせて再起動する必要がある。 - **マルチコンポーネント検証**: 新規コンポーネント追加が既存の稼働コンポーネントの設定変更を要する場合(例: アプリケーションサーバ追加に伴う Web サーバの設定変更)、新規コンポーネントを検証スライスに導入して単体検証した後、設定変更が必要な既存コンポーネントを1つずつ検証スライスへ持ち込みペアで相互運用性を検証する。同時に検証スライスにあるコンポーネントは最大2つ(k=1)で十分とされ、一般にはk個まで拡張可能とされる。 - **実装上の工夫**: スライス間の隔離と透過的な移行は、[[Mendosus]](SAN ベースの障害注入・ネットワークエミュレーションツール、参考文献[15])を用いた仮想ネットワークにより、ノード粒度で実現している。Mendosus に2スライスを分割するネットワークパーティションを指示することで隔離を実現し、シャントは特権ノードを経由してこのバリアをトンネルする。オークションサービス向けにクライアント・Webサーバ・アプリケーションサーバ・データベースの4種類のプロキシを実装し、各プロキシはメンバーシッププロトコル・サービスインターフェース・共通メッセージングコアの3モジュールから構成される。改変量は Rice大学の[[DynaServer]]クライアントエミュレータ・Apache・Tomcatへそれぞれ232・307・274 NCSL(非コメントソース行)、MySQLプロキシは新規384 NCSLと、比較的小さな実装コストで済んだと報告している。非決定性(特にリクエストのルーティング非決定性)への対処もプロキシ側で行っている。 ## 新規性 先行研究(参考文献[19]、すなわち[[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]])はオペレータミスを大まかに分類し例をいくつか示すにとどまっていたのに対し、本論文は観測した全42件のミスを詳細に記述・分析し、さらにそれらを検知するプロトタイプ基盤を設計・実装した点で拡張している。[[Undo for Operators]](Brown & Patterson、参考文献[6])が提案する状態ロールバックによる「undo」とは直交的アプローチであり、undoが操作後の状態修復に焦点を当てるのに対し、本手法はオペレータのアクションを検証環境で妥当性確認するまでライブサービスから隠すことに焦点を当てる。offline testing(参考文献[3])との違いは、検証環境がライブサービスの「レプリカ」ではなく「拡張」である点にあり、これによりコンポーネントを本番へ移行する際の設定変更に起因するミス(offline testingでは検出できないもの)も捕捉できる。 ## 実験設定 - 実験環境: 三層オークションサービス(EBay 風)。第一層(Web)2台(Apache 1.3.27、1.2GHz Intel Celeron、512MB RAM)、第二層(アプリケーション)5台(Tomcat 4.1.18、同スペック)、第三層(データベース)1台(MySQL 4.12、1.9GHz Pentium IV、1GB RAM)。全機Linux kernel 2.4.18-14。 - データセット/被験者: 21人のボランティアオペレータ(大学院生14名、運用スタッフ2名、プロのプログラマ5名)。スキル別に novice(11名)・intermediate(5名)・expert(5名)に分類。合計43回の実験を実施。 - 比較対象: オフラインテスト(offline testing)、undo(Brown & Patterson の手法)との定性比較。検証アプローチ自体の効果測定にはmicrobenchmark・live-operator実験・operator-emulation実験(過去のオペレータ操作トレースをシェルスクリプトで再生)・mistake-injection実験の4種類を用いた。 - 評価指標: ミスの検知率(検証によって捕捉されたミス数 / 観測された総ミス数)、CPUオーバーヘッド(%CPU利用率)、ディスク/ネットワーク帯域、バッファリング遅延。 ## 実験結果 - **オペレータミスの特性化**: 43回の実験で42件のミスを観測。設定ミス(configuration mistake)が最頻(24件)、誤ったソフトウェア再起動が14件で続く。19件が即座にサービスのスループット低下を招いた。 - **Figure 1: オペレータミスとその影響** ![[_attachments/naragaraja/fig01-mistakes-impact.png]] (Figure 1. X軸はミスの影響(スループット低下・サービス到達不能・MTTR増加・不完全なコンポーネント統合・セキュリティ脆弱性・Webサーバ到達不能の可能性・システム容量低下・潜在的データベースクラッシュ)、Y軸は積み上げ棒で示したミスカテゴリごとの発生件数。グローバル誤設定(16件)とローカル誤設定(8件)の合計24件が「スループット低下」に最も強く寄与している。Source: 論文 Figure 1。) - **Figure 2: オペレータカテゴリ別のミス内訳** ![[_attachments/naragaraja/fig02-mistakes-by-category.png]] (Figure 2. 各オペレータカテゴリ(Expert/Intermediate/Novice)が参加した実験数で正規化したミス発生率。エキスパートも「local misconfig」「start of wrong SW version」で無視できない割合のミスを犯しており、これは最難関の実験の多くをエキスパートが担当したためと説明されている。global misconfigはNoviceの寄与が最大。Source: 論文 Figure 2。) - **検証システムの検知率(定量評価)**: Live-operator実験(8回、9件のミス観測)では6件を検証で捕捉。Operator-emulation実験では、観測42件中40件を再現可能なスクリプト化に成功し(2件は基盤の制約で非再現)、うち26件を単一コンポーネント検証(trace-based/replica-based)が捕捉、multi-componentが検証で latent error 4件を追加捕捉、非再現の2件も同種のミスとして捕捉可能と推定し、**合計28/42件(66%)**を検知可能と結論づけた(Table 2)。 | Technique | Immediate impact (29 total) | Latent (11 total) | |---|---|---| | Trace-based | 22 | 0 | | Replica-based | 22 | 0 | | Multi-component | 22 | 4 | (Table 2. Coverage results of the emulation experiments. 40件の再現可能なミスに対する内訳。) - **オフラインテストとの比較**: offline testingでは42件中17件(40%)しか捕捉できないと推定され、検証アプローチ(66%)が明確に上回った。 - **CPUオーバーヘッド(定量評価)**: - **Figure 4: 検証操作によるプロセッサオーバーヘッド** ![[_attachments/naragaraja/fig04-cpu-overhead.png]] (Figure 4. Web サーバに対する各種検証手法の %CPU 利用率(縦軸)対オファードロード[requests/sec](横軸)。base(無改変)に対し、完全ロギング(trace-val)・完全転送(replica-val)は追加でそれぞれ24〜32%・29〜39%のCPU利用率増加を招く。応答の先頭64バイトのみを扱う要約(summary)方式では18〜25%・20〜27%、50%セッションサンプリング(sample)方式では15〜21%・18〜25%、HTTPリクエスト/応答のみに絞るデータフロー(data-flow)方式では13〜19%・16〜22%まで低減する。Source: 論文 Figure 4。) - ディスク/ネットワーク帯域は最悪ケースで約4MB/s(完全ロギング時)、セッション間引きサンプリングで約2.5MB/s、最終結果のみのサンプリングで約1.5MB/sまで低減。 - **バッファリングオーバーヘッド**: レプリカベース検証が最長のバッファリング遅延を要するが、1秒未満(高負荷レプリカサーバで150リクエスト未満のバッファ容量)。セッション状態を64KBまで人工的に肥大化させても応答時間は5秒未満に収まった。 - **ミス注入実験(定性評価)**: Mendosusを拡張してパーミッションエラー・ファイル欠損・ファイル破損エラーを注入。PRESSサーバではパーミッション/欠損エラーは検証で確実に検知されたが、一部のファイル破損は比較関数の閾値(HTTPページの一部バイト差異を許容するしきい値)のため検知漏れが生じ、比較関数設計における偽陽性率とミス露出のトレードオフの重要性が指摘された。 ## 考察 - 42件中28件(66%)を検証アプローチが検知できた一方、残る14件(不要なソフトウェア再起動6件+不要なハードウェア交換等)は検証の対象外だった。これらは「オペレータの意図した変更」と「ミス」の区別が原理的に難しい、検証の限界事例である。 - 検証環境が稼働中システムの「拡張」であることが本手法の中核的優位性である——offline testingのように完全な複製を用意する必要がなく、かつ本番移行時の設定変更に起因するミスも同一の設定のまま検証できる。 - 検証とundoは直交的技術であり組み合わせ可能(検証がundoにミス露出を防がせ、undoが検証環境内での修復を助ける)と論じている。 - 著者らは検証の妥当性検証期間の動的決定、比較関数の統計的サンプリングの拡張などをオープンな課題として挙げている。 ## 強み / 弱点・課題 - **Strengths**: (1) 実オペレータによるライブ実験で得た詳細なミスの実態データを提供し、業界慣行上非公開になりがちな運用ミスの実データを公開した([[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]が指摘した「業界横断の障害データが非公開」という課題への部分的回答)。(2) offline testingを明確に上回る66%の検知率を実証した。(3) CPUオーバーヘッドをサンプリング・要約により13-22%まで抑制できることを示した。 - **Weaknesses/Limitations**: (1) 43実験・21人という規模はオペレータ行動の完全な統計的特性化を意図しておらず、著者ら自身も限定的なカバレッジであると認めている。(2) 不要な再起動や不要なハードウェア交換など、「意図された操作の結果として見た目上正しく振る舞うが実質的に誤り」のミスは検証原理上検出しづらい。(3) 比較関数はアプリケーション固有の実装が必要であり、汎用化には限界がある(スループットベースの汎用比較関数を除く)。(4) ノード粒度の隔離(Mendosusによる仮想ネットワーク)を前提としており、より細粒度なコンポーネント単位の隔離への一般化は今後の課題として残されている。