著者 | 坪内 佑樹(*1), 鶴田 博文(*1), 古川 雅大(*2) |
---|---|
所属 | (*1) さくらインターネット株式会社 さくらインターネット研究所、(*2) 株式会社はてな |
研究会 | 第7回Webシステムアーキテクチャ研究会 |
2010年代のクラウド技術であるコンテナオーケストレーション、サーバーレス、マイクロサービス、さらにはエッジコンピューティングなどの普及により、分散システムとしての複雑度が高まっている。このまま複雑度が高まっていくと、人手によるルールベースの運用にいずれは限界が訪れるのではないかと考えている。そこで、最近は、このようなクラウドを中心とするSRE分野の課題に対して、機械学習やその他の数理的アプローチを適用するアプローチを模索している。特に、SREの中でも、システムに発生する異常への対応については、現場のエンジニアの経験に基づき直感に大きく依存している。
異常への対応を構成する要素を分解すると次のようになる。
https://speakerdeck.com/yuukit/slo-based-causality-discovery-in-distributed-applications?slide=12
この中でも、異常箇所の特定については、特に現場の経験に依存することが多かろうと考え、自動で異常箇所を探索する技術を研究している。その研究の第1歩が以下に述べる、性能異常を検知したときに迅速に原因を診断するためのシステムの一部品となる時系列データの次元削減手法TSifterである。異常の発生に対して、その異常を表現するための刹那的なシステムの特徴を反応的に抽出することが目的となる。次の図が最終的に実現したいシステムの全体像となる。
この次元削減手法に関するWSA研での口頭発表内容を次のスライドに公開する。
1. はじめに
ソフトウェア開発者が多数の機能を日々追加することにより、アプリケーションのコード規模が増大するため、変更を加えるときに問題があった場合の影響がアプリケーション全体に及ぶようになる。変更の影響範囲を小さくするために、昨今のクラウド上に展開されるWebアプリケーションのアーキテクチャはマイクロサービスアーキテクチャへと変遷している。マイクロサービスは、巨大な一枚岩のアプリケーションを複数の異なる小さなサービスに分解し、疎結合な状態にした上で、分解された各サービスが協調して動作するアーキテクチャをとる。
Webサービスの高信頼化のためには、サービスの性能に異常が発生したときに、異常の根本原因を迅速に特定しなければならない。しかし、そのためには次の3点の問題を解決する必要がある。
- 依存関係の複雑化: マイクロサービスは、分散された構成要素を多数のサーバホスト上に展開するため、構成要素間のネットワーク通信関係は従来の構成よりも複雑となる。システムに異常が発生したときに、構成要素間の異常が伝搬するため、異常の伝搬経路も複雑化する。マイクロサービスにおけるサービス数は数百から数千にまで増大しているケースもあるため、それらのサービスの性質や関係性をシステム管理者が記憶することも難しい。
- ソフトウェアの動的な変更: マイクロサービスでは、個々のサービスが頻繁に更新されることから、異常の発生確率と負荷傾向の変化頻度を増大させる。
- メトリック数の増大: 構成要素数の増大により、システムの性能やリソース消費量を定量的に示すためのメトリックの個数が増大する。
これらの要因により、システム管理者にとってシステムを認知するための負荷が増大するため、異常の原因を診断するために時間を要するようになる。したがって、システム管理者が異常の原因を迅速に特定できる手法が必要となる。
先行手法では、まず、メトリック以外のデータソースである、各構成要素が出力するテキストログを用いたログベースのアプローチ1と、各構成要素間の呼び出し関係や応答速度を追跡する実行経路トレースベースのアプローチ2,3がある。しかし、すべての異常の動作が記録されるわけではなく、計測のためにアプリケーションのソースコードを修正する手間があることから、情報の網羅性と適用性に課題がある。次に、複数の構成要素を横断したメトリック間の因果関係を検定することにより、システム内の異常の伝播経路を自動で推論するメトリックベースのアプローチ4-9がある。しかし、このアプローチは、診断に利用するメトリックをシステム管理者が一つあるいは複数個に指定しなければならないため、より原因に近いメトリックが探索結果から除外される可能性がある。そのため、診断に有用な情報を迅速に得るためには、できる限り多くの関連するメトリックを高速に解析する必要がある。
本研究では、マイクロサービスにおいて、異常の伝播経路を自動で推論するための基盤を提供することを目的に、異常発生時に観測されたすべてのメトリックから診断に有用なメトリックを高速に抽出可能な次元削減手法であるTSifterを提案する。TSifterは、まず、各メトリックに対して、時系列データの定常性を検定し、定常性を有するメトリックを事前に除去することにより、異常発生前後で傾向が変化したメトリックを抽出する。次に、時系列グラフとして類似の形状をとるメトリックをクラスタリングしたのちに、各クラスタから代表メトリックを選出することにより、メトリックを集約する。
異常発生前後で傾向が変化したメトリックは、そうでないものと比較し、原因を示すメトリックである可能性が高いため、原因の診断に有用となる。さらに、クラスタリング処理はメトリック数が増加するにつれて、計算量が増加するため、メトリックの事前除去により、クラスタリング処理を高速化できる。また、事前除去とクラスタリングの2つの異なる次元削減法を適用することにより、単一の次元削減法と比較して、より高い次元削減性能を得られる。
TSifterを評価するために、Kubernetesクラスタ上に構築したマイクロサービスのテストベッド環境に故障を注入する実験を行った。実験の結果、TSifterは、ベースライン手法に対して、原因であるメトリック(原因メトリック)が除外されていないことを示す正確性、次元削減性能、およびメトリック数とCPUコア数に対するそれぞれの実行時間のスケーラビリティに対して、それぞれ同等程度の性能を有しながらも、270倍以上高速に動作することを確認した。
2. 関連研究
性能異常が発生したときの原因診断手法として、メトリック以外のデータソースを利用するアプローチとメトリックを自動解析するアプローチがこれまでに提案されている。
メトリックベースの自動解析アプローチは、複数の構成要素を横断したメトリック間の因果関係を検定することにより、システム内の異常の伝播経路を自動で推論する。このアプローチは、メトリックをノードとして因果関係グラフを構築した上で、システム内の最前段の構成要素を起点に因果の伝播経路を探索する。Qiuらの研究5とMicroscope8は、事前に選択した単一または複数の種類のメトリックとサービス間の呼び出し関係や複数のシステム階層の従属関係を示すシステムトポロジ情報を事前情報として利用する。AutoMAP4、MS-Rank6およびCloudRanger7は、システムトポロジー情報を必要とせず、複数種類のメトリック情報のみを用いて、因果関係グラフを構築する。これらのアプローチは、メトリックの収集のためにアプリケーションコードに修正を加える必要がないため、システムへの適用性が高い。しかし、いずれの手法もシステム管理者が単一または複数の種類のメトリックを事前に選択しておく必要がある。
Sieve10は、迅速な原因診断を目的としてはせず、オートスケールの指標などに恒常的に利用するための代表メトリックを抽出するために、メトリックの次元削減手法を提案している。Sieveは、事前の負荷テストにより、観測されたメトリックを構成要素ごとに時系列クラスタリングにより次元削減した上で、クラスタ内の代表となるメトリックを選択する。しかし、Sieveを異常発生時の迅速な原因診断に応用する場合、事前の負荷テストで顕在化できなかった異常のケースには対応できない。
3. メトリックの次元削減手法
TSifterの概要
(図1: TSifterの概要図)
図1はTSifterの概要図である。TSifterは、異なるアルゴリズムを適用してメトリックの次元削減性能を高めるために、2段階のステップに分けて、メトリックを次元削減する。
1段階目は、原因となるメトリックを除去させない範囲で次元削減性能を高めるために、異常発生前後に収集した全てのメトリックの定常性を検定し、定常性を有するメトリックを除外する。
2段階目は、1段階目で残った非定常のメトリックに対して、データの形状の類似性に着目した距離尺度を用いてクラスタリングを適用する。その後、さらなる次元削減性能向上のために、各クラスタからそのクラスタを代表するメトリックを選定する。 TSifterは、マイクロサービスにおけるサービス単位でクラスタリングすることを想定する。
ステップ1: 個々のメトリックの定常性に着目した次元削減
異常に関連するメトリックは、異常発生後にメトリックの値が増加、減少、不安定化するなど、異常発生前後でデータの傾向が変化するはずである。 そのため、異常に関連するメトリックは、データの平均および分散が時間によらず一定、かつ自己共分散が時間差のみに依存する性質である定常性を満たさず、非定常性を示す。この洞察に基づき、TSifterでは、異常に関連しないメトリックを除去するために、定常性の検定を用いてメトリックが定常性を有するかを判別し、定常性を有するメトリックを除去する。
TSifterは、収集した全メトリックに対して、定常性の検定を行い、除外するかどうかを決定する。メトリックの定常性の検定には、広く用いられている検定手法の一つであるAugmented Dickey-Fuller(ADF)検定を採用する。ADF検定は、あるメトリックから算出したp値が有意水準を下回り帰無仮説が棄却された場合、対立仮説である「データの定常性」が採択され、メトリックは定常性を有すると判定できる。TSifterは、ADF検定により定常性を有すると判定されたメトリックを全て除去する。
ステップ2: メトリック間の形状類似性に着目した次元削減
マイクロサービスにおける各サービスで収集するメトリックの中には、メトリック同士が互いに強く相関しており、時間の推移に対して同様の傾向で変動するものが存在する。例えば、単位時間あたりのネットワーク送信バイト数とネットワーク送信パケット数は、値の単位は異なるが、時間に対して概ね同様の変動傾向を示す。このようなメトリック群は、異常の診断において冗長な情報であり、メトリック群の中からどれか一つのみを抽出すれば十分である。この洞察に基づき、TSifterではクラスタリングにより同様の変動傾向をもつメトリックを集約し、その中から代表メトリックを一つ抽出して他のメトリックを除外する。代表メトリックは、クラスタ全体の特徴をよく反映するために、クラスタ内のメトリックで、それ以外のメトリックとの距離の総和が最小になるメトリックであるmedoidを選出する。また、TSifterは、マイクロサービスにおけるサービス単位でメトリックを集約してクラスタリングを実行する。
異常の診断のための有用な情報をシステム管理者に提供するためには、同様の変動傾向をもつ冗長なメトリックをなるべく多く集約、除外することでメトリックの削減数を高める必要がある。クラスタリングにおいて、どのようなデータを類似性が高いと判断し、同一クラスタに集約するかは、データ間の非類似度を表す距離の定義に依存する。時系列データであるメトリックの変動傾向の類似性を捉えるためには、メトリックの形状に着目することが有効である。メトリックの形状の類似性を考慮した距離の定義は、メトリック値の軸方向へのスケールと時間軸方向へのシフトに対する不変性を満たす必要がある。TSifterでは、メトリック値の軸方向へのスケールに対する不変性を満たすために、メトリックを平均0、分散1に標準化する。時間軸方向へのシフトに対する不変性を満たすために、標準化したメトリック間の距離をshape-based distance(SBD)11に基づき算出する。
TSifterは、マイクロサービスの性能異常時の原因診断に活用することを想定しているため、クラスタリングの処理には高速性が要求される。メトリックをクラスタリングする際に、いくつのクラスタに分けるのが適当であるかは事前に決定されておらず、その時々のメトリックの変動傾向によって変わりうる。このようにクラスタ数が事前に決定されていない場合には、最適なクラスタ数を決定するための処理が必要がある。k-means法を始めとした非階層的クラスタリングは、最適なクラスタ数を決定するためにクラスタ数を変化させて繰り返しクラスタリングを実行し、情報量基準などに基づき最適なクラスタ数を決定する。一方、階層的クラスタリングは、1回のクラスタリング実行後に、最適なクラスタ数を決定できるため、非階層的クラスタリングに比べてクラスタ数を高速に決定できる。以上の理由から、TSifterでは階層的クラスタリングを採用する。
4. 実験と評価
本章では、実験用に構築したマイクロサービス環境にて、手動で故障を注入する実験を行った結果を用いて、TSifterの次元削減の正確性、次元削減性能、および高速性を評価する。
実験の環境と設定
(表1: テストベッドにおけるハードウェアとソフトウェア構成)
テストベッド 実験のためのテストベッド環境は表1の通りである。 本実験では、Kubernetesクラスタの自動管理サービスであるGKE(Google Kubernetes Engine)上に構築したクラスタ上に、マイクロサービスのベンチマークアプリケーションであるSock Shopを構築した。 Kubernetesクラスタは5台のWorkerノードから構成されており、5台の内4台をマイクロサービスを配置するためのサービス用途、残り1台をデータ収集と負荷生成のための管理用とした。
ベンチマークアプリケーション Sock Shopは靴下を販売する電子商取引Webサイトを模したデモアプリケーションである。Sock Shopは、front-endサービス、catalogueサービス、cartsサービス、userサービス、paymentサービス、shippingサービスの計7個のマイクロサービスから構成されている。各マイクロサービスのコンテナの複製数は1に設定した。
データ収集 Prometheusにより、各コンテナからCPU利用量やメモリ使用量、ファイルシステム使用、ディスクI/O、ネットワークI/Oなどの物理資源とミドルウェアの性能や論理資源に関するコンテナレベルのメトリックを収集した。また、各マイクロサービスから平均応答時間と時間あたりの処理リクエスト数などのサービスレベルのメトリックを収集した。Prometheusのメトリック収集のインターバルを5秒に設定した。
負荷生成 Sock Shopアプリケーションに対して、擬似的な負荷を生成するために、Locustを利用した。本物の利用者がサイトのトップページからカタログ一覧を取得し、その中から商品を選び、注文するまでの典型的なフローを模倣するようなシナリオを記述し、シナリオを読み込ませて負荷を生成した。
故障注入 Locustによる負荷を生成している間に、実際のマイクロサービスにおける性能異常を模倣するために、関連研究のMicroScopeの実験で共通して採用されている故障を注入した。特定のコンテナ内のCPU負荷が100%となる故障を注入するために、stress-ngを利用した。また、特定のコンテナと通信するネットワーク遅延が増大する故障を注入するために、tc(Traffic Control)を利用した。
ベースライン手法 TSifterを評価するためのベースライン手法として、関連研究の中で唯一メトリックの次元削減手法を提案しているSieveを選択した。Sieveは、変動の少ないメトリックを除去するために、分散値の小さいものを除去したのちに、時系列クラスタリング手法を用いて、構成要素ごとにその構成要素を特徴を最もよく表す代表メトリックを抽出している。Sieveの目的は、本研究の目的とは異なるが、本研究の目的に対して有効な手法でもある可能性を評価する。
TSifterとベースライン手法の実装 両手法ともにPythonを用いて実装した。TSifterにおいて、ADF検定における有意水準は0.05、最短距離法におけるクラスタ併合の距離の閾値は0.01を用いた。CPUのマルチコアによる高速化のために、両手法ともに、全体の実行時間への寄与度が高いタスクを、互いに依存のない小さなタスクに分割し、マルチプロセスで処理するように実装した。
評価指標 TSifterの要件に、メトリックのクラスタリング後に原因メトリックが削減されないことがある。その上で、どの程度次元削減できているかを示す次元削減性能と、高速性の要件から次元削減処理の実行時間の評価が必要となる。そのためにまず、各故障注入時のメトリックを次元削減した結果、正解となるメトリックが次元削減後に残留しているかをTSifterとベースライン手法の両者で正誤を確認する。次に、次元削減率を評価するために、各故障ケースにおけるメトリックの次元削減率をベースライン手法と比較する。最後に、高速性を評価するために、特定の故障ケースにおいて、CPUコア数の増加と、メトリック数の増大に対して、次元削減処理の実行時間の変化を確認する。実行時間の計測値として、TSifterでは5回試行した結果の平均値を採用した。ベースライン手法では、実行時間の都合により、1回試行した結果の値を採用した。
microservices-demo リポジトリに、テストベッド環境の構築と実験に利用した各種設定ファイルとソースコード、およびデータセットを公開している。
実験の結果
表2に示す各故障ケースに対して、1メトリックあたり360個のデータ点に対して、TSifterとベースライン手法を適用することにより、マイクロサービスごとに複数の代表メトリックを選出した。故障を注入したサービスの代表メトリックが、表2に示す各故障ケースに対する代表メトリック候補のいずれかに該当することを以って、性能異常の特徴を表すメトリックを正しく抽出できたこととする。表2より、TSifterは全てのケースに対して正しく代表メトリックを抽出した一方で、ベースライン手法はshippingサービスのCPU過負荷のケースのみ正解でないメトリックを代表として抽出した。
表3に、userとshippingサービスへの各故障注入ケースに対するメトリックの次元削減数と削減率を示す。/で区切られた数値は左から元のメトリック数、事前除去後のメトリック数、クラスタリング後の代表メトリック数となる。いずれの手法、いずれのケースにおいても次元削減率は90\%を超えており、削減後のメトリック数は1/10以下となった。また、TSifterとベースライン手法を比較すると、shippingサービスのCPU過負荷のケースを除いて、ベースライン手法のほうが高い次元削減率を示した。
(図2: CPUコア数に対する実行時間の変化 (左)ベースライン (右)TSifter)
ハードウェアのリソース量を増加させたときに、実行時間をどの程度短縮できるかを確認するために、TSifterとベースライン手法のそれぞれについて、CPUコア数に対する実行時間の変化を確認した。メトリックの個数を1545個、メトリックあたりのデータ点数を360個で固定した上で、利用するCPUコア数を1から4まで増加させたときの実験結果を図2に示す。図2より、TSifterとベースライン手法はそれぞれコア数に反比例して実行時間が変化していた。また、TSifterの実行時間は、いずれのコア数においてもベースライン手法の270倍以上となった。
(図3: メトリック数増に対する実行時間の変化 (左)ベースライン (右)TSifter)
メトリック数を増加させたときのTSifterの実行時間の変化を図3に示す。CPUコア数を8、データ点数を360に固定した上で、横軸のメトリック数を1,000から100,000まで増加させた。メトリック数を増加させたデータを作成するために、既存の7サービスのメトリックを複製し、サービス数を擬似的に増加させた。実験の結果、メトリック数に対して実行時間が線形に増加し、メトリック数100,000において244.87秒で処理を完了できている。また、TSifterの実行時間は、いずれのデータ点数においてもベースライン手法の315倍以上となった。
実験の考察
正確性 本実験の範囲内において、ベースライン手法は誤ったメトリックを代表として選択した一方で、TSifterは全てのケースにおいて正しく代表メトリックを選択できたことから、TSifterのほうが性能異常の特徴を表したメトリックを削減させないと言える。しかし、本実験では、故障を注入したサービスの種類や故障ケースも限定的であったため、その他の故障ケースやサービスに対してTSifterが有利であるとは言えず、現時点では同等程度の正確性であると評価する。
次元削減率 次元削減率に関する実験の結果、ベースライン手法のほうが次元削減率が高い結果とはなったが、いずれもメトリック数を1/10以下に削減できたため、TSifterとの大きな差はなく、同程度の削減性能といえる。
高速性 実行時間に関する実験の結果、TSifterはメトリックの個数と実行時間は線形に増加する一方で、CPUコア数に対して実行時間が反比例した。したがって、メトリックのデータ量が増加しても同割合の計算リソースを追加することにより、実行時間を維持できる。ベースライン手法と比較し、TSifterのほうが最低でも270倍以上高速に動作したため、TSifterのほうが高速性の要件を満たすと言える。
なぜTSifterが高速なのか TSifterと比較し、ベースライン手法はクラスタリング処理のための実行時間が長い。ベースライン手法では、クラスタ数を変化させながら繰り返しk-Shapeを実行し、最適なシルエットスコアに基づき、クラスタ数を決定している。すなわち、クラスタ数を決定するために複数回クラスタリングを実行する必要がある。一方、TSifterにおける階層的クラスタリングでは、クラスタリング実行後に距離の閾値を用いてクラスタ数を決定できるため、クラスタリングの実行回数は1回のみである。このクラスタリングの実行回数の違いが、TSifterとベースライン手法の実行時間の差の主な原因となっている。
5. まとめと今後の展望
本研究では、マイクロサービスにて性能異常が発生したときの原因をシステム管理者が迅速に診断することを目的に、大量のメトリックから診断に有用なメトリックを抽出するための次元削減手法TSifterを提案した。マイクロサービスのテストベッド環境にてTSifterを評価した結果、TSifterは、ベースライン手法に対して、正確性、次元削減率、およびメトリック数とCPUコア数に対するそれぞれの実行時間のスケーラビリティでは、同等程度の性能をもち、最低でも270倍以上の高速性をもつことがわかった。TSifterは、10万メトリックのデータに対しても1分程度の時間で実行可能であり、計算リソースの追加投入によりさらに高速化可能である。
今後は、システム管理者が利用可能なシステムを実現するために、TSifterを性能異常の原因診断システムへ組み込むことを検討する。具体的には、メトリックベースの自動解析アプローチと同様に、各構成要素において、抽出された代表メトリック同士の因果関係を判定することにより、性能異常がシステム内をどのように伝搬したかを追跡可能とするといったシステムがありえる。
その他の今後の課題は次の通りとなる。
- マイクロサービス以外にネットワーク層のシステムなどの異なる階層のシステムへの応用。
- より広範囲の故障ケースやシステムに対するTSifterの正確性の評価は今後の課題とする。
- 時系列データの問い合わせ処理を含めた実行時間の評価。
- 最短距離法におけるクラスタ併合の距離の閾値を統計的根拠をもっての決定。
参考文献
- [1]: Lin, Q., Zhang, H., Lou, J.-G., Zhang, Y. and Chen, X., Log Clustering based Problem Identification for Online Service Systems, IEEE/ACM 38th International Conference on Software Engineering Companion (ICSE-C), pp.102–111 2016. ↩
- [2]: 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. ↩
- [3]: 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. ↩
- [4]: Ma, M., Xu, J., Wang, Y., Chen, P., Zhang, Z. and Wang, P., AutoMAP: Diagnose Your Microservice-based Web Applications Automatically, The Web Conference (WWW), pp. 246–258 2020. ↩
- [5]: Qiu, J., Du, Q., Yin, K., Zhang, S.-L. and Qian, C., A Causality Mining and Knowledge Graph Based Method of Root Cause Diagnosis for Performance Anomaly in Cloud Applications, Applied Sciences, Vol. 10, No. 6, p. 2166 2020. ↩
- [6]: Ma, M., Lin, W., Pan, D. and Wang, P., Self-Adaptive Root Cause Diagnosis for Large-Scale Microservice Ar- chitecture, IEEE Transactions on Services Computing (TSC) 2020. ↩
- [7]: Wang, P., Xu, J., Ma, M., Lin, W., Pan, D., Wang, Y. and Chen, P., CloudRanger: Root Cause Identifi- cation for Cloud Native Systems, IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID), pp. 492–502 2018. ↩
- [8]: Lin, J., Chen, P. and Zheng, Z., Microscope: Pinpoint Performance Issues with Causal Graphs in Micro-Service Environments, International Conference on Service-Oriented Computing (ICSOC), pp. 3–20 2018. ↩
- [9]: 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. ↩
- [10]: Thalheim, J., Rodrigues, A., Akkus, I. E., Bhatotia, P., Chen, R., Viswanath, B., Jiao, L. and Fetzer, C., Sieve: Actionable Insights from Monitored Metrics in Distributed Systems, the ACM/IFIP/USENIX Middleware Conference (Middleware), pp. 14–27 2017. ↩
- [11]: Paparrizos, J. and Gravano, L., k-Shape: Efficient and Accurate Clustering of Time Series, The ACM Special Interest Group on Management of Data (SIGMOD), pp. 1855–1870 2015. ↩
WSA研での質疑
Q1. クラスタリングの処理時間がメトリック数に対して線形になるのはなぜか?
一般にはクラスタリングの処理時間は、要素数に対して線形にはならないはずなのはそのとおり。ただし、本研究では、メトリック数を増加させるために、マイクロサービスのサービス数を増加させている。現実にも単一のマイクロサービス内のメトリックが増加するというよりは、このようなメトリックの増え方になるはず。マイクロサービス内でクラスタを構成していることから、マイクロサービス内でメトリックは増加させていないため、線形増加となる。
Q2. クラスタリングにより重要なメトリックが抜け落ちるという懸念はあるか?
懸念はあるが、この次元削減手法のユースケースでは、ワークアラウンドで十分対応できると考えている。 想定ユースケースは、マイクロサービス単位の因果関係を推定することなので、マイクロサービス内でメトリックが抜け落ちたとしても、因果関係が正しければそれでよい。また抜け落ちたメトリックをみたい場合は、監視ツールのビューに、抜け落ちたメトリックを表示させるといったワークアラウンドがありえる。
Q3. 時系列データのホワイトノイズが定常性の判定やクラスタリングに影響を与えるのではないか
Q4. クラスタリングの距離とは相関か?相関であれば,時系列データのようなノイジーなデータではほとんど相関がゼロになってしまうようなことは起きないか
SBDと呼ばれる時系列の形状の類似性をクラスタリングの距離尺度として利用している。時系列の形状を荒くみることによって、ノイズ(ギザギザ)を扱っているため、相関がゼロになるようなことは起きていない。
質疑やSlack内でのコメントをみながら、既存のデータ分析手法に対しての差異を考えると、異常検知前の過去n分(実験だと30分)のみに絞って分析することにより、刹那的な(特定の異常に特化した)システムの特徴を抽出するのがやはりこの研究の要点だなと思えてきた。その他、Invariant Analysisやkmeans++、プロセスマイニングなど知らなかった用語を教えてもらった。