> [!abstract] 概要(arXiv abstract の日本語訳) > 主要なクラウドコンピューティング事業者は、自社インフラに展開された分散システムの現在(および過去)の状態を把握するための強力な監視ツールを提供している。このようなツールはスケールにおける詳細な監視メカニズムを提供する一方で、アプリケーション開発者やオペレータが膨大なモニタリングメトリクスを有用なインサイトへと変換するという大きな課題ももたらす。こうしたインサイトは、分散システムの効率性・回復力・依存性を向上させる効果的な管理ツールを構築するために不可欠である。 > 本論文では、分散システムにおける監視メトリクスから実行可能なインサイトを導出するプラットフォームである Sieve の構築・展開に関する経験を報告する。Sieve は 2 つのコアコンポーネントに基づいている。すなわち、メトリクス削減フレームワークとメトリクス依存性抽出器である。より具体的には、Sieve はまず時間経過とともにシグナルを観察することで重要でないメトリクスを自動的に除外し、メトリクスの次元数を削減する。その後、Sieve は Granger 因果性をテストする予測的因果モデルを使用して、システムの分散コンポーネント間のメトリクス依存性を推定する。 > Sieve を汎用プラットフォームとして実装し、2 つのマイクロサービスベースの分散システム、OpenStack と ShareLatex に展開した。我々の経験から、(1) Sieve は監視メトリクスの総数に対する統計的等価性を保ちながら、メトリクスの数を少なくとも 1 桁(10〜100 倍)削減できる、(2) Sieve は全システムスタックにわたる関連オーバーヘッドを削減することで既存の監視インフラを劇的に改善できる(CPU—80%、ストレージ—90%、ネットワーク—50%)、(3) 最後に、Sieve は分散システムにおける幅広いワークフローをサポートするのに効果的に活用できる——我々は 2 つのワークフローを紹介する。オートスケーリングのオーケストレーションと根本原因分析(RCA)——ことがわかった。本テクニカルレポートは我々の会議発表 [87] の拡張版である。 ## 論文情報 - **タイトル**: Sieve: Actionable Insights from Monitored Metrics in Microservices - **著者**: Jörg Thalheim (University of Edinburgh), Antonio Rodrigues (Carnegie Mellon University), Istemi Ekin Akkus (NOKIA Bell Labs), Pramod Bhatotia (University of Edinburgh), Ruichuan Chen (NOKIA Bell Labs), Bimal Viswanath (University of Chicago), Lei Jiao (University of Oregon), Christof Fetzer (TU Dresden) - **媒体**: arXiv プレプリント(会議版は Middleware 2017 で発表) - **発表年**: 2017年(arXiv 投稿: 2017-09-20) - **arXiv ID**: 1709.06686 - **コード**: https://sieve-microservices.github.io/ ## 概要 Sieve は、マイクロサービスベースの分散システムで大量に公開されるメトリクスから実行可能なインサイトを自動的に導出するプラットフォームである。k-Shape クラスタリングでメトリクスの次元を削減し、Granger 因果性テストでコンポーネント間の依存グラフを自動構築する。OpenStack と ShareLatex の 2 システムで検証し、メトリクスを 10〜100 倍削減しながらオートスケーリングと RCA の 2 ユースケースを実証した。 ## 問題設定 - **対象**: マイクロサービスベースの分散システム(数百〜数千のコンポーネントで構成) - **入力**: 各コンポーネントが公開するシステム/アプリケーションメトリクスの時系列(Netflix: 200 万、Uber: 5 億以上、OpenStack: 17,608) - **出力**: (1) 削減されたメトリクスセット(代表メトリクス)、(2) コンポーネント間の依存グラフ - **課題**: 膨大なメトリクスを人間が手動で精査するのは非現実的。Amazon CloudWatch のような従量課金型では全メトリクス収集がコスト高。既存手法は計装(インストルメンテーション)が必要か、アプリ固有の実装が必要で汎用性がない - **前提条件**: (1) アプリケーション開発者がワークロードジェネレータを提供できること、(2) RCA ユースケースでは正常版と障害版のバージョンが識別されていること ## 提案手法 ### アーキテクチャ Sieve は 3 段階のパイプラインで動作する(Figure 1)。 **Step #1: アプリケーションのロード** - ワークロードジェネレータでアプリケーションに負荷をかけながらメトリクス時系列を記録する - sysdig を用いてコンポーネント間の通信を取得し、コールグラフを構築する - tcpdump(7% オーバーヘッド)より sysdig(22% オーバーヘッド)を選択した理由: コンテナ識別とコンテキスト情報が豊富で、計装不要 - メトリクスは Telegraf で収集し InfluxDB に保存する **Step #2: メトリクス削減** - 前処理フィルタリング: 分散が低いメトリクス(var ≤ 0.002)を除去する - k-Shape クラスタリング: Shape-Based Distance (SBD) を距離指標として使う時系列クラスタリングアルゴリズムを適用する - SBD: 正規化相互相関(NCC)の変形で、時間シフトに頑健 $\text{SBD}(\vec{x}, \vec{y}) = 1 - \max_w NCC_w(\vec{x}, \vec{y})$ - Jaro 距離を使ったメトリクス名の類似性に基づく初期割り当てにより収束を高速化する - シルエット値(−1〜1)を用いてクラスタ数を自動決定する - 各クラスタから重心に最も近い代表メトリクスを選ぶ 3 つの調整を加えた: 1. 欠損データをスプライン補間(3 次)で再構築する 2. 500ms 解像度に離散化する(元論文の 2 秒から変更) 3. 名前類似性による初期クラスタ割り当てで収束を加速する **Step #3: 依存関係の同定** - コールグラフで通信するコンポーネントペアのみに Granger 因果性テストを適用する - 2 つの線形モデルを最小二乗法で構築し F 検定で比較する: - モデル 1: $Y_t$ を $Y_t$ の過去値のみで予測する - モデル 2: $Y_t$ を $X_t$ と $Y_t$ の両者の過去値で予測する - p 値が閾値を下回れば X が Y を Granger 因果すると判定する - 非定常時系列は Augmented Dickey-Fuller 検定で検出し、差分を取ってから検定する - 双方向エッジ(X→Y かつ Y→X)は疑似因果として除去する ### RCA エンジン(ユースケース 2) 正常版(C)と障害版(F)の依存グラフを 5 段階で比較する(Figure 2): 1. **メトリクス分析**: C/F 間で新規/消失メトリクスを抽出する 2. **コンポーネントランキング**: 新規性スコア(新規 + 消失メトリクス数)でコンポーネントを順位づける 3. **クラスタ分析**: クラスタの新規性と類似性を計算する(Jaccard 係数の変形: $S = |M^A_{i,C} \cap M^A_{j,F}| / |M^A_{i,C}|$) 4. **エッジフィルタリング**: 高新規性・類似性変化・時間ラグ変化のエッジを抽出する 5. **最終ランキング**: \{コンポーネント, メトリクスリスト\} のペアを出力する ## 新規性 | 先行研究の課題 | Sieve の解決方法 | |---|---| | Dapper/Pip/X-trace: アプリへの計装が必要 | sysdig のカーネルレベルシステムコール観測でコールグラフを計装不要で取得 | | Netflix の tools: アプリ固有で汎用性なし | アプリケーション非依存の汎用プラットフォーム | | 既存メトリクス削減手法(PCA/ランダム射影): 解釈性が低い・不安定 | k-Shape クラスタリングで開発者が視覚的に検証可能な代表メトリクスを選択 | | MonitorRank: 事前定義の(コンポーネント, メトリクス)関係が必要 | コールグラフ + Granger 因果でメトリクス関係を動的に推定 | 2017 年時点での独自性: メトリクス削減と依存グラフ構築を組み合わせた 2 段構成、sysdig によるブラックボックス的なコールグラフ取得、オートスケーリングと RCA の両ユースケースへの適用。 ## 実験設定 **ハードウェア(一般実験)**: - 10 ノードクラスタ。各ノードに 4 コア Xeon E5405 / 8 GB DDR2-RAM / 500 GB HDD **ハードウェア(オートスケーリング)**: - Amazon EC2: 12 × t2.large (2 vCPU, 8 GB RAM, 20 GB EBS) - Docker コンテナ / Rancher クラスタマネージャを使用 **ハードウェア(RCA Bug #1533942)**: - Amazon EC2: 2 × m4.xlarge (16 vCPU, 64 GB RAM, 20 GB EBS) + 3 × t2.medium **ハードウェア(RCA Bug #1590179)**: - Amazon EC2: 3 × t2.large + 2 × t2.medium **データセット**: - ShareLatex: 889 ユニークメトリクス(約 15 コンポーネント) - OpenStack Kolla: 47 マイクロサービス(7 主要 + 12 補助コンポーネント)、約 508〜657 メトリクス **評価対象バグ**: - Bug #1533942: VM 起動失敗(Neutron Open vSwitch エージェントのクラッシュ) - Bug #1590179: Fernet トークン性能劣化(Liberty → Mitaka のトークンキャッシュ戦略変更) **比較対象**: - オートスケーリング: CPU 使用率ベースの従来手法(Amazon AWS Auto Scaling デフォルト) - RCA: 文書化された既知の根本原因(グラウンドトゥルース)と照合 ## 実験結果 ### メトリクス削減の有効性 - ShareLatex で 889 メトリクスを平均 65 に削減(ランダムワークロード 5 回の平均) - 削減率: コンポーネントによって 1〜2 桁 - AMI(Adjusted Mutual Information)スコア: 平均 0.597(ランダム割り当てより有意に良い) ### 監視オーバーヘッドの削減(Table 3) | 指標 | 削減前 | 削減後 | 削減率 | |---|---|---|---| | CPU 時間 | 0.45G | 0.085G | 81.2% | | DB サイズ | 588.8 KB | 36.0 KB | 93.8% | | ネットワーク流入 | 11.1 MB | 2.3 MB | 79.3% | | ネットワーク流出 | 15.1 KB | 7.4 KB | 50.7% | ### オートスケーリング評価(Table 4) - Sieve が選択した代表メトリクス: `http-requests_Project_id_GET_mean`(Figure 6) - SLA 条件: 90 パーセンタイルレイテンシ ≤ 1000ms | 指標 | CPU 使用率 | Sieve | 差異 | |---|---|---|---| | 平均 CPU 使用率/コンポーネント | 5.98 | 9.26 | +54.82% | | SLA 違反(1400 サンプル中) | 188 | 70 | -62.77% | | スケーリング操作数 | 32 | 21 | -34.38% | → Sieve の代表メトリクスを使うと SLA 違反を 62.77% 削減しつつスケーリング操作も 34.38% 減少 ### RCA 評価 - Bug #1533942(VM 起動失敗) - 16 コンポーネントのうち、Nova API(1位)・Nova libvirt(2位)・Neutron server(3位)が上位ランキング - 最終ランキング(類似度閾値 0.50)で 16 コンポーネント・508 メトリクスから 10 コンポーネント・163 メトリクスに絞り込み - Figure 8: Nova API の `nova-instances-in-state-ERROR` と Neutron の `neutron-ports-in-status-DOWN` の因果エッジが真の根本原因を捉えた ### RCA 評価 - Bug #1590179(性能劣化) - AU&VT Rally タスクで Memcached が 2 位にランキング(最終的に 1 位) - ただし Keystone は 16 位と低ランク——性能劣化バグではメトリクスの出現/消失が少なくメトリクス新規性スコアが根本原因を直接指さないため - エッジフィルタリングで 2 つの注目エッジが特定されたが、Keystone のメトリクスは含まれなかった ## 考察 **Bug #1533942 での成功**: メトリクスの出現/消失が VM 起動失敗(クラッシュ)で顕著に現れ、メトリクス新規性スコアが有効に機能した。Neutron のネットワーキング問題を示すメトリクスが直接根本原因と紐付いた。 **Bug #1590179 の限界**: 性能劣化バグではメトリクスが消失/出現するのではなく値が変化するため、メトリクス新規性スコアでは直接捉えられない。関係の時間ラグ変化を追う手法が必要であることが判明した。 **依存グラフの複雑性**: 当初は木構造の依存グラフを期待したが、実際には根のない複雑なグラフになった。コンポーネント間関係は通常線形ではなく、アプリケーション知識の補完が必要(Lesson #1)。 **ブラックボックス性の限界**: システムメトリクス(CPU・I/O 等)は汎用的に取得できるが、アプリケーション固有メトリクス(リクエストレイテンシ・エラー数)が特に有用であることが判明。Sieve はブラックボックスでも動作するが、アプリケーションメトリクスを組み合わせると精度が向上する(Lesson #2)。 **ワークロードジェネレータの必要性**: 本番トレースを使ったオンラインモデル構築や段階的更新(Lesson #3)が将来課題として指摘された。 ## 強み / 弱点・課題 ### 強み - **計装不要**: sysdig によりアプリコードを変更せずにコールグラフを取得できる - **汎用性**: OpenStack・ShareLatex という異なる性質のシステムで有効性を実証 - **定量的改善**: 監視オーバーヘッドを大幅削減し、AWS CloudWatch のようなコスト課金型での費用削減に直結 - **解釈可能な削減**: PCA と異なり k-Shape の結果は開発者が視覚的に検証可能 - **2 つのユースケース**: オートスケーリングと RCA という異なるワークフローを 1 つのプラットフォームでカバー ### 弱点・課題 - **オフライン分析が前提**: ワークロードジェネレータをオフラインで実行し依存グラフを事前構築する設計のため、本番ダイナミクスへのリアルタイム適応は未対応 - **RCA はバージョン比較が前提**: 正常版と障害版を識別する必要があり、「ある時点での単一システム状態」だけでは動作しない - **Granger 因果性の限界**: 双方向因果・瞬時因果・潜在変数(交絡因子)を捉えられない。Lesson #1 でも「根のない複雑なグラフ」となる問題が判明 - **性能劣化バグへの限定的対応**: Bug #1590179 の評価では、クラッシュ型バグ(#1533942)と異なり根本原因を直接指示できず。メトリクス値の変化(分布変化)を捉える手法が必要 - **ワークロードジェネレータが必須**: アプリ固有のワークロードジェネレータを開発者が準備する必要があり、すべての環境に適用できるわけではない - **評価規模が限定的**: 2 つのシステム、2 つのバグのみでの評価