# Magpie: Online Modelling and Performance-aware Systems ## 論文情報 | 項目 | 内容 | |------|------| | 著者 | [[Paul Barham]]・[[Rebecca Isaacs]]・[[Richard Mortier]]・Dushyanth Narayanan | | 所属 | [[Microsoft Research]] Cambridge, UK | | 発表会議 | HotOS IX: The 9th Workshop on Hot Topics in Operating Systems | | 開催地 | Lihue, Hawaii, USA | | 開催日 | 2003-05-18 〜 21 | | ページ数 | 7 ページ | ## 概要(アブストラクト和訳) 分散システムの性能を理解するには、多数のコンポーネント間における数千もの相互作用を相関付ける必要があり、これはコンピュータに任せるのが最善である。現在のシステムは各コンポーネントから大量のトレースを出力するが、そのデータを簡潔なシステム性能モデルへと統合しない。 本論文では、オンラインの性能モデリングをユビキタスなオペレーティングシステムサービスとして提供すべきであると主張し、性能デバッグ・容量計画・システムチューニング・異常検知を含む複数の活用シナリオを概説する。複数マシンにまたがる詳細なトレースを収集し、リクエスト単位の監査証跡を抽出し、リクエスト挙動の確率的モデルを構築する Magpie モデリングサービスを説明する。フィージビリティスタディはオフラインのデモンストレータを用いてアプローチを評価する。結果はアプローチが有望であることを示す一方、真にユビキタスなオンラインモデリング基盤の構築には多くの課題があることも示している。 ## 問題設定 分散インフラへの依存が深まる現代において、エンドユーザーが性能低下を経験したとき、原因特定は極めて困難である。問題はしばしば間欠的であったり、ごく一部のユーザーやトランザクションにのみ影響したりする(「自分の環境では動く」症候群)。 集約統計ではこのような問題の診断に不十分で、正確な診断には各リクエストの詳細な監査証跡と、正常なリクエスト挙動のモデルが必要である。個々のリクエストの観測挙動をモデルと比較することで、異常なリクエストと誤動作しているシステムコンポーネントを特定できる。 ## 提案手法: Magpie Magpie は二つの設計原則に基づく: 1. **ブラックボックス計装(Black-box instrumentation)**: 計測対象システムのソースコード改変を不要とする 2. **エンドツーエンドトレーシング(End-to-end tracing)**: 集約統計だけでなく、各リクエストのシステム通過経路を個別に追跡する ### アーキテクチャ 各マシンでイベントトレーシングを行い、モデルを構築、クエリエンジンを通じて性能クエリに応答するアーキテクチャを採用する(図1)。Windows 環境では Event Tracing for Windows(ETW)・.Net Profiling API・Detours などを活用する。 計装点はコンテキストスイッチ・I/O 操作・選択された手続きへの入出口などのイベントを生成し、ローカルサイクルカウンタでタイムスタンプを付与する。マシン間でリクエストの制御フローを縫合するには、ログに記録されたネットワーク送受信イベントを利用する。 ### オーバーヘッドの評価 テストサイトで全システムアクティビティをトレースしたストレス実験では 150k イベント/分(10 MB/分)のログを生成した。マイクロベンチマークではスループットが 18% 低下したが、これは ASCII ロギングの非効率によるものであり削減可能である。 ### 行動クラスタリング(Behavioural clustering) Magpie は URL ではなく、実際の観測挙動でリクエストを分類する。各リクエストのイベント列を直列化したイベント文字列を構築し、**Levenshtein 文字列編集距離**とリソース消費ベクトル間の正規化ユークリッド距離を合わせたメトリクスでクラスタリングを行う。 最適化されていない C 実装で 5 分間のトレースデータ(1,800 リクエスト)から 8 クラスタを 2GHz Pentium 4 で 2 秒未満で抽出した。URL ベース手法と比べ、代表リクエストと実際のトランザクション間のリソース消費の RMS 誤差が全リソース種別にわたって改善された(図5)。 図: Request audit trail (Figure 4) — クライアント・Webサーバ・SQLサーバにわたるリクエストの自動生成タイムライン ![[wiki/sources/_attachments/barham/image-005-001.png]] ### 確率的文脈自由文法(SCFG)によるモデリング ALERGIA アルゴリズムを用いて、リクエストイベント文字列の集合から確率的文脈自由文法(SCFG)を導出する。SCFG はリクエスト生成の基盤プロセスを確率的状態機械として表現し、上位レベルの制御フローやアプリケーションコードの内部構造(階層・ループ)を推論するための有用な手掛かりを与える。 テスト用文法(Reber 文法)では 400 サンプル文字列で正しい状態機械に収束し、2.5GHz マシンで約 30 ミリ秒を要した。前述の 5 分間データセット(1,800 イベント文字列)では収束に約 1 分を要すると推定される。 ### 並行性のモデリング(課題) クラスタリングと SCFG は決定論的な直列化を用いるため、リクエスト内の並行性をモデル化できない。複雑なシステムでは、クラスタリング距離メトリクスの拡張と、SCFG を結合隠れマルコフモデル(coupled HMM)に置換することが必要になる。 ## 応用シナリオ - **性能デバッグ**: SQLServer の設定ミスのような間欠的バグを、異常リクエストのクラスタから特定 - **容量計画**: ライブシステムトレースから自動的にワークロードモデルを生成(Indy 予測ツールキット向け) - **ワークロード変化の追跡**: サービスへの定性的変化(新機能追加等)と通常変動を区別 - **コンポーネント障害検知**: 各コンポーネントを通じたリクエスト追跡によって疑わしいコンポーネントを特定 - **ベイジアンウォッチドッグ**: 確率的リクエスト挙動モデルに基づくリアルタイム異常エスコート - **SLA 監視**: Web サービス標準を用いた複数サイト間のサービスレベル合意監視 - **エンドツーエンドレイテンシチューニング**: SEDA のような単一コンポーネント最適化へのリクエスト内並行性の活用 ## 関連研究との比較 - **Pinpoint**(Chen+ 2002): フォールト検知に焦点。積極的ロギング・分析・異常検知という同様の哲学を持つが、性能分析ではなく障害検知が主眼 - **Scout・SEDA**: リクエストがシステム通過する経路を明示的に定義する必要がある。これに対し Magpie はブラックボックス計装によってイベントログを組み合わせてパスを推論する - **分散イベントベースモニタ**(HiFi 等): マシン間のイベント列を追跡するが、リソース消費を監視しない ## 強みと弱点 ### 強み - ソースコード改変なしのブラックボックス計装でリクエスト単位の監査証跡を構築できる - URL ベース分類より精度の高い行動クラスタリングによるワークロードモデル生成 - SCFG による確率的リクエスト挙動モデルが異常検知・デバッグに応用可能 - 2003 年時点で「エンドツーエンドリクエストトレーシング」という分散システムオブザーバビリティの核心課題を先取り ### 弱点 - プロトタイプはオンラインモデリングではなくオフライン処理に限定 - 並行性(リクエスト内並行処理)をモデル化できない - Windows/.Net 環境に特化した計装(Event Tracing for Windows、.Net Profiling API、Detours) - イベントストリームのオンライン分散処理アルゴリズムが未開発 - 生成されたモデルを実用的に活用するクエリ機構が未実装 ## 関連 - 概念: [[分散トレーシング]] / [[リクエストモデリング]] / [[サービス依存性発見]] - エンティティ: [[Paul Barham]] / [[Rebecca Isaacs]] / [[Richard Mortier]] / [[Microsoft Research]] - 関連 MOC: [[SRE - MOC]] / [[異常検知 - MOC]] / [[AI Infra Telemetry - MOC]]