DEIM Forum 2017 I7-1

マイクロサービス・アーキテクチャにおける通信情報を用いた呼び出し関係可視化手法
北島 信哉†

松岡 直樹†† 株式会社富士通研究所 ソフトウェア研究所 新世代ＩａａＳ・ＰａａＳプロジェクト〒 211–8588 川崎市中原区上小田中 4-1-1
E-mail: †{kitajima.shinya,matsuoka.naoki}@jp.fujitsu.com
あらまし 近年，マイクロサービス・アーキテクチャと呼ばれる Web サービス設計手法が注目を集めている．マイクロサービス・アーキテクチャはさまざまなメリットをもたらすが，障害分析が複雑になるというデメリットもあわせもっている．Zipkin のような分散トレーシングシステムも存在するが，サービスのソースコードの改変が難しい企業
システムや大規模 Web サービスに適用することは困難である．そこで本稿では，各サーバで取得できる通信に関する情報をもとにマイクロサービス間の呼び出し関係を推測し，可視化する手法を提案する．提案手法を用いることにより，ソースコードを改変することなくマイクロサービス間の呼び出し関係が可視化できるため，マイクロサービス・アーキテクチャにおける障害分析が行いやすくなる．実際に稼働しているマイクロサービス・アーキテクチャのシス
テムにおいて通信ログを取得し，評価を行った結果から，提案手法を用いることでマイクロサービス間の呼び出し関係を高い精度で可視化できることを確認した．
キーワード

マイクロサービス・アーキテクチャ，分散システム，可視化，通信ログ，フロー

1. は じ め にで通信を行う際に ID の受け渡しを行うとともに，Zipkin サー
バに対してログを送信するように各マイクロサービスのソー

近年，マイクロサービス・アーキテクチャと呼ばれる Web

スコードを変更する必要がある．そのため，既存のサービスのサービス設計手法が注目を集めている．マイクロサービス・アー

コードを容易に変更できないような企業システムや，すでに稼

キテクチャでは，1 つの Web サービスを細かい粒度のサービス

働中の大規模 Web サービスにおいては，Zipkin を利用するた（マイクロサービス）に分割し，マイクロサービス同士が Web

めの障壁が大きい．

API のようなシンプルな手段によって疎結合に連携すること

そこで本稿では，各サーバで取得できる通信情報（送信元 IP

で，1 つの Web サービスを構成する [6]．元々は，Amazon や

アドレス，送信先 IP アドレス，送信先ポート番号，送信時刻，

Netflix といった巨大な Web サービスをもつ企業から自然発生

受信時刻）をもとにマイクロサービス間の呼び出し関係を推測的に生まれた手法であり，James Lewis らによって，この手法

し，可視化する手法を提案する．提案手法では，ある通信に対は Microservices（マイクロサービス・アーキテクチャ）としてして，その通信（子通信）が発生するきっかけとなった通信（親再定義された [4]．

通信）が存在すると仮定し，子通信の送信時刻からさかのぼっマイクロサービス・アーキテクチャがもたらすメリットは，て閾値以内の時間に受信した通信を親候補通信とする．この処

技術の多様性，回復性，スケーリングやデプロイの容易性など，理を一定量の通信ログに対しておこない，親候補通信の中から多数挙げられる．一方で，分散システム化することによるデメ

不要なものを削除し，残ったものを親通信と推測する．提案手

リットも複数存在する．デメリットの 1 つに，障害分析の複雑法を用いることにより，例えばあるマイクロサービス・アーキ

さが挙げられる．巨大な Web サービスを構成するマイクロサー

テクチャの Web サービスにおいて処理遅延が発生した際，原

ビスの数は数十，数百にのぼり，処理遅延やエラーが発生した因となっている可能性のあるマイクロサービスを絞り込むこと

場合，その中から原因箇所を見つけ出すのは非常に困難である．

ができる．

このような問題を解決するための 1 つの手段として，2012

以下，2. で想定環境について述べ，3. で提案手法について説年に Twitter, Inc. がオープンソースプロジェクトとして発表

明する．4. で提案手法の性能評価を行い，最後に 5. で本稿のした Zipkin [8] が挙げられる．Zipkin は 2010 年に Google Inc.

まとめと今後の課題について述べる．

が発表した Dapper [9] と呼ばれる分散トレーシングシステムをもとにしている．Zipkin を利用することで，マイクロサービス

2. 想 定 環 境

間の呼び出し関係や各マイクロサービスにおける処理時間を可

2. 1 Web サービス

視化し，処理遅延の原因となっている箇所を見つけ出すことが各マイクロサービスは，複数人からなるチームによって開発できる．
しかし，Zipkin を利用するためには，マイクロサービス間が行われる．一般的には，設計から実装，運用まですべてを担当する 5,6 人からなるチームが理想とされている [6]．1 チーム

ポイント
付与処理
注文処理

注文マイクロサービス

マイクロサービス運用者が用意
インフラ管理者が用意

顧客マイクロサービス

発注処理
倉庫マイクロサービス

図 1 マイクロサービス・アーキテクチャの EC サイトにおける注文
処理の例

マイクロサービス

マイクロサービス

コンテナ基盤 提案手法

コンテナ基盤 提案手法

OS

OS

サーバ

サーバ

（a）PaaS（b）ミドルウェア

が 1 マイクロサービスを担当する場合が多いが，1 チームで複

図2数のマイクロサービスを開発・運用する場合もある．各マイクロサービスは異なる言語で実装されていてもよく，共通の規約に従った Web API さえ提供されていれば，他のチームが作成したマイクロサービスと疎結合に連携して動作できる．
マイクロサービス・アーキテクチャによって作成される Web
サービスの例としては，オンラインショッピングサイトのような EC サイトが挙げられる．マイクロサービス・アーキテク
チャの EC サイトは，例えば，顧客からの注文を処理する注文
マイクロサービスや，商品の在庫や発送を管理する倉庫マイク
ロサービス，顧客の氏名や住所を管理する顧客マイクロサービ
スなど，複数のマイクロサービスによって構成される．新たに商品の購入者に対してポイントを付与するサービスを始める場
合，顧客マイクロサービスを更新し，ポイント数を管理する機能を追加する．また，実際にポイントを付与する処理は，注文
マイクロサービスから顧客マイクロサービスを呼び出すことによって実現できる．図 1 に，マイクロサービス・アーキテクチャの EC サイトにおける注文処理の例を示す．注文マイクロサー
ビスは顧客からの注文を受けると，倉庫マイクロサービスに対して商品の発注処理を行うとともに，顧客マイクロサービスに対してポイント付与処理を実行する．

2. 2 全体像把握の困難さ
2. 1 で述べたように，マイクロサービス・アーキテクチャのシ
ステムは複数のマイクロサービスが連携して動作する分散シス
テムともいうことができ，システムの全体像を把握することは困難である．なぜなら，システムを構成するマイクロサービスの数は数十，多い場合で数百にもなり [2]，また，マイクロサー
ビスは絶えず更新が行われ，新たなマイクロサービスも随時追加されるためである．しかし，障害や遅延の原因分析を行う際には，どのマイクロサービスがどのマイクロサービスを呼び出しているかという情報が必要になるため，システムの全体像を常に把握しておきたいというニーズがある．マイクロサービス
間の呼び出し関係を可視化したものを，本稿ではフローと呼ぶ．
また，実際の Web サービスは，障害や負荷などへの対策のため，多重化されていることが多い．マイクロサービス・アー
キテクチャの場合，処理が集中するマイクロサービスや，負荷が高いマイクロサービスなど，マイクロサービスの単位で多重化を行うことができる．あるマイクロサービスのインスタンス
数は一定ではなく，時間や状況に応じてリアルタイムに変化していくことが考えられる．このような状況下では，事前に全体設計がわかっていたとしても，実際の通信経路を把握することは非常に難しくなる．そこで本稿では，実際の通信情報をもと提供形態に，リアルタイムのフローを可視化することで，障害や遅延の原因分析に役立てることを想定している．

2. 3 提 供 形 態
マイクロサービス・アーキテクチャの Web サービスが動作している環境として，次の 2 つのパターンを想定する．

2. 3. 1 PaaS
図 2(a) に示すように，例えば社内や大学内など，ある組織
内で複数のマイクロサービスを稼働できるインフラがインフラ管理者によって用意されていると想定する．マイクロサービス
運用者は，用意されたインフラの上でマイクロサービスを稼働させることで，Web サービスを運用する．この場合，インフラとしては Kubernetes [3] や Cloud Foundry [1] のようなコン
テナ管理基盤が該当し，各マイクロサービスはコンテナアプリ
ケーションとして実行されることが多い [5]．マイクロサービス
運用者は，インフラ管理者と同じ組織に属している必要はなく，

PaaS サービスとしてインフラ管理者が他の組織にインフラを貸し出しする場合も想定される．
インフラ管理者は，コンテナ管理基盤などが稼働しているサーバ上で通信ログを取得するか，通信ログを取得する仕組みを組み込んだコンテナ管理基盤を利用する．インフラ上で各マイクロサービス運用者が運用するマイクロサービスの通信を可視化するサービスをインフラの一部として提供することで，マイクロサービス運用者が障害分析などに役立てる．

2. 3. 2 ミドルウェア
図 2(b) に示すように，例えば社内や大学内など，ある組織内でマイクロサービス・アーキテクチャの Web サービスを運用する場合を想定する．マイクロサービス運用者は，マイクロサー
ビスの稼働環境として，複数の物理サーバもしくは仮想サーバからなるインフラ環境を構築し，その上でマイクロサービスを稼働させることで，Web サービスを運用する．インフラとしては，前節と同じく Kubernetes や Cloud Foundry のようなコンテナ管理基盤が該当し，マイクロサービスはコンテナアプリ
ケーションとして実行されることが多い．
マイクロサービス運用者は，マイクロサービスの通信を可視化するミドルウェアを追加でセットアップするか，あらかじめこの機能が組み込まれたコンテナ管理基盤などを利用すること
で，Web サービスの障害分析などに役立てる．

2. 4 フローの利用方法
図 3 に示すように，マイクロサービス A がマイクロサービス

B を呼び出し，マイクロサービス B がさらにマイクロサービス

マイクロ
サービス
A

マイクロ
サービス
B

マイクロ
サービス
C

送信元

時刻

172.17.96.6:9041

172.17.20.3

1

172.17.96.2

2TH

図 3 呼び出し関係の例

a

親通信候補

C を呼び出している，というフローがあらかじめわかっている

172.17.32.6:9032

親通信候補

172.17.96.2
172.17.32.10

3
TH

4

ものとする．また，この環境には，他にも多数のマイクロサーb

ビスが稼働しているものとする．マイクロサービス A を利用するユーザへの応答に遅延が生じていると報告があった際に，マイクロサービス運用者は可視化されたフローをもとに，遅延の

図4

提案手法の概要

原因はマイクロサービス A，B，C のいずれかにあると絞り込
むことができる．このように，フローがあらかじめわかっていれば，遅延発生時の原因特定に役立てることができる．また，ある時間帯にフローを可視化したとき，マイクロサービス B からマイクロサービス C への呼び出しが現れなかった場合，マイクロサービス B か，マイクロサービス B からマイクロサービ

送信元IP：172.17.96.2
送信元ポート：67435
送信先IP：172.17.96.6
送信先ポート：9041
受信時刻：2016/8/19 10:38:23.212

送信側
マイクロサービスA
172.17.96.2

通信1
9041

送信元IP：172.17.96.6
送信元ポート：52133
送信先IP：172.17.32.6
送信先ポート：9032
送信時刻：2016/8/19 10:38:23.345

受信側
サーバX
172.17.96.6

ス C への通信経路になんらかの障害が発生したと推測すること

通信2

送信側

ができる．

マイクロサービスB
172.17.32.6:9032

受信側

図 5 親子関係の例

3. 提 案 手 法
本章では，各サーバで取得できる通信情報（送信元 IP アド

もつ通信（図中では a，b）に対し，送信時刻からさかのぼってレス，送信先 IP アドレス，送信先ポート番号，送信時刻，受閾値 T H の間に受信した通信すべて（図中では a に対する 1，

信時刻）をもとにマイクロサービス間の呼び出し関係を推測し，2，b に対する 3，4）を，親候補通信として列挙する．閾値 T H

可視化する手法を提案する．提案手法では，ある通信に対して，の間に複数の IP アドレスからの通信を受信していた場合，どその通信（子通信）が発生するきっかけとなった通信（親通信）の IP アドレスからの通信が親通信なのかを確定できない．そが存在すると仮定し，子通信の送信時刻からさかのぼって閾値のため，不要な親通信候補のみを除外し，残りの親通信候補は以内の時間に受信した通信を親候補通信とする．この処理を一すべてフローに出力する．

定量の通信ログに対しておこない，親候補通信の中から不要な

3. 2 通信の親子関係ものを削除し，残ったものを親通信と推測する．

図 5 に示すように，通信 1 が通信 2 を呼び出した状況を，

3. 1 概要

サーバ X において観測した場合を考える．ここで，通信 1 と通提案手法では，一定時間通信情報を取得し，その後，取得し信 2 は親子関係にあるといい，通信 1 は通信 2 の親通信，通信

た通信情報をもとにフローを可視化する．通信情報として用い

2 は通信 1 の子通信と呼ぶ．このとき，サーバ X からは通信 1

るのは，送信元 IP アドレス，送信先 IP アドレス，送信先ポーの送信時刻と通信 2 の受信時刻は観測できない．

ト番号，送信時刻，受信時刻であり，通信の内容は取得しない．

提案手法では，マイクロサービス間の呼び出し関係を推測す

通信情報の取得方法としては，tcpdump コマンドを利用する

る際，単一のサーバで取得した通信情報のみを利用する．これ

方法や，マイクロサービスが稼働している基盤側で通信を行う

は，送信側と受信側両方の通信情報を関連付けて利用しようと際にこれらの情報をログとして出力する方法が考えられる．

すると，送信側で得られた通信情報と受信側で得られた通信情提案手法では，ある通信が発生した場合には，必ずその通信報を紐付けるために，通信自体に ID などの特定可能な情報をが発生するきっかけとなった通信が存在すると仮定することで，付加する必要があるためである．図 5 の例では，サーバ X に通信同士の呼び出し関係を推測する．各マイクロサービスのイ

おいて観測した情報のみを用いると，通信 1 の直後に通信 2 がンスタンスは固有の IP アドレスとポート番号の組 H をもつも発生したことは判別できるが，通信 2 が通信 1 によって呼び出のとし，任意の Hi から Hj への通信が存在した場合，Hi をもされた通信なのか，他の通信によって呼び出された通信なのか，つマイクロサービスから Hj をもつマイクロサービスへの Web

もしくは通信 1 とは関連性がない通信なのかは判別できず，推API 呼び出しが発生したと考える．マイクロサービス・アーキ

測するしかない．

テクチャのシステムではデータベースや他のサービスへの通信

3. 3 通信情報の取得も想定されるが，あるホスト上の特定のポートで接続を待つと通信情報は，対象となる Web サービスに関連するマイクロいう動作はマイクロサービスと共通の動作である．そのため，サービスが稼働しているすべてのホスト上で取得する．例えば，提案手法ではマイクロサービスとこれらを区別しなくてよい．

マイクロサービスがコンテナ上で稼働している場合はそのホス

図 4 に 示 す よ う に ，提 案 手 法 で は 任 意 の Hi （ 図 中 で はトとなっている物理マシンのすべてのポートを対象に，VM の172.17.96.6:9041）に着目し，その IP アドレスを送信元としてような仮想マシンの上で稼働している場合はすべての仮想マシ

ンのすべてのポートを対象に tcpdump を実行することで，関対象通信の送信元IPアドレス：10.254.131.37

連する通信情報を一括して取得することができる．また，通信ID

親通信候補の送信元IPアドレス

対象通信の送信先

1

172.17.41.8

172.17.94.2

2

172.17.41.8

172.17.94.2

3

172.17.94.8

172.17.94.2

4172.17.41.8，172.17.94.8

172.17.94.2が発生した際にコンテナ管理基盤側で通信情報をログとして出力する方法でもよい．
可視化のために利用する通信情報の量は，フローを可視化する目的によって異なる．例えば，常に通信ログを取得しておき，障害が発生した際は過去 1 時間分の通信ログを用いてフローを可視化して障害箇所の特定に役立てる方法や，過去 5 分間の通信ログをもとにフローを可視化し，Web サービスの状態監視に

集計結果：10.254.131.37
親対象通信の送信先

親通信候補の送信元IPアドレス

出現回数

172.17.94.2

172.17.41.8

3

172.17.94.2

172.17.94.8

2

利用する方法などが考えられる．
図 6 親通信候補の集計

通信ログに含まれない通信はフローには現れないため，できる限り長い時間の通信情報をもとにフローを可視化することも考えられるが，マイクロサービス・アーキテクチャのシステム
では頻繁に構成が変化するため，構成が変化する前後の通信ロ
グは分割して分析することが望ましい．この場合，ある構成変更から次の構成変更までを一区切りとしてフローを可視化する

対象通信の送信元IPアドレス：10.254.23.165
ID

親通信候補の送信元IPアドレス

対象通信の送信先

1-

172.17.94.5

2-

172.17.94.5

3

172.17.94.1

172.17.94.5

4-172.17.94.5

方法が考えられる．ここでいう構成の変化とは，新たなマイク
ロサービスの追加や，負荷変動によるマイクロサービスのイン

集計結果：10.254.23.165
親対象通信の送信先

親通信候補の送信元IPアドレス

出現回数

172.17.94.5-

3

172.17.94.5

172.17.94.1

1

スタンス数変更などを指す．
こ こ で ，ホ ス ト が m 台 あ る と し ，あ る ホ ス ト Hk (1 <=k <= m) で 取 得 し た す べ て の 通 信 情 報 に 含 ま れ る 通 信 を

Ck = {ck,1 , ck,2 , . . . , ck,nk } とする．また，通信 ck,i の送信

図 7 不要な親通信候補の除外

元 IP アドレスを sendk,i ，送信先 IP アドレスを recvk,i ，発生時刻を tk,i とする．tk,i が送信時刻を表すか受信時刻を表

呼び出しが複数回存在することを意味している．親通信候補

すかは，ck,i が送信側で観測された通信か受信側で観測されCk,i = F C(sendk,i ) は，たとえ ip が同一であっても i が異なた通信かによって異なる．tcpdump などのツールで通信情報

ると，異なる集合になる．そこで，sendk,i = ip となるすべてを取得すると，スリーウェイハンドシェイクのようなデータの親通信候補 Ck,i を集計することで，呼び出し元のマイクロ送信をともなわない通信も取得されるため，これらの通信はサービスを特定する．

あらかじめ除外しておき，Ck には含まれないものとする．ま図 6 に，親候補の集計方法を示す．送信元 IP アドレスがた，sendk,i = F S(ck,i ) となるような ck,i から sendk,i への写

10.254.131.37 である通信が 4 回存在し，各通信の親通信候補

像 F S を定義する．

の送信元 IP アドレスをそれぞれ示している．ここで，対象通3. 4 親通信候補の列挙

信の送信先ごとに親通信候補の送信元 IP アドレスを数え上げ

一定時間通信情報を取得したのち，親通信候補の列挙を行う．

ることで，出現回数を集計する．

親通信候補の集合 Ck,i は，次のように表される．

3. 6 不要な親通信候補の除外
親通信候補 Ck,i = F C(sendk,i ) が空集合になる場合，sendk,iCk,i = {ck,j | recvk,j = sendk,i , tk,i −T H < tk,j < tk,i }(1 <=j<= nk )(1)

がホスト Hk 上の IP アドレスではないか，もしくは親通信がもともと存在しない通信であると考えられる．親通信が存在しない通信の例としては，例えば 1 時間に 1 回ログを送信する場

tcpdump などでまとめてホスト上の全ポートの通信情報を合など，一定期間ごとに自動的に実行される処理が挙げられる．

取得した場合，他ホストから自ホスト宛の通信も取得されるが，したがって，親候補通信が一度でも存在しない通信には親通信

そのような通信の親通信候補は自ホスト上では取得できないたが存在しないはずと仮定し，親通信の推測はおこなわない．

め，親通信候補は空集合となる．すなわち，Ck,i =| ∅ の場合，

図 7 に，親候補通信の集合が空集合になる場合の処理を示す．

sendk,i はホスト Hk 上の仮想ホストもしくはコンテナなどの送信元 IP アドレスが 10.254.23.165 である通信が 4 回存在し，IP アドレスであるため，tk,i は送信時刻，tk,j は受信時刻とな

そのうちの 3 回は親候補通信の集合が空集合であることを示しる．よって，Ck,i は，sendk,i の送信時刻からさかのぼって T Hている．この場合，10.254.23.165 から 172.17.94.5 の通信には以内に sendk,i 宛に受信した通信すべての集合を表す．

親通信が存在しないと仮定し，親通信の推測はおこなわない．

3. 5 親通信候補の集計

3. 7 親通信の推測ある IP アドレス ip に対して，sendk,i = ip となる i は複数ある通信に対する親候補通信が複数存在する場合，それらの存在する場合が多い．これは，通信情報を取得した期間内に，ip

送信元 IP アドレスを確認し，同一のものは 1 つにマージする．

で要求を待ち受けているマイクロサービスに対する Web API

これは，あるマイクロサービスが非常に短い間隔で同じマイク表1

Kubernetes には Service と呼ばれる機能が存在し，この機能

パラメータ

パラメータ名値

によって，コンテナがいずれのホスト上にデプロイされていてTH

1, 2.5, 5, 10, 25, 50, 100, 250, 500,も一意の名前でアクセスが可能になるという，DNS のような

1000, 2500, 5000, 10000(ms)
通信情報の取得時間

約 1 時間取得した通信数

42,602役割を果たしている．
表 1 に，本評価で用いたパラメータを示す．通信情報はあらかじめ約 1 時間取得しておき，取得した通信数は 42,602 だった．この通信情報に対して表に示したように閾値 T H を変化さ

ロサービスから呼び出された場合，T H 内に同一の送信元 IP
アドレスからの通信が複数回含まれるためである．

せ，評価をおこなった．

4. 2 評 価 結 果

ある送信元 IP アドレスと送信先 IP アドレスの組をもつ通信

図 8，図 9，図 10 に，それぞれ T H = 1，T H = 1000，の集合に対して，親候補通信の送信元 IP アドレスが 1 通りでT H = 10000 の場合に得られたフローを示す．フロー中の楕円

あれば，その IP アドレスを親通信の送信元 IP アドレスと推測

形はマイクロサービス，楕円形の中の数字は IP アドレスもしする．しかし，親候補通信の送信元 IP アドレスが 2 通り以上

くは IP アドレスとポート番号の組を表している．また，矢印存在する場合，誤って抽出された親候補通信が含まれている可はマイクロサービス同士の親子関係を表し，あるマイクロサー能性が考えられる．一方で，例えばマイクロサービスが多重化

ビスの左側の矢印が親通信，右側の矢印が子通信を表している．

されており，同一マイクロサービスのインスタンスが複数稼働

矢印上の数字は，その通信の発生回数を表している．

している場合，それらは異なる IP アドレスをもつものの，い図から，T H が大きいほど得られるフローが複雑かつ大きずれも親通信といえる場合もある．本稿では，親候補通信の送くなっていることがわかる．今回の評価で用いたマイクロサー

信元 IP アドレスが 2 通り以上存在する場合，いずれも親通信

ビス・アーキテクチャの Web サービスでは，常にすべての通であると推測する．

信が発生しているわけではないため，正解のフローを知るこ

4. 評

価

とは難しい．そのため，正解率のような評価を行うことはできない．しかし，例えば図 8 において 10.25.212.100 から同じ

本章では，提案手法の評価を行う．本評価では，提案手法に10.25.212.100:9035 への通信が現れている箇所や，図 9 におおいて閾値 T H を変化させた際に得られるフローの確からしさ

いて 10.25.212.100:3306 という MySQL から 172.17.94.3:9000について評価する．

のマイクロサービスへの通信が現れている箇所など，いくつか

4. 1 評 価 環 境

誤っていると思われる部分が見受けられる．

評価対象の Web サービスとして，我々の研究グループで日

また，図 10 の一番上部にあるフローは 4479 回となっている

常的に利用しているチャットボット向けの情報収集システムをにもかかわらず，T H が小さい場合には現れていない．提案手

用いる．このシステムは 20 程度のマイクロサービスからなり，

法では，一度でも T H の時間内に親通信が含まれない場合は親マイクロサービス間の通信は Web API を用いるものが大半で通信候補から除外する，という処理を行うため，このように発あるが，一部 AMQP によるメッセージングを用いるものもあ

生回数が多いにもかかわらず T H が小さい場合に除外されてしる．また，MySQL や HAProxy といったサービスも含まれてまうフローが存在する．本稿で対象としたマイクロサービスにいる．各マイクロサービスのインスタンス数は大半が 1 であるは最長 10 秒のタイムアウトが設定されており，T H が 10 秒以が，インスタンス数が 2 のマイクロサービスも存在する．

下の場合，なんらかのエラーによりタイムアウトが生じると，これらのマイクロサービスの目的は，主に社外や社内の Web

エラーが発生した通信はフローに現れなくなってしまう．

サーバや Web API からデータを取得し，整形したのちにチャッ

T H = 10000 では不要と思われる箇所も可視化されているもトボット経由でチャット画面に情報を表示することである．まのの，T H = 1000 では削除されてしまっている箇所があり，どた，一部のマイクロサービスは GUI をもっており，Web ブラ

ちらのフローがよいと判断するのは難しい．いずれにしても，ウザに情報を表示する．社内の通信環境による制限のため，マ多少の誤りは見受けられるものの，それ以外の箇所は正しい親イクロサービスが社外へアクセスを行う際には，必ずプロキシ

子関係がフローに現れており，マイクロサービス間の呼び出し

サーバを経由する必要がある．マイクロサービスの大半にはタ関係を高い精度で推測できているといえる．

イムアウト時間が設定されており，最も長いタイムアウト時間

図 11 に，T H を変化させた際の子側の通信の内訳を示す．

は 10 秒，最も短いタイムアウト時間は 1 秒である．これらのPno は親通信候補が存在しなかった通信の数，Pdelete は親通Web サービス群へのアクセス経路は複数存在し，チャットコマ

信候補が除外された通信の数，Pexist は親候補が 1 つでも存在

ンドによるチャットボット経由のアクセス，Web GUI 経由のア

した通信の数を表している．

クセス，スケジューラや統合監視ソフトウェアである Zabbix [7]による定期的なアクセスなどである．
各マイクロサービスは Kubernetes によって管理されるコンテナ上で稼働している．各コンテナには Kubernetes によって固有の IP アドレスとポート番号が割り当てられる．また，図から，T H が大きいほど親通信候補が存在する通信の数が増えていることがわかる．これは，T H が小さい場合，親通信が T H の範囲外に発生したことになってしまい，親通信候補が正しく抽出されなくなるためである．T H <= 5 の場合，Pexist
が 0 となっており，親通信がまったく抽出されていない．一方

図 8 T H = 1 の場合に得られたフロー

図 9 T H = 1000 の場合に得られたフロー図 10 T H = 10000 の場合に得られたフローた親通信候補が現れにくいことによる結果である．
これらの評価結果から，本稿における評価では T H = 1000が最適な T H ではないかと考えられる．これは，T H が 1000
より大きい場合，削除比率が大きく増加していることから，1回以上前の親通信を親通信候補として挙げていると考えられるためである．しかし，最適な T H は各マイクロサービスの呼び出し頻度に応じて異なると考えられることから，環境に応じて最適な T H を設定する必要がある．

5. ま と め
図 11

子側の通信の内訳

本稿では，各サーバで取得できる通信情報（送信元 IP アド
レス，送信先 IP アドレス，送信先ポート番号，送信時刻，受信時刻）をもとにマイクロサービス間の呼び出し関係を推測
し，可視化する手法を提案した．実際に稼働しているマイクロ
サービス・アーキテクチャのシステムにおいて通信ログを取得
し，評価を行った結果から，提案手法を用いることで，マイクロサービス間の呼び出し関係を高い精度で可視化できることを確認した．
今後の課題としては，以下の項目が挙げられる．

•

不要な親通信候補を削除する際に，必要な親通信候補まで削除しないように調整する方法を検討する．

•
図 12

親通信候補が重複した割合

討する．

•
で，T H >
= 2500 の場合，Pdelete は約 10 となっており，本来削除されるべきでない親通信候補が削除されなくなったために

Pexist が増加したと考えられる．提案手法では，一度でも親通マイクロサービスごとに最適な T H を算出する方法を検複数の親通信候補が得られた場合に，その中から最適な親通信を決定する方法を検討する．

•

正解のフローがあらかじめわかるような評価環境を準備し，提案手法の正解率を評価する．

信候補が存在しない場合には親通信候補を削除することによって，親通信が存在しないはずの通信に対して親通信候補を挙げることを防いでいる．しかし，評価の結果から，この方法には短所があることがわかる．よって，例えば親通信候補が抽出されなかった回数が比較的少ない場合には，単純に親通信候補を削除してしまうのではなく，ある程度残すような手法を導入する必要があると考えられる．
図 12 に，T H を変化させた際の削除比率と親候補比率を示
す．削除比率は 3. 7 節におけるマージ後の親通信候補数をマー
ジ前の親通信候補数で割った割合を表し，親候補比率はマージ後に残った親通信候補数を子通信数で割った割合を表す．
図から，T H が大きいほど削除割合が大きくなっていることがわかる．本稿の評価環境では，基本的に 1 つのマイクロサー
ビスが 1 つの IP アドレスをもつため，親通信候補として抽出される通信は，ほとんどが同一のマイクロサービスからの Web

API アクセスである．T H が大きくなると，本来の親通信と，それ以前に受信した親通信の複数が親通信候補として抽出され，結果として同一の送信元である親通信候補として削除されるた
め，削除比率が大きくなる．一方，親候補比率はほぼ 1 であり，複数の親通信候補から最適な親通信を選択すべき場面はほとん
どなかったといえる．これも，本稿の評価環境では，基本的に1 つのマイクロサービスが 1 つの IP アドレスをもつため，誤っ文

献[1] “Cloud Foundry | The Industry Standard for Cloud Applications,” https://www.cloudfoundry.org/, 参照 Jan. 2017.
[2] D. Bryant, “Scaling Microservices at Gilt with Scala, Docker
and AWS,” InfoQ, https://www.infoq.com/jp/news/2015/05/scaling-microservices-gilt, Apr. 2015.
[3] “Kubernetes - Production-Grade Container Orchestration,”
http://kubernetes.io/, 参照 Jan. 2017.
[4] J. Lewis and M. Fowler, “Microservices,”, MARTINFOWLER.COM, http://martinfowler.com/articles/
microservices.html, Mar. 2014.
[5] J. Stenberg, “Microservices, Containers and Docker,” InfoQ,
https://www.infoq.com/news/2014/12/microservices-docker,
Dec. 2014.
[6] S. Newman，佐藤直生（監修），木下哲也（翻訳），マイクロサービスアーキテクチャ，オライリージャパン，Feb. 2016．
[7] “Zabbix ::The Enterprise-Class Open Source Network Monitoring Solution,” http://www.zabbix.com/, 参照
Jan. 2017.
[8] “OpenZipkin ・ A distributed tracing system,” http://
zipkin.io/, 参照 Jan. 2017.
[9] B. H. Sigelman, L. A. Barroso, M. Burrows, P.=Stephenson,
M. Plakal, D. Beaver, S. Jaspan, C. Shanbhag, “Dapper,a Large-Scale Distributed Systems Tracing Infrastructure,”
Google Technical Report dapper-2010-1, Apr. 2010.