ネットワークアプリケーションの依存関係の自動抽出と可視化に関する論文 - ゆううきメモ

# ネットワークアプリケーションの依存関係の自動抽出と可視化に関する論文 - ゆううきメモ Created: November 5, 2020 12:56 PM URL: https://memo.yuuk.io/entry/2019/proceeding-macroscope "Macroscope: End-Point Approach to Networked Application [Dependency](http://d.hatena.ne.jp/keyword/Dependency) Discovery" という論文を読んだ内容をここでまとめておく。 [Popa, L and Chun, B-G and Stoica, I and Chandrashekar, J and Taft, N, “Macroscope: End-point approach to networked application dependency discovery”, 5th International Conference on Emerging Networking Experiments and Technologies(CoNEXT), 229-240, 2009.](http://conferences.sigcomm.org/co-next/2009/papers/Popa.pdf) [ACM](http://d.hatena.ne.jp/keyword/ACM) CoNEXTはCORE Rankings(2018)基準でAランクのトップカンファレンスである。 # 読んだ動機以下の記事にあるように、サーバにエージェントをインストールするだけで、[TCP](http://d.hatena.ne.jp/keyword/TCP)/[UDP](http://d.hatena.ne.jp/keyword/UDP)層でデータセンター内/データセンター間のサーバ(or ユーザーランドアプリケーション)同士のネットワーク依存関係を過去に渡って自動的に発見できないかを考えている。自分が調査した限りでは、2009年の論文で古くはあるもの、このMacroscopeが自分のアプローチに最も近い先行研究であるため、細部まで読み込んだ。 # 概要と感想本論文では、**分散システムの依存関係を[TCP](http://d.hatena.ne.jp/keyword/TCP)/[UDP](http://d.hatena.ne.jp/keyword/UDP)のコネクションテーブルとパケットトレースの結合により自動抽出する、実践的で高精度な手法**を提案している。エンドホスト上のコネクションテーブルとパケットトレースを組み合わせて依存の検出精度を高めている着想がおもしろい。これまで自分はどちらか一方のみを利用する前提で捉えていたこともあり、この着想は参考になった。アプリケーションの例として、MS [Outlook](http://d.hatena.ne.jp/keyword/Outlook)が例に出されていたり、評価環境のホストが[Windows](http://d.hatena.ne.jp/keyword/Windows)ラップトップであることから、社内システム管理者が、オフィスネットワーク内の各クライアントPCと[LDAP](http://d.hatena.ne.jp/keyword/LDAP)などの提供サービスの依存関係を把握するという前提があると解釈している。これをデータセンター内のサーバの依存関係だと思い込んで読むと、細部の記述に違和感を感じてしまう。とはいっても、データセンター環境を対象としても十分応用できる手法であるように思う。 # Introduction ## 社会の背景今日の企業ネットワークとデータセンターにおいては、数多くのネットワークアプリケーションが相互に依存し、複雑化している。企業のITコスト70%までは、メンテナンスとコンフィグレーションコストであると文献[15]により推測されている。 ## 問題意識アプリケーションとサービスの間の依存関係の発見（または[マッピング](http://d.hatena.ne.jp/keyword/%A5%DE%A5%C3%A5%D4%A5%F3%A5%B0)）は、以前から重要なタスクとして認識されている。これらの仕事の多くにおいて、依存関係の発見は、単にネットワークレベルのパケットトレースのデータに頼っている。 ## 先行手法例えば、[Sherlock](http://d.hatena.ne.jp/keyword/Sherlock)[5]は、異なるサービス間のパケットの時間相関を利用する。また、Orion[9]はフローペアの遅延分散のスパイクを利用する。パケットトレースは、各ホストに影響をあたえずに収集できる利点がある。しかし、アプリケーションとサービスの依存を抽出するという観点では、次のような制約がある。 ## 先行手法の課題まず、これらのパケットトレースによる手法はかなり正確さに欠けうることが挙げられる。独立したサービス間の時間相関は、[偽陽性](http://d.hatena.ne.jp/keyword/%B5%B6%CD%DB%C0%AD)につながるような因果関係の幻想をつくりうる。また、バックグラウンドの[トラフィック](http://d.hatena.ne.jp/keyword/%A5%C8%A5%E9%A5%D5%A5%A3%A5%C3%A5%AF)がネットワークパケットのタイミングをかきみだしてしまうか、一時的にパケットをどのように観測するかで大きな変化がある場合、[偽陰性](http://d.hatena.ne.jp/keyword/%B5%B6%B1%A2%C0%AD)が起こりうる。次に、パケットトレースのみでは、通信パターンが非常に動的または頻繁であるときに依存関係を明らかにできないことが制約としてある。これは依存関係の抽出手法が多数のサンプルを必要とするからである。三つ目の制約は、パケットトレースのみを利用するとき、依存関係を正しく抽出するために人間の介入が必要となることである。これは、抽出された依存関係の精度が人間のオペレーターに完全に依存することになる。 ## 提案手法そこで、この論文では、アプリケーションの依存関係を自動で抽出するアプローチを提案する。先行手法と対比すると、提案するアプローチは、特定のアプリケーションについての情報をエンドホストで収集し、ネットワークパケット追跡と結合する。さらに、アプリケーションの依存関係に到達するために、複数のエンドホストからの情報を関連付ける。 ## システム構成 Macroscopeは、ネットワークレベルとアプリケーションレベルの情報を利用し、ネットワークアプリケーションの依存関係を自動で抽出するシステムである。 ![[%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A2%E3%83%95%E3%82%9A%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E4%BE%9D%E5%AD%98%E9%96%A2%E4%BF%82%E3%81%AE%E8%87%AA%E5%8B%95%E6%8A%BD%E5%87%BA%E3%81%A8%E5%8F%AF%E8%A6%96%E5%8C%96%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%AB%96%E6%96%87%20-%20%E3%82%86%E3%81%86%E3%81%86%E3%81%8D%E3%83%A1%E3%83%A2%20a5f249c3ce234fd2a95da0dc902c2329 s_5DB413D3A59696DF8660A12E60440F604893D25E410FA08ED8AB7D1249394610_1556004017575_file.jpeg]] Macroscopeは、Tracers、Collector、Analyzerという3つの[コンポーネント](http://d.hatena.ne.jp/keyword/%A5%B3%A5%F3%A5%DD%A1%BC%A5%CD%A5%F3%A5%C8)により構成される。 Tracerは、各エンドホストで動作し、定期的に[TCP](http://d.hatena.ne.jp/keyword/TCP)/[UDP](http://d.hatena.ne.jp/keyword/UDP)コネクションテーブルをサンプリングしネットワークレベルのパケットトレースと結合することにより、アプリケーションレベルのプロセス情報をログ収集する。その後、これらの処理済みのトレース結果を中央のCollectorへ転送する。 Analyzerはエンドホストの母集団全体のトレースを相関させて、最終的に様々な属性の依存関係の抽出する。 ## 提案手法の意義 1. アプリケーションによって使用されるすべての主要サービスを列挙することによって障害診断を支援可能。 2. 依存関係により、ネットワークオペレータは、障害影響を理解し、効用を最大化するためのリソースを配置可能。 3. アプリケーションの一時的な依存関係を学習することは、オペレータがサービスを再開するための正しい順序を決定するのを助けることが可能。 4. アプリケーションの正しい依存関係を知ることにより、アプリケーションまたはサービスの異常を検出可能。 ## 提案手法の貢献 - サービスレベルの依存関係を特定可能。複数の粒度レベルについて、アプリケーションとサービスの依存関係グラフについてアプリケーション-サービス依存グラフを構築する。 - 53の企業のエンドホストで収集したトレース結果をもって提案手法を評価した。Macroscpeはパケットトレースのみ利用する最新の手法(Orion[9])と比較し、大幅な差をつけて優位となった。これは、アプリケーションレベルの情報を持ち込んだことによる成果である。 - アプリケーション-サービスの関係のプロファイルにより、150を超えるアプリケーションで探索的な評価を実行する。像とねずみの現象や驚くほど多くのシングルサービスアプリケーションなどの興味深い発見を明らかにする。最後に、これらの提案手法の特性を活用するサービス管理アプリケーション(障害の局所化、負荷分散/[レプリケーション](http://d.hatena.ne.jp/keyword/%A5%EC%A5%D7%A5%EA%A5%B1%A1%BC%A5%B7%A5%E7%A5%F3)/キャパシティ計画、[マルウェア](http://d.hatena.ne.jp/keyword/%A5%DE%A5%EB%A5%A6%A5%A7%A5%A2)検出)について説明する。 ## Macroscope Approach ### 用語定義 - アプリケーション(*application*, *app*): 実行可能なアプリケーション - アプリケーション[インスタンス](http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%B9%A5%BF%A5%F3%A5%B9)(*application instance*): 特定のエンドホストで動作するアプリケーション。(app, PID, IP) のタプルで表現される。 - PID: プロセス識別子 - サービス[インスタンス](http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%B9%A5%BF%A5%F3%A5%B9)(*service instance*): (IP’, protocol, port)のタプルで表現される。 ### Multilevel Dependencies static dependenciesよりもローレベルの粒度をもつ関係性もよく利用される。そのために、アプリケーションとサービス間の[寛解](http://d.hatena.ne.jp/keyword/%B4%B2%B2%F2)性の粒度レベルを次のように定義する。 1. *app → (IP’,protocol,port)* : アプリケーションにより利用される独立したサービス[インスタンス](http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%B9%A5%BF%A5%F3%A5%B9) 2. *(app,PID,IP)→ (protocol,port)* : 特定のアプリケーション[インスタンス](http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%B9%A5%BF%A5%F3%A5%B9)により利用される汎用サービス 3. *(app,PID,IP) → (IP’,protocol,port)* : 特定のアプリケーション[インスタンス](http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%B9%A5%BF%A5%F3%A5%B9)により利用されるサービス ![[%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A2%E3%83%95%E3%82%9A%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E4%BE%9D%E5%AD%98%E9%96%A2%E4%BF%82%E3%81%AE%E8%87%AA%E5%8B%95%E6%8A%BD%E5%87%BA%E3%81%A8%E5%8F%AF%E8%A6%96%E5%8C%96%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%AB%96%E6%96%87 - %E3%82%86%E3%81%86%E3%81%86%E3%81%8D%E3%83%A1%E3%83%A2/s_5DB413D3A59696DF8660A12E60440F604893D25E410FA08ED8AB7D1249394610_1556071019299_Screenshot2019-04-2410.56.32.png]] 依存関係グラフにおいて、各依存は利用頻度もしくは[トラフィック](http://d.hatena.ne.jp/keyword/%A5%C8%A5%E9%A5%D5%A5%A3%A5%C3%A5%AF)量のような**重み**と関連付けられる**。** **因果順序** を次のように定義する。 “appの依存Aが依存Bよりも前に頻繁にアクセスされ、AとBのアクセスが短時間のタイムウィンドウW以内の発生するとき、依存Bよりもappの依存Aが因果的に依存Bよりも前に並べられる。” MacroscpeはOrion[9]と異なり、フローの方向を常に考慮する。 ### End-point Tracing vs Network Tracing エンドポイントトレーシングの利点は、(1) 完全に自動であることと (2) より精度が高いということにある。反面、エンドホストでの計測とそれらがもたらすオーバーヘッドというコストが発生するが、CPUやメモリ使用量といった統計値を収集するわけではないので、マシンが低速になることに気づくユーザーはいない。精度の改善については、先行手法であるOrion[9]や[Sherlock](http://d.hatena.ne.jp/keyword/Sherlock)[5]は、完全な依存関係グラフの部分グラフを検出のみとなり、しかも、タイムウィンドウ内での同時発生に頼ることから、かなりノイズがある。対象的に、提案手法は、同一アプリケーションの接続を識別できることから、より精度が高くなる。 MacroScopeは[偽陽性](http://d.hatena.ne.jp/keyword/%B5%B6%CD%DB%C0%AD)率も削減する。Orionでは、(app) → (A → B)の依存と(app’) → (X → B)の依存があるとき正解シードとしてappがBに依存することを手動で設定するため、appがXに依存すると誤判定してしまう。[*1](https://memo.yuuk.io/entry/2019/proceeding-macroscope) ## Macroscope ### System Architecture Tracerは、MS [Windows XP](http://d.hatena.ne.jp/keyword/Windows%20XP)が動作するラップトップ向けに実装している。 Tracerは、[TCP](http://d.hatena.ne.jp/keyword/TCP)と[UDP](http://d.hatena.ne.jp/keyword/UDP)の接続テーブルをサンプル取得し、ファイルに追加する。サンプルはサンプリング時刻とアプリケーション名、プロセスID、(protocol, [ports](http://d.hatena.ne.jp/keyword/ports))などのアプリケーションレベルの情報を含む。 Tracerは5秒ごとに、GetExtendedTcpTableとGetExtendedUdpTableコールを発行する。 Tracerは[WinPcap](http://d.hatena.ne.jp/keyword/WinPcap)を利用しパケットレベルのトレースを取得する。実装ではエンドホストでパケットキャプチャをしているが、パケットトレーシングの手段は他にもあり、組織ネットワーク内にあるネットワークモニタを利用してもよい。 Collectorは、[Bro](https://www.zeek.org/)[*2](https://memo.yuuk.io/entry/2019/proceeding-macroscope)を利用しパケットトレースからフロー([TCP](http://d.hatena.ne.jp/keyword/TCP)/[UDP](http://d.hatena.ne.jp/keyword/UDP)セッション)を構築し、[XML](http://d.hatena.ne.jp/keyword/XML)の接続テーブルと結合する。 Analyzerは、依存関係の抽出、依存関係の問い合わせ、依存関係の可視化のためのツールセット群により構成されており、[Python](http://d.hatena.ne.jp/keyword/Python)で実装されている。 4つの粒度レベルに応じてstatic [dependency](http://d.hatena.ne.jp/keyword/dependency)を可視化でき、利用頻度や[トラフィック](http://d.hatena.ne.jp/keyword/%A5%C8%A5%E9%A5%D5%A5%A3%A5%C3%A5%AF)量による依存の重み付けもできる。サンプリング頻度を増加させると、より精度を高められるが、エンドホストのリソース消費も高めてしまう。5秒間隔であれば、オーバーヘッドは無視できるが、サンプリングアプローチにはいくつか注意すべき点がある。まず、非常に短命なフローを見逃してしまうこと。次に、プロセスのフォークやローカルのプロキシへのコネクションの委譲などにより、実際のアプリケーションの情報を隠してしまう可能性があること。 ### Algorithm to Identify Static Dependencies [アルゴリズム](http://d.hatena.ne.jp/keyword/%A5%A2%A5%EB%A5%B4%A5%EA%A5%BA%A5%E0)の入力は、(PID,アプリケーション[インスタンス](http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%B9%A5%BF%A5%F3%A5%B9)のユーザー識別子、src/dst [IPアドレス](http://d.hatena.ne.jp/keyword/IP%A5%A2%A5%C9%A5%EC%A5%B9)、src/dst ポート、[プロトコル](http://d.hatena.ne.jp/keyword/%A5%D7%A5%ED%A5%C8%A5%B3%A5%EB))。 static [dependency](http://d.hatena.ne.jp/keyword/dependency)を特定する2つのステップがある。 1. Classifying applications: アプリケーションを2つのタイプ(static [dependency](http://d.hatena.ne.jp/keyword/dependency)のみを生成する、static dependenciesとtransient relationsの療法を生成する)に分類する。 2. Identify Static Dependencies: static dependenciesとtransient relationsの両方のコネクションをもつアプリケーションからデータを取り出し、その2つを区別する。これには、同じアプリケーションの[インスタンス](http://d.hatena.ne.jp/keyword/%A5%A4%A5%F3%A5%B9%A5%BF%A5%F3%A5%B9)であればstatic dependenciesは共通し、transientな接続はそうではないという仮定のもとに、コネクションの利用頻度情報を活用する。 ### Classifying applications ### Identify Static Dependencies 次の手法でstatic dependenciesを抽出する。 ### Adjuestments due to sampling Macroscopeの手法は非常に短命なコネクションを見逃しうるため、実際の利用頻度よりも低く観測されて、transient connectionsとしてミスラベリングしてしまう課題がある。そのため、検知確率(コネクションテーブル内のTracerによりサンプルされる確率)をもとに値を更新する。平均コネクション期間を、Macroscopeのコネクションテーブルサンプリング間隔をとすると、検知確率をと定義する。よりも短いコネクションのために、複数の利用頻度サンプルが使用可能なときに、利用頻度にを掛け算する。 # Evaluation 本論文で使用したトレース結果は、ある大企業の52台の雇用者のラップトップを11週間の間キャプチャしたものである。 ![[%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A2%E3%83%95%E3%82%9A%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E4%BE%9D%E5%AD%98%E9%96%A2%E4%BF%82%E3%81%AE%E8%87%AA%E5%8B%95%E6%8A%BD%E5%87%BA%E3%81%A8%E5%8F%AF%E8%A6%96%E5%8C%96%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%AB%96%E6%96%87 - %E3%82%86%E3%81%86%E3%81%86%E3%81%8D%E3%83%A1%E3%83%A2/s_5DB413D3A59696DF8660A12E60440F604893D25E410FA08ED8AB7D1249394610_1556084973012_Screenshot2019-04-2414.49.21.png]] Figure3は、複数の粒度レベルの依存関係を可視化した様子である。 static [dependency](http://d.hatena.ne.jp/keyword/dependency)検知の精度を確認するために、MSオフィス系アプリケーション、[Skype](http://d.hatena.ne.jp/keyword/Skype)などを含む12のアプリケーションを選び、(1) static [dependency](http://d.hatena.ne.jp/keyword/dependency)を手動検証し、(2) Orion[9]の結果と比較した。 ![[%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A2%E3%83%95%E3%82%9A%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E4%BE%9D%E5%AD%98%E9%96%A2%E4%BF%82%E3%81%AE%E8%87%AA%E5%8B%95%E6%8A%BD%E5%87%BA%E3%81%A8%E5%8F%AF%E8%A6%96%E5%8C%96%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%AB%96%E6%96%87 - %E3%82%86%E3%81%86%E3%81%86%E3%81%8D%E3%83%A1%E3%83%A2/s_5DB413D3A59696DF8660A12E60440F604893D25E410FA08ED8AB7D1249394610_1556174666531_Screenshot2019-04-2515.43.47.png]] Table2は手動によるground truthとMacroscope、Originの比較結果表である。(tp)はtrue positives、(fp)はfalse positives、(fn)はfalse negativesを示す。 Macroscopeはfpとfnも非常に小さく、tpを95%以上の精度で検出している。fpは18%。Orionは91%の精度で検出するが、315%のfpとなっている。シード選択をfpに最適化すると、fpは80%となるが、tpは57%となってしまう。 ![[%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A2%E3%83%95%E3%82%9A%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E4%BE%9D%E5%AD%98%E9%96%A2%E4%BF%82%E3%81%AE%E8%87%AA%E5%8B%95%E6%8A%BD%E5%87%BA%E3%81%A8%E5%8F%AF%E8%A6%96%E5%8C%96%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%AB%96%E6%96%87 - %E3%82%86%E3%81%86%E3%81%86%E3%81%8D%E3%83%A1%E3%83%A2/s_5DB413D3A59696DF8660A12E60440F604893D25E410FA08ED8AB7D1249394610_1556085049842_Screenshot2019-04-2414.50.31.png]] ![[%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A2%E3%83%95%E3%82%9A%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E4%BE%9D%E5%AD%98%E9%96%A2%E4%BF%82%E3%81%AE%E8%87%AA%E5%8B%95%E6%8A%BD%E5%87%BA%E3%81%A8%E5%8F%AF%E8%A6%96%E5%8C%96%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%AB%96%E6%96%87 - %E3%82%86%E3%81%86%E3%81%86%E3%81%8D%E3%83%A1%E3%83%A2/s_5DB413D3A59696DF8660A12E60440F604893D25E410FA08ED8AB7D1249394610_1556085049857_Screenshot2019-04-2414.50.40.png]] # Future Work - Causal order of dependencies: ****依存の因果順序の[アルゴリズム](http://d.hatena.ne.jp/keyword/%A5%A2%A5%EB%A5%B4%A5%EA%A5%BA%A5%E0)を実装は示したが、ground trueが手に入らないために、評価結果は出せていない - Server side dependencies: 本論文では、クライアントサイドのトレースだったが、サーバサイドのトレースがあれば、深さ1よりも大きい複雑な依存関係グラフを作成に拡張できる。 - Kernel-level tracing: コネクションテーブルのサンプリングを[カーネル](http://d.hatena.ne.jp/keyword/%A5%AB%A1%BC%A5%CD%A5%EB)内の[システムコール](http://d.hatena.ne.jp/keyword/%A5%B7%A5%B9%A5%C6%A5%E0%A5%B3%A1%BC%A5%EB)のモニタリングに置き換えられる。パケットトレースなしで[UDP](http://d.hatena.ne.jp/keyword/UDP)の依存も検出できる。プロセス間通信をトレースすることにより、OSサービスの利用を通して間接的にアクセスのある依存を検出できる。しかし、ネットワーク[トラフィック](http://d.hatena.ne.jp/keyword/%A5%C8%A5%E9%A5%D5%A5%A3%A5%C3%A5%AF)に比例して、トレーシングオーバーヘッドが上がってしまうのが難点である。 - Identifying applications: 名前衝突を避けるために、実行ファイル名の代わりに、実行ファイルのハッシュを利用し、アプリケーションを特定できる。しかし、[コンパイラ](http://d.hatena.ne.jp/keyword/%A5%B3%A5%F3%A5%D1%A5%A4%A5%E9)により異なる実行ファイルが生成される可能性がある。 # 手法の制約論文中には書かれていないが、提案手法では次のようなものはスコープ外であると考えている。 - 2ホップ以上の依存関係の収集には未対応 - おそらくephemeral portへ接続する[P2P](http://d.hatena.ne.jp/keyword/P2P)アプリケーションには未対応。厳密には[P2P](http://d.hatena.ne.jp/keyword/P2P)アプリケーションのコネクションを排除することは可能。 - リアルタイムな依存関係の収集 - 大量のエンドホストからのトレースの収集 - 2009年の論文なので当然だがコンテナランタイム上のアプリケーションの依存関係の収集は未対応