さくらインターネット研究所の坪内（@yuuk1t）です。
2024年3月に、さくらインターネット研究所から投稿した学術論文が、アメリカ合衆国に本部を置く電気・情報工学分野の学術研究団体（学会）、技術標準化機関であるIEEEの、査読付き国際オープンアクセスジャーナル「IEEE Access」に採録・掲載されました。掲載された論文の情報は次の通りです。
- 書誌情報：Yuuki Tsubouchi, Hirofumi Tsuruta, MetricSifter: Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications, IEEE Access (ACCESS) , Vol. 12, pp. 37398-37417, March 2024.
- 論文のファイル: https://ieeexplore.ieee.org/ielx7/6287639/6514899/10462133.pdf
- ソースコードとデータセットのリポジトリ： https://github.com/ai4sre/metricsifter
さくらインターネット研究所では、以前より、機械学習や統計解析技術を用いて、クラウドのシステム障害管理（インシデント管理とも呼ばれる）を自動化する研究を行ってきました。障害管理は、主にクラウドを用いたオンラインサービスの信頼性に着目するソフトウェア工学分野「SRE（Site Reliability Engineering）」が取り扱う重要課題です。
障害管理の自動化に関する我々の研究活動の中で、国際的な学術機関の媒体に掲載された論文は、本論文が初となります。以降では、本論文の概要を紹介します。
本論文が取り上げる問題
クラウドコンピューティングの普及に伴い、社会インフラとしてのクラウドを用いたオンラインサービスへの依存が高まっています。しかし、クラウド上に展開されたアプリケーション（以降、クラウドアプリケーション）の大規模化・複雑化により、障害発生時の迅速な原因特定が難しくなっているのが現状です。
クラウドアプリケーションの運用では、各コンポーネントで計測されるテレメトリデータの一種である監視メトリクス（CPU使用率、メモリ使用量、レスポンス時間など）をもとに、システムの健全性を監視します。障害発生時には、これらのメトリクスデータから異常を示すメトリクスを見つけ出し、障害箇所を特定する必要があります。
しかし、アプリケーションが大規模になるほど監視メトリクスの数は膨大となり、そのすべてを人手で分析するのは現実的ではありません。また、障害の影響は複雑に波及するため、異常を示すメトリクスが多数存在する一方で、必ずしもそのすべてが障害の根本原因とは限りません。つまり、障害と関連の薄いメトリクスを自動で取り除く「特徴量削減」が、迅速かつ的確な障害特定には不可欠です。
従来の特徴量削減手法の課題
従来の特徴量削減手法には、大きく2つのアプローチがあります。1つ目は「冗長性削減」で、メトリクス間の相関関係をもとに類似のメトリクスを取り除く手法です。2つ目は「正常性削減」で、統計的手法により正常時から逸脱したメトリクスのみを残す手法です。
しかし、冗長性削減は障害関連メトリクスを誤って削除してしまう可能性があります。一方、正常性削減では障害時間帯を的確に絞り込めず、無関係な異常メトリクスを残しすぎてしまうことがあります。障害特定の精度向上には、これらの課題を克服する新たな特徴量削減手法が必要です。
提案フレームワーク「MetricSifter」の概要
我々が提案する「MetricSifter」は、メトリクスの時系列データに現れる「変化点」に着目することで、上記の課題を解決します。障害発生時、その影響は関連メトリクスに次々と波及するため、障害関連メトリクスの変化点は時間的に近接して現れる傾向があります。その例を論文内のFIGURE 1.に示しています。 MetricSifterは、この変化点の時間的近接性を手がかりに、障害時間帯とそこに含まれる異常メトリクスを高精度に絞り込みます。
メトリクスの変化点検知とその密度推定を組み合わせることで、MetricSifterは「障害時間帯」を自動的に特定します。これにより、障害発生前後の正常時データを人手で設定する必要がなくなり、特徴量削減の自動化が可能となります。さらに、変化点の時間的近接性を利用することで、障害関連メトリクスを的確に選別でき、これまで課題となっていた誤削除や削り残しのリスクを大幅に低減できます。
MetricSifterの詳細
本論文のFIGURE 4.は、MetricSifterの全体像を示しています。故障箇所特定アルゴリズムは、クラウドアプリケーションのサービスレベルを示すSLI（Service Level Indicator）などの監視メトリクスの異常によって障害を検出し、データの複雑さを軽減し、潜在的な故障箇所をピンポイントで特定するステップ・バイ・ステップのアプローチです。最終的な出力は、考えられる障害原因を示唆する一連のメトリクスであり、これをエンジニアが調査して問題に対処します。特徴量削減は、故障を検出し、故障を特定するための中間プロセスです。
MetricSifterは、次の3つのステップで特徴量削減を行います。本論文のFIGURE 5.は、特徴量削減の各ステップの処理例を図解しています。
ステップ1：変化点検知
各メトリクスの時系列データに対し、統計的手法を用いて変化点を検出します。本研究では、計算量の少ない平均シフトモデルを用いることで、大量のメトリクスを効率的に処理できるようにしています。
ステップ2：変化点の密度推定
検出された変化点の時間的分布を推定します。具体的には、カーネル密度推定（KDE）を用いて、変化点の時間軸上の密度分布を求めます。これにより、変化点が集中している時間帯を特定できます。
ステップ3：障害時間帯の選択
密度分布が最も高いセグメントを障害時間帯として選択します。このセグメントに変化点をもつメトリクスを障害関連メトリクスとみなし、それ以外のメトリクスを削減します。
以上の処理により、MetricSifterは障害関連メトリクスを自動的に絞り込むことができます。特に、変化点の時間的近接性に着目することで、従来手法では困難だった障害時間帯の特定を可能にしている点が、本手法の大きな特長です。
実験結果
我々は、MetricSifterの有効性を評価するため、シミュレーションと実アプリケーション（Sock ShopとTrain Ticket）から得た２種類のデータセットを用いました。特徴量削減として、既存の定番の手法は存在せず、既存論文が前処理として記載しているアルゴリズムを選択しています。シミュレーションによるデータセットで評価した結果、個々のメトリクスが障害に関連するかそうでないかの分類性能指標において、MetricSifterは0.981という高い精度を達成し、既存手法を大きく上回る性能を示しました。
さらに、MetricSifterと既存の故障箇所特定手法を組み合わせたところ、障害関連メトリクスの再現率が最大22.4%改善し、障害特定の処理時間も大幅に短縮されました。特徴量削減により問題空間を絞り込むことで、アプリケーション全体のメトリクスを対象とする場合と比べ、障害特定手法の性能を引き出せることを確認しました。
MetricSifterのパラメータ設定
MetricSifterには、変化点検知のペナルティ重みパラメータと、密度推定のバンド幅パラメータという2つの主要なパラメータがあります。我々は、これらのパラメータがMetricSifterの性能に与える影響を詳細に分析しました。分析の結果を本論文のFIGURE 9. (a)に示しています。
分析の結果、バンド幅パラメータ(h)は比較的ロバストで、広い範囲で安定した性能が得られることが分かりました。一方、ペナルティ重みパラメータ(ω)は性能への影響が大きく、障害の種類によっても最適値が異なる場合があることが示されました。
ただし、FIGURE 10.で示したように、たとえパラメータωが最適値からずれていてもも、ステップ2と3の処理により性能劣化が抑えられることも明らかになりました。これは、MetricSifterがパラメータ設定に対してある程度頑健であることを示唆しています。
MetricSifterの限界
一方で、MetricSifterにはいくつかの限界も存在します。
1つ目は、障害関連メトリクスの変化点の近接性が低い場合です。障害の影響が緩やかに波及するケースでは、変化点が時間的に離れて現れることがあります。このような場合、MetricSifterでは一部の障害関連メトリクスを見逃す可能性があります。
2つ目は、変化点が検出されない障害関連メトリクスへの対応です。例えば、リソース枯渇に近い状態で性能劣化が発生する場合、リソースメトリクスの変化は緩やかで変化点として検出されないことがあります。MetricSifterを含む正常性削減手法は、このような異常を捉えられない可能性があります。
また、本実験では、障害シナリオが限定的であったことにも留意が必要です。実環境では、より多様な障害パターンが存在するため、MetricSifterの性能がどの程度一般化できるかは、さらなる検証が求められます。
これらの限界を踏まえ、今後はMetricSifterをより多様な障害シナリオで評価していくとともに、変化点検知の精度向上や他の特徴量削減手法との組み合わせなど、手法のさらなる改良を進めていく必要があります。加えて、特徴量削減後のメトリクスをどのように障害特定に活用するかについても、引き続き研究が必要なテーマです。
特徴量削減のスケーラビリティの課題
様々な特徴量削減手法を用いて実験する中で、障害に無関係なメトリクスを削減したとしても、実験で用いた6種類の故障箇所特定法では、十分な精度を達成できないケースがあることに気づきました。本論文の実験では、1,000以上の監視メトリクスを含むデータセットでは、top-5までの再現率は0.2以下となりました。しかし、より最新の故障箇所特定モデルを用いることで、精度の問題を解決できる可能性はあります。
むすび
本論文では、人間のエンジニアや機械学習モデルが故障箇所を特定するために必要なテレメトリデータの「解析負荷」とも呼べる負荷の増大を課題として取り上げています。解析負荷が増大すると精度の低下を招いたり、解析時間が増大してしまいます。そこで、テレメトリデータのうち監視メトリクスの解析負荷を低減させるため、我々は、障害に関連しない不要なメトリクスを削減可能な特徴量削減フレームワークMetricSifterを提案しました。
本論文では、MetricSifterの出力を故障箇所特定アルゴリズムに渡すことを想定しています。その一方で、障害発生時にその障害固有の監視ダッシュボードを生成することも応用として可能です。また、大規模言語モデル（LLM）を用いて障害診断を自動化する最新の手法1に対して、LLMのプロンプトサイズの使用量を削減するために、監視メトリクスを削減することにも応用できる可能性があります。
今後も監視メトリクスに限らず、その他のテレメトリデータの解析負荷は重要な課題であり続けることが予想されるため、テレメトリデータの特徴量削減にも取り組んでいきたいと考えています。