# Enabling Programmable Metric Flows > [!abstract] 概要（日本語訳） > 集中型クラウドからマルチクラウドおよびエッジへと計算環境が拡大するなか、適応的なオブザーバビリティの必要性が高まっている。従来の静的な監視手法は、非効率なデータ転送、限定的なスケーラビリティ、異種環境、および固定的なメトリクス処理パイプラインに苦しんでいる。本論文は、動的性を原理とする新しいメトリクス処理システム Programmable Metric Flows（PMF）を提案する。PMF は初の軽量 SQL ベースメトリクスプロセッサであり、変化する資源可用性やアプリケーション要件に応じた最適化駆動のメトリクス変換を可能にする。本論文では PMF が動的かつ細粒度のメトリクス収集のための各種変換をどのように実現するかを示し、エッジ環境での WAN コスト削減のためのメトリクス周波数の動的チューニング能力を紹介する。実験の結果、PMF は最先端技術と同等のメトリクス処理能力を持ちながら、資源利用を 10 分の 1 に抑えることを示す。PMF はオープンソースで提供されている（https://github.com/observ-vol-mgt/PMF）。 ## 論文情報 - **会議**: IEEE 17th International Conference on Cloud Computing (CLOUD) 2024 - **著者**: Aishwariya Chakraborty, Chander Govindarajan, Kavya Govindarajan, Priyanka Naik, Seep Goel（全員 [[IBM Research]] India） - **DOI**: 10.1109/CLOUD62652.2024.00050 ## 概要 マルチクラウド・エッジ環境ではメトリクスの量が爆発的に増加し、収集・保持・処理のコストと平均検知時間（MTTD）・平均復旧時間（MTTR）が増大する。従来のメトリクス収集ツール（[[Prometheus]]、OpenTelemetry、Datadog 等）は動的なオンデマンド変更やメトリクスごとの収集周波数設定をサポートしない。PMF はメトリクスの重要度と資源制約に基づき、メトリクスごとの収集周波数をトップダウンで動的に最適化する初のシステムである。 ## 問題設定 1. **メトリクスの不均等な重要度**: 複数の多変量時系列異常データセット（Exathlon、SMD 等）で COPOD による異常検知を行うと、上位 20% の重要メトリクスのみで得られる AU-ROC が下位 20% を大きく上回る（図 1）。全メトリクスを均等に扱うのは非効率である。 2. **静的なボトムアップ手法の限界**: 既存手法（閾値ベース、適応サンプリング、IoT データ駆動手法）は個別メトリクスの局所履歴に基づくボトムアップ方式で、利用可能帯域や下流タスクへの個別メトリクスの貢献といったグローバルな視点を欠く。 3. **マルチクラウドの動的性**: トラフィック変動、ワークロード変化、帯域幅変動に対し、既存ツールは動的な再構成を欠く。 ## 提案手法 ### PMF アーキテクチャ（§III） エッジのローカルコレクタと中央アグリゲータの間にプロキシ的に配置されるミドルボックス。5 つのサブコンポーネントで構成される。 1. **レシーバ**: 送信されたメトリクスを処理用フォーマットへデコード（Protobuf 等） 2. **エグゼキュータ**: メトリクスの変換を実行するコアコンポーネント。インメモリ SQLite 上に構築 3. **トランスミッタ**: 変換済みメトリクスを元フォーマットにエンコードし中央アグリゲータへ送信 4. **コントローラ**: ユーザ向け API を提供し DAG の作成・更新を受け付ける 5. **コンフィギュレータ**: YAML 仕様を SQL クエリへ変換 ### 変換操作（§III-A） SQL トランザクションとして実現される 5 種の変換をサポートする。 - **周波数変換（Frequency Transform）**: セレクタで選択したメトリクス群のサンプリング周波数を制御 - **フィルタ変換（Filter Transform）**: セレクタに一致するメトリクスのデータポイントをすべて破棄 - **適応変換（Adaptive Transform）**: 値が過去の観測から有意に異なる場合のみ転送（例: 2σ 逸脱） - **集約変換（Aggregate Transform）**: 時間窓内の平均等の集約値のみ送信 - **NoOp 変換（No-Op Transform）**: 変換対象外のメトリクスをそのまま転送するデフォルト動作 ### 変換 DAG（§III-B） 変換操作を有向非巡回グラフ（DAG）としてモデル化する。各ノードが変換ユニットで、入力テーブルから深さ優先で処理を行い、葉ノードで選択された行をバッチ送信する。YAML で DAG を指定する。エッジクラウドでの現実的なユースケース（エンリッチ→フィルタ→周波数変換を組み合わせた 3 分岐）を例示する（図 5）。 ### 動的性（§III-C） 2 種類の動的再構成をサポートする。 1. **パラメータ更新**: 変換ユニットのセレクタや変数のみを更新。DAG 全体の再構築は不要 2. **構造更新**: DAG にノードを追加・削除。帯域制約時にフィルタノードを追加し、回復時に削除する例 ### 動的周波数最適化（§IV） 中央に配置されるオプティマイザが、メトリクスごとの最適収集周波数を線形計画問題として決定する。 - **帯域制約**: クラスタごとのアップロード帯域 $B_i$ とコントローラのダウンロード帯域 $B$ を上限に設定（式 1） - **異常検知の TTD 制約**: 異常 $k$ の検知時間 $T_k$ は影響メトリクスの最低周波数で律速される（式 3） - **3 つの目的関数**: (1) 総帯域消費の最小化、(2) 全異常の平均 TTD の最小化、(3) フレッシュネスインデックス（FI、重み付き周波数平均）の最大化（式 5–6） - 補助変数 $z_k = 1/T_k$ の導入で線形化し、Gurobi で解く。スパース行列によるモデル化で 4M メトリクスまで 1 秒未満で求解 ## 新規性 1. **SQL ベースの動的メトリクスプロセッサ**: メトリクス変換を SQL クエリとして表現し、OpenTelemetry Transformation Language と比較してフィルタ変換の実装を 221 行から 14 行に削減する汎用的かつ軽量な設計 2. **DAG ベースの変換合成**: 単一の変換を再利用可能な SQL ブロックとして組み合わせることで多様なメトリクスフロー処理を実現 3. **トップダウンの動的周波数最適化**: メトリクスの下流タスク（異常検知）への貢献度と資源制約をグローバルに考慮する最適化。ボトムアップの局所適応と対照的 4. **オンデマンド再構成**: パラメータ更新（マイクロ秒級）と構造更新の両方をサポートし、実行中のバッチ処理への影響を最小化 ## 実験設定 - **ハードウェア**: Intel Xeon Gold 5218（2.30GHz、64 コア、128 スレッド）、800GB RAM、Ubuntu 20.04.6 - **ソフトウェア**: SQLite v3.31.1、Prometheus v2.43.0、Cortex v1.14.1、OpenTelemetry v0.92.0、Gurobi v10.0.1 - **デフォルト設定**: 40K メトリクス、10 ラベル、30 秒間隔で生成、周波数変換（セレクタはラベル 1 つ） - **比較対象**: OpenTelemetry（OTel）コレクタ ## 実験結果 ### 性能とスケーラビリティ（§V-A） - **スループット**: 200K メトリクスまで線形スケール。約 40K メトリクス/秒のスループットを維持（図 7） - **バッチ実行時間（BET）**: 40K メトリクスで約 0.9 秒。エグゼキュータ遅延が支配的 - **資源消費**: CPU 約 2.5–3%、メモリは線形増加（40K メトリクスで約 328MB）（図 8） - **制御プレーン遅延**: DAG 作成は 30–288µs。更新は約 12µs（表 II） ### OTel との比較（§V-B） - **フィルタ変換の実行時間**: NoOp を無効化した公平比較で同等の実行時間（図 9） - **CPU 消費**: PMF は OTel の **10 分の 1** の CPU 消費（図 10）。エッジクラウドへの適用に有利 - OTel は動的変換の更新をサポートしないため、その比較は対象外 ### マイクロベンチマーク（§V-C） - **ラベル数の影響**: ラベル数が 5→20 に増加するとエグゼキュータ遅延が増加（ラベルテーブルのサイズ増）。CPU は安定（図 11–12） - **変換種別の影響**: フィルタが最速。NoOp が最遅（全行更新+エクスポート）。CPU・メモリは変換種別に依存しない（図 13–14） - **DAG サイズ・種別**: 並列 DAG はエグゼキュータ遅延が大、直列 DAG はエクスポート遅延が大（NoOp の伝搬による）（表 III） - **インメモリ対ファイルストレージ**: インメモリが挿入で 3 倍高速、総合で約 1.6 倍高速（表 V） ### 動的周波数のユースケース（§V-D） - **シミュレーション**: 中央 1 クラウド + エッジ 10 クラウド × 100 クラスタ、50 異常、メトリクス生成 1 秒間隔 - **重み付き再構成誤差（WRE）**: Prometheus（30 秒固定）と同一帯域（13.2MB/s）で WRE を**約 600 倍削減**（図 16）。重要メトリクスに高周波数を割り当てるため - **フレッシュネスインデックス（FI）**: 同一帯域で Prometheus より高い FI を達成（図 17）。重要メトリクスの鮮度を優先 - **最適化実行時間**: 10K→4M メトリクスで実行時間に大きな増加なし（1 秒未満）。スケーラブル（図 18） ## 考察 PMF は「メトリクスパイプラインのプログラマブルな動的処理」という新しいカテゴリを開く。SQL ベースの設計は汎用性と拡張性を担保し、インメモリ SQLite の選択は軽量性を確保する。トップダウンの周波数最適化は、下流タスク（異常検知）のメトリクスへの依存度を考慮したグローバルな帯域配分を実現する。ただし現行実装は SQLite の単一トランザクション制約のため DAG を深さ優先で逐次処理しており、並列処理による高速化の余地がある。著者らはメトリクスに続きログやトレースへの拡張を展望する。 ## 強み - **軽量かつ汎用**: Go 678 行 + インメモリ SQLite で CPU 約 2.5%。エッジ環境に適合 - **DAG による合成可能性**: 単純な変換の組み合わせで多様なフロー処理を実現 - **数理的最適化**: 帯域・異常重要度・検知時間の 3 目的を線形計画で最適化 - **オンデマンド再構成**: マイクロ秒級の制御プレーン遅延で動的環境に対応 - **OTel 比 10 倍の CPU 効率**: リソース制約環境での差別化 ## 弱点・課題 - **SQLite の並行性制限**: 単一トランザクションのため DAG の並列処理ができず、並列 DAG のスループットが制限される - **メモリ最適化の未実施**: バッチ処理でメトリクス全量をインメモリに格納するためメモリ使用量が線形増加 - **異常検知モデルの単純化**: 下流タスクをブラックボックスとし、メトリクス重みを静的に与える前提。実際の異常検知アルゴリズムは時間とともに重みが変化する - **シミュレーションベースの評価**: 動的周波数の効果は合成データでのシミュレーションに依存。実環境のマルチクラウドでの検証は未実施 - **メトリクス以外のモダリティ未対応**: ログ・トレースへの拡張は将来課題として言及のみ ## 出典 - [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]](本ページ)