インターネットと運用技術シンポジウム 2019
Internet and Operation Technology Symposium 2019

IOTS2019
2019/12/6※ 論文の著作権は情報処理学会に帰属します。論文は著作権者である情報処
理学会の許可のもとに掲載するものです。ご利用に当たっては「著作権法」
ならびに「情報処理学会倫理綱領」に従うことをお願い致します。

Transtracer: 分散システムにおける TCP/UDP 通信の終端点の監視によるプロセス間依存関係の自動追跡坪内 佑樹†1,a)

古川 雅大†2

松本 亮介†1

概要：Web サービスの利用者による多様な要求に応えるために，Web サービスを構成する分散システムが複雑化している．その結果，システム管理者が分散システム内のプロセス間の依存関係を把握することが難しくなる．そのような状況では，システムを変更するときに，変更の影響範囲を特定できず，想定よりも大きな障害につながることがある．そこで，システム管理者にとって未知のプロセス間の依存関係を自動で追跡することが重要となる．先行手法は，ネットワーク接続を終端するホスト上で Linux のパケットフィルタを利用してトランスポート接続を検知することにより依存関係を発見する．しかし，Linux カー
ネル内のパケット処理に追加の処理を加えることになるため，アプリケーションの通信に追加の遅延を与えることになる．そこで，本論文では，サーバ用途で広く利用されている Linux を前提に，TCP/UDP 接
続の終端点であるネットワークソケットに含まれる接続情報を監視することにより，未知のプロセス間の依存関係を網羅的に追跡可能なアーキテクチャを提案する．このアーキテクチャにより，プロセスがLinux カーネルの TCP/UDP 通信機構を利用する限り，未知のプロセスの依存を見逃さずに追跡できる．
また，接続情報の監視処理は，ソケットがすでに保持する接続情報を読み取るだけとなり，アプリケーショ
ンの通信処理とは独立するため，アプリケーションの通信遅延に影響を与えない．最後に，先行手法との比較実験を行い，応答遅延オーバーヘッドとリソース負荷を評価した結果，応答遅延オーバーヘッドを
13–20%，リソース負荷を 43.5%低減させていることを確認した．

Transtracer: Automatically Tracing for Processes Dependencies
in Distributed Systems by Monitoring Endpoints of TCP/UDP
Yuuki Tsubouchi†1,a)Masahiro Furukawa†2

Ryosuke Matsumoto†1

Abstract: Distributed systems in Web services are becoming more complex to respond to various demandsby the Web services users. As a result, it becomes diﬃcult for system administrators to understand the processes dependencies in a distributed system. In such a situation, when system administrators add changes toparts of the system, the area of influence by the change cannot be identified, which may lead to a more significant outage than expected. Therefore, system administrators need to trace dependencies between unknown
processes automatically. The previous method discovers the dependency by detecting the transport connection using the Linux packet filter on the hosts at ends of the network connection. However, since the method
adds the additional processing to the packet processing in the Linux kernel, it gives extra latency to theapplication traﬃc. In this paper, we propose an architecture that traces the dependency between unknown
processes by monitoring network sockets, which are endpoints of TCP/UDP connection. Our proposed architecture enables tracing without missing unknown processes as long as they use the TCP/UDP protocol
stack in the Linux kernel. The architecture makes the monitoring processing only reading the connection
information from sockets. Since the processing is independent of the application communication, it does not
aﬀect the network latency of the application. Finally, as a result of the evaluation of latency overhead andadditional resource load compared with the previous method, we confirmed that our architecture reduces thelatency overhead by 13–20 % and reduces the resource load by 43.5 %.

ⓒ 2019 Information Processing Society of Japan64

インターネットと運用技術シンポジウム 2019
Internet and Operation Technology Symposium 2019

IOTS2019
2019/12/6

1. はじめにWeb サービスが世の中に普及したことにより，利用者からのアクセス数が増大している．Web サービスが人々の生活に欠かせないものとなったために，サービス提供者
が 10 年以上の長期間に渡り，サービスを提供し続けてきている．また，Web サービスの利用者による多様な要求に

図 1: local-remote 依存と remote-remote 依存

応えるために，単一のサービス提供者が，ソーシャルネッ
トワーク，電子商取引および音声・動画配信など，多様なサービスを提供するようになってきている．さらに，あるWeb サービスがもつ一部機能を他の Web サービスから利用する場合，互いにネットワーク接続することにより，機能を共通して利用する事例もある．このような長期間にわたる Web サービスの機能追加，利用者からのアクセス増
加および複数のサービスとの接続などの要因により，Web
サービスを構成する分散システムが複雑化している．

Web サービスにおける分散システムは，通常，OS 上のプロセス同士がネットワーク通信することにより構成される．Web サービスにおいて分散システムが複雑化している
ため，分散システム内のプロセス間のネットワーク依存関係も複雑化し，システム管理者は自身が管理する分散シス
テム内のプロセス間の依存関係を把握することが難しくなる．特定のプロセスに故障や性能劣化などの異常が発生す
ると，ネットワーク通信先の他のプロセスに影響することがあり，システム管理者がシステムを変更するときに，その変更に問題があった場合に変更箇所に依存する全てのプ
ロセスへ，ネットワークを通じて影響が伝搬する可能性がある．そこで，システム管理者がプロセス間のネットワー
ク依存関係を知らずに変更すると，システム管理者の予想よりも大きな範囲の障害が発生することがある．したがって，システム管理者はプロセス間の依存関係を把握することにより，変更が影響する範囲を特定する必要がある．そのような調査のための手間を削減するために，システム管理者の手によらず，システム管理者にとって未知のプロセスの依存関係を自動で発見する必要がある．
これまでに，先行手法として，Linux のパケットフィル
タを利用してトランスポート接続の状態を取得することにより依存関係を追跡するコネクションベースアプローチ [1]がある．このアプローチでは，実際に発生した接続を元に依存があると判定するため，偽陽性がなく，Linux カーネ
ルがサポートするトランスポート接続をアプリケーションが利用する限りは依存を検出できる．さらに，偽陽性がな
いため正確に障害の影響範囲を見積もることができ，Linuxの TCP/UDP 接続を利用しているプロセスであればアプ
†1

†2
a)

さくらインターネット株式会社 さくらインターネット研究
所 SAKURA internet Research Center, SAKURA internet
Inc., Ofukatyo, Kitaku, Osaka 530-0011 Japan
株式会社はてな Hatena Co., Ltd.
y-tsubouchi@sakura.ad.jpⓒ 2019 Information Processing Society of Japan

リケーションを変更せずに網羅的に追跡可能であるため，未知のプロセスを追跡することに適している．しかし，パケットフィルタを利用すると，Linux カーネル内のパケッ
ト処理に介入することになるため，アプリケーション処理に余分な遅延が増える．また，トランスポート接続の開始のみを検出するため，プロセスが一度確立した接続を再利用する場合，接続確立後にはプロセスが再接続するまで当該接続を検出できない．
そこで，本論文では，サーバー用途で広く利用されている OS である Linux を対象に，TCP/UDP 接続の終端点であるネットワークソケットに含まれる接続情報を監視することにより，Web サービスの分散システムにおける未知のプロセス間の依存関係を網羅的に追跡可能なアーキテク
チャを提案する．このアーキテクチャにより，プロセスがLinux カーネルの TCP/UDP 通信機構を利用している限り，未知のプロセスの依存を見逃さずに追跡できる．先行研究の課題である遅延オーバーヘッドについて，接続情報の監視処理は，ソケットがすでに保持する接続情報を読み取るだけとなり，アプリケーションの通信経路とは独立するため，アプリケーションの通信遅延に影響を与えない．
さらに，接続が再利用されていても，接続の終端点である
ソケットから接続情報を取得できる．ただし，TCP/UDP
接続情報と OS プロセス情報しか取得しないため，OSI 参照モデルのうちトランスポート層以外のプロトコルがもつ通信単位での依存関係を追跡できないという制約がある．
本論文を次のように構成する．2 章では，分散システムの依存関係の追跡技術について述べる．3 章では，提案する依存関係追跡のためのアーキテクチャについて説明する．4 章では，提案手法の有効性を評価する．5 章では，本論文をまとめ，今後の展望を述べる．

2. 分散システム内の依存関係の追跡技術
Web サービスにおける分散システムが複雑化している
状況において，システム管理者がシステム内の依存関係を把握することが難しくなっている．そのような状況では，システムの変更時の影響範囲を特定できず，変更に問題があった場合に，予想を超える規模の障害に発展することがある．そこで，分散システムの依存関係を自動で追跡する手法がこれまでに提案されている．本章では，先行研究のそれぞれの特徴を整理する．
65

インターネットと運用技術シンポジウム 2019
Internet and Operation Technology Symposium 2019

2.1 プロセス間の依存関係の定義

IOTS2019
2019/12/6

ングし，パケットの解析コストを低減させる．

本論文では，プロセス間の依存関係を，Zand らの研究 [2]しかし，その結果，トラヒック量の小さい依存を見逃すと同様に，次のように定義する．プロセス P1 での遅延，性可能性がある．さらに，相関するパターンを発見するとき能低下および故障が，直接または間接的に，プロセス P2 のに，相関する度合いを計算することになるため，依存関係

遅延，性能低下および故障を引き起こすのであれば，プロの有無を確率で表現することになる．したがって，複数のセス P2 はプロセス P1 に依存する．この定義を元に，Chen

プロセス間のトラヒックパターンについて，実際に依存はらの研究 [3] は，プロセス間の依存関係を local-remote 依存

していないにも関わらず，偶然似ているときに依存があると remote-remote 依存の 2 つに分類している．図 1 にそれと誤判定するために，偽陽性がある．また，相関する度合

ぞれの依存を示す．図 1 の番号はリクエストとレスポンス

いに対して，予め設定した閾値をもとに依存を判定するこの順番を示しており，プロセスへのリクエストを送る前にとから，閾値をシステム管理者がチューニングする必要がネットワーク接続するものとする．まず，P2 がクライアン

ある．

トからのリクエスト処理の中で P1 に接続する必要がある

Sherlock[4]，Orion[3]，NSDMiner[5] は，既存のトラヒッ

場合，P2 は P1 に local-remote 依存している．次に，P2 にクのパケット情報のみを利用する．Macroscope[6] は，ホ接続するために，遠隔にあるクライアントが P1 に最初に接ストまたはネットワークデバイスで収集するネットワーク

続する必要があるのであれば，P2 は P1 に remote-remote

パケットとホスト上のトランスポート接続情報を結合す依存している．

る．Rippler[2] は，ネットワークトラヒックに意図的に遅例えば，データベースサーバを P1 ，アプリケーション

延を注入することにより，依存するシステムへ遅延が伝搬サーバを P2 とすると，クライアントからリクエストを受けする特性を利用し，偽陽性を低減させている．

たアプリケーションサーバは，データベースサーバに問い

2.2.2 コネクションベースアプローチ

合わせた後に，Web サーバへレスポンスを返却するため，

コネクションベースアプローチは，トランスポート接続

アプリケーションサーバはデータベースサーバに対しての情報を接続を終端するホスト上で取得することにより依

local-remote 依存している（図 1 左）．一方で，DNS サー

存関係を追跡する．パケットベースアプローチのように相バを P1 ，Web サーバを P2 とすると，クライアントはまず関するパターンを識別するわけではなく，実際に発生した

DNS サーバに問い合わせ，IP アドレスを取得したのちに，接続を元に依存があると判定するため，偽陽性がない．一Web サーバに接続するため，Web サーバは DNS サーバに方で，ホスト上にトランスポート接続の情報を取得するた

remote-remote 依存している（図 1 右）．

めの追加のソフトウェアを配置する必要があり，システム

2.2 依存関係の追跡技術
これまでに分散システムにおける依存関係の追跡手法として，パケットベースアプローチ，コネクションベースア
プローチおよびリクエストベースアプローチの 3 種類のア
プローチが提案されている．

2.2.1 パケットベースアプローチ
パケットベースアプローチは，既存のトラヒックからパケットを収集し，パケットヘッダ上の送信元と送信先のそれぞれのホストとポート，パケットの送受信の時刻などの情報を解析することにより，依存を発見する．いずれのパケットベースアプローチにおいても，各プロセス間でトラ
ヒック流量に時間差があることに着目し，各プロセス間のトラヒック性質に相関するパターンを発見することにより，依存を推定する手法がとられている．
パケットベースアプローチの利点は，既存のアプリケー
ションの変更が不要であることである．さらに，ネット
ワークスイッチでパケットを観測すれば，スイッチの変更のみで済むため，ホスト上に追加のソフトウェアを配置する必要がない．しかし，全てのパケットを観測すると，パケット流量が大きい場合に，パケットの解析処理のコストが大きくなるため，通常は一部のパケットのみをサンプリⓒ 2019 Information Processing Society of Japan

管理者の手間が増加する．ただし，実用上，サーバ構成管理ツール [7] を利用して，ソフトウェアの配置を自動化す
ることにより，負担を低減させられる．
コネクションベースアプローチとして Clawson の研究 [1]がある．Clawson の研究では，Linux のパケットフィルタを利用して，ホスト上で終端しているトランスポート接続を監視することにより依存を検出する．Linux がサポートするトランスポートプロトコルをアプリケーションが利用する限りは，依存を検出できる．パケットフィルタを利用すると，Linux カーネル内のパケット処理に介入することになるため，アプリケーション処理に余分な遅延が増えるというデメリットがある．さらに，トランスポート接続の開始イベントのみを検出するため，接続ごとに発生する処
理コストを減らすためにプロセスが一度確立した接続を再利用する場合，プロセスが再接続するまで接続を検出できない．

2.2.3 リクエストベースアプローチ
リクエストベースアプローチは，アプリケーション層のリクエストがシステム内のどの経路をたどるかを追跡す
る．具体的には，各リクエストに識別子を割り振り，通信
内容に埋め込んだ上で，後続のプロセスへ伝搬させる．これにより，識別子を頼りに，リクエストがシステム内のど66インターネットと運用技術シンポジウム 2019
Internet and Operation Technology Symposium 2019

IOTS2019
2019/12/6のプロセスを経由して処理されたかを追跡できる．
リクエストベースアプローチの利点は，コネクション
ベースアプローチと同様に，実際の接続をもとに依存を判定するため，偽陽性が低いことである．さらに，アプリ
ケーションの処理内容やアプリケーション層のプロトコルに応じた情報を追跡することが可能である．
一方で，リクエストベースアプローチは，リクエストに識別子を埋め込むため，アプリケーションの応答時間に余分な遅延を与える．ただし，識別子の埋め込みをリクエス
ト単位でサンプリングすることにより，遅延を低減できる

図 2: ソケットの接続情報の取得

が，その一方で，依存の検出について偽陰性が高くなる．
さらに，識別子を埋め込むために，アプリケーションを変更する手間，または通信経路上にソフトウェアを配置する
手間が発生する．

Pinpoint[8]，Magpie[9]，X-Trace[10]，Dapper[11] は，ア
プリケーションの処理を変更し，リクエストの識別子を埋め込む処理を加える．サービスメッシュ [12] は，マイクロサービス [13] やプロセスの単位でプロキシを配置し，プ
ロキシを経由してその他のサービスと通信させることにより，アプリケーションを変更することなく，リクエストに識別子を埋め込める．

2.2.4 各アプローチのまとめ
本論文の目的である Web サービスの分散システムにおける未知のプロセスの依存を追跡する観点で，各アプロー
チの課題を整理する．
まず，網羅的に依存を追跡できることが重要であるため，パケットのサンプリングによりトラヒック量の小さいプロセスとの依存を見逃すこともあるパケットベースアプロー
チは本研究の目的には適さない．
次に，コネクションベースアプローチであれば，偽陽性がないため，システムに対する変更の影響範囲を実際よりも大きく見積ることがない．しかし，プロセスの接続の再利用により，未知のプロセスの依存を見逃す可能性がある．

Web サービスでは，単一のトランスポート接続上で複数の HTTP リクエストを送信する HTTP/2[14] が普及するなどの要因により，プロセスの接続を再利用するケースが増えている．
さらに，未知のプロセスの依存を検出するためには，網羅的に計測するために，遅延オーバーヘッドが大きくなる
ことが課題となる．リクエストベースアプローチでは，事Web サービスの分散システムに対して，システム管理者がサーバに対して変更を加えるときに，変更の影響範囲を特定するために依存関係を追跡することを目的とする．サー
バで動作するアプリケーションのある特定のリクエスト処理の内容を変更する場合でも，同一プロセス内の処理であればメモリ空間を共有することから，リクエスト処理をするプロセス上の他のリクエスト処理にも変更の影響が伝搬する可能性がある．したがって，変更の影響範囲を特定するためには，ホスト上のプロセス単位での依存関係を取得できれば十分である．
各先行研究の特徴を踏まえると，未知のプロセスの依存を検出するために，偽陰性とアプリケーションに与える遅延オーバーヘッドを低減した上で，システムに対する変更の影響範囲を正確に見積もるために，偽陽性が低いアーキ
テクチャが必要となる．そこで，本論文では，コネクショ
ンベースアプローチを採用することにより偽陽性をなくした上で，Linux カーネル内の各接続の終端点であるソケッ
トに含まれる接続情報を監視することにより，依存関係を追跡するアーキテクチャ Transtracer を提案する．
このアーキテクチャにより，接続情報の監視処理は，ソケットがすでに保持する接続情報を読み取るだけとなり，
アプリケーションの通信処理とは独立することになる．したがって，パケットフィルタのようにアプリケーション通
信経路中のパケットに対して監視のための処理を追加することがないため，コネクションアプローチの課題である遅延オーバーヘッドを低減できる．また，一度確立した接続を再利用したとしても，接続の終端点であるソケットは存在するため，ソケットから接続情報を取得できる．

3.1 提案するアーキテクチャの詳細

前に依存を把握した上で処理や通信の経路上に変更を加え

図 2 に Transtracer アーキテクチャにおける TCP/UDP

るため，新たに未知のプロセスを発見するには適さない．

接続のソケット情報の取得手法を示す．Tracer プロセスをまた，コネクションベースアプローチ同様に，未知のプロホスト上で動作させておき，Tracer プロセスが Linux カー

セスの依存を検出するためには，計測のための遅延オーネルに問い合わせ，各接続に対応するソケットからその瞬バーヘッドが課題となる．

間の TCP/UDP の接続状態のスナップショットを取得す

3. 提案する依存関係追跡アーキテクチャ
本論文では，未知のプロセスを含むような複雑化したⓒ 2019 Information Processing Society of Japan

る．Tracer プロセスは，接続状態と対応するプロセス情報も同時に取得し，接続と接続に対応するプロセスとを紐付ける．新規の接続を検知して取得し続けるために，接続状
67インターネットと運用技術シンポジウム 2019
Internet and Operation Technology Symposium 2019

IOTS2019
2019/12/6

X 上のプロセス A がポート M で待ち受けているとして，
ホスト Y 上のプロセス B がホスト X 上のポート M に対して接続するとすると，プロセス A がなければプロセス B
は接続処理に失敗するため，プロセス B はプロセス A に依存すると言える．
ホスト上で取得可能な全ての TCP/UDP 接続イベントを収集すると，接続情報の個数が大きくなり，CMDB 上のレコード数が大きくなるという課題がある．そこで，レ
コード数を削減するために，プロセス間の依存関係を識別する目的に対して冗長となる接続情報を削減する．プロセスを構成する各プロセスやスレッドが OS から割り当てら
図 3: Transtracer のシステム構成れるランダムな送信元ポートであるエフェメラルポート（Ephemeral Port，短命ポート）を利用して，別のプロセスへ接続することがある．したがって，特定のポートで待ち受けるプロセスに対して，特定のプロセスのクライアン
トから複数のランダムな送信元ポートを利用して接続されることがあると言える．しかし，依存関係を識別するのみ

図 4: 依存の方向の識別

態のスナップショットを定期的にポーリング取得する．ただし，ポーリングによる情報取得は，ポーリングの時間間
隔分だけ新規の接続検出が遅れるという特徴がある．本論であれば，接続の度に異なるポート番号が割り当てられる
エフェメラルポートを一意な接続情報とみなす必要がない
ため，Tracer プロセスが特定ホスト上の特定ポートに対す
るエフェメラルポートによる接続情報を重複するものとみ

文では，ポーリング間隔を秒単位に設定することを想定しなし，それらを集約した上で，CMDB へ送信する．

ているため，検出が遅れる時間も秒単位となる．システム

3.2 提案するアーキテクチャの制約

管理者がシステム変更時に依存関係を確認するという利用

Transtracer アーキテクチャは，TCP/UDP 接続情報とケースであれば，秒単位よりも高速に検出できてもシステ

OS プロセス情報のみ取得するため，OSI 参照モデルのうム管理者が認識できないため，秒単位で十分である．また，

ちトランスポート層の接続以外のプロトコルがもつ通信単

ポーリングによる情報取得はポーリング間隔以内の短命な位での依存関係を追跡できないという制約がある．具体的接続を見逃す可能性がある．ポーリング間隔を小さくするには，HTTP などのアプリケーション層におけるリクエス

ことで，単位時間あたりのハードウェアリソース消費量は

ト単位やネットワーク層のパケット単位での依存関係を追増加するが，より短命な接続を検知できる．ポーリング間跡できない．その結果，アプリケーション層においては，隔の想定が秒単位であるため，検出可能な接続の生存時間

プロセス間の通信の間に，接続を中継するプロセスとしても秒単位を想定している．

プロキシサーバを配置するときに，複数の異なる通信経路

図 3 に，複数のホスト上の接続情報を突き合わせ，依存関係のグラフを作成するためのシステム構成を示す．各を中継する場合，各経路の依存関係を個別に認識できなくなるという制約がある．

ホスト上で動作する Tracer は，取得した接続情報を中央

ただし，プロキシサーバの中継先のプロセスのうちどれの CMDB（Connection Management DataBase，接続管理

か一つでも不調になれば，プロキシサーバがその影響を受

データベース）へ送信する．システム管理者または各ホス

け，中継元の全てのクライアントプロセスにも影響が伝搬

トは，対象のホストやプロセスを一意に識別する情報と時する可能性がある．したがって，プロキシサーバを配置し間範囲をパラメータとして，CMDB に問い合わせ，対象ても 2.1 節にて定義した依存関係を満たした上で依存を追に紐づく依存関係を取得する．依存関係は，ネットワーク

跡できている．さらに，ネットワーク層においては，プロ接続された各プロセスについて，プロセスをノード，ネッ

セス間の通信の間に，NAT(Network Address Translation)

トワーク接続をエッジとみなしたグラフ構造として表現で装置を配置すると，片方のホスト上でみえる相手先の IP ア

きる．関係データベースを用いたデータ構造の詳細についドレスやポート番号が実際の接続先の IP アドレスやポーては，3.3 節にて述べる．

ト番号ではなくなるため，CMDB 上で接続の両端のプロ

図 4 に，依存の方向を識別する手法を示す．プロセス間の依存の方向を識別するために，プロセス間の TCP/UDP
接続について，次のように，接続を要求する側と接続を待ち受ける側に分けた上で，依存の方向を決定する．ホストⓒ 2019 Information Processing Society of Japan

セスを紐付けられないことがある．

3.3 提案するアーキテクチャの実装
サーバ用途で広く利用されていることから Linux(Linux68

インターネットと運用技術シンポジウム 2019
Internet and Operation Technology Symposium 2019

IOTS2019
2019/12/6$ ttctl --dbhost 10.0.0.20 --ipv4 10.0.0.10
10.0.0.10:80 (’nginx’, pgid=4656)└<-- 10.0.0.11:many (’wrk’, pgid=5982)
10.0.0.10:80 (’nginx’, pgid=4656)└--> 10.0.0.12:8080 (’python’, pgid=6111)
10.0.0.10:many (’fluentd’, pgid=2127)└--> 10.0.0.13:24224 (’fluentd’, pgid=2001)

表 1: 実験環境
項目

ClientServer

図 5: ttctl コマンドの出力
CMDB

Kernel 4.15) を前提に Tracer プロセスを実装する．また，
データベース管理システムとして広く利用される関係デー
タベースシステムのうち，テーブルのデータ型としてネッ
トワークアドレス型をもつために接続情報の IP アドレスを管理しやすい PostgreSQL(バージョン 11.3)[15] を利用
し，CMDB を実装する．
通常，TCP/UDP のソケット情報の取得には，トランス
ポートプロトコルのソケットを監視する inet diag モジュールを利用する．inet diag モジュールにより，ソケットがもつ情報である，宛先 IP アドレス，宛先ポート番号，送信元

IP アドレス，送信元ポート番号，接続の状態，ソケットのinode 番号などを取得可能である．inet diag モジュールにアクセスするためのインタフェースには，ファイルシステ
ム形式の Process Filesystem(procfs) と，Linux におけるカーネル空間とユーザー空間との間でメッセージ通信するための機構である Netlink[16] がある．本実装では，procfsのようにファイル内容の解析が不要なため，より高速にアクセス可能な Netlink を利用する．

inet diag モジュールから取得できるソケット情報には，
そのソケットを所有しているプロセスの情報は含まれない．そこで，ソケット情報の inode 番号と，プロセスがもつ inode 番号を照合し，一致すれば当該ソケットとプロセスを紐付ける．プロセスがもつ inode 番号は，Process

Filesystem(procfs) 上の/proc/[pid]/[fd]/以下のファイルから，取得可能である．
プロセス間の依存関係を PostgreSQL サーバに保存し，

CMDB として利用する．プロセス間の依存関係は，プロセスをノードとして，接続を向きをもつエッジとする有向グラフとして表現できるため，ノードを管理するテーブルとエッジを管理するテーブルが必要となる．しかし，接続を集約する都合上，パッシブオープン側のノードはリッス
ンするポート番号をもつが，アクティブオープン側のノードはエフェメラルポートが集約されており，特定のポー
ト番号をもたない．したがって，アクティブオープン側とパッシブオープン側を同一のスキーマで表現しづらいこと

以上のような実装を，筆者らは Transtracer*1 という名称で開発している．Transtracer では，ホスト上でデーモン

Benchmarker

wrk 4.1.0-4

CPUIntel Xeon CPU E5-2650 v3 2.30GHz 4core

Memory1 GBytes

HTTP Server

nginx 1.17.3

CPUIntel Xeon CPU E5-2650 v3 2.30GHz 1core

Memory1 GBytes

Database

PostgreSQL 11.3

このように書き込み側と読み取り側のコマンドを分離する
ことにより，利用者が引数オプションを混同せずに指定しやすくできる．利用者は，CMDB となる PostgreSQL サー
バをセットアップしたのちに，ttracerd を依存関係を追跡したい全てのホスト上で起動し，CMDB に依存関係を蓄積した上で，ttctl を利用して CMDB に問い合わせ，依存関係を取得する．ttracerd に渡すパラメータに，ポーリング取得のための間隔を秒単位で指定できる．なお，UDP 接
続情報の取得と，1 より大きな深さの依存関係グラフの取得は，現時点では未実装である．
利用者が Transtracer をどのように利用するかを示す
ために，本実装における入出力の例を示す．IP アドレス

10.0.0.10 のホストを起点に深さ 1 の依存関係グラフを取得するには，図 5 のように ttctl の引数に IP アドレスを指定し，CMDB に問い合わせる．このような出力を得た
場合，利用者は次のことがわかる．まず，指定した IP ア
ドレス 10.0.0.10 のホスト上では 80 番ポートで待ち受けるnginx*2 と Fluentd*3 が動作している．次に，nginx プロセ
スは，10.0.0.11 のホスト上で動作する HTTP のベンチマー
クツールである wrk*4 からの接続を受けつけ，10.0.0.13 のホスト上でポート 8080 番で待ち受ける Python のプロセスに接続している．さらに，10.0.0.10 上の fluentd プロセ
スは，10.0.0.12 上でポート 24224 番で待ち受ける fluentd
プロセスに接続している．また，3.1 節で述べた手法により，アクティブオープン側のプロセスのエフェメラルポー
トからの接続を同一ポートへの 1 つの接続として集約したものを many と表記している．以上により，Transtracer を利用することにより，対象のホストを変更する前に，当該ホスト上のプロセスを起点とした依存関係を確認できる．

4. 評価
提案する Transtracer アーキテクチャの有効性を確認するために，依存関係の追跡処理がアプリケーションに与える遅延オーバーヘッドとサーバに与えるリソース負荷を 3.3
*2
*3

*1

*4

ⓒ 2019 Information Processing Society of Japan

1 GBytesを取得するための ttctl という 2 つの実行コマンドがある．

として動作し，ソケットの接続情報を収集しつつ，CMDB
https://github.com/yuuki/transtracer v0.1.0

Intel Xeon CPU E5-2650 v3 2.30GHz 2core

Memoryに保存する ttracerd と，CMDB に問い合わせて依存関係

から，アクティブオープン側のノードとパッシブオープン
側のノードを異なるテーブルとして分離している．

仕様

CPU

https://nginx.org/
https://fluentd.org
https://github.com/wg/wrk

69

インターネットと運用技術シンポジウム 2019
Internet and Operation Technology Symposium 2019

401.2

400
359.0

350
310.0
291.8
279.3

300
250

236.0
214.4

200

191.6
188.3

70

50

500

55

450

50

408.6

400
75.9
72.2

78.8

78.6

350

317.8

60

300

50

250
199.1

40

44.4
34.2

30

150
100

ttracerd’s CPU usage
ESTB filter’s CPU usage
Reading sockets time

80

353.8

CPU usage (%)

Average Latency (ms)

90

200
150

102.3
115.0
113.1
94.7
93.1

5000

NormalTranstracer
ESTB filter
NEW filter

10000

15000

20000

20
10
0

50

13.2

5000

10000

Connections(a) 応答時間

100

23.0

15000

20000

0

45

CPU usage
44.4

40

CPU usage (%)

100
462.5
449.3

450

Reading sockets time(ms)500

IOTS2019
2019/12/6

35
30
25

21.6

20
15

13.0
10.8
8.6

10
5
0

1

Connections(b) CPU 利用率と接続情報取得時間

2

3

4

5

Polling interval(c) ポーリング間隔に対する CPU 利用率

図 6: 実験結果

章で述べた実装を用いた実験により評価した．表 1 に実験に設定し，接続のタイムアウト時間をベンチマーク時間よ環境を示す．実験環境の各ロールをさくらのクラウド*5 上

りも大きな値とすることにより，ベンチマーク中の接続数の仮想サーバを用いてそれぞれ 1 台ずつ構築した．各ローが一定の値をとるようにした．プロセス単位の CPU 利用

ルの OS は全て Ubuntu 18.04.2 Kernel 4.15.0 であり，各率を計測するために，Linux の pidstat コマンドを利用し，仮想サーバ間の帯域は 1 Gbps である．実験では，Server

pidstat コマンドに指定する計測間隔をポーリング間隔と同上で ttracerd プロセスを動作させ，Client から Server 上の一の値に設定した．以降で特に指定がない場合，ttracerd

nginx に対して，HTTP のベンチマーカーである wrk によ

プロセスがソケットから接続情報を取得するときのポーリ

るベンチマークを行った．

ング間隔は 1 秒とした．なお，以降で計測したリソース消

コネクションベースアプローチの先行手法である Clawsonの研究 [1] との比較のために，Server 上で Linux のパケッ

費量と実行時間の値は 1 回のベンチマーク中に連続で 5 回計測したときの平均値である．

トフィルタである iptables を利用して検知した TCP/UDP

まず，Transtracer が追跡対象のサーバ上のアプリケー

接続のログを Ubuntu 18.04 のデフォルトで採用されていションに与える遅延オーバーヘッドを評価した．具体的にるログ管理プロセスの systemd-journald に流すようにしたは，wrk の同時接続数パラメータを 5,000 から 20,000 まで

上で同様のベンチマークを行った．接続検知のためパケッ増やしたときに，依存関係を追跡しない通常状態，ttracerd

トフィルタ方式として，1 つ目に，iptables により Client

プロセスを起動した状態，ESTB フィルタ方式，NEW フィからの新規に接続されたときのみログを残すようにする

ルタ方式のそれぞれの平均応答時間をグラフ化した．こNEW フィルタ方式があり，NEW フィルタ方式はログの量の実験の結果を図 6(a) に示す．図 6(a) より，Transtracer

が少ない代わりに，再利用された接続をあとから検知できは，いずれの接続数においても ESTB フィルタ方式の値

ない．2 つ目に，Client からのすでに確立済みの接続を流の 13–20%小さい値，NEW フィルタ方式の値の 5.8–16.2%

れるパケット全てのログを残すようにする ESTB フィルタ

小さい値をとった．また，通常状態と比較し，Transtracer

方式があり，ESTB フィルタ方式は NEW フィルタ方式との応答時間は 1.7–13.4%大きい値となった．以上により，比べてログの量が多い代わりに検知漏れがない．Clawson

Transtracer により先行手法と比較して，応答時間の遅延の研究における実験では，ESTB（ESTABLISHED）フィオーバーヘッドを低減できていることがわかる．

ルタ方式を採用しているが，1 分あたり 20 パケットのみの

次に，Transtracer の導入により，依存関係を追跡可能

サンプリングとなっており，パケット流量の少ない接続をとなる代わりに，追跡対象のサーバにどの程度のリソース

検知できない可能性があるため，本論文の実験ではサンプ

負荷のオーバヘッドを与えるかを評価した．具体的には，リングを無効とするように設定にした．

wrk の同時接続数パラメータを 5,000 から 20,000 まで増以降の各実験に共通する設定を整理する．nginx は静的やしたときの ttracer プロセスと ESTB 方式の CPU 利用に配置した 612 バイトの HTML ファイルを返却するのみ率の変化と接続情報の取得時間の変化をグラフ化した．こである．nginx のみで CPU コアを使い切らないように，の実験の結果を図 6(b) に示す．図 6(b) より，ESTB フィ

nginx のワーカープロセス数は，Server の 4 コアのうち 2ルタ方式と比較すると，ESTB フィルタ方式はいずれの接コアになるように設定した．また，wrk のスレッド数を 1

続数においても CPU 利用率が 70%を超えている一方で，に設定し，60 秒のベンチマークを行った．wrk は HTTP

ttracer プロセスの CPU 利用率は 20,000 接続時においてKeep-Alive により，一旦確立した接続を再利用するようにも，44.4%となる．したがって，ESTB フィルタ方式に対なっているため，nginx 側でも HTTP Keep-Alive を有効

して，Transtracer は依存関係追跡のための CPU 負荷を*5

43.5%低減している．

https://cloud.sakura.ad.jpⓒ 2019 Information Processing Society of Japan70

インターネットと運用技術シンポジウム 2019
Internet and Operation Technology Symposium 2019

IOTS2019
2019/12/6

さらに，図 6(b) において，20,000 接続時の 44.4%の CPUる手法を検討する．最後に，収集した依存関係情報をもっ利用率について，CPU コアが少ない環境であれば，nginxて本来存在するはずの依存を発見できない場合に異常とみプロセスと ttracerd プロセスで CPU リソースを取り合っなすなどの異常検知への応用を進める．

た結果，nginx プロセスの処理性能が低下する可能性がある．そこで，ポーリング間隔を増加させると，その分短命な接続を検出できない可能性が大きくなるかわりに，CPU 利

参考文献
[1]

用率をどの程度低減できるかを評価した．具体的には，wrkの接続数パラメータを 20,000 に固定した上で，ttracerd プ[2]

ロセスのポーリング間隔を 1 秒から 5 秒まで増加させたと
きの ttracerd プロセスの CPU 利用率の変化をグラフ化した．この実験の結果を図 6(c) に示す．図 6(c) より，ポー[3]

リング間隔を増加させると，ポーリング間隔に反比例してCPU 利用率が低下する．ポーリング間隔を 5 秒に設定す
ると，CPU 利用率は 8.6%まで低下する．

[4]以上により，先行手法と比較し，応答遅延オーバーヘッ
ドとリソース負荷オーバーヘッドを低減させていることから，Transtracer アーキテクチャが有効に機能すると考えて[5]いる．接続数の大きい高負荷環境であっても，低オーバーヘッドで利用可能であることから，高負荷環境のみ依存関[6]係を追跡しないといった実環境の運用上都合による妥協をせずに，網羅的に依存関係を追跡できる．ただし，ポーリ
ングによる取得であるために，秒単位の短命な接続を見逃[7]

す可能性がある．Web サービスにおいては，HTTP/2 の利用などにより，接続ごとに実行される処理コストを削減するために，プロセスが接続を再利用することがあること[8]から，実際の依存関係の検出漏れは少ないと考えている．

5. まとめと今後の展望[9]

本論文では，Web サービスの分散システムを対象に，Linux
上で接続の終端点であるソケットに含まれる TCP/UDP[10]接続情報を監視することにより，システム管理者にとって未知のプロセス間依存関係を追跡可能なアーキテクチャ

Transtracer を提案した．Transtracer アーキテクチャによ[11]り，サーバ上のリソース消費の負荷を低減しつつ，アプリ
ケーションの通信遅延に影響を与えずに，プロセス間の依[12]存関係を網羅的に検出できる．実験の結果，先行手法と比較し，応答遅延オーバーヘッドを 13–20%，リソース負荷を 43.5%低減させていることを確認し，Transtracer アー
キテクチャが有効に機能することを示した．
今後の展望としては，短命な接続であっても確実に依存関係を検出するために，Linux の eBPF(extended Berkley

Packet Filter)[17] を利用し，ソケットから接続情報をポー

[13]
[14]
[15]
[16]

リング取得するだけでなく，ソケットに対する接続イベン
トを検知をできる手法と組み合わせることを考えている．
さらに，コンテナ型仮想化環境においても依存関係を追跡できるようにしていくつもりである．また，CMDB のセッ[17]

J. K. Clawson, Service Dependency Analysis via
TCP/UDP Port Tracing, Master’s thesis, Brigham
Young University-Provo 2015.
A. Zand, et al., Rippler: Delay Injection for Service
Dependency Detection, IEEE International Conference
on Computer Communications (INFOCOM), pp. 2157–
2165 2014.
X. Chen, et al., Automating Network Application Dependency Discovery: Experiences, Limitations, and New
Solutions, USENIX Symposium on Operating Systems
Design and Implementation (OSDI), pp. 117–130 2008.
P. Bahl, et al., Towards Highly Reliable Enterprise Network Services via Inference of Multi-Level Dependencies,
ACM SIGCOMM Computer Communication Review,Vol. 37, No. 4, pp. 13–24 2007.
A. Natarajan, et al., NSDMiner: Automated Discovery of Network Service Dependencies, IEEE International Conference on Computer Communications (INFOCOM), pp. 2507–2515 2012.
P. Lucian, et al., Macroscope: End-Point Approach to
Networked Application Dependency Discovery, International Conference on Emerging Networking Experiments and Technologies (CoNEXT), pp. 229–240 2009.
J. O. Benson, et al., Survey of Automated Software Deployment for Computational and Engineering Research,
Annual IEEE Systems Conference (SysCon), pp. 1–6
2016.
M. Y. Chen, et al., Pinpoint: Problem Determinationin Large, Dynamic Internet Services, IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), pp. 595–604 2002.
P. Barham, et al., Magpie: Online Modelling and
Performance-aware Systems, 17th Workshop on Hot
Topics in Operating Systems (HotOS), pp. 85–90 2003.
R. Fonseca, et al., X-Trace: A Pervasive Network Tracing
Framework, USENIX Conference on Networked Systems Design & Implementation (NSDI), pp. 20–20 2007.
B. H. Sigelman, et al., Dapper, a Large-Scale Distributed Systems Tracing Infrastructure, Technical report, Google 2010.
W. Li, et al., Service Mesh: Challenges, State of theArt, and Future Research Opportunities, IEEE International Conference on Service-Oriented System Engineering (SOSE), pp. 122–1225 2019.
M. Fowler and J. Lewis, Microservices, http://martinfowler.com/articles/microservices.html.
M. Belshe, et al., Hypertext TransferProtocol Version 2(HTTP/2), Technical report, RFC 7540 2015.
The PostgreSQL Global Development Group, PostgreSQL, https://www.postgresql.org.
P. Neira-Ayuso, et al., Communicating between the kernel and user-space in Linux using Netlink sockets, Software: Practice and Experience, Vol. 40, No. 9, pp. 797–
810 2010.
D. Calavera, L. Fontana, Linux Observability with BPF:
Advanced Programming for Performance Analysis andNetworking, O’Reilly Media 2019.

トアップのコストを削減するために，各ホスト上の Tracer
プロセスがローカルホスト上に接続情報を分散して保存すⓒ 2019 Information Processing Society of Japan71