# Reviewing Cloud Monitoring: Towards Cloud Resource Profiling > Hauser, Wesner — 2018 IEEE 11th International Conference on Cloud Computing (CLOUD 2018), pp. 678-685. DOI 10.1109/CLOUD.2018.00093 > [!abstract] 概要 > クラウドデータセンターでは、物理層のプロバイダと仮想層の顧客がともにハードウェアとソフトウェアの基盤を監視し、負荷パターンを把握して、故障とボトルネックを検知している。物理層と仮想層におけるクラウド監視の動機は、警告(alerting)、リソース割当、可視化の 3 つの場面にまとめられる。典型的なクラウド監視の解は、観測対象の全システムの全メトリクスを、時系列データベースのような中央のストアへ転送して保存する。アプリケーションはそこから問い合わせ、集約し、結果を計算する。大規模なデータセンターではデータ量が増大し、相応のオーバーヘッドを招く。さらに、仮想層と物理層の双方で監視を行うため、オーバーヘッドが二重になる。本論文は、物理層のみでリソース統計を監視し、生の時系列データを保存する代わりに、リソース利用率プロファイルをクラウドミドルウェアと顧客へ提供する手法を提示する。この手法はまず、過剰予約(オーバーブッキング)された物理サーバも考慮したうえで、ハードウェアに依存しないリソースプロファイルに必要なメトリクスを見直す。プロファイルは静的部分(例: CPU コア数)と動的部分(例: 変化する利用率)から成り、ヒストグラムやマルコフ連鎖といった統計計算に基づく。 ## 論文情報 - 著者: Christopher B. Hauser, Stefan Wesner(Ulm University, Institute of Information Resource Management) - 会議: CLOUD 2018(8 ページ) - 種別: 既存監視のレビューと、代替アプローチ Clomon の構想提示(ポジション論文に近い) - 実装: kvmtop(KVM 向け収集ツール。https://github.com/cha87de/kvmtop)と NumPy ベースの統計変換ツール。両者は統合予定で、現時点の変換ツールは TSDB か CSV から生の時系列を読む ## 概要 クラウド監視を、収集(collect)と処理(handle)の 2 段に分けて現行方式を批評し、生の時系列を中央へ集めない代替として、物理ホストのエージェントが利用率の統計プロファイルをその場で更新して提供する構想 Clomon を示す。プロファイルは静的部分(CPU コア数など)と動的部分(状態遷移確率行列)から成る。評価はなく、実装は途中段階である。 ## 問題設定 課題は 2 群に分かれる。 **リソース統計の収集** - プロバイダとカスタマーは別々の監視系を持ち、互いに見えない。物理層が測る負荷は、仮想マシン(VM)の内側で体感される利用率と一致しない。例として、VM 内では CPU が 100% 使用中でも、過剰予約により 40% のサイクルが飛ばされ、物理 CPU の使用率は 60% にとどまる。cgroups による制限でも同様に起きる。 - 過剰予約下では「VM が今は資源を要らない」のか「ボトルネックで資源を使えない」のかを区別する必要がある。CPU 利用率だけでなく、ネットワークインタフェースのバッファサイズや CPU steal など、資源不足を表すメトリクスが要る。 - 利用率はハードウェア(CPU 周波数、ディスク速度)に依存するため、異種混在のデータセンターでは値が比較できない。ハイパーバイザ自身の消費資源も差し引く必要がある。 - 隔離のため、VM 内のアプリケーション固有メトリクスは物理層の監視系に届かない。 **リソース統計の処理** - 数千台規模では統計量がすぐ膨大になる。転送(ネットワーク)、処理(CPU)、保管(ストレージ)、および監視基盤自体のサーバが浪費になる。 - TSDB は古い測定値を集約・縮約して解像度を落とすため、全測定は保存されるが間隔は不均一になる。 - 警告・割当・可視化の用途では、実際に問い合わせられるのは平均・最小・最大や直近状態との比較程度であり、テラバイト級の保存に見合うかが疑問になる。 ## 提案手法 構想のみで、次の要素から成る。 **目標** - 物理層・仮想層の二重監視を減らし、顧客向けの監視サービスも成り立たせる - 静的なハードウェア特性を統計に組み込み、ホスト間で比較可能にする - 生の測定値の代わりにプロファイルを保存する。時間とリソース量に対して非線形にスケールさせ、意味のある情報は失わない **アーキテクチャ(Clomon)** — 各物理ホスト上で動く。コネクタ(libvirt や docker に問い合わせてワークロード一覧を得る)、コレクタ(/proc などからワークロードごとの利用率を読む)、プロファイラ(ワークロードごとにプロファイルを作る)の 3 部品から成る。ブラックボックスの VM やコンテナにコレクタを入れる必要はない。得たプロファイルは、ダッシュボード、データセンター最適化ツール、警告エンジンへ渡す。図1が全体の位置づけ、図2が内部構成である。 ![[_attachments/2018__CLOUD__Reviewing-Cloud-Monitoring-Towards-Cloud-Resource-Profiling/fig01-clomon-overview.png]] *Figure 1. Clomon Overview* ![[_attachments/2018__CLOUD__Reviewing-Cloud-Monitoring-Towards-Cloud-Resource-Profiling/fig02-clomon-architecture.png]] *Figure 2. Detailed Architecture of Clomon* **過剰予約下の収集** — 表 I の追加メトリクスを集める。 - CPU: スケジューラのサイクルと奪われたサイクル(steal)、エミュレーション(I/O)用の CPU 利用率 - RAM: スワップに起因するページフォールトとエラー(メモリアクセス自体は性能劣化のため測れない) - ディスク I/O: スケジューラキューサイズ、ファイルシステムキャッシュのミス - ネットワーク I/O: インタフェースのキューサイズ、パケットのエラーと損失 **ハードウェア非依存化** — 物理ハードウェアごとの仕様(CPU・メモリ周波数、ネットワークとストレージの理論最大速度)を引き、ストレージはベンチマークで実測最大値を得る。この校正は機器の構成が変わるたびに行い、実行時の統計を仕様に対する相対値へ直して比較可能にする。 **アプリケーション固有メトリクス** — プロバイダが、仮想デバイスまたは仮想ネットワークアダプタとして隔離された一方向チャネルを用意し、顧客がそこへ指標を流す。 **統計モデル** — 動的部分は状態遷移確率行列、静的部分は CPU コア数などの固定情報と基準値である。生成手順(図3)は次のとおり。 1. ストリームを n 秒バッファしてチャンクにする 2. チャンクをヒストグラムなどで集約して統計表現にする 3. ローカルのキャッシュにある既知の表現と照合し、一致すれば ID を取り、なければ登録する 4. 状態(=キャッシュ済み表現の ID)の遷移をマルコフ連鎖に記録し、確率行列を更新する 精度は、バッファ時間幅、集約関数、照合の粒度の 3 点で制御する。上位アルゴリズムがリソース間の利用率の同時出現確率(例: 高 CPU と低ディスクの確率 0.1)を求め、ボトルネック検知・予測に使う。バッファ幅を変えて階層化し、秒単位の短期モデルから月単位の長期モデルまで持たせて季節性を表す。 ![[_attachments/2018__CLOUD__Reviewing-Cloud-Monitoring-Towards-Cloud-Resource-Profiling/fig03-stream-conversion.png]] *Figure 3. Convert raw resource utilisation stream into statistical model* ## 新規性 - 監視の動機を警告・リソース割当・可視化に整理し、出力を「現在の状態」と「通常の履歴状態」の 2 種に絞った点 - 生の時系列を中央へ送らず、収集元で統計プロファイル(ヒストグラム + マルコフ連鎖)へ変換する構想 - 物理層のみの監視で、過剰予約下の VM 体感利用率とハードウェア差を補正する点 - 最も近い先行研究は LinkedIn の ODP(オンデマンドのサービスプロファイリング)だが、本論文は資源割当・警告も対象とし、中央 DB の必要性自体を減らす点が異なる ## 実験設定 本論文に定量評価は無い。図4 は HPC ワークロードの CPU 利用率を例に、変換過程(生信号、ヒストグラムとマルコフ連鎖、確率行列)を示す説明図である。 ![[_attachments/2018__CLOUD__Reviewing-Cloud-Monitoring-Towards-Cloud-Resource-Profiling/fig04-histogram-markov.png]] *Figure 4. Statistical conversion with histograms and Markov chains with an exemplary HPC workload (CPU utilisation)* ## 実験結果 なし。実装状況は、kvmtop(過剰予約を考慮し VM 体感の利用率を出力)と NumPy 製の変換ツールが別々に存在する段階である。プロファイルは Vice Registry に統合し、資源・利用率を意識した自己組織化クラスタへ進める計画である。 ## 考察 **既存監視の整理(第 IV 章)** - 収集: Nagios・Ganglia は収集・転送・保存・可視化を備えた一体型。collectd・Snap は収集と転送に特化し、保管は外部 DB に任せる。node-monitor・cAdvisor は OS から読むだけのアダプタで、コンテナホスト上でコンテナとして動くことが多い。 - 処理: Ganglia・Nagios は RRDTool(固定サイズのファイルで古いデータを自動集約)を使う。collectd・Snap・cAdvisor などは InfluxDB や Prometheus といった TSDB を使う。TSDB はキーがタイムスタンプとタグの拡張キーバリューストアで、ヒストグラムやパーセンタイルの問い合わせが得意だが、専用の基盤が要る。 - 議論: コレクタは変化するデータに偏り、CPU 情報などの静的なリソース記述が乏しい(Ganglia は RAM に持つだけで RRD に残らない)。過剰予約による資源不足の指標も、可視化と警告のユースケースに引きずられて収集対象になっていない。どの保管方式でも全データの転送が必要で、Snap のような転送中の集約には別途計算資源が要る。 **限界(著者自身の記述)** - 各ホストに変換の計算が要る - Grafana のような拡大表示による手動分析はできなくなる。代替の可視化に期待する ## 強み / 弱点・課題 - 強み: 過剰予約による「VM 内の体感」と物理層の乖離、静的情報の欠落、TSDB への全転送の無駄という、現行監視の欠点を具体的に示した。プロファイルが「現在状態と通常状態」という 2 出力に対応する点で用途との対応が明確である。 - 弱点: 評価がなく、「必要な精度は現行より遥かに低い」という前提は仮定にとどまる。情報損失(短時間のスパイクや稀な異常が状態へ丸められる)と、警告の精度への影響は検証されていない。マルコフ連鎖は 1 次の状態遷移しか持たず、長期依存や季節性は階層化に頼る。物理層のみの監視は、アプリケーション固有メトリクスの経路が別途要る。 - 課題: 状態(統計表現)の照合しきい値、バッファ幅の選び方、リソース間相関の算出コストが未定である。