# Cloud monitoring: A survey > [!abstract] 概要 > 今日、クラウドコンピューティングは技術的にも経済的にも理由があり、インターネット越しにサービスを提供する手段として広く使われている。クラウドベースのサービスの数はここ数年で急速かつ大幅に増え、それらを支えるインフラの複雑さも増した。こうした複雑なインフラを適切に運用・管理するには、有効かつ効率的な監視が常に必要である。 > 文献には、クラウドの特性、機能、基盤技術(仮想化など)、セキュリティとプライバシーを調査した研究が数多くある。しかし著者らの知る限り、これらのサーベイにはクラウドの監視に関する詳細な分析が欠けている。この空白を埋めるため、本論文ではクラウド監視のサーベイを示す。まずクラウド監視の動機を分析し、以降の貢献に向けた定義と背景を与える。次に、クラウド向け監視システムの性質、その性質から生じる課題、および文献でそれらの課題がどう扱われてきたかを丁寧に分析し議論する。さらに、商用とオープンソースの双方について現行のプラットフォームとサービスを述べ、先に特定した性質・課題との関係を明らかにする。最後に、クラウド監視分野の未解決課題、主要な挑戦、今後の方向を特定する。 ## 論文情報 - タイトル: Cloud monitoring: A survey - 著者・所属: Giuseppe Aceto, Alessio Botta, Walter de Donato, Antonio Pescapè(University of Napoli Federico II, イタリア。Pescapè が責任著者) - 媒体・年: Computer Networks(Survey Paper)、2013 年。受理 2013-04-03 - DOI: 10.1016/j.comnet.2013.04.001 - 先行版: 同じ枠組みの予備的結果を IEEE CloudNet'12(2012 年 11 月、パリ)で発表している(脚注 1) ## 概要 クラウド監視を単独の主題とした初期のサーベイである。NIST のクラウド定義を土台に、監視の動機を 8 種の運用活動として整理し、監視の基本概念を層・抽象度・テストと指標の 3 軸で分類する。そのうえで、クラウド向け監視システムに求められる 12 の性質と、各性質に付随する課題および既存研究を整理し、商用 9・オープンソース 8・評価サービス 11 を、その 12 の性質に対応づけて概観する。最後に、有効性と効率の観点から未解決課題を挙げ、7 つの研究方向を示す。 ## 問題設定 - クラウドの利用者数とインフラ複雑度が急増し、細粒度で正確な監視が運用に不可欠になった。一方、クラウド一般・仮想化・セキュリティのサーベイは多いが、クラウドのインフラ・サービス・アプリケーションを監視するプラットフォーム、技術、ツールを扱う専門サーベイは無い、というのが出発点である。 - 対象は監視全般であり、特定の手法の提案ではない。目標は、動機・性質・課題・既存基盤・未解決課題を 1 つの分類軸で通して眺められるようにすることである。 ## 調査の方法と分類軸 **Figure 1: 調査の方法論(Research methodology)** ![[_attachments/2013__Computer-Networks-__Cloud-monitoring-A-survey/fig01-research-methodology.png]] (Figure 1. 5 段階の進め方。NIST 参照モデルの採用 → 動機軸と(層・抽象度・テストと指標)軸の二軸分類 → 性質・課題・既存研究の分析 → 基盤とサービスの調査 → 未解決課題と今後の方向。) - 文献調査の進め方は [126] の指針に従う。用語と役割の文脈づけには NIST の定義([1][20])を用いる。 - NIST の概念は Table 1 にまとめられている。 | 概念 | 内容 | |---|---| | 本質的特性 | オンデマンドのセルフサービス / 広帯域ネットワークアクセス / 資源のプーリング / 迅速な弾力性 / 従量制サービス | | サービスモデル | IaaS / PaaS / SaaS | | ホスティング | 外部 / 内部 | | 配備モデル | プライベート / コミュニティ / パブリック / ハイブリッド | | 役割 | クラウド監査者 / サービスプロバイダ / サービスキャリア / サービスブローカ / サービスコンシューマ | (Table 1. クラウドコンピューティングの用語と定義 [1,20]。) - 以降、クラウドサービス提供者を「プロバイダ」、利用者を「コンシューマ」と略す。 - クラウドの利点として、経済面では総所有コスト(TCO)の低下と SLA・資源の柔軟性、技術面ではスケーラビリティ・遍在的アクセス・災害復旧を挙げる。課題は、スケーラビリティ・負荷分散・QoS の提供、SLA の保証、大規模かつ連合したインフラの管理、エンドツーエンド性能の根本原因分析である。 **Figure 2: クラウド監視の分類(動機・性質・基本概念・未解決課題・今後の方向)** ![[_attachments/2013__Computer-Networks-__Cloud-monitoring-A-survey/fig02-taxonomy.png]] (Figure 2. 論文全体の分類図。監視の必要性(8 種の運用活動)、基本概念(層・抽象度・テストと指標)、性質、未解決課題と今後の方向を 1 枚に配置している。) ## 監視の動機(第 3 章) クラウド監視は、インフラ制御・管理の道具であると同時に、プラットフォームとアプリケーションの KPI を与える。継続監視は、負荷や性能・QoS の情報をプロバイダとコンシューマの双方に与え、違反の防止・回復の仕組みを可能にする。クラウド監査者の活動もすべて監視に依存する。動機は次の 8 種に分けられる。 - **容量・資源計画**: 需要の実測値は予測不能で変動が大きい。プロバイダは QoS 保証を SLA で約束し、資源と容量の計画を担うので、QoS 保証に関わる全パラメータの推移を監視で追う必要がある。 - **容量・資源管理**: システムの状態を正確に捉える監視がすべての前提である。仮想資源は物理マシン間を随時移動し、物理と仮想の両方の管理が要るため、資源の揮発性と変わりやすいネットワーク条件への対処に監視が要る。重要な公共サービスでは 100% の稼働が期待され、監視自体の耐障害性と信頼性が求められる。 - **データセンター管理**: 監視(ハードウェア・ソフトウェア指標の追跡)とデータ分析(状態の推定)の 2 つの基本作業からなる。どちらも実時間性と数万ノード規模への拡張が要り、省エネルギーが分析の主要な駆動力になる。 - **SLA 管理**: 監視は SLA 準拠の証明、規制対応の監査、ユーザが体感する性能に基づく現実的で動的な SLA・価格モデルの策定に必須である。 - **課金**: 従量制サービスの計測が必要で、IaaS なら VM 数(構成別)、PaaS なら CPU 利用率やタスク完了時間、SaaS なら同時ユーザ数や機能別性能が課金基準になる。課金の粒度が粗い定額制なら監視は単純だが、クラウドサービスブローカが介在する場合は資源提供と請求配賦の戦略のため高度な監視が要る。コンシューマ側も自身の使用量の検証とプロバイダ比較に監視を使う。 - **障害切り分け**: 原因の候補が複数のコンポーネントと層(実・仮想ハード、ホスト OS、ゲスト OS など)に散る。プロバイダは問題の所在を、コンシューマは原因がプロバイダ・ネットワーク・アプリケーション自身のどれかを知るために、網羅的で信頼できる時宜を得た監視が要る。 - **性能管理**: 一部のクラウドノードは他より桁違いに性能が悪くなり得る([38])。コンシューマが体感性能を監視して適応・是正する必要がある(複数クラウドへ配置し、性能に応じて切り替える例)。 - **セキュリティ管理**: クラウド普及の最大の障害の 1 つがセキュリティである。監視は監査可能性(データを国内に留める規制への準拠など)を実現する手段になる。 ## 基本概念(第 4 章) ### 層と抽象度 クラウドは Cloud Security Alliance の整理に従い 7 層でモデル化される([54,41,42])。監視プローブをどの層に置くかが、観測できる現象を直接決める。 | 層 | 対象 | |---|---| | ファシリティ | データセンターなどの物理インフラ | | ネットワーク | クラウド内とクラウド―ユーザ間のリンク・経路 | | ハードウェア | 計算機・ネットワーク機器の物理部品 | | OS | ホスト OS とユーザ側(VM 上)OS | | ミドルウェア | OS とアプリケーションの間。主に SaaS・PaaS | | アプリケーション | ユーザが実行するアプリケーション | | ユーザ | エンドユーザとクラウド外で動くアプリケーション(ブラウザなど) | - これらとは直交して、Du らの仮想マシンのプロファイリング [141] に沿い、クラウド内で見えるものと外から見えるものを分けるシステム全体・ゲスト全体の計測が定義できる。 - クラウドは複雑なので、観測している現象を確実に特定できない。例として、アプリケーションに置いたプローブが測る通信速度にネットワーク転送が含まれるかは、2 つのアプリケーションが同じ物理ホスト上にあるかによるが、その情報はプロバイダが公開しないことが多い。同様に、計算時間は実 CPU と同居する他の VM の負荷に依存し、後者は全く見えない。 - **高水準監視**: ミドルウェア・アプリケーション・ユーザ層で、仮想プラットフォームの状態を対象とする。SaaS ではコンシューマの関心が高い(体感 QoS に直結するため)。 - **低水準監視**: プロバイダが物理インフラの状態を集め、通常コンシューマには公開されない。ハードウェア(CPU・メモリ・温度・電圧など)、OS・ミドルウェア(バグ・脆弱性)、ネットワーク(ファイアウォール・IDS・IPS)、ファシリティ(データセンター室の映像監視・認証)の各層を対象にする。IaaS では両水準が双方の関心事になる。 ### テストと指標 監視テストは計算ベースとネットワークベースに大別される([47])。 - **計算ベース**: サーバスループット(1 秒あたりの要求数)、CPU 速度、1 実行あたりの CPU 時間、CPU 使用率、1 秒あたり/1 実行あたりのメモリページ交換数、ディスク・メモリのスループット、プロセス間メッセージのスループット・遅延、既定タスクの所要時間、応答時間、VM 起動時間、VM 取得・解放時間、実行・アクセス時間、稼働時間。平均・中央値などの統計指標や、時間的特性(安定性・変動・予測可能性)で評価する。プロバイダが実施するか第三者に委ねられ、EC2 と Google App Engine では Hyperic 社が CloudStatus で公開している([48])。 - **ネットワークベース**: 往復遅延(RTT)、ジッタ、スループット、パケット・データ損失、利用可能帯域、容量、トラフィック量など([49–52])。これらを使い、従来型ホスティングとクラウドホスティングを比較する実験研究が多い。 ### クラスタ・グリッド・クラウドの監視の違い - グリッドは資源共有が主眼で、課金基準が単純で資源の抽象化も限られ、監視パラメータと物理資源の状態の関係が単純である。クラウドは多層・多サービスの構造ゆえに抽象度が高く、層・サービス固有の観測量と基盤資源の関係が不透明である。 - クラウドではコンシューマへの抽象インタフェースにより監視の必要が減るように見えるが、実際には必要性がプロバイダ側へ移り、約束した性能の維持と、動的で異種混在の環境での資源最適化に対処する必要が生じる。 - クラスタは、剛直な構造、限られたサービス交渉、資源提供の自動化の低さから、クラウド IaaS の基盤技術に近く、要求はクラウドの部分集合になる。弾力性・適応性・自律性はクラスタやグリッドには当てはまらないか、包括性・拡張性・侵襲性は必須ではない。 - グリッド向けの Ganglia [59]、Nagios [60]、MonaLisa [91]、R-GMA [92]、GridICE [93] などはクラウド向けに手直しされてきたが、高い入れ替わりを想定していない。Zanikolas らのグリッド監視のサーベイ [94] も参照されている。 ## 監視システムの性質と課題(第 5 章) **Figure 3: 監視システムの性質と関連する研究課題** ![[_attachments/2013__Computer-Networks-__Cloud-monitoring-A-survey/fig03-properties-issues.png]] (Figure 3. 8 つの性質群と、それぞれに付随する研究課題の対応。課題が複数の性質にまたがる場合があり、その解決は複数の利益につながる。) 分散監視システムが備えるべき性質が、クラウドでは新しい課題を生む。性質ごとに定義・課題・文献の対応を述べる。 - **スケーラビリティ**(多数のプローブに対応できる)。仮想化により 1 つの物理資源上に多数の仮想資源が載るため重要度が増す。監視データの収集・転送・分析を、クラウドの通常運用を損なわずに行う必要がある。多くの研究は、監視データとイベントを集約(複数指標を合成指標にまとめる)とフィルタリング(不要データを流さない)で減らしてから制御側へ伝える構成を採る。集約の例は、機械学習による高水準性能指標の抽出 [24]、層をまたぐ指標とカルマンフィルタによる予測値の抽出 [58]、OS 層指標の線形結合 [56] である。エージェント配置・相互接続の効率的なアルゴリズム [57]、内容ベースルーティングと複合イベント処理 [37]、データ源近くの軽量分析や適応的サンプリング・時間ベースのフィルタリング [44] も提案されている。 - **弾力性**(仮想資源の生成・破棄に追随して正しく監視できる)。スケーラビリティを含意し、資源プールのオンラインな拡縮対応を加える。仮想資源の増減、監視要件の変動、テナントの出入りが 3 つの駆動要因である。Ganglia [59] や Nagios [60] は緩やかに変わる物理インフラ向けで、そのままでは適さない。拡張として、仮想化資源の監視対応と、パブリッシュ・サブスクライブによる条件契機のプッシュ報告が主流である。Lattice [55] はハイパーバイザの VM 一覧を定期取得してプローブを追加・削除し、Carvalho と Granville [61] は Nagios にアクティブチェック(プル)とパッシブチェック(プッシュ)で仮想化を認識させ、RESTful なイベントブローカ [25] はプッシュ・プルの二重モデルを採る。Monalytics [44] は選挙ベースのブローカ階層を持ち、通信トポロジと計算の種類を資源状態に応じて動的に変更する。 - **適応性**(負荷に応じて自身が侵襲的にならない)。アクティブ計測の負荷や監視データの収集・処理・保存・管理自体が資源を消費するので、精度(予測可能な遅延など)と侵襲性のトレードオフを保ちつつ素早く負荷変動に応じる必要がある。Park ら [31] はマルコフ連鎖で資源状態を予測し、プッシュ間隔を適応的に設定する。Monalytics は監視トポロジを動的計算通信グラフ(DCG)でモデル化し、負荷に応じてエージェントを実時間で再構成する。Wang ら [33] は動的トポロジと従来型を、time-to-insight と管理コスト(ハードウェアと関連ソフトウェア管理の資本コスト)で比較し、柔軟かつ性能・費用対効果が高いと示した。 - **適時性**(検知したイベントを使う時点までに利用できる)。事象発生から通知までの時間は、サンプリング・分析・通信の遅延に分解でき、それぞれ課題がある。短い間隔ほど捕捉は速いが、精度とのトレードオフや資源制約がある。複合イベントは分析側でも他パラメータの到着待ちが要り、通信遅延はリモート発の複合イベントで効いてくる。Park ら [31] は揮発性の高い(モバイル)資源の挙動モデルからサンプリング間隔を予測し、Wang ら [33] はデータ近傍での分析と通信・分析トポロジの適応で遅延を抑える。評価指標として **Time to Insight**(「各ノードで 1 つの監視サンプル(関心のあるイベント)が収集されてから、そのすべてのサンプルの分析が完了するまでの遅延」)を定義した。 - **自律性**(予測不能な変化に、人手を介さず自己管理で反応する)。オンデマンドのセルフサービスと迅速な弾力性を持つクラウドで、変化・障害・性能劣化に人手なく反応するため、多数のセンサ(監視データ)から多数のアクチュエータへ制御を返す制御ループの実装が要る。状況認識の分析能力と、イベントに対する方針の定義も必要になる。Iqbal ら [63] は多層 Web アプリのボトルネックと過剰プロビジョニングの自動検知・解消法を、最大応答時間の要件に基づいて提案した。Ayad と Dippel [65] は VM の可用性を常時確認し、障害時に自動復旧するエージェント型監視を示した。DeSVi [64] は低水準資源指標(ホストの稼働・停止時間)をユーザ定義の SLA(サービス可用性)へ写像し、SLA 違反を予測する。 - **包括性・拡張性・侵襲性**。包括的とは、物理・仮想資源、複数種の監視データ、複数テナントを扱えること。拡張的とは、プラグインなどで容易に対応を広げられること。侵襲的とは、導入にクラウドの大きな改変が要ること。共通標準が普及していないため、コンシューマは 1 つの監視 API を使え、プロバイダは 1 つの基盤を保守できるのが利点である。従来の非クラウド専用の監視系は拡張性と低侵襲性を備えており、クラウドへの拡張でも保たれた [59,60,26,66]。課題は、異種のアーキテクチャ・資源に対応しつつテナント分離を保つこと、動的で異種混在の構成要素を網羅した状態で障害切り分けを行うことである。分離は Hasselmeyer と d'Heureuse [23] が初めて明示的に扱い、監視情報を同一のストリーム管理系に通して意図した受け手だけへ見せ、アダプタで技術差を抽象化した。VMDriver [71] は VM レベルのイベントを傍受し、ゲスト OS の違いを隠す。障害切り分けの実験研究は EC2 を対象とするものが多く、Hill と Humphrey [67] は科学アプリの性能の原因を特定できなかった。Wang と Ng [68] は、データセンターのネットワークが低負荷でも、仮想化が大きなスループットの不安定さと異常なジッタを生み、原因がプロセッサ共有の仕組みだと特定した。Schad ら [39] は層ごとの性能が時間・VM インスタンスで大きく変動することを見出した。Mei ら [47] は同居 VM の影響を調べ、アイドルなインスタンスがあると他 VM が低頻度・短時間でしかスケジューリングされないこと、VM の新規作成による性能劣化が約 100 秒以内であること、CPU 集約タスクの同居で性能が劣化することを示した。 - **耐障害性・信頼性・可用性**。監視が課金、SLA 検証、資源管理を支えるため、監視系自体が耐障害でなければならない。仮想化で監視対象が移動すると従来の監視ロジックが無効化される。Park ら [30,31] はモバイルクラウドの揮発性が監視頻度の選択に効くと論じた。Ayad と Dippel [65] は耐障害性が仮想化技術に依存することを扱った。AWS の性能を測った研究では、監視プローブ自体が使えない期間に苦労した [72]。Romano ら [37] の QoS-MONaaS は「サービスとしての QoS 監視」で、KPI と違反時アラートを形式的な SLA として記述させる。Padhy ら [32] は監視系へのビザンチン障害を想定し、パブリッシュ・サブスクライブに冗長ブローカとビザンチン耐性アルゴリズム [74] を組み合わせた。 - **精度**(計測値が真値にできる限り近い)。障害切り分けで不正確だと原因を誤り、SLA 違反ペナルティで金銭的損失になる。課題は 2 点ある。1 点目は計測用のワークロードで、アクティブ計測には適切な負荷(HTTP GET を特定の統計分布で到着させるなど)が要る。実ワークロードの特性解析と再現、どのテストをどう実施するかなどの研究があり、EC2 で科学・高性能計算を支えられるかを調べる研究が多い([62,72,75,76,67,77–79])。指標は金銭コスト、ジョブ実行時間、VM 取得・解放時間、ディスク・メモリのスループット、CPU 速度、メッセージのスループット・遅延など多様である。Binnig ら [83] は TPC-H・TPC-C・TPC-W などの既存ベンチマークが、スケーラビリティ・ピーク負荷・耐障害性を測れないと指摘した。2 点目は仮想化による計測誤差で、時間関連の計測が CPU・NIC・バッファの共有で損なわれる。RTT [87–89]、ジッタ、容量、利用可能帯域、トポロジ [87]、自動チューニングアプリの性能 [90] が調べられた。VM 切り替え待ちのパケットがキューに残ると時刻付与が不正確になる。RTT の正確な計測は低ネットワーク・低計算負荷でのみ可能で、遅延の大半は送信側で生じ、カーネル空間のタイムスタンプは高負荷で不十分であり、物理 NIC が見るタイムスタンプが必要だと結論された [89]。トポロジは、仮想化で 1 つの物理トポロジ上に複数の仮想トポロジができ、traceroute では真の物理トポロジを発見できないと示された [87]。Youseff ら [90] は、ATLAS の自動チューニングと Xen の準仮想化の組み合わせで、ネイティブと同等の性能とほぼ同じメモリ階層プロファイルが得られると示した。 ## プラットフォームとサービス(第 6 章) 商用、オープンソース、クラウド性能・信頼性の評価サービスを Table 2 に示す。 | 商用プラットフォーム | オープンソースプラットフォーム | サービス | |---|---|---| | CloudWatch [95] | Nagios [104] | CloudSleuth [112] | | AzureWatch [137] | OpenNebula [105] | CloudHarmony [113] | | CloudKick [96] | CloudStack ZenPack [108] | Cloudstone [114] | | CloudStatus [48] | Nimbus [110] | Cloud CMP [116] | | Nimsoft [97] | PCMONS [111] | CloudClimate [118] | | Monitis [99] | DARGOS [128] | Cloudyn [119] | | LogicMonitor [100] | Hyperic-HQ [138] | Up.time [120] | | Aneka [101] | Sensu [139] | Cloudfloor [121] | | GroundWork [129] | | CloudCruiser [122] | | | | Boundary [136] | | | | New Relic [140] | (Table 2. クラウド監視のプラットフォームとサービス。) ### 商用プラットフォーム 商用は高水準・低水準の両監視を実装するとされる。 - **CloudWatch**: Amazon は低水準の監視系や収集・分析の方法を公開しない。EC2 などの VM 関連情報を 2 週間保存し、グラフ・統計・しきい値・アラームを構成でき、SNS や Autoscaling を契機にできる。課金は監視対象と独立で、基本機能は無料(5 分間隔)、高度な機能と 1 分間隔は有料へ移行中とされる。適時性・拡張性・弾力性が中心で、層横断の監視は限られる。 - **AzureWatch**: Azure SDK 上に作られた第三者サービス。インスタンス、データベース、ストレージ、Web サイトなどの主要指標を集約し、ユーザ定義のカウンタも扱う。スケーラビリティ・適応性・自律性・拡張性を掲げる。 - **CloudKick**: RackSpace が買収したマルチクラウド管理基盤。高水準・低水準の多数の指標とカスタムプラグイン、リアルタイム可視化とメール・SMS の警報を持つ。スケーラビリティと適応性が中心。 - **CloudStatus**: Hyperic-HQ 上に構築された、EC2 と Google App Engine を対象とする初期の独立監視サービスの 1 つ。アプリの性能監視、性能変化の根本原因分析の方法論、リアルタイムと週次の傾向を提供する。適時性が売りである。 - **Nimsoft**: 単一ビューの統合ダッシュボードで、プライベート・パブリックのクラウドとデータセンターを監視する。SLA 監視の実績がある。スケーラビリティと包括性が中心である。 - **Monitis**: 資源に置いたエージェントで性能を通知し、Amazon 系を中心に、HTTP REST の公開 API で拡張できる。包括性が中心である。 - **LogicMonitor**: 弾力的な多層アプローチで、新しい資源を自動発見して監視する。Xen、vSphere、ESX、EC2、Eucalyptus に対応する。スケーラビリティ・弾力性・包括性が中心である。 - **Aneka**: クラウドアプリケーションの開発・配備・管理のフレームワーク。拡張可能な SOA のサービス群のひとつに監視を含む。スケーラビリティと弾力性に注力する。 - **GroundWork**: Nagios を基盤に、数千のプラグインを使ってあらゆる種類の機器・仮想実体を監視できる。プロバイダ以外の視点で監視することで、共通指標の取得、サービスレベルの検証、複数ベンダー戦略が楽になる。包括性が中心である。 ### オープンソースプラットフォーム - **Nagios**: 企業級のオープンソース監視基盤で、仮想インスタンスとストレージサービスの監視に拡張され、Eucalyptus と OpenStack の監視に使われる。拡張性が中心である。 - **OpenNebula**: Information Manager が、ノードに置いたプローブから SSH 経由で物理ノードの状態を集める。スケーラビリティと適応性が中心である。 - **CloudStack ZenPack**: Zenoss 拡張で、CloudStack の仮想・物理機器を管理し、ゾーン・ポッド・クラスタ・ホスト横断で集約したメモリ・CPU・ストレージ・ネットワークの指標を与える。適時性が中心である。 - **Nimbus**: 科学利用向けの IaaS。Context Broker(プル型)は大規模仮想クラスタの起動を自動化・再現可能にし、cloudinit.d(プッシュ型)は相互依存する VM 群の起動・設定・監視・修復を行う。自律性が中心である。 - **PCMONS**(Private Cloud MONitoring System): 7 つのモジュール(ノード情報収集、クラスタデータ統合、監視データ統合、VM 監視、設定生成、監視ツールサーバ、ユーザインタフェース)からなり、初版は Eucalyptus と Nagios に対応する。拡張性が中心である。 **Figure 4: PCMONS のアーキテクチャ** ![[_attachments/2013__Computer-Networks-__Cloud-monitoring-A-survey/fig04-pcmons-architecture.png]] (Figure 4. PCMONS のアーキテクチャ [111]。ビュー層(事業管理者・ネットワーク管理者)、統合層(クラスタデータ統合・ノード情報収集・設定生成)、インフラ層(Xen、OpenNebula、KVM、Eucalyptus など)の 3 層構成。) - **DARGOS**: プッシュとプルの混成で資源監視情報を配布する分散監視アーキテクチャ。ノード監視エージェント(NMA)が資源使用統計を収集し、ノード監督エージェント(NSA)が購読して局所にキャッシュする。低オーバーヘッドで、拡張性・適応性・侵襲性の低さが中心である。 **Figure 5: DARGOS のアーキテクチャ** ![[_attachments/2013__Computer-Networks-__Cloud-monitoring-A-survey/fig05-dargos-architecture.png]] (Figure 5. DARGOS のアーキテクチャ [128]。クラウドコンピュートノード上の NMA、クラウドコントローラと REST 監視コンソール上の NSA、ユーザ・管理者向けの Cloud API と DARGOS REST API を配置している。) - **Hyperic-HQ**: CloudStatus のオープンソースの中核で、Java エージェントが Unix・Linux・Windows・VMware・AWS などに対応する。スケーラビリティと包括性が中心である。 - **Sensu**: 従来型の限界を越えるため、RabbitMQ(AMQP)上に監視サーバ・エージェント・ダッシュボードを載せ、REST の JSON API でデータを取得する。拡張性と弾力性が中心である。 ### 性能・信頼性の評価サービス - **CloudSleuth**: 地理的に分散した拠点(Gomez Performance Network)から、動的コンテンツを模したアプリを各クラウドに配置して応答時間を測り、ユーザ層の信頼性と適時性を可視化する。 - **CloudHarmony**: パブリッククラウドの広範なベンチマーク(OS 層の CPU・ディスク・メモリ I/O、Unixbench・IOzone などのアプリ層、ユーザ層の RTT・スループット、クラウド間のネットワーク)と、ping・TCP ポート検査による長期稼働監視。包括性と適時性が中心である。 - **Cloudstone**: UC Berkeley の再現性と公平性のあるベンチマーク。Web 2.0 アプリと、マルコフ連鎖のワークロード生成器 Faban で試験し、指標は「ユーザあたり月額ドル」である。精度と可用性が中心である。 - **Cloud CMP**: Duke 大学と Microsoft Research による、コンピューティング・ストレージ・クラウド内ネットワーク・クラウドからユーザへのネットワークの費用効果比較。精度と可用性が中心である。 - **CloudClimate**: 異なるプロバイダ・拠点のクラウドに置いた IaaS 上のアプリが相互に負荷試験と HTTP・ping を行い、1 か月スケールでグラフ化する。比較から異常の根本原因が仮想サーバ・クラウドインフラ・エンドツーエンド経路のどこにあるかを推定できる。可用性・適時性・耐障害性が中心である。 - その他の Cloudyn・Up.time・Cloudfloor・CloudCruiser・Boundary・New Relic は、いずれもエージェント型で、主に可用性・適時性・精度・耐障害性の情報を与える。 ### 全体像 調べた基盤は、12 の性質のうち一部に集中している。以下の 3 表は、原論文の図表(チェックマーク行列)を性質名で書き起こしたものである。 | 商用プラットフォーム | 主要な性質 | |---|---| | CloudWatch [95] | 弾力性、適時性、拡張性 | | AzureWatch [137] | スケーラビリティ、適応性、自律性、拡張性 | | CloudKick [96] | スケーラビリティ、適応性 | | CloudStatus [48] | 適時性 | | Nimsoft [97] | スケーラビリティ、包括性 | | Monitis [99] | 包括性 | | LogicMonitor [100] | スケーラビリティ、弾力性、包括性 | | Aneka [101] | スケーラビリティ、弾力性 | | GroundWork [129] | 包括性 | (Table 3. 商用クラウド監視プラットフォームの主要な性質。侵襲性・耐障害性・信頼性・可用性・精度の列には 1 件もチェックが無い。) | オープンソースプラットフォーム | 主要な性質 | |---|---| | Nagios [104] | 拡張性 | | OpenNebula [105] | スケーラビリティ、適応性 | | CloudStack ZenPack [109] | 適時性 | | Nimbus [110] | 自律性 | | PCMONS [111] | 拡張性 | | DARGOS [128] | 適応性、拡張性、侵襲性 | | Hyperic-HQ [138] | スケーラビリティ、包括性 | | Sensu [139] | 弾力性、拡張性 | (Table 4. オープンソースクラウド監視プラットフォームの主要な性質。耐障害性・信頼性・可用性・精度の列にはチェックが無い。) | 評価サービス | 評価している性質 | |---|---| | CloudSleuth [112] | 適時性、信頼性 | | CloudHarmony [113] | 適時性、包括性 | | Cloudstone [114] | 可用性、精度 | | Cloud CMP [116] | 可用性、精度 | | CloudClimate [118] | 適時性、耐障害性、可用性 | | Cloudyn [119]、Up.time [120]、Cloudfloor [121]、CloudCruiser [122]、Boundary [136]、New Relic [140] | 適時性、耐障害性、可用性、精度 | (Table 5. クラウドの性能・信頼性を監視するサービスが評価する性質。) - 侵襲性・耐障害性・信頼性・可用性・精度は、商用・オープンソースの監視基盤のほとんどで明示されていない(Tables 3・4)。監視対象のクラウドに対してなら、これらをむしろ評価サービスの多くが測っている(Table 5)。クラウドサービスで重視される性質が、監視基盤自体では中心に置かれていない、という指摘である。 - 指標は膨大で、大半が新指標の定義を許す。例として CloudKick はエージェント(内側)とリモートチェック(外側)から、メモリ・CPU・ディスク・ネットワークの多数の指標を集める。 ## 未解決課題と今後の方向(第 7 章) 有効性と効率の 2 群に分けて論じる。 - **有効性**: (i) 異なるプローブの情報を効果的に要約・フィルタ・相関する独自のアルゴリズム、(ii) 複雑なクラウド構造から原因の糸口を見つける根本原因分析、(iii) 仮想化環境での精度の高い計測、が要る。監視系自体の耐障害性には貢献があるが、信頼性にはさらなる努力が要る。適時性は [33] でしか明示的に評価されておらず、Time to Insight を今後の比較に使うべきで、関連パラメータのモデル化が課題である。可用性も、見逃しイベントや未応答クエリの割合の評価や、可用性水準を保証する設計制約は知る限り無い。 - **効率**: 主にデータ管理。収集・フィルタ・集約・相関・分割・保存を、時間・計算・通信の厳しい制約で行える、より効率的なアルゴリズムが要る。 今後の研究方向として、次の 7.3〜7.9 の 7 つを挙げる。 - **新しい監視技術・ツール**(7.3): きめ細かな計測と全体の概観を両立し、性能負荷を追加せず、性能制御の方法論と統合されること。 - **層横断監視**(7.4): 強い層構造のため、コンシューマは下位層の指標に、プロバイダは上位層の指標にアクセスできず、限られた視野で判断している。克服は技術・プライバシー・運営の面で難しい。 - **ドメイン横断監視**(7.5): 連合クラウド・ハイブリッドクラウド・マルチテナントの監視。標準化は初期段階で、異種性とセキュリティ上の制約が加わる。性能を監視できることがセキュリティ上のリスク(攻撃の道具)として扱われてきたため、包括的な監視はまだ扱われていない。 - **クラウド型の新しいネットワーク構成の監視**(7.6): OpenStack と Quantum、OpenFlow、SDN、情報指向ネットワーキングなどを使うクラウドベースのネットワーキング。 - **クラウド向けワークロード生成器**(7.7): 実・合成ワークロードの研究はあるが、クラウド専用の生成器が残る課題である。 - **省エネルギー・低コストの監視**(7.8): 精度・網羅性・信頼性の要件を満たしながら消費エネルギーとコストを最小化する。 - **標準と共通テストベッド・慣行**(7.9): 手順・形式・指標の標準が乏しい。Open Cirrus [125] のような公開テストベッドで公平な比較を可能にすべきである。 ## 新規性 - 既存のクラウドサーベイが一般論・仮想化・セキュリティに偏る中、クラウドの監視だけを主題にした点が新規である(著者の主張)。 - 監視を、動機(運用活動)の軸と、層・抽象度・テストと指標の軸で二軸に分類し、その上で性質(12 種)と課題と既存研究を 1 つの表で対応づけた。商用・オープンソース・評価サービスの各基盤を、その性質の語彙に写した点が、製品カタログの列挙と異なる。 - 「監視基盤が自身の耐障害性・信頼性・可用性・精度を語らない一方、評価サービスは監視対象のそれらを測る」という非対称の指摘は、著者が「最も興味深い」と述べる観察で、性質の語彙で基盤と評価サービスを並べたことで見えている。 ## 強み / 弱点・課題 - 強み: 動機・性質・課題・製品・展望が 1 つの分類で通っており、各製品が性質のどれに重点を置くかを表で引ける。既存研究の引用が、性質ごとの課題に紐づく形で具体的な数値・現象(遅延の原因、100 秒以内の劣化など)まで示される。 - 弱点・課題: 製品の性質の判定は、公開資料の宣伝上の重点に基づくとされ(「主な特徴」の記述)、実測による比較ではない。プラットフォームの記述は 2013 年時点のもので、課金体系などは移行中と記されている。ログ・トレース・障害診断の自動化(異常検知や根本原因分析の手法)は、課題として挙げるだけで、手法の比較にまでは踏み込まない。 ## 関連 - 概念: [[クラウドモニタリング]] / [[分散モニタリング]] / [[クラウドコンピューティング]] / [[グリッドコンピューティング]] - エンティティ: [[Giuseppe Aceto]] / [[Alessio Botta]] / [[Walter de Donato]] / [[Antonio Pescapè]] / [[University of Napoli Federico II]] / [[Nagios]] / [[Ganglia]] / [[Amazon EC2]] / [[National Institute of Standards and Technology]] - 隣接ソース: [[@2013__TC__Enhanced Monitoring-as-a-Service for Effective Cloud Management]](MaaS。本論文の適応性・拡張性・弾力性の議論の続き)/ [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]](本論文の [38])/ [[@2008__SIGCOMM__A Break in the Clouds - Towards a Cloud Definition]]