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

IOTS2021
2021/11/26

Internet and Operation Technology Symposium 2021

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

Meltria：マイクロサービスにおける異常検知・原因分析のためのデータセットの動的生成システム
坪内 佑樹†1,†2,a),b)

青山 真也†1,c)

概要：クラウド上の大規模なアプリケーションの構成は，機能単位で独立して変更可能とするために，単一の巨大なアプリケーションを分解して分散協調させるマイクロサービスアーキテクチャへと変遷している．アプリケーション構成の分散化により，構成要素数が増大し，構成要素間の依存関係が複雑化することから，システム管理者の認知負荷が高まっている．認知負荷を低減するために，システム管理者の経験と直感が要求される異常検知と異常の原因分析を自動化するための研究が盛んである．これらの研究では，
データ分析手法を実験により評価する際に，正常データと異常データを含む運用データが必要となる．既存の公開されているデータセットは，その静的な性質故に，データセットに含まれる異常パターンの数は限られる．本研究では，多様な異常のパターンに対して異常検知・原因分析手法を評価するために，デー
タセットを動的に生成するためのシステムである Meltria の設計基準を提案する．我々が提案する設計基
準は，(1) 運用データに異常を含めるために，多様な故障注入を実行し，データを採取するための一連の手
続きを実行可能なスケジューリング，および，(2) 故障注入の影響と想定外の異常のそれぞれの有無をデー
タセットにラベル付けするための検証の自動化である．Meltria を用いて，故障注入の種類やパラメータを変更することにより，様々な異常のパターンを含んだデータセットを生成できる．実験の結果，生成されたデータセットに対する (2) の基準に基づいた検証手法の正解率は 85%となった．

Meltria: A Dynamic Datasets Generating System for Anomaly
Detection and Root Cause Analysis in Microservices
Yuuki Tsubouchi†1,†2,a),b)

Masaya Aoyama†1,c)

Abstract: Large-scale applications in the cloud are migrating to Microservices architecture to change application features independently. Microservices architecture brings high cognitive load on system administrators
because it increases the number of application components and the complexity of dependencies between components. To reduce cognitive load, there are many pieces of researches for automated anomaly detection andcause analysis, which require the experience and intuition of system administrators. These researches require
operational data including normal and abnormal data to evaluate their methods by experiments. Because
existing public datasets are static, the number of anomaly patterns included in the datasets is limited. In
this paper, we propose new design criteria for a dynamic datasets generating system named Meltria to evaluate anomaly detection and cause analysis methods for a wide variety of anomaly patterns. The criteria we
propose include (1) feasible scheduling of a scenario to perform various fault injections and picking data toinclude anomalies in a dataset, and (2) the automation of veriﬁcation to label the dataset with the presenceor absence of fault injection eﬀects and unexpected anomalies. Meltria can generate datasets containing
various patterns of anomalies by changing the type and parameters of fault injection. Experimental results
indicate that the accuracy of the veritication method based on the criteria (2) is 85%.

†1

†2

さくらインターネット株式会社 さくらインターネット研究
所 SAKURA internet Research Center, SAKURA internet
Inc., Ofukatyo, Kitaku, Osaka 530-0011 Japan
京都大学情報学研究科, Graduate School of Infomatics, Kyoto

c 2021 Information Processing Society of Japan
⃝

a)
b)
c)

University, Kyoto 606–8501, Japany-tsubouchi@sakura.ad.jp
y-tsubouchi@net.ist.i.kyoto-u.ac.jp
amsy810@gmail.com

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

IOTS2021
2021/11/26

Internet and Operation Technology Symposium 2021

1. はじめに常のパターンを含むデータセットを柔軟に生成できるように，正常・異常データを含むデータセットを動的に生成すSNS（Social Networking Service），メディア配信，電子るためのシステムである Meltria を提案する．まず，異常商取引，および，IoT (Internet of Things) などを実現する

検知・原因分析の既存研究の文献から，評価実験に必要な

今日の IT サービスのアプリケーションは，クラウドの分

データセットの要件を導出する．次に，導出されたデータ

散コンピューティング環境に展開されている．クラウド上

セットの要件を満たすことが可能な，データセット生成シで大規模なアプリケーションを構成する際に，アプリケー

ステムの設計基準を提示する．第一の設計基準は，Meltria

ション開発者が機能単位で独立して変更するために，単一の基本機能であり，運用データに異常を含めるために故障の巨大なアプリケーションを独立した小さなサービスとし注入のスケジューリングを自動化することと，故障内容とて分解して分散協調させるマイクロサービスアーキテク

データを紐付けられるようにデータを管理することであチャ [20] が採用されている．マイクロサービス化により，る．第一の設計基準にしたがってデータセットを動的に生アプリケーションの内部システムの構成要素数が増加し，成すると，管理するデータセットの個数が増加しやすくな

構成要素間の相互作用の関係性も複雑化するため，シスることから，それらのデータセットにデータ分析者の助け

テム管理者の認知負荷が増大する．そのため，アプリケーとなるラベル情報を手動で付与することが困難となる．第ションの異常を検知したり，異常の原因を分析するといっ二の設計基準は，故障注入の影響の有無と想定外の異常

た，システム管理者の経験や直感が要求されるような仕事の有無を生成されたデータセットにラベル付けするためがより困難となっている．そこで，認知負荷を低減するたに，データセットの検証を自動化することである．これら

めに，統計学や機械学習によるデータ分析により，異常検の設計基準に従い，コンテナ型仮想化の管理基盤である

知・原因分析を自動化するための研究が活発である [19]．

Kubernetes [12] 上に構築したマイクロサービスのデモアプ

異常検知・原因分析の研究では，提案されるデータ分析

リケーションである Sock Shop [6] を用いて，本システム

手法の有用性を評価するために，アプリケーションの運用を実装した．第一の設計基準に従い実際に生成されたデー中に計測される運用データセットが必要となる．異常検

タセットに対して，第二の設計基準に従った検証手法を適知・原因分析は，正常なデータと異常なデータの両方を含用する実験を行い，検証手法の性能と，データセットの妥

んだデータに対して，異常の有無，または，異常の原因を当性を評価した．

予測するタスクである．したがって，データ分析手法の評

本論文を以下のように構成する．2 章で，既存の異常検価用のデータセットには，正常なデータだけでなく，異常知・原因分析の研究における評価実験を調査し，公開デー

なデータを含めなければならない．既存研究では，評価用タセットと意図的に異常を再現するシステムの関連研究をのデータセットは独自に作成されており，それらのデータ

述べる．3 章では，既存研究の調査内容から，Meltria の設

セットは研究コミュニティに対して非公開であることがほ計基準を導出した上で，具体的な設計とその実装方法を提とんどである．また，データセットを作成するための手順示する．4 章では，実際にデータセットを生成する実験をの詳細は記載されていないことが多い．

行い，生成されたデータセットの検証手法を評価する．最

公開されたデータセットが不足しているという課題に対して，コミュニティから利用可能なデータセットを公開する取り組みがある [11, 13]．多様な異常のパターンを含む
データセットが公開されていれば，既存の異常検知・原因診後に，5 章にて，本研究の結論と今後の展望を述べる．

2. 関連研究2.1 異常検知・原因分析のデータ生成手法

断手法について，既存の評価実験とは異なる異常のパター

Soldani らの調査 [19] に挙げられているマイクロサービ

ンに対して，性能を再評価することが容易となる．もし既スにおける異常検知・原因分析の研究にて実施されたデー

存手法の性能が低下するような異常のパターンを発見すれ

タセットの生成手法を表 1 に示す．これらの研究で収集さば，そのパターンに対応するために，新たな手法を考案すれる運用データは，時系列の数値データ（メトリック），シる契機となりえる．しかし，作成済みの静的なデータセッ

ステムイベントに関する高度に構造化されたデータ（イベトに含まれる異常のパターンには限りがある．新たな異常

ント），構造化されていない文字列のログ（ログ），リクエ

パターンをデータセットに含めるのであれば，その異常パストの実行経路のグラフ（トレース）の 4 種類 [14] のうターンを再現させた上で，データセットを再作成する必要

ちのいずれか，あるいは複数の組み合わせとなる．イベンがある．データセット作成者にとって未知の異常パターン

トとログを総称してログと呼ぶこともあるため，以降ではが存在することやデータセットが肥大化することを考慮す

まとめてログとする．表 1 の列のうち，タスクは異常検知

ると，全ての異常パターンを含むデータセットを事前に作（AD：Anomaly Detection）または原因分析（RCA：Root

成することは難しい．

Cause Analysys），テストベッドは Sock Shop [6]（SS），

本研究では，異常検知・原因分析の評価用に，多様な異c 2021 Information Processing Society of Japan⃝

Pymicro [5]（P），TrainTicket [2]（TT），データ種別はメ64

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

IOTS2021
2021/11/26

Internet and Operation Technology Symposium 2021

表 1: マイクロサービスを対象とした異常検知・原因分析研究のデータ生成手法
文献

タスク

RCA

テスト
ベッド
SS

データ
種別
M

Microscope [15]AutoMAP [17]CloudRanger [22]MicroRCA [24]

RCA
RCA
RCA

P
P
SS

M
M
M

Aggarwal et al. [7]
MEPFL [26]

RCA
RCA

L
DT

Qiu et al. [18]

RCA

TT
SS,
TT
SS

Wang et al. [21]

RCA

TT

L,M

Arya et al. [8]MicroRAS [23]

RCA
AD

TT
SS

L
M

CPU 過負荷, メモリリーク, ディス
ク I/O ブロック, ネットワーク混雑
計算機リソース枯渇,HTTP 要求遅延・中断, その他 16 ケースの故障
NA
CPU 過負荷, メモリリーク

TraceAnomaly [16]

AD

TT

DT

ネットワーク遅延, コンテナ削除*1

M

注入される故障

CPU 過負荷, ネットワーク混雑,
コンテナ停止
コンテナ停止,DoS 攻撃
NA
ネットワーク遅延,CPU 過負荷, メ
モリリーク
サービス間の HTTP 要求エラー
NA

注入回
数
5
(240)
NA
NA
5 (95)

注入
時間
1分

負荷生成

データの規模や粒度

5000 QPS

1 分サンプリング

NA
NA
1分

注入の前後 1 時間，2 秒サンプリング
2 時間
5 秒サンプリングNA
SS:32,
TT:142
20

NA
NA

NA
NA
500users,
600QPS
NA
NA

NA

NA

NA

NA

NA

NA

NA

NA
3-5
(23)
1

NA
3分

NA
500 users,
600QPS
NA

NA
時間範囲 5 分

5分

注入あたり平均 164,740 行
NA

1 日分*2

トリック（M: Metrics），ログ（L: Logs），トレース（DT:

イクロサービス間に配置された HTTP プロキシが，HTTP

Distributed Traces）のいずれかを示し，NA（No Answer）

通信を中断させるか，または遅延を追加することにより，は文献に記載がないことを表す．

(b) の故障が実現される．最後に (c) の故障は，事前に用意

表 1 の調査により，各研究で共通してみられるデータ

された，故障の原因を含むアプリケーションコードや設定セット作成の手順は，(1) マイクロサービスのデモアプリ

ファイルをアプリケーションに反映することにより，再現

ケーションを構築し，(2) そのアプリケーションに対して，される．

実験者が意図的に故障を注入し，(3) 故障が注入された前

表 1 に示す 11 件の文献のうち，アプリケーションに後の期間の運用データを取得する，というものであること

対して，どのように負荷を生成し，どのように故障を注が分かった．このように作成されたデータセットを使用し入するかについて，一通りの手順が記載された文献は，て，異常検知または原因分析のタスクが評価される．異常Microscope [15]，MicroRCA [24]，および，MicroRAS [23]検知では，故障が注入されていない正常期間のデータを学の 3 件のみであった．またこれらの 3 件の文献において習しておき，学習済みのモデルに対して，正常期間またはも，ネットワーク遅延を注入するときの遅延時間などの故異常期間のデータを入力として与えて，異常の有無を予障注入時のパラメータは記載されていない．

測する．原因分析では，故障注入ごとの前後の期間の運用
データを分析手法の入力として与えて，故障注入を正解として，故障が注入された箇所や故障に対応するメトリック，
ログ，トレースを予測する．

2.2 公開データセット
異常検知・原因分析用の公開されたデータセットには，Loghub [11] と Exathlon [13] の 2 つがある．Loghub [11]表 1 より，商用環境以外のマイクロサービス構成のアプ

は，OS やミドルウェアなどの 16 種類のシステムソフ

リケーションとして，Sock Shop，TrainTicket，および，トウェアが出力したログを含むデータセットである．

Pymicro が使用されている．Sock Shop は，8 個のマイク

Exathlon [13] は，大規模データ向け分散処理ミドルウェア

ロサービスにより構成される小規模のアプリケーションでから収集された高次元時系列データを対象とした異常検知

ある．TrainTicket は，41 個のマイクロサービスにより構のためのデータセットである．公開データセットを使用す成される中規模のアプリケーションである．Pymicro は，れば，第三者が自身でデータセットを作成する必要がない

16 個のマイクロサービスによる構成される，実際のアプリため，第三者がそのデータセットを使用した既存の実験結

ケーション処理を含まないシミュレータである．

果を容易に再現できる．これらのデータセットは，誰でも表 1 より，注入される故障は，(a)CPU 過負荷，メモリ利用できるように公開されているため，研究コミュニティ

リーク，パケット遅延・パケット損失，コンテナの停止など

内で提案されてきた各種手法を比較評価するための標準との計算機リソースに関する故障，(b) サービス間の HTTP

なりえる．いずれのデータセットも，月単位の長期間にわ通信の成否と遅延，および，(c)Zhou らの調査 [25] によるたって収集されたデータを含むため，第三者が同等の期間

マイクロサービス特有の故障，の 3 つに分類される．まずのデータセットを作成するには，同等の時間を要する．

(a) の故障は，CPU 過負荷やメモリリークは，仮想マシン

アプリケーションに発生する異常は，表 1 の列のうち，やコンテナ上で stress-ng*3 を実行することにより擬似的に故障の種類，故障の注入時間，および，負荷生成に応じて，再現し，パケット遅延と損失は Linux のトラヒック制御を異なるパターンを示す．故障の種類，故障の注入時間，お行う tc*4 を使用することにより実現されている．次に，マ

よび，負荷生成は，データセットの作成前に設定する項目とパラメータである．したがって，静的なデータセットに*3*4stress-ng: https://kernel.ubuntu.com/~cking/stress-ng/
tc: https://linux.die.net/man/8/tc

c 2021 Information Processing Society of Japan⃝

含まれる異常のパターンの数は限られ，データセットを再65

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

IOTS2021
2021/11/26

Internet and Operation Technology Symposium 2021

作成しないかぎりは，追加することもできない．これらの項目とパラメータの組み合わせごとにデータセットを事前に作成することも可能だが，組み合わせ数が大きいほど，
データセットの生成には時間を要する．

Fault αInjected Span

Slot

Fault βInjected Span

ComponentA
Component
B
Component
C
Recovery time

2.3 Chaos Engineering のツール
表 1 の Qiu らの研究 [18] の実験では，異常を含むデー
タを採取するために，故意に故障を注入することが可能な

Chaos Engineering のツール [3, 4] が使用されている．これらのツールの目的は，分散システムが予期せぬ事態に耐えられるかどうかの確証を得るための検証の規律である

Time

ComponentA
Component
B
ComponentCTime

図 1: データセット生成のスケジューリング

Chaos Engineering [10] を実践することである．これらのツールには，予期せぬ事態を故意に発生させるための故障
3. Wait until theapplication recovers

注入の機能と，故障注入のスケジューリング実行機能が含まれる．注入可能な故障として，CPU・メモリ・ディスク

Workflow
Scheduler

2. Pick latest data
to datasets

Datasets
Repository

1. Inject a fault to
a componentなどの計算機リソース消費，パケット消失・パケット遅延
増加・ネットワーク帯域制限，および，コンテナの停止などが挙げられる．ツールの利用者は，故障注入対象の構成

LoadGenerator

要素と，故障の種類，故障注入間の時間間隔などの一連のOperational
Data Storage
Component

手続きをワークフローとしてスケジューラに設定できる．

Target Application

しかし，ワークフローの中に，故障注入以外の，運用デー

図 2: Meltria のアーキテクチャ

タの採取や分析のための処理を含めることが難しいという制約がある．

3. データセットの動的生成システム
データセットを用意する手間，既存文献の実験手順の不足，および，公開データセットに含まれる異常パターンの限なデータが両方含まれるデータを基本単位（以降，スロット）として管理されている(6) 故障注入内容からそれに対応するスロットを発見できるように，データセット内の各スロットが管理されている

定性を考慮すると，多様な異常パターンを含むデータセッ

第一の設計基準は，データセットの要件を満たすように，

トを動的に生成するためのシステムが新たに必要である．

故障注入をスケジュールすること，および，故障注入とス

3.1 データセット生成システムの設計（5）を満たすような故障注入のスケジューリングの様子をロットが紐付け可能であることである．図 1 に要件（1）〜2.1 節の調査より，各既存研究の評価実験にて，メトリッ示す．図 1 は，複数のコンポーネントにそれぞれ 2 種類のクのみを収集し，かつ，(a) の計算機リソースに関する故障

故障を繰り返し注入する様子を示している．図 1 の斜線部注入を使用した研究が最多であることから，以降では，メ分は故障注入期間を示している．注入される故障の種類とトリックのみを収集するものとし，かつ計算機リソースに構成要素の組み合わせを事前に設定可能であり，同一の故関する故障注入のみを対象とする．そのときのデータセッ

障注入を複数回スケジューリング可能であることが求めらトの要件を以下に示す．

れる．要件（5）より，スロット（Slot）単位で正常と異常(1) アプリケーション内の複数の構成要素のそれぞれに故を含むデータを生成するために，故障注入後にシステムが障注入されたデータを含む．

(2) アプリケーション内の各構成要素に対して，複数の異なる種類の故障が注入されたデータを含む．

回復するまで，指定された期間だけ待機する．要件（6）より，スロットと故障注入内容を紐付けるために，故障注入の内容をスロットのメタデータとして記録する．

(3) データ分析手法の予測結果の統計的な確からしさを高第一の設計基準に基づいた，データセットの動的生成シ

めるために，同一の構成要素に同じ種類の故障が複数

ステムのアーキテクチャを図 2 に示す．負荷生成器（Load

回注入されたデータを含む．

Generator）が対象アプリケーション（Target Application）(4) 複数回の故障注入の影響を分離して評価するために，に一定の負荷を与え続ける．負荷を与えられた対象アプリ

同一の時間帯に，複数の異なる故障注入の影響が混在

ケーションから収集される運用データを運用データスト

していない．

レージ（Operational Data Storage）に継続的に保存する．

(5) 1 回の故障注入とそれに対応する正常なデータと異常c 2021 Information Processing Society of Japan
⃝第一の設計基準より，事前に与えられた故障注入対象と注
66

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

IOTS2021
2021/11/26

Internet and Operation Technology Symposium 2021

入する故障の種類の設定に基づいて，ワークフロースケ

Algorithm 1 系列の状態分類アルゴリズム

ジューラ（Workﬂow Scheduler）が必要な対象に必要な回

Input: A series y = {yt }T
t=1 including an expected anomaly sub

数の故障注入を実行する．1 回の故障注入は，(1) 対象の構成要素に特定の故障を，5 分など事前に設定された時間だ
け注入し続け，(2) 事前に設定された 1 時間などの時間範囲の運用データを採取して，採取されたデータをデータセッ
トリポジトリ（Datasets Repository）に追加し，(3) アプ
リケーションの回復を待つために一定時間待機する，までseries {yt }T
t=a (1 < a ≤ T ).
Output: One

NOT_FOUND,FOUND_INSIDE_ANOMALY,

FOUND_OUTSIDE_ANOMALY
1: upper val ← mean(y) + 2 ∗ std(y)2: lower val ← mean(y) − 2 ∗ std(y)3: for t ← 1; t ≤ T ; t = t + 1 do
4:の 3 ステップから成る．故障注入とスロットの紐付けのた

5:めに，採取されたスロットを追加する際に，データセット

6:

リポジトリの各レコードのメタデータに，注入された故障

7:の種類と故障注入された構成要素名を付与する．

8:

第二の設計基準は，故障注入の影響の有無と想定外の異

of

9:
10:

if yt < lower val or yt > upper val then
if t < a thenreturn FOUND_OUTSIDE_ANOMALY
else
return FOUND_INSIDE_ANOMALY
end ifend if常の有無を効率よく調べるために，各スロットを自動で

11: end for

検証することである．データセットを検証する手順は，ス

12: return NOT_FOUND

ロットごとに検査対象となるメトリックの系列を選択し，各系列を故障注入の影響の有無と想定外の異常の有無を表す状態のいずれかに分類する，というものである．

選択された個々の系列に対して，故障注入の影響を分類するための手法をアルゴリズム 1 に示す．アルゴリズム 1

検査対象を限定するためのメトリックの系列の選択には，は，入力として標本数 T の系列 y = {yt }Tt=1 を与えると，故障（Fault）からエラー（Error）が発生し，障害（Failure）へ

その系列が次の 3 つの状態のいずれかであるかの分類結と至るサイクルを示す影響伝搬モデルである Fault-Error-

果を出力する．mean 関数は算術平均値，std 関数は標準

Failure サイクル [9] を使用する．Fault-Error-Failure サイ

偏差を返すものとする．NOT_FOUND とそれ以外の状態のクルは，システム内部に故障が発生すると，故障がエラー

分類には，正規分布において 68%, 95%, 99.7%の値がそれを引き起こし，エラーが伝搬した結果，システム内部と外ぞれ平均の 1,2,3 標準偏差以内に収まるという経験則であ部の境界に影響が現れると，システム利用者へ影響する障る 68-95-99 則 [1] を使用する．特に，99.7%の値が 3 標準

害へと至る機構を示している．このサイクルに基づくと，偏差以内に収まる規則は 3 シグマ則とも呼ばれ，表 1 の

データセット内の各スロットデータに対して，(a) 故障注入

Microscope [15] がアプリケーションの障害を検知するため箇所に直接対応するメトリック（以降，故障メトリック），に使用する．(a) の故障に対応するメトリックでは，すで(b) 故障注入箇所を含むマイクロサービスの定常状態を示にリソース消費量が上限に近い状態でリソースを上限まですメトリック（以降，マイクロサービスレベルメトリッ

消費する種の故障を注入する場合，時系列の変動が小さくク），(c) 対象アプリケーション全体の定常状態を示すメト

なる可能性がある．そのため，本研究では，3 シグマ則よリック（以降，アプリケーションレベルメトリック）の 3

りも異常検出率が高い，95%の値が 2 標準偏差以内に収ま種類を検査対象の系列として選択すれば十分である．(a)る 2 シグマ則を用いる．

は故障の種類に応じて，(b) と (c) は対象アプリケーショ
ンに応じて，それぞれ事前に定義されるものとする．

3.2 データセット生成システムの実装

各系列の状態を分類するために，故障注入の影響の有

2.1 節にて述べた既存研究の評価実験にて使用されてい無と想定外の異常の有無を表現可能な，次の 3 つの系列

る Sock Shop [6] を対象アプリケーションとする．Sockの状態を定義する．NOT_FOUND は入力系列に顕著な異常

Shop は，コンテナ型仮想化環境を管理するための Kuber-がないこと，FOUND_INSIDE_ANOMALY は入力系列内の故netes [12]（version 1.20）上に展開される．Sock Shop は，

障注入期間に相当する時間範囲のみに異常があること，靴下を販売する電子商取引 Web サイトを模したマイクロ

FOUNT OUTSIDE ANOMALY は，故障注入期間外に異サービス構成のデモアプリケーションである．

常があることを表す．故障注入の結果，対象アプリケー

Sock Shop に対する負荷生成には，負荷テストツール

ション全体に期待どおりに顕著な影響が顕在化した状態は，である Locust*5 （version 1.6.0）を用いる．ワークフロー(i) 単一のメトリックの系列内に正常標本と異常標本の両スケジューラにおけるスケジューリングを実現するため者が含まれている，(ii) 単一の故障から成る異常標本のみに，Kubernetes 上で動作するワークフローエンジンであるが含まれている，(iii) 異常標本が故障注入期間にあること，

Argo Workﬂows*6（version 3.1）を使用する．Argo Work-のすべてを満たす状態である．FOUND_INSIDE_ANOMALY は*5(i) から (iii) を同時に満たす状態と同等である．

*6c 2021 Information Processing Society of Japan⃝

Locust: https://locust.io/
Argo Workﬂows: https://argoproj.github.io/workflows/67インターネットと運用技術シンポジウム 2021

IOTS2021
2021/11/26

Internet and Operation Technology Symposium 2021

ﬂows は，Kubernetes 環境で実行したい一連の処理の各ス

表 2: 系列の状態分類の正確度（故障別）

テップが，コンテナとして動作するようなワークフローを

故障

系列数

正解系列数

正確度 (%)

定義できる．故障注入には，Kubernetes が管理するコン

合計

257

219

85

テナに対して，プリセットで用意された様々な故障を注

pod-cpu-hog:carts

15

5

33

入可能な LitmusChaos（version 2.0）[4] を用いる．故障注

pod-cpu-hog:carts-db

15

15

100

pod-cpu-hog:catalogue

15

15

100

入以外の検証処理などをワークフローに組み込めるよう

pod-cpu-hog:catalogue-db

15

15

100

に，LitmusChaos が備えるスケジューラではなく，Argo

pod-cpu-hog:front-end

10

9

90

Workﬂows を使用する．Argo Workﬂows のワークフロー

pod-cpu-hog:orders

15

15

100

pod-cpu-hog:orders-db

15

15

100

pod-cpu-hog:user

15

15

100

pod-cpu-hog:user-db

15

13

87

pod-memory-hog:carts

12

4

33

pod-memory-hog:carts-db

15

15

100

pod-memory-hog:catalogue

15

8

53

pod-memory-hog:catalogue-

15

15

100

のステップとして，LitmusChaos による故障注入を定義
する．

Sock Shop アプリケーションからのメトリックの収集には，メトリックを収集・保存・取得するためのツールである

Prometheus*7 （version 2.20.0）を使用した．Kubernetes
上のコンテナのメトリックが，cAdvisor*8 により公開さ

db

れ，Sock Shop の各マイクロサービスが受信する HTTP

pod-memory-hog:front-end

10

10

100

リクエストに関するメトリックが各マイクロサービスのア

pod-memory-hog:orders

15

11

73

pod-memory-hog:orders-db

15

11

73

pod-memory-hog:user

15

13

87

pod-memory-hog:user-db

15

15

100

プリケーションにより公開される．Prometheus はこれらの 2 種類のメトリックを収集する．データセットリポジ
トリには，オブジェクトストレージである Google Cloud

Storage*9 を使用する．
以上の実装のためのソースコードは，著者らが管理する

GitHub リポジトリ*10 内に公開されている．

4. 実験と評価

均応答遅延，マイクロサービスレベルメトリックとして，当該マイクロサービスの平均応答遅延を選択した．cAdvisor
が提供するメトリックのうち，CPU 過負荷の故障メトリック
として user_cpu_user_seconds_total，メモリリークの故障メトリックとして user_memory_working_set_bytes

本章では，3.2 節に示した実装を用いて，実際にデータを選択した．1 種類のコンテナに対して，原則 3 つの系列

セットを生成し，生成されたデータセットに第二の設計基が選択される．ただし，front-end コンテナについては，

準で述べた系列の状態分類手法を適用したときの評価を述

アプリケーションレベルメトリックと，マイクロサービス

べる．

レベルメトリックが一致するため，2 つの系列が選択され実験環境 Kubernetes クラスタの自動管理サービスである．carts コンテナに対するメモリリーク故障注入時の繰る GKE（Google Kubernetes Engine）*11 を使用して作成

り返しのうち 1 回分は，対応するスロットのデータ採取にした Kubernetes クラスタ（バージョン 1.16.13-gke.1）上失敗していたため，データセットには含まれていない．

に，5 個の Worker ノードを構成し，5 個のうち 4 個をマイ評 価 指 標 本 実 験 で は ，デ ー タ セ ッ ト 内 の 全 ス ロ ッ

クロサービスを配置するためのサービス用途，残り 1 個をト の 選 択 さ れ た 全 系 列 が FOUND_INSIDE_ANOMALY に 分

データ収集と負荷生成のための管理用とした．ノードのマ類 さ れ る こ と を 期 待 し て い る ．し か し ，第 二 の 設 計

シンタイプはすべて e2-medium とした．

基 準 よ り ，実 際 に 生 成 さ れ た 系 列 を 目 視 で 分 類 し た

実験設定 Sock Shop を構成するコンテナのうちの 8 種類と し て も ，FOUND_INSIDE_ANOMALY と な る と は 限 ら なのコンテナを予め指定し，各コンテナに対して，CPU 過負荷

い．そこで，実験で生成されたデータセット内の各スとメモリリークの故障を 5 回ずつ注入する計 90 回の故障注

ロットに対して，NOT_FOUND，FOUND_OUTSIDE_ANOMALY，入を実行したときのデータセットを使用した．このときのFOUND_INSIDE_ANOMALY の 3 状態のうちのいずれかに 257

Prometheus のデータ取得頻度は 15 秒とし，スロットの時個の系列を目視で分類した．この目視による分類を正解と間範囲を 30 分，スロットの時間範囲の最後の 5 分を故障注したときの系列の状態分類手法の正確度を分類性能の評価

入期間とした．アプリケーションレベルメトリックとして，指標とする．

Sock Shop の最前段に配置される front-end コンテナの平分類結果 表 2 に故障ケース別の状態分類手法の正確 度 を 示 す ．256 個 の 全 体 の 系 列 に 対 し て ，正 確 度 は*7Prometheus: https://prometheus.io/*8 cAdvisor: https://github.com/google/cadvisor*9 Google Cloud Storage: https://cloud.google.com/storage*10 https://github.com/ai4sre/meltria/*11 Google Kubernetes Engine: https://cloud.google.com/kubernetes-enginec 2021 Information Processing Society of Japan⃝

85%で あ っ た ．正 解 の 状 態 別 に 仕 分 け る と ，197 個 のFOUND_INSIDE_ANOMALY の系列に対して正確度が 98%，
22 個の FOUND_OUTSIDE_ANOMALY に対して正確度が 68%，
36 個の NOT_FOUND に対して 28%の正確度であった．した68インターネットと運用技術シンポジウム 2021

IOTS2021
2021/11/26

Internet and Operation Technology Symposium 2021

正確に異常を分類するためには，類似の変動傾向であって

6.25
Response time (ms)Memory usage (MB)

10.8
10.6
10.4
10.2

0

20

40

60

Plots

80

100

6.00

も，メトリックの種類に依ることが障壁となる．そこで，

5.75

メトリックごとの知識を教師データとすることが可能な，

5.50

教師ありの機械学習モデルを適用することを今後検討す5.25

る．本システムでは，注入される故障の種類，故障注入先

5.00

120

0

(a) メモリ使用量の微増

40

60

Plots

80

100

120

データセット生成の課題 分類手法が正答したとしても，

CPU usage seconds

Response time (ms)

500

0.3
0.2

0

20

40

60

Plots

80

100

120

(c) CPU 時間のスパイク変動の構成要素，検証対象のメトリックが予め定まっているた
め，教師データを作成しやすい．

(b) ホワイトノイズ

0.4

0.1

20

400

目視による分類が期待される FOUND_INSIDE_ANOMALY で300なかったケースを考察する．第一に，あるスロットで注200入された故障の影響がその直後のスロットまで残留して1000いたため，FOUND_OUTSIDE_ANOMALY に正確に分類された
0

20

40

60

Plots

80

100

120

(d) 前回の故障注入影響の混入

図 3: 誤分類された時系列データの例

ケースがあった．現在のワークフロースケジューラの設
計は，故障の影響からアプリケーションが回復したのちに，スロットが開始されることを保証していない．したがって，アプリケーションの回復が遅れると，スロット

がって，NOT_FOUND が正解となる系列に対して，特に低いに 2 つの故障の影響が混在することになる．スロット間

分類性能を示したと言える．低い分類性能を示したケースの故障の影響の独立性を保証することは今後の課題とす

は，carts，orders，orders-db，catalogue の 4 コンテ

る．第二に，故障注入期間外の系列にごく短時間のスパイ

ナについて，繰り返しの故障注入の一部が何らかの理由でクが発生したため，FOUND_OUTSIDE_ANOMALY に正確に分実行されなかったため，異常が含まれておらず，正解の分類されたケースがあった．ごく短時間のスパイクはランダ類が NOT_FOUND となったケースである．

ムで発生し，その要因がクラウド事業者が管理するシステ

低い分類性能を示した要因を詳細に分析するために，図ムにある可能性もあるため，突出自体を発生させないよ

3 に誤分類された時系列データの 4 つの例を示す．横軸はうにすることは難しい．また，短時間の突出を無視して，データ点のプロット順であり，100 から 120 プロットの間のFOUND_INSIDE_ANOMALY に分類すると，データ分析する際

赤い影は故障注入期間である．図 3(a) では，メモリ使用量に，その短時間の突出の存在に気づかず分析結果に影響をが 10.2MB に対して微増しているにすぎないため，正解は及ぼす可能性がある．これらの第一と第二のケースを一括

NOT_FOUND であるが，FOUND_OUTSIDE_ANOMALY と分類されして FOUND_OUTSIDE_ANOMALY に分類するのではなく，よた．図 3(b) では，応答時間が広範囲に同程度の強度のノイズ

り詳細の状態を定義し，分類が可能となるような分類手法を含むホワイトノイズとなっているため，正解は NOT_FOUNDを今後検討する．

だが，FOUND_OUTSIDE_ANOMALY と分類された．図 3(c) では，CPU 過負荷の故障注入により，故障注入期間に CPU が5. まとめ

大幅に増加しているため，正解は FOUND_INSIDE_ANOMALY

本研究では，マイクロサービスの異常検知・原因分析をだが，FOUND_OUTSIDE_ANOMALY と分類された．図 3(d) で対象とした既存研究の実験手法を調査することにより，実は，直前の故障注入の影響により，左側に回復の変動

験に必要なデータセットに求められる要件を導出した．そが見られるため，正解は FOUND_OUTSIDE_ANOMALY だが，して，導出された要件に基づき，故障注入のスケジューリ

FOUND_INSIDE_ANOMALY と分類された．

ング，データセットのラベル管理，および，統計学の経験分類結果に対する考察 誤分類されたケースのうち，図 3(a)則によるデータセットの自動検証を行う，データセットのと図 3(b) の例のように NOT_FOUND が正解のケースは，故障自動生成システムである Meltria の設計基準を提案した．

注入に失敗していたケースと一致した．2 シグマ則では，故自動検証手法を評価するために，実際に生成されたデータ

障注入の成功時ほど大きな変動を示さない注入失敗時の系列

セットに含まれる個々の時系列データを異常の状態別に分が，FOUND_OUTSIDE_ANOMALY や FOUND_INSIDE_ANOMALY

類したところ，85%の正確度となった．正確度をより高めに分類された．仮に，故障注入に成功したとしても，故障るための手がかりは，故障注入に失敗するかあるいはその注入の影響がもし小さければ，2 シグマ則では誤分類され影響が小さかったケースにあることを示した．

ると予想される．その一方で，3 シグマ則を用いると，正今後の展望は，メトリック以外のデータ種別のデータ

しく FOUND_INSIDE_ANOMALY と分類できていたケースでセット生成，複数の異なる対象アプリケーションのサポー

FOUND_OUTSIDE_ANOMALY と誤分類されるケースが増加す

ト，多様な種類の故障のサポート，および，データセット

ることがわかっている．このような変動が小さなケースでの生成時間の短縮，を実現できるように，Meltria を拡張

c 2021 Information Processing Society of Japan⃝69

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

IOTS2021
2021/11/26

Internet and Operation Technology Symposium 2021

することである．また，異種のアプリケーションや異種の故障のサポートに加えて，スロット内の故障注入期間の配[17]

置を変更するなどの，異常パターンを増加させるための条件を設定可能にしていく．最後に，データ種別ごとに，異常パターンを分類した上で，既存の異常検知・原因分析手[18]法による分析精度が不十分となるような異常パターンを発見していく予定である．
[19]

参考文献
[1]
[2]
[3]
[4]
[5]

[6]
[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

68-95-99.7 rule, https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7 rule.
A Benchmark Microservice System, https://github.com/FudanSELab/train-ticket/.
Chaos Mesh: A Powerful Chaos Engineering Platform
for Kubernetes, https://chaos-mesh.org/.
LitmusChaos: Open Source Chaos Engineering platform,
https://litmuschaos.io/.
Pymicro: Microservice-based Sample Application Written in Python, https://github.com/rshriram/pymicro.
Sock Shop: A Microservices Demo Application, https://microservices-demo.github.io/.
Aggarwal, P., Gupta, A., Mohapatra, P., Nagar, S.,
Mandal, A., Wang, Q. and Paradkar, A., Localizationof Operational Faults in Cloud Applications by Mining
Causal Dependencies in Logs using Golden Signals, International Conference on Service-Oriented Computing(ICSOC), pp. 137–149 2020.
Arya, V., Shanmugam, K., Aggarwal, P., Wang, Q., Mohapatra, P. and Nagar, S., Evaluation of Causal Inference
Techniques for AIOps, 8th ACM IKDD CODS and 26th
COMAD, pp. 188–192 2021.
Avizienis, A., Laprie, J.-C., Randell, B. and Landwehr,C., Basic Concepts and Taxonomy of Dependable andSecure Computing, IEEE Transactions on Dependable
and Secure Computing, Vol. 1, No. 1, pp. 11–33 2004.
Basiri, A., Behnam, N., De Rooij, R., Hochstein, L.,
Kosewski, L., Reynolds, J. and Rosenthal, C., Chaos
Engineering, IEEE Software, Vol. 33, No. 3, pp. 35–41
2016.
He, S., Zhu, J., He, P. and Lyu, M. R., Loghub: A Large
Collection of System Log Datasets towards AutomatedLog Analytics, arXiv preprint arXiv:2008.06448 2020.
Hightower, K., Burns, B. and Beda, J., Kubernetes: Up
and Running: Dive into the Future of Infrastructure,”O’Reilly Media, Inc.” 2017.
Jacob, V., Song, F., Stiegler, A., Rad, B., Diao, Y.
and Tatbul, N., Exathlon: A Benchmark for Explainable Anomaly Detection over Time Series, the VLDB
Endowment (PVLDB) 2021.
Karumuri, S., Solleza, F., Zdonik, S. and Tatbul, N., Towards Observability Data Management at Scale, ACM
SIGMOD Record, Vol. 49, No. 4, pp. 18–23 2021.
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.
Liu, P., Xu, H., Ouyang, Q., Jiao, R., Chen, Z., Zhang,S., Yang, J., Mo, L., Zeng, J., Xue, W. et al., Unsupervised Detection of Microservice Trace Anomalies throughService-Level Deep Bayesian Networks, IEEE 31st International Symposium on Software Reliability Engineer-c 2021 Information Processing Society of Japan
⃝

[20]

[21]

[22]

[23]

[24]

[25]

[26]

ing (ISSRE), pp. 48–58 2020.
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.
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.
Soldani, J. and Brogi, A., Anomaly Detection and
Failure Root Cause Analysis in (Micro) ServiceBased Cloud Applications: A Survey, arXiv preprint
arXiv:2105.12378 2021.
Soldani, J., Tamburri, D. A. and Van Den Heuvel, W.J., The pains and gains of Microservices: A Systematic
Grey Literature Review, Journal of Systems and Software, Vol. 146, pp. 215–232 2018.
Wang, L., Zhao, N., Chen, J., Li, P., Zhang, W. and Sui,
K., Root-Cause Metric Location for Microservice Systems via Log Anomaly Detection, IEEE International
Conference on Web Services (ICWS), pp. 142–150 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.
Wu, L., Tordsson, J., Acker, A. and Kao, O., MicroRAS:
Automatic Recovery in the Absence of Historical Failure
Data for Microservice Systems, IEEE/ACM 13th International Conference on Utility and Cloud Computing(UCC), pp. 227–236 2020.
Wu, L., Tordsson, J., Elmroth, E. and Kao, O., MicroRCA: Root Cause Localization of Performance Issues
in Microservices, IEEE/IFIP Network Operations andManagement Symposium (NOMS), pp. 1–9 2020.
Zhou, X., Peng, X., Xie, T., Sun, J., Ji, C., Li, W. andDing, D., Fault Analysis and Debugging of Microservice Systems: Industrial Survey, Benchmark System, andEmpirical Study, IEEE Transactions on Software Engineering 2018.
Zhou, X., Peng, X., Xie, T., Sun, J., Ji, C., Liu, D., Xiang, Q. and He, C., Latent Error Prediction and Fault
Localization for Microservice Applications by Learningfrom System Trace Logs, the 27th ACM Joint Meeting on European Software Engineering Conference andSymposium on the Foundations of Software Engineering, pp. 683–694 2019.

70