# メトリクス削減 ## 定義 メトリクス削減(Metric Reduction)は、分散システムの多数のコンポーネントが公開するメトリクス時系列から、情報損失を最小限に抑えながらモニタリングや意思決定に必要な代表的なサブセットを選択する手法である。目的は「情報過負荷(information overload)」の解消と監視インフラのコスト削減にある。Netflix(200 万メトリクス)・Uber(5 億メトリクス超)のような大規模マイクロサービス環境では、全メトリクスを収集・保存・分析することは非現実的かつコスト高となる。([[@2017__arXiv__Sieve - Actionable Insights from Monitored Metrics in Microservices]]) 主要なアプローチ: - **フィルタリング**: 低分散・不変メトリクスを除去する(var ≤ 閾値) - **クラスタリング**: 類似挙動のメトリクスをグループ化し代表を選ぶ(k-Shape, k-means, k-medoids, ファジーロジック) - **サンプリング**: 偏りサンプリング・近似計算で密度を保ちながら削減する - **次元圧縮**: PCA・ランダム射影で線形空間に写像する(解釈性は低下) ## 横断的知見 - **クラスタリングによる削減は解釈可能性と精度のバランスで PCA より優れる**: Sieve は k-Shape クラスタリングで代表メトリクスを選択し、PCA との差別化として「開発者が視覚的に検証可能」な結果を強調する。一方 PCA は削減後の成分が原次元に対応しないため、どのシステムリソースが問題かを人間が判断しにくい。単一ソースからの観察だが、この設計選択は AIOps のより広い原則——「モデルの精度だけでなく説明可能性が運用上の信頼に直結する」——を示す。(Source: [[@2017__arXiv__Sieve - Actionable Insights from Monitored Metrics in Microservices]]) - **PCA の解釈可能性の低さは、2005 年の分散異常検知研究でも独立に指摘されていた**: [[@2005__Machine Learning__Principle Components and Importance Ranking of Distributed Anomalies]](Begnum & Burgess, 2005)は、PCA を「メトリクス削減」ではなく「ホスト重要度ランキング」の用途で使ったが、そこでも同じ弱点——PCA は各ホストの個別性を犠牲にして全体共通の最良近似(絶対スケール)を探すため、結果に一貫した解釈可能な意味を与えられない——を実証的に確認している。Sieve (2017) が「開発者が視覚的に検証可能」という設計原則から PCA を代替した判断は、12 年前に別ドメイン(ホスト間相関 vs メトリクス次元)で観測された同じ限界の追認と読める。加えて Begnum & Burgess は、PCA が振幅(分散)の大きい変数に敏感でノイズの多い参加者を強調するという、Sieve の議論にない追加の弱点も指摘しており、削減後の解釈性だけでなく削減対象の選び方自体がノイズに脆弱になりうることを示唆する。(Source: [[@2005__Machine Learning__Principle Components and Importance Ranking of Distributed Anomalies]], [[@2017__arXiv__Sieve - Actionable Insights from Monitored Metrics in Microservices]]) - **アルゴリズム的削減(クラスタリング・PCA)と運用的削減(パイプラインGatewayのフィルタ/集約/サンプリング)は同じ「削減」でも作用点が異なる**: Sieve・PCA研究はメトリクス群の統計的類似性から代表を選ぶ**分析前**の次元削減を扱うのに対し、`Observability Engineering`第2版第16章([[@2026__OReilly__Observability Engineering 2E - Chapter 16 Telemetry Management with Pipelines]])が説明するテレメトリパイプラインのReduce段階は、収集・転送の**途中**でGatewayがフィルタリング(低価値メトリクスの破棄)・集約(高レベルロールアップ)・サンプリングを適用する運用的な削減である。前者はどのメトリクスが情報を持つかを事後分析で判定するのに対し、後者は流れているデータをリアルタイムに、多くはルールベースで間引く。両者は独立に併用可能で、パイプラインのReduce段階を通過した後のメトリクス群に対してさらにSieve的なクラスタリング削減を適用する二段構成も考えられる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 16 Telemetry Management with Pipelines]], [[@2017__arXiv__Sieve - Actionable Insights from Monitored Metrics in Microservices]]) - **PCAの解釈可能性を批判する前に、1996年のソフトウェア信頼性工学がすでに「負荷量パターンの命名」という緩和策を実践していたことが分かった**: 本ページは Sieve(2017)・Begnum & Burgess(2005)を根拠に PCA の解釈可能性の弱さを繰り返し確認してきたが、*Handbook of Software Reliability Engineering* 第12章(Munson & Khoshgoftaar, 1996)は同じ PCA を、複雑性メトリクス群(LOC・Halstead・McCabe 循環的複雑度)の多重共線性を解消する「ドメインメトリクス」構築に使いながら、各ドメインの負荷量パターンを検査して「サイズ」「制御フロー」といった人間可読な名前を与えることで解釈可能性を後付けしている。これは本ページの「クラスタリングで PCA を代替する」路線とは異なる第三の対処——PCA の数学はそのまま使い、成分の解釈を体系的な事後手続きにする——であり、[[主成分分析]] ページの横断的知見で詳述する。(Source: [[主成分分析]], [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 12 Software Metrics for Reliability Assessment]] §12.2.3) - **RRD による時間軸ダウンサンプリングは、2011 年時点で既に確立していた「運用的削減」の最も単純な先行形態である**: 本ページが整理する「運用的削減」(テレメトリパイプライン Gateway でのフィルタ/集約/サンプリング)は 2026 年の Observability Engineering 第16章を根拠にしてきたが、[[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] は、ラウンドロビンデータベース(RRD)による「経過時間に応じて時間分解能を段階的に下げる」設計を 2011 年時点で「デファクトスタンダード」と述べる。RRD は個々のメトリクスの重要度やクエリパターンを判定せず、単純に「新しいデータは高分解能・古いデータは低分解能」という時間軸のみを基準に固定サイズで削減する——Sieve のクラスタリングや PCA のような「どのメトリクスが情報を持つか」を判定する分析的削減とも、Gateway のフィルタ/集約のような「リアルタイムにルールベースで間引く」運用的削減とも異なる、**時間経過だけを軸にした最も単純な運用的削減**である。この設計は後年の [[時系列データベース]] 概念が整理する Graphite の whisper(固定サイズ・ローリング・精度劣化)へそのまま継承されており、メトリクス削減の系譜において「集約対象を選ぶ」次元とは独立に「保持期間に応じて解像度を落とす」次元が古くから存在したことを裏づける。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] §3.1, §3.9.2.5, [[@2026__OReilly__Observability Engineering 2E - Chapter 16 Telemetry Management with Pipelines]]) - **「分析層での特徴量削減」は Netflix・Uber が示す実際のメトリクス規模に遠く及ばない地点で精度が崩壊する——収集層の削減が分析層の削減を代替できない理由の定量的な裏付け**: 本ページの定義は Netflix(200 万メトリクス)・Uber(5 億メトリクス超)という収集層の規模を示すが、[[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 5 Feature Reduction of Multivariate Time Series Data for Automated Fault Localization]](博士論文第 5 章、MetricSifter の完全版)の empirical study は、コンポーネントあたり数千メトリクス(TT-large: 平均 9,458 メトリクス)の段階で、特徴量削減の有無によらず障害箇所特定の top-5 recall が 0.2 を下回り実用的でなくなることを報告する(§5.7.2)。これは Netflix/Uber の**システム全体**のメトリクス数(百万〜億単位)からは 2〜3 桁小さい、**単一コンポーネント**あたりのメトリクス数ですでに分析層のアルゴリズム(統計的因果探索・特徴量削減)が破綻することを意味する。したがって Sieve のようなクラスタリングベースの収集層メトリクス削減(本ページの主対象)は、大規模テレメトリの運用コスト削減だけでなく、下流の障害箇所特定アルゴリズムが機能する問題空間を保つための**前提条件**としても必要であり、両者は代替関係ではなく直列の依存関係にある。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 5 Feature Reduction of Multivariate Time Series Data for Automated Fault Localization]] §5.7.2, [[@2017__arXiv__Sieve - Actionable Insights from Monitored Metrics in Microservices]]) - **サーベイが伝える Sieve の「削減後」段階が、本ページが定義節で扱ってきた削減アルゴリズムそのものの記述を補完する**: 本ページはこれまで Sieve を k-Shape クラスタリングによる「Reduce Metrics」段階(§3.2)の代表例として扱ってきたが、[[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.2 Failure Diagnosis Through Metrics]] はサーベイの視点から Sieve を「その他の技術・コンポーネントレベル」に分類し、削減後の下流タスクまで記述する——クラスタリングベースのセントロイド保存法で次元削減した後、既存の呼び出し関係を持つインスタンス間で Granger 因果性検定を行い予測的因果モデルで依存関係を推論、正常時・異常時の依存グラフの差分を比較して根本原因を診断する。**メトリクス削減は Sieve にとって独立した目的ではなく、下流の因果グラフ差分比較(RCA)を可能にする前処理段階として設計されている**ことが、削減アルゴリズム単体を扱ってきた本ページの記述に、診断パイプライン全体としての位置づけを補う。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.2 Failure Diagnosis Through Metrics]], [[@2017__arXiv__Sieve - Actionable Insights from Monitored Metrics in Microservices]]) - **CauseRank のモジュール単位グルーピングは、Sieve のクラスタリング・MetricSifter の特徴量削減とは異なる第3の削減戦略として、因果グラフベースRCAファミリーの中にメトリクス削減がもう一箇所存在することを示す**: 同サーベイが整理する CauseRank(§4.2.2、因果グラフ・ウォークベース)は、システムのメトリクスをモジュールごとにグループ化して高次元性による複雑さを低減したのち、各グループのボラティリティで候補グループを絞り込み、group-based greedy equivalent search(G-GES)で一時的因果グラフを構築する。本ページが既に扱う Sieve(クラスタリングベースのセントロイド保存)・MetricSifter(特徴量削減による障害箇所特定の高速化)とあわせると、**「メトリクスを削減してからRCAを行う」という設計は、フィルタリング・クラスタリング・モジュール単位グルーピングという異なる粒度・異なる実装で、因果グラフベースRCA研究に繰り返し現れる共通パターン**であることが分かる。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.2 Failure Diagnosis Through Metrics]], [[@2017__arXiv__Sieve - Actionable Insights from Monitored Metrics in Microservices]], [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 5 Feature Reduction of Multivariate Time Series Data for Automated Fault Localization]]) ## 未解決の問い - **メトリクス削減を前処理に組み込むRCA手法(Sieve・CauseRank)は、本ページが定量化してきた「単一コンポーネントあたり数千メトリクスで精度が崩壊する」規模(MetricSifterのPhD論文、§5.7.2)にどこまで耐えるか**。サーベイ(chapter 4.2)は Sieve・CauseRank の削減率や削減後の診断精度を定量報告しておらず、両者を同一のスケール基準で比較できない。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.2 Failure Diagnosis Through Metrics]], [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 5 Feature Reduction of Multivariate Time Series Data for Automated Fault Localization]]) - **収集層のメトリクス削減(Sieve 等)と分析層の特徴量削減(MetricSifter 等)を直列適用した場合、単一コンポーネントあたりのメトリクス数がどこまで下がれば障害箇所特定の top-5 recall が実用域(0.2 超)を回復するか**は定量化されていない。両層の削減率をどう配分すべきかは [[特徴量削減]] の未解決の問いとも重なる。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 5 Feature Reduction of Multivariate Time Series Data for Automated Fault Localization]] §5.7.2) - **動的な本番環境でのリアルタイムメトリクス削減**: Sieve はオフライン分析(ワークロードジェネレータでの負荷テスト後)を前提とする。本番トラフィックを使った継続的なモデル更新はどう設計するか。新しいコンポーネントやメトリクスが追加された際のインクリメンタルな更新手法は何か。 - **最適なクラスタ数の自動決定**: Sieve はシルエット値でクラスタ数を決定するが、最大 7 クラスタを実験的に設定している。より大規模なシステム(数千コンポーネント・数億メトリクス)での自動決定手法は有効か。 - **メトリクス削減と依存グラフ品質のトレードオフ定量化**: 削減率を上げるほど Granger 因果性テストの精度が低下するか。どの削減率が依存グラフ品質の下限を形成するか。 - **異なる削減手法の組み合わせ効果**: フィルタリング + クラスタリング + Granger 因果をパイプラインで組み合わせた場合の相互作用は。各段での削減率の最適配分は。 ## 関連 - ソース: [[@2017__arXiv__Sieve - Actionable Insights from Monitored Metrics in Microservices]] / [[@2005__Machine Learning__Principle Components and Importance Ranking of Distributed Anomalies]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 16 Telemetry Management with Pipelines]] / [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 12 Software Metrics for Reliability Assessment]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] / [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 5 Feature Reduction of Multivariate Time Series Data for Automated Fault Localization]] / [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.2 Failure Diagnosis Through Metrics]] - 概念: [[マイクロサービスアーキテクチャ]] / [[因果推論ベースRCA]] / [[オブザーバビリティ]] / [[異常検知]] / [[Scaling Telemetry Workloads]] / [[PageRank]] / [[テレメトリパイプライン]] / [[主成分分析]] / [[時系列データベース]] / [[特徴量削減]] / [[Fault Localization]] - エンティティ: [[Jörg Thalheim]] / [[Pramod Bhatotia]] / [[Mark Burgess]] / [[Kyrre Begnum]] / [[John Munson]] / [[Taghi Khoshgoftaar]] / [[Ganglia]] / [[MetricSifter]] ## 出典 - [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.2 Failure Diagnosis Through Metrics]](§4.2.5 Sieve のクラスタリングベース削減+Granger因果によるRCA、§4.2.2 CauseRank のモジュール単位グルーピング) - [[@2017__arXiv__Sieve - Actionable Insights from Monitored Metrics in Microservices]] (§3.2 Reduce Metrics, Table 3, Figure 4) - [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 5 Feature Reduction of Multivariate Time Series Data for Automated Fault Localization]](§5.7.2 大規模テレメトリでのスケーラビリティ限界) - [[@2005__Machine Learning__Principle Components and Importance Ranking of Distributed Anomalies]](§7 Conclusions: PCA が個別性を放棄し一貫した意味を与えられないという指摘) - [[@2026__OReilly__Observability Engineering 2E - Chapter 16 Telemetry Management with Pipelines]](§Reduce — パイプラインGatewayでのフィルタリング・集約・サンプリングという運用的削減) - John C. Munson, Taghi M. Khoshgoftaar, "Software Metrics for Reliability Assessment", in Michael R. Lyu (ed.), *Handbook of Software Reliability Engineering*, IEEE Computer Society Press / McGraw-Hill, 1996, Chapter 12, §12.2.3. - マット・マッシー、ジョン・オルスポー, 「3章 インフラとアプリケーションのメトリクス」, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, §3.1, §3.9.2.5.