インターネットと運用技術シンポジウム 2020

IOTS2020
2020/12/3

Internet and Operation Technology Symposium 2020

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

TSifter: マイクロサービスにおける性能異常の迅速な診断に向いた時系列データの次元削減手法
坪内 佑樹†1,†2,a),b)

鶴田 博文†1,c)

古川 雅大†3,d)

概要：Web サービスのソフトウェア規模は，長年の機能開発により日々増大しており，ソフトウェア開発者によるソフトウェアの変更が難しくなっている．そこで，変更を容易にするために，一枚岩のアプリ
ケーションを分解して分散させるマイクロサービスアーキテクチャが普及している．しかし，マイクロサービス化によりシステムの構成要素数が増大するにつれて，システムの性能を示す時系列データ形式の指標であるメトリックの個数が増大する．そのため，システムの性能に異常が発生したときに，網羅的にメトリックを目視できず，システム管理者がその異常の原因を診断することが難しくなっている．先行手法では，複数の構成要素を横断したメトリック間の因果関係を推定することにより，システム内の異常の伝播経路を推論する．しかし，診断に利用できるメトリックの個数は限定されるため，より原因に近いメトリックが推論結果から除外される可能性がある．本論文では，性能異常の診断に有用なメトリックを網羅的に抽出するために，観測されたすべてのメトリックの次元数を削減する手法である TSifter を提案す
る．TSifter は，定常性を有するメトリックを除外したのちに，類似の形状をとるメトリックをクラスタリ
ングすることにより，異常の特徴を強く表すメトリックのみを抽出する．本手法により，メトリック数が膨大であっても，その異常の診断に適した有用なメトリックを都度抽出できる．マイクロサービスのテス
トベッド環境に故障を注入する実験の結果，TSifter は，ベースラインとなる手法に対して，正確性と次元削減率の指標では同等程度の性能を有しながらも，270 倍以上高速に動作することを確認した．

TSifter: Dimention Reduction of Time Series Data
for Quick Diagnosis of Performance Issues in Microservices
Yuuki Tsubouchi†1,†2,a),b)

Hirofumi Tsuruta†1,c)Masahiro Furukawa†3,d)

Abstract: The scale of Web services is growing day by day due to the development of functions over theyears, making it diﬃcult for software developers to change the software. Therefore, microservices architecture that decomposes and distributes monolithic applications has become widespread to facilitate softwarechanges. However, as the number of system components increases due to the adoption of the microservices
architecture, the number of metrics, which are indicators of system performance in time-series format, increases. This makes it diﬃcult for system administrators to diagnose the cause of the anomalies becauseof the lack of comprehensive visibility of metrics when the system performance issues occur. In the priormethods, the propagation path of anomalies in the system is inferred by discovering causal structure between
metrics across multiple components. However, since the number of metrics used for diagnosis is limited,
metrics closer to the cause may be excluded from the inference results. In this paper, we propose TSifter,a method to reduce the dimensionality of all observed metrics to extract useful metrics for the diagnosis ofperformance issues comprehensively. TSifter extracts only metrics that strongly represent the characteristics
of anomalies by clustering metrics based on their shape similarity after excluding stationary metrics. With
this method, even if the number of metrics is large, useful metrics suitable for diagnosing anomalies can beextracted each time. Experiments injecting failures into a microservices testbed environment conﬁrmed that
TSifter performed more than 270 times faster than the baseline method while having comparable performancein terms of accuracy and dimension reduction rate.

ⓒ 2020 Information Processing Society of Japan9

インターネットと運用技術シンポジウム 2020

IOTS2020
2020/12/3

Internet and Operation Technology Symposium 2020

1. はじめにチ [5–9] がある．しかし，すべての異常の動作が記録されるわけではなく，計測のためにアプリケーションのソース

ソーシャルネットワーク，メディア，電子商取引，IoT

コードを修正する手間があることから，情報の網羅性と適（Internet of Things）などを実現する Web サービスは，利用性に課題がある．次に，複数の構成要素を横断したメト

用者のサービス利用体験を向上させるために，高い信頼性

リック間の因果関係を推定することにより，システム内のを維持した上で，多数の機能を追加していく必要がある．

異常の伝播経路を自動で推論するメトリックベースのアプ

ソフトウェア開発者が多数の機能を日々追加することによ

ローチ [10–16] がある．しかし，このアプローチは，診断

り，アプリケーションのコード規模が増大するため，変更に利用するメトリックをシステム管理者が一つあるいはを加えるときに問題があった場合の影響がアプリケーショ

複数個に指定しなければならないため，より原因に近いメ

ン全体に及ぶようになる．変更の影響範囲を小さくするたトリックが探索結果から除外される可能性がある．そのために，昨今のクラウド上に展開される Web アプリケーショ

め，診断に有用な情報を迅速に得るためには，できる限り

ンのアーキテクチャは，巨大な一枚岩のアプリケーション

多くの関連するメトリックを高速に解析する必要がある．

を複数の異なる小さなサービスに分解した上で，疎結合な

本論文では，マイクロサービスにおいて，異常の伝播経状態にして各サービスが協調して動作するマイクロサービ

路を自動で推論するための基盤を提供することを目的に，

スアーキテクチャ [1] へと変遷している．

異常発生時に観測されたすべてのメトリックから診断に有Web サービスの高信頼化のためには，サービスの性能に用なメトリックを高速に抽出可能な次元削減手法である異常が発生したときに，異常の根本原因を迅速に特定しな

TSifter を提案する．TSifter は，まず，各メトリックに対ければならない．しかし，マイクロサービスは，分散されして，時系列データの定常性を検定し，定常性を有するメ

た構成要素を多数のサーバホスト上に展開するため，構成

トリックを事前に除去することにより，異常発生前後で傾要素間のネットワーク通信関係は従来の構成よりも複雑と向が変化したメトリックを抽出する．次に，時系列グラフ

なる．そのため，システムに異常が発生したときに，構成として類似の形状をとるメトリックをクラスタリングし，要素間の異常が伝搬するため，異常の伝搬経路も複雑化す

各クラスタから代表メトリックを選出することにより，同る．マイクロサービスにおけるサービス数は数百から数千等の傾向をもつメトリックを集約する．本手法により，異にまで増大しているケース [2] もあるため，それらのサー常発生前後で傾向が変化したメトリックは，そうでないもビスの性質や関係性をシステム管理者が記憶することは難のと比較し，原因を示すメトリックである蓋然性が高いた

しい．さらに，マイクロサービスでは，個々のサービスがめ，原因の診断に有用となる．さらに，クラスタリング処

頻繁に更新されることから，異常の発生確率と負荷傾向が理はメトリック数が増加するにつれて，計算量が増加する

変化する頻度を増大させる．加えて，構成要素数の増大にため，メトリックの事前除去により，クラスタリング処理

より，システムの性能やリソース消費量を定量的に示す時を高速化できる．また，事前除去とクラスタリングの 2 つ

系列データ形式の指標であるメトリックの個数が増大すの異なる次元削減法を適用することにより，単一手法と比る [3]．このような依存関係の複雑性，ソフトウェアの動較して，高い削減性能を得られる．

的な変更，および，メトリック数の増大により，システム

TSifter を評価するために，コンテナ型仮想化環境を管管理者にとってシステムを認知するための負荷が増大する理するための Kubernetes [17] クラスタ上に構築したマイため，異常の原因を診断するために時間を要するようにな

クロサービスのテストベッド環境に故障を注入する実験をる．したがって，マイクロサービス環境にて，システム管行った．実験の結果，TSifter は，ベースラインとなる手法

理者が異常の原因を迅速に特定できる手法が必要となる．

（以降，ベースライン手法とする）に対して，原因であるメ先行手法では，まず，メトリック以外のデータソースでトリックが除外されていないことを示す正確性，次元削減ある，各構成要素が出力するテキストログを用いたログ率，およびメトリック数と CPU コア数に対するそれぞれ

ベースのアプローチ [4] と，各構成要素間の呼び出し関係の実行時間のスケーラビリティでは，同等程度の性能を有や応答速度を追跡する実行経路トレースベースのアプロー

しながらも，270 倍以上高速に動作することを確認した．
本論文を次のように構成する．2 章では，関連研究を述

†1

†2
†3
a)
b)
c)
d)

さくらインターネット株式会社 さくらインターネット研究
所 SAKURA internet Research Center, SAKURA internet
Inc., Ofukatyo, Kitaku, Osaka 530-0011 Japan
京都大学情報学研究科, Graduate School of Infomatics, Kyoto
University, Kyoto 606–8501, Japan
株式会社はてな Hatena Co., Ltd.
y-tsubouchi@sakura.ad.jp
y-tsubouchi@net.ist.i.kyoto-u.ac.jp
hi-tsuruta@sakura.ad.jp
masayoshi@hatena.ne.jpⓒ 2020 Information Processing Society of Japan

べる．3 章では，提案するメトリックの次元削減手法を説明する．4 章では，提案手法の有効性を確認するための実験を示し，実験結果を考察する．5 章では，本論文をまとめ，今後の展望を述べる．

2. 分散システムにおける原因診断手法
クラウド上の分散システムにおける一般的なシステム障10インターネットと運用技術シンポジウム 2020

IOTS2020
2020/12/3

Internet and Operation Technology Symposium 2020

害対応手順は，利用者へ悪影響のある性能異常を検知した
のちに，システムの観察と診断により根本原因を特定し，原因を除去することにより異常から回復させる，という流れになる．システム管理者は各種メトリックをデータベースに収集し，サービスの主要メトリックを表示するダッシュ
ボードを作成しておき，性能異常を検知するとダッシュ
ボードを利用して，システムの状況を観察する [18]．一般
的に選択される主要メトリックとして，CPU 使用時間，メ
モリ使用量，ディスク I/O，ネットワーク I/O などの物理

図 1: TSifter の概要図

資源の利用を示すメトリックと，ソフトウェアレベルの処
理時間やスループット，エラー数などのメトリックがある．

る [10–16]．MicroRCA [12] 以外の手法は，メトリックを

しかし，これらの主要メトリック以外に，例えば，ロック，ノードとして因果関係グラフを構築した上で，システム内のネットワーク接続上限数，OS のファイルディスクリプタ

最前段の構成要素を起点に因果の伝播経路を探索する．Qiu

数などの論理資源の使用を示すメトリックがある．論理資らの研究 [11]，Microscope [15]，および，CauseInfer [16]

源が枯渇すると，性能異常が発生するため，主要メトリッ

は，事前に選択した単一または複数の種類のメトリックとク以外のメトリックが診断のために有用となるケースがあサービス間の呼び出し関係や複数のシステム階層の従属関るといえる．より原因に近い有用なメトリックがダッシュ係を示すシステムトポロジ情報を事前情報として利用する．

ボードにない場合，メトリックを網羅的に調査する必要が

AutoMAP [10]，MS-Rank [13]，および，CloudRanger [14]ある．

は，システムトポロジー情報を必要とせず，複数種類のメマイクロサービス構成をとると，システム全体のメト

トリック情報のみを用いて，因果関係グラフを構築する．

リック数が増大するため，システム管理者が異常を診断す

MicroRCA [12] は，前述の関連研究が利用者に近い最前段

ることがより困難となる．そこで，性能異常が発生したとのサービスのメトリックを起点として因果を追跡するため，きの原因診断手法として，メトリック以外のデータソース

最前段のサービスへの因果伝搬の影響が小さいサービスがを利用するアプローチとメトリックを自動解析するアプ原因であるときに精度が低い前提があることに着目し，マローチがこれまでに提案されている．

イクロサービス内のサービス間の応答速度の情報を利用し各構成要素がデバッグのために出力するテキストログをて，精度を向上させている．これらのメトリックベースの用いたログベースのアプローチでは，ログを分析して，シアプローチは，メトリックの収集のためにアプリケーショ

ステムに発生した問題を特定する [4]．テキスト情報であンコードに修正を加える必要がないため，システムへの適るログは数値情報であるメトリックと比較し，情報量が多用性が高い．しかし，いずれの手法もシステム管理者が単いため，デバッグのために有用な情報を提供する．しかし，一または複数の種類のメトリックを事前に選択しておく必

すべての異常の動作がログに記録されているわけではない

要がある．

ため，実際にはログ以外の複数のデータソースから問題を診断しなければならない．

Sieve [19] は，迅速な原因診断を目的とせず，オートス
ケールの指標などに恒常的に利用するための代表メトリッ

構成要素間の実行パスを追跡する実行経路トレースベー

クを抽出するために，メトリックの次元削減手法を提案しスのアプローチは，実行経路に沿った応答時間の偏差を分ている．Sieve は，事前の負荷テストにより，観測された

析することにより，問題領域や潜在的なボトルネックを特メトリックを構成要素ごとに時系列クラスタリングにより定するために有用な情報を可視化する [5–9]．マイクロサー

次元削減した上で，クラスタ内の代表となるメトリックをビスにこれらのアプローチを適用すると，サービス間でや選択する．しかし，Sieve を異常発生時の迅速な原因診断

りとりされるアプリケーションレベルのリクエスト発行経に応用する場合，事前の負荷テストで顕在化できなかった

路やアプリケーションのソースコード内の処理経路と各経異常のケースには対応できない．

路の実行時間を把握できる．そのため，アプリケーション

3. 性能異常の原因診断に向いたメトリックの次元削減手法のソースコード内の問題箇所を特定しやすい．しかし，各サービスのアプリケーションコードに計測のための処理を追加することになるため，アプリケーション開発者の作業量が大きい．

情報の網羅性と実システムへの適用性の高さに着目すると，メトリックベースのアプローチを採用した上で，論理メトリックベースの自動解析アプローチは，複数の構資源の枯渇などの潜在的な異常原因に対応する必要があ

成要素を横断したメトリック間の因果関係を推定するこる．そのために，異常の発生前後に観測された全てのメトとにより，システム内の異常の伝播経路を自動で推論す

リックを対象とした上で，システム管理者の迅速な診断のために有用なメトリックのみを抽出し，かつ高速に動作すⓒ 2020 Information Processing Society of Japan11

インターネットと運用技術シンポジウム 2020

IOTS2020
2020/12/3

Internet and Operation Technology Symposium 2020

る原因診断システムを実現することが望ましい．本論文でリックの中には，メトリック同士が互いに強く相関しておは，そのような原因診断システムに組み込むことを目指し

り，時間の推移に対して同様の傾向で変動するものが存在た基盤として，原因となるメトリックを除去させない正確する．例えば，単位時間あたりのネットワーク送信バイト

性と時系列データの高い次元削減率を両立した上で，高速数とネットワーク送信パケット数は，値の単位は異なるが，性をもつメトリック次元削減手法 TSifter を提案する．

時間に対して概ね同様の変動傾向を示す．このようなメトリック群は，異常の診断において冗長な情報であり，メト

3.1 TSifter の概要

リック群の中からどれか一つのみを抽出すれば十分である．

図 1 は TSifter の概要図である．TSifter は，異なるアル

この考えに基づき，TSifter ではクラスタリングにより同様

ゴリズムを適用してメトリックの次元削減率を高めるための変動傾向をもつメトリックを集約し，その中から代表メに，2 段階のステップでメトリックを次元削減する．1 段

トリックを一つ抽出して他のメトリックを除外する．代表

階目は，原因となるメトリックを除去させない範囲で，次メトリックは，クラスタ全体の特徴をよく反映するために，元削減率を高めるために，異常発生前後で 収集した全て

クラスタ内のメトリックで，それ以外のメトリックとの距のメトリックの定常性を検定し，定常性を有するメトリッ

離の総和が最小になるメトリックである medoid を選出す

クを除外する．2 段階目は，1 段階目で残った非定常のメる．また，TSifter は，マイクロサービスにおけるサービス

トリックに対して，データの形状の類似性に着目した距離単位でメトリックを集約してクラスタリングを実行する．

尺度を用いてクラスタリングを適用する．その後，さらな異常の診断のための有用な情報をシステム管理者に提供

る次元削減率向上のために，各クラスタからそのクラスタするためには，同様の変動傾向をもつ冗長なメトリックをを代表するメトリックを選定する．クラスタリングはメト

なるべく多く集約，除外することでメトリックの削減数をリック数の増加に対して，非類似度を表す距離の計算回数高める必要がある．クラスタリングにおいて，どのようなが増えるため計算量が増加する．TSifter は，クラスタリ

データを類似性が高いと判断し，同一クラスタに集約するングを実行する前に定常性の検定によりメトリックを除外

かは，データ間の非類似度を表す距離の定義に依存する．

することで，クラスタリング対象のメトリック数を減らす

時系列データであるメトリックの変動傾向の類似性を捉ことができ，クラスタリングを高速に実行できる．以下，えるためには，メトリックの時系列変化の形状に着目する

次元削減の各ステップについて詳細に示す．

ことが有効である．時系列変化の形状の類似性を考慮した距離の定義は，メトリック値の軸方向へのスケールと時

3.2 ステップ 1: 定常性の検定による事前除去

間軸方向へのシフトに対する不変性を満たす必要がある．

異常に関連するメトリックは，異常発生後にメトリック

TSifter では，メトリック値の軸方向へのスケールに対すの値が増加，減少，不安定化するなど，異常発生前後でデーる不変性を満たすために，メトリックを平均 0，分散 1 にタの傾向が変化するはずである．そのため，異常に関連す標準化する．時間軸方向へのシフトに対する不変性を満たるメトリックは，データの平均および分散が時間によらずすために，標準化したメトリック間の距離を shape-based

一定，かつ自己共分散が時間差のみに依存する性質である
定常性を満たさず，非定常性を示す．この洞察に基づき，distance（SBD）[21] に基づき算出する．SBD は，二つの時系列データ #»x と #»
y が与えられたとき，#»
x を #»y に対してTSifter では，異常に関連しないメトリックを除去するためスライドさせながら規格化した相互相関 N CCw が最大とに，定常性の検定を用いてメトリックが定常性を有するかなる位置 w をとり，以下の式に基づき算出される．

どうかを判別し，定常性を有するメトリックを除去する．

TSifter は，収集した全メトリックに対して，定常性の検定を行い，除外するかどうかを決定する．メトリックの定常性の検定には，広く用いられている検定手法の一つでSBD( #»
x , #»y ) = 1 − maxw (N CCw ( #»x , #»y ))(1)

SBD は 0 から 2 の値をとり，0 はデータ間の形状が完全に一致することを意味している．

ある Augmented Dickey-Fuller（ADF）検定 [20] を採用す

TSifter は，マイクロサービスの性能異常時の原因診断

る．ADF 検定は，あるメトリックから算出した p 値が有に活用することを想定しているため，クラスタリングの処

意水準を下回り帰無仮説が棄却された場合，対立仮説であ理には高速性が要求される．メトリックをクラスタリング

る「データが定常性」が採択され，メトリックは定常性をする際に，いくつのクラスタに分けるのが適当であるかは有すると判定できる．TSifter は，ADF 検定により定常性

事前に決定されておらず，その時々のメトリックの変動傾を有すると判定されたメトリックを全て除去する．

向によって変わりうる．このようにクラスタ数が事前に決定されていない場合には，最適なクラスタ数を決定するた

3.3 ステップ 2: 形状の類似性に基づく階層的クラスタリ
ング
マイクロサービスにおける各サービスで収集するメトⓒ 2020 Information Processing Society of Japan

めの処理が必要である．k-means 法 [22] を始めとした非階層的クラスタリングは，最適なクラスタ数を決定するためにクラスタ数を変化させて繰り返しクラスタリングを実行
12

インターネットと運用技術シンポジウム 2020

IOTS2020
2020/12/3

Internet and Operation Technology Symposium 2020

表 1: テストベッドにおけるハードウェアとソフトウェア構成
項目

仕様

Worker ノード(サービス用途)CPU
vCPU
Memory
Type
OS
CPU
vCPU
Memory
Type
OS
CPU
vCPU
MemoryType
OS
PythonVersionVersionWorker ノード(管理用途)

解析用サーバ

Kubernetes
Prometheus

Intel Xeon CPU 2.20GHz
2 core4 GiB
e2-medium
Container-Optimized OS 77Intel Xeon CPU 2.20GHz
2 core8 GiB
e2-standard-2
Container-Optimized OS 77Intel Xeon CPU 3.10GHz
8 core32 GiBc2-standard-8
Debian 11v3.8.2
1.16.13-gke.1
2.20.04.1 実験の環境と設定
テストベッド 実験のためのテストベッド環境は表 1 の通りである．本実験では，Kubernetes クラスタの自動管理サービスである GKE（Google Kubernetes Engine）*1 上に構築したクラスタ上に，マイクロサービスのベンチマー
クアプリケーションである Sock Shop*2 を構築した．Ku-

bernetes クラスタは 5 台の Worker ノードから構成されて
おり，5 台の内 4 台をマイクロサービスを配置するためのサービス用途，残り 1 台をデータ収集と負荷生成のための管理用とした．
ベンチマークアプリケーション Sock Shop は靴下を販売する電子商取引 Web サイトを模したデモアプリケーションである．Sock Shop は，front-end サービス，catalogue
サービス，carts サービス，user サービス，payment サー

し，情報量基準などに基づき最適なクラスタ数を決定する．

ビス，shipping サービスの計 7 個のマイクロサービスから

一方，階層的クラスタリングは，1 回のクラスタリング実構成されている．各マイクロサービスのコンテナの複製数

行後に，最適なクラスタ数を決定できるため，非階層的クは 1 に設定した．

ラスタリングに比べてクラスタ数を高速に決定できる．以

データ収集 メトリックのデータ収集のために，システム上の理由から，TSifter では階層的クラスタリングを採用の構成要素が公開するメトリックを収集・保存・取得するた

する．

めのツールである Prometheus*3 を使用した．Prometheus

クラスタリングの高速性を満たすためには，クラスタ数

により，各コンテナから CPU，メモリ，ディスク，およびの決定に加えて，クラスタリングの処理自体を高速に実行

ネットワークの物理資源とミドルウェアの性能や論理資源する必要がある．TSifter は，類似性が高いメトリックのに関するコンテナレベルのメトリックを収集した．また，ペアが一つでも見つかれば積極的に集約するために，階層各マイクロサービスから平均応答時間と時間あたりの処理的クラスタリングの一種である最短距離法 [23] を用いる．

リクエスト数などのサービスレベルのメトリックを収集し最短距離法は，個々のメトリックがそれぞれ一つのクラス

た．Prometheus のメトリック収集のインターバルを 5 秒

タを形成している状態から開始し，メトリック間のうち距に設定した．

離が最も短いメトリックが属しているクラスタを再帰的に負荷生成 Sock Shop アプリケーションに対して，擬似的併合する．一般に階層的クラスタリングは，クラスタリン

な負荷を生成するために，Locust*4 を利用した．本物の利

グ対象のデータ数の増加に対して計算量が大幅に増加す

用者がサイトのトップページからカタログ一覧を取得し，る問題があり，最短距離法では全てのメトリック間の距離

その中から商品を選び，注文するまでの典型的なフローをを計算する必要があるため，計算量はデータ数 n に対し模倣するようなシナリオを記述し，シナリオを読み込ませ2て O(n ) である．TSifter ではクラスタリングをマイクロて負荷を生成した．

サービスにおけるサービス単位で実行しており，マイクロ故障注入 Locust による負荷を生成している間に，実際サービスが大規模化する場合，サービス内の構成要素が増のマイクロサービスにおける性能異常を模倣するために，大するより，サービス数が増えることが想定されるため，関連研究 [11, 12, 15] の実験で共通して採用されている故障

クラスタリング対象のメトリック数の増加は起きにくく，を注入した．特定のコンテナ内の CPU 負荷が 100%とな

データ数に対する計算量の増大は大きな問題とならない．

る故障を注入するために，stress-ng*5 を利用した．また，また，TSifter で採用した距離尺度である SBD は，式 (1)特定のコンテナと通信するネットワーク遅延が増大する故における相互相関の計算を離散フーリエ変換の高速演算法*6 を利用した．
障を注入するために，tc（Traﬃc Control）

である高速フーリエ変換 [24] を用いて高速に計算できるた

ベースライン手法 TSifter を評価するためのベースライ

め，この利点が最短距離法の高速性にも大きく寄与する．

ン手法として，2 章で挙げた関連研究の中で唯一メトリッ

4. 実験と評価*1

本章では，実験用に構築したマイクロサービス環境にて，手動で故障を注入する実験を行った結果を用いて，TSifterの次元削減の正確性，次元削減率，および高速性を評価する．
ⓒ 2020 Information Processing Society of Japan

*2
*3
*4
*5
*6

Google Kubernetes Engine: https://cloud.google.com/
kubernetes-engine
Sock Shop: https://microservices-demo.github.io/
Prometheus: https://prometheus.io/
Locust: https://locust.io/
stress-ng: https://kernel.ubuntu.com/~cking/stress-ng/
tc: https://linux.die.net/man/8/tc

13

インターネットと運用技術シンポジウム 2020

IOTS2020
2020/12/3

Internet and Operation Technology Symposium 2020

クの次元削減手法を提案している Sieve [19] を選択した．

表 2: 各故障ケースに対する代表メトリックの正誤

Sieve は，変動の少ないメトリックを除去するために，分

正解メトリックの候補

user

散値の小さいものを除去したのちに，時系列クラスタリン
グ手法 k-Shape [21] を用いて，構成要素ごとにその構成要ベース

shipping

TSifterライン

ベース

TSifter

ラインCPU

cpu usage seconds total

×

×

×

×

過負荷

cpu user seconds total

×

×

×

✓

Sieve の著者らは，特定の性能異常に対するシステムの特cpu cfs periods total

✓

×

×

×

徴を抽出するよりは， 事前に対象システムに対して開発者

cpu cfs throttled periods total

×

✓

×

×

cpu cfs throttled seconds total

×

×

×

×

ネット

network transmit packets total

×

×

×

×

ワーク

network transmit bytes total

×

×

✓

×

混雑

network receive packets total

×

×

×

×

network receive bytes total

✓

✓

×

✓

素の特徴を最もよく表す代表メトリックを抽出している．

による負荷テストを実施することにより，恒常的に利用可
能なシステムの特徴を抽出することを目的としている．本
研究の目的とは異なるが，本研究の目的に対して有効な手法でもある可能性を評価する．

表 3: 故障の種類ごとのメトリックの次元削減率

TSifter とベースライン手法の実装 両手法ともに Python

userを用いて実装した．TSifter において，ADF 検定における有意水準は 0.05，最短距離法におけるクラスタ併合の距離の閾値は 0.01 を用いた．CPU のマルチコアによる高速化のために，両手法ともに，全体の実行時間への寄与度が高shipping

ベースライン

TSifter

ベースライン

TSifter

CPU 過負荷1545/324/79

1545/201/122

1541/328/98

1541/156/89

94.8%

92.1%

93.6%

94.2%

ネットワーク

1596/344/110

1596/248/128

1543/335/63

1543/262/128

93.1%

91.9%

95.9%

91.7%

混雑

いタスクを，互いに依存のない小さなタスクに分割し，マ
1400

ルチプロセスで処理するように実装した．
評価指標 TSifter の要件に，メトリックのクラスタリン

高速性の要件から次元削減処理の実行時間の評価が必要となる．そのためにまず，各故障注入時のメトリックを次元削減した結果，正解となるメトリック（以降，正解メトリッ
クとする）が次元削減後に残留しているかを TSifter とベー
スライン手法の両者で正誤を確認する．次に，次元削減率を評価するために，各故障ケースにおけるメトリックの次元削減率をベースライン手法と比較する．最後に，高速性

0.37

1224.87
3.57

Execution time (sec)

で，どの程度次元削減できているかを示す次元削減率と，Clustering
Filtering
Total

3.93
4

1000

Execution time (sec)

グ後に原因メトリックが削減されないことがある．その上Clustering
Filtering
Total

1225.04
1200

800
613.48600
613.31416.72

400

3

2.02
0.21

2

1.46
1.81

0.20

317.82416.55

1.14
0.15

1

1.26

317.65

200
0.17

0
1

0.17
2

0.17
3

0.17
4

Number of CPU cores(a) ベースライン

0.99

0
1

2

3

4

Number of CPU cores(b) TSifter

図 2: CPU コア数に対する実行時間の変化を評価するために，特定の故障ケースにおいて，CPU コア

表 2 より，TSifter は全てのケースに対して正しく代表メ数の増加と，メトリック数の増大に対して，次元削減処理

トリックを抽出した一方で，ベースライン手法は shippingの実行時間の変化を確認する．実行時間の計測値として，サービスの CPU 過負荷のケースのみ正解でないメトリッ

TSifter では 5 回試行した結果の平均値を採用した．ベークを代表として抽出した．

スライン手法では，実行時間の都合により，1 回試行した
結果の値を採用した．

表 3 に，user と shipping サービスへの各故障注入ケースに対するメトリックの次元削減数と削減率を示す．/で著者らが管理する GitHub リポジトリ*7 内に，テストベッ

区切られた数値は左から元のメトリック数，事前除去後のド環境の構築と実験に利用した各種設定ファイルとソース

メトリック数，クラスタリング後の代表メトリック数とな

コード，およびデータセットを公開している．

る．いずれの手法，いずれのケースにおいても次元削減率
は 90%を超えており，削減後のメトリック数は 1/10 以下

4.2 実験の結果
表 2 に示す各故障ケースに対して，1 メトリックあたり

360 個のデータ点に対して，TSifter とベースライン手法となった．また，TSifter とベースライン手法を比較すると，shipping サービスの CPU 過負荷のケースを除いて，ベースライン手法のほうが高い次元削減率を示した．

を適用することにより，マイクロサービスごとに複数の代

ハードウェアのリソース量を増加させたときに，実行時

表メトリックを選出した．故障を注入したサービスの代表

間をどの程度短縮できるかを確認するために，TSifter とメトリックが，表 2 に示す各故障ケースに対する代表メト

ベースライン手法のそれぞれについて，CPU コア数に対すリック候補のいずれかに該当することを以って，性能異常

る実行時間の変化を確認した．表 1 より，実験環境のコアの特徴を表すメトリックを正しく抽出できたこととする．

数は論理コア数 8 であるが，物理コア数は 4 であるため，

CPU コア数を変化させる実験では最大コア数を 4 とした．
*7

https://github.com/yuuki/microservices-demoⓒ 2020 Information Processing Society of Japan

メトリックの個数を 1545 個，メトリックあたりのデータ
点数を 360 個で固定した上で，利用する CPU コア数を 1
14

インターネットと運用技術シンポジウム 2020

IOTS2020
2020/12/3

Internet and Operation Technology Symposium 2020

20000

19623.16

Clustering
FilteringTotal

19590.83 60

Clustering
Filtering
Total

63.09
8.68

15693.72
47.86
5.72

15670.81

Execution time (sec)

Execution time (sec)

15000
11723.80
11710.26

100007780.637773.00
5000

34.86
3.81
22.71
2.43
11.45
1.21

42.14

は，TSifter と比較し，低速だが次元削減率が高いことを踏

31.05

まえると，高速性を公平に評価するには，両手法の次元削減率を揃えた上で，実行時間を比較する必要がある．両手

20.28

法のアルゴリズムの性質上，次元削減率を揃える実験を行

10.24

2.88

7.63
40000

でも 270 倍以上高速に動作したため，TSifter のほうが高203910.9820000

その一方で，ベースライン手法と比較し，TSifter は最低速性の要件を満たすと言える．しかし，ベースライン手法

40

3908.10
0

54.41

リソースを追加することにより，実行時間を維持できる．

22.91

13.54
60000

80000

32.33
1000000
20000

Number of metrics(a) ベースライン

40000

60000

80000

100000

Number of metrics(b) TSifter

図 3: メトリック数増に対する実行時間の変化

うことは難しいため，より公平な高速性の評価は今後の課題とする．

4.2 節より，ベースライン手法ではクラスタリングに長い実行時間を要している．ベースライン手法では，クラスから 4 まで増加させたときの実験結果を図 2 に示す．図 2

タ数を変化させながら繰り返し k-Shape を実行し，最適なより，TSifter とベースライン手法はそれぞれコア数に反比シルエットスコア [25] に基づき，クラスタ数を決定してい例して実行時間が変化していた．また，TSifter の実行時

る．すなわち，クラスタ数を決定するために複数回クラス

間は，いずれのコア数においてもベースライン手法の 270

タリングを実行する必要がある．一方，TSifter における倍以上となった．

階層的クラスタリングでは，クラスタリング実行後に距離メトリック数を増加させたときの TSifter とベースライの閾値を用いてクラスタ数を決定できるため，クラスタリン手法の実行時間の変化を図 3 に示す．CPU コア数を 8，ングの実行回数は 1 回のみである．このクラスタリングのデータ点数を 360 に固定した上で，横軸のメトリック数を実行回数の違いが，TSifter とベースライン手法の実行時

1,000 から 100,000 まで増加させた．メトリック数を増加

間の差の主な原因となっている．

させたデータを作成するために，既存の 7 サービスのメト

TSifter の要件である高速性に対して，実行時間がどのリックを複製し，サービス数を擬似的に増加させた．実験

程度であれば十分であるかについて考察する．人間が手動の結果，両手法にて，メトリック数に対して実行時間が線で性能異常から回復させるとすると，原因の診断を秒単位形に増加した．TSifter は，メトリック数 100,000 においで完了させる必要はない．また，サービスの利用者へシスて 63.09 秒で処理を完了できた．また，TSifter の実行時

テム障害情報を告知する際に，分単位の事象を報告するこ

間は，いずれのデータ点数においてもベースライン手法のとがほとんどである．これらを踏まえると，性能異常の検315 倍以上となった．

知後，数分以内程度に原因の診断を終えられることが理想である．TSifter は，10 万メトリックのデータに対しても

4.3 実験の考察
本実験の範囲内において，ベースライン手法は誤ったメ

1 分程度の時間で実行可能であることから，十分に高速であると言える．

トリックを代表として選択した一方で，TSifter は全てのTSifter は最短距離法におけるクラスタ併合の距離の閾

ケースにおいて正しく代表メトリックを選択できたことか

値をパラメータとして持つ．閾値を大きくすることで，次ら，TSifter のほうが性能異常の特徴を表したメトリック

元削減率は高まるが，原因となるメトリックが削減されるを削減させないと言える．しかし，本実験では，故障を注可能性が高くなるため，適切な値の設定が必要である．こ入したサービスの種類や故障ケースも限定的であったたの閾値を統計的かつ自動的に決定することは，今後の課題

め，その他の故障ケースやサービスに対して TSifter が有とする．

利であるとは言えず，現時点では同等程度の正確性である

TSifter を原因診断システムに組み込むことを想定すると評価する．より広範囲の故障ケースやシステムに対すると，メトリックの次元削減以外に，大量の時系列データを

TSifter の正確性の評価は今後の課題とする．次に，次元短時間に取得する必要がある．時系列データの問い合わせ

削減率に関する実験の結果，ベースライン手法のほうが次処理を含めた実行時間の評価は，今後の課題とする．

元削減率が高い結果となったが，いずれもメトリック数を1/10 以下に削減できたため，TSifter との大きな差はなく，

5. まとめと今後の展望

同程度の次元削減率といえる．さらに，実行時間に関する

本論文では，マイクロサービスにて性能異常が発生した

実験の結果，TSifter とベースライン手法のいずれもメトときの原因をシステム管理者が迅速に診断することを目

リックの個数と実行時間は線形に増加する一方で，CPU コ

的に，大量のメトリックから診断に有用なメトリックを抽

ア数に対して実行時間が反比例した．したがって，両手法出するための次元削減手法 TSifter を提案した．マイクロ

ともに，メトリックのデータ量が増加しても同割合の計算

サービスのテストベッド環境にて TSifter を評価した結果，ⓒ 2020 Information Processing Society of Japan15

インターネットと運用技術シンポジウム 2020

IOTS2020
2020/12/3

Internet and Operation Technology Symposium 2020

TSifter は，ベースライン手法に対して，正確性，次元削減[11]率，およびメトリック数と CPU コア数に対するそれぞれの実行時間のスケーラビリティでは，同等程度の性能をもち，最低でも 270 倍以上の高速性をもつことがわかった．

TSifter は，10 万メトリックのデータに対しても 1 分程度[12]の時間で実行可能であり，計算リソースの追加投入によりさらに高速化可能である．
今後は，システム管理者が利用可能なシステムを実現す[13]

るために，TSifter を性能異常の原因診断システムへ組み込
むことを検討する．具体的には，2 章に示したメトリック
ベースの自動解析アプローチと同様に，各構成要素におい[14]て，抽出された代表メトリック同士の因果関係を判定する
ことにより，性能異常がシステム内をどのように伝搬したかを追跡可能とするといったシステムがありえる．また，マイクロサービス以外にネットワーク層のシステムなどの[15]異なる階層のシステムへの応用を検討する．
参考文献
[1]
[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

Newman, S., Building Microservices: Designing FineGrained Systems, ”O’Reilly Media, Inc.” 2015.
Taichi Nakashima, SRE Practices in Mercari Microservices, https://speakerdeck.com/tcnksm/sre-practices-inmercari-microservices.
Introducing Atlas: Netﬂix s Primary Telemetry Platform，http://techblog.netﬂix.com/2014/12/introducingatlas-netﬂixs-primary.html.
Lin, Q., Zhang, H., Lou, J.-G., Zhang, Y. and Chen, X.,
Log Clustering based Problem Identiﬁcation for Online
Service Systems, IEEE/ACM 38th International Conference on Software Engineering Companion (ICSE-C),
pp. 102–111 2016.
Kaldor, J., Mace, J., Bejda, M., Gao, E., Kuropatwa,
W., O’Neill, J., Ong, K. W., Schaller, B., Shan, P., Viscomi, B. et al., Canopy: An End-to-End Performance
Tracing and Analysis System, the 26th Symposium on
Operating Systems Principles (SOSP), pp. 34–50 2017.
Sigelman, B. H., Barroso, L. A., Burrows, M., Stephenson, P., Plakal, M., Beaver, D., Jaspan, S. and Shanbhag,
C., Dapper, a Large-Scale Distributed Systems Tracing
Infrastructure, Technical report, Google 2010.
Fonseca, R., Porter, G., Katz, R. H. and Shenker,
S., X-Trace: A Pervasive Network Tracing Framework,
USENIX Conference on Networked Systems Design &Implementation (NSDI), pp. 20–20 2007.
Barham, P., Donnelly, A., Isaacs, R. and Mortier, R., Using Magpie for Request Extraction and Workload Modelling, USENIX Symposium on Operating Systems Design and Implementation (OSDI), Vol. 4, pp. 18–18
2004.
Chen, M. Y., Kiciman, E., Fratkin, E., Fox, A.
and Brewer, E., Pinpoint: Problem Determination in
Large, Dynamic Internet Services, IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), pp. 595–604 2002.
Ma, M., Xu, J., Wang, Y., Chen, P., Zhang, Z. andWang, P., AutoMAP: Diagnose Your Microservice-based
Web Applications Automatically, The Web Conference(WWW), pp. 246–258 2020.

ⓒ 2020 Information Processing Society of Japan

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

Qiu, J., Du, Q., Yin, K., Zhang, S.-L. and Qian, C., A
Causality Mining and Knowledge Graph Based Methodof Root Cause Diagnosis for Performance Anomaly in
Cloud Applications, Applied Sciences, Vol. 10, No. 6, p.
2166 2020.
Wu, L., Tordsson, J., Elmroth, E. and Kao, O., MicroRCA: Root Cause Localization of Performance Issues
in Microservices, NOMS 2020-2020 IEEE/IFIP Network Operations and Management Symposium, pp. 1–9
2020.
Ma, M., Lin, W., Pan, D. and Wang, P., Self-Adaptive
Root Cause Diagnosis for Large-Scale Microservice Architecture, IEEE Transactions on Services Computing(TSC) 2020.
Wang, P., Xu, J., Ma, M., Lin, W., Pan, D., Wang,
Y. and Chen, P., CloudRanger: Root Cause Identiﬁcation for Cloud Native Systems, IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID), pp. 492–502 2018.
Lin, J., Chen, P. and Zheng, Z., Microscope: Pinpoint
Performance Issues with Causal Graphs in Micro-Service
Environments, International Conference on ServiceOriented Computing (ICSOC), pp. 3–20 2018.
Chen, P., Qi, Y., Zheng, P. and Hou, D., CauseInfer:
Automatic and Distributed Performance Diagnosis with
Hierarchical Causality Graph in Large Distributed Systems, IEEE Conference on Computer Communications(INFOCOM), pp. 1887–1895 2014.
Hightower, K., Burns, B. and Beda, J., Kubernetes: Up
and Running: Dive into the Future of Infrastructure,”O’Reilly Media, Inc.” 2017.
Beyer, B., Jones, C., Petoﬀ, J. and Murphy, N. R., Site
Reliability Engineering: How Google Runs Production
Systems, ”O’Reilly Media, Inc.” 2016.
Thalheim, J., Rodrigues, A., Akkus, I. E., Bhatotia,
P., Chen, R., Viswanath, B., Jiao, L. and Fetzer, C.,
Sieve: Actionable Insights from Monitored Metrics inDistributed Systems, the ACM/IFIP/USENIX Middleware Conference (Middleware), pp. 14–27 2017.
Dickey, D. and Fuller, W., The Likelihood Ratio Statistics For Autoregressive Time Series With a Unit Root,
Econometrica, Vol. 49, No. 4, pp. 1057–1072 1981.
Paparrizos, J. and Gravano, L., k-Shape: Eﬃcient andAccurate Clustering of Time Series, The ACM Special
Interest Group on Management of Data (SIGMOD),
pp. 1855–1870 2015.
MacQueen, J., Some Methods for Classiﬁcation andAnalysis of Multivariate Observations, The Fifth Berkeley Symposium on Mathematical Statistics and Probability, pp. 281–297 1967.
Murtagh, F., A Survey of Recent Advances in Hierarchical Clustering Algorithms, The Computer Journal,
Vol. 26, No. 4, pp. 354–359 1983.
Cooley, J. and Tukey, J., The Likelihood Ratio Statistics For Autoregressive Time Series With a Unit Root,
Mathematics of Computation, Vol. 19, No. 90, pp. 297–
301 1965.
Rousseeuw, P., Silhouettes: A Graphical Aid to the Interpretation and Validation of Cluster Analysis, Journalof Computational and Applied Mathematics, Vol. 20,
pp. 53–65 1987.

16