オブザーバビリティ成熟度の頂点とその先

この記事はMackerel Advent Calendar 2024の23日目の記事です

はじめに

世の中には多くのオブザーバビリティ製品が存在しています。
オブザーバビリティ(可観測性)の重要性を、多くの会社が訴えています。
Mackerel Advent Calendar 2024にもオブザーバビリティ向上に貢献する話が多く書かれています。
筆者がWebアプリケーションエンジニアとして所属しているMackerelも同様です。

そんな中、オブザーバビリティの活用度を測る指標として、「オブザーバビリティ成熟度」という言葉を使うことがあります。
New RelicやAWS、Grafanaなど、色々な会社が独自に定義していますが、おおまかに「データを収集している->活用できている->進歩的な手法が実践できている」と進んでいくのは共通しています。

では、それらが出来ていればオブザーバビリティを完全に活用できていると言えるのでしょうか。
オブザーバビリティ成熟度の最高点より先には何があるのでしょうか。

この記事は、オブザーバビリティを高めた先に開けてくる、オブザーバビリティを応用した、未来の当たり前をのぞき見する記事です。

オブザーバビリティ成熟度の先

オブザーバビリティがあり、システムの状態を把握できるようになった世界で、品質を更に向上させるために、人類は機械に何を期待するでしょうか。
オブザーバビリティ成熟度が最高になったとき、より良くするために何ができればよいでしょうか。

機械に期待する能力を大別すると、下のように分けられるでしょう。

平常時に期待する能力
異常時に期待する能力
異常を解決した後に期待する能力
能力を向上させるための能力

それぞれについて例と一緒に見ていきましょう。

※ 紹介する論文やWebページは理解を手助けするためのものであり、妥当性や実現可能性、評価を検証していないことに注意してください。

平常時に期待する能力

まずは、平常時に期待する能力について。

異常を予測する能力

異常が起きそうだとわかれば、異常が発生する前に対処することができます。
リソースが足りなくなる兆候を見つけられればリソースを追加することができますし、ハードウェアの劣化を予測できれば故障前に取り替えることができます。

マイクロソフトは、そんな予測に挑戦しています。
「Predictive and Adaptive Failure Mitigation to Avert Production Cloud VM Interruptions」によると、ノードの劣化を検知してVMを別ノードへ移動しているそうです。

リソース最適化する能力

リソースを自動で調整することができれば、インフラコストを削減したり、消費電力を抑えることで環境に貢献する、など出来ます。
CPU利用率などの閾値を事前に設定することで使用量を調整することが一般的ですが、システムが複雑になるほど最適解を決めることが難しくなります。
機械に代替させたい能力です。

たとえば、esDNNのように将来のリソース量を予測することができれば自動でスケーリングをすることができるでしょう(esDNN: Deep Neural Network Based Multivariate Workload Prediction in Cloud Computing Environments)

異常を検知する能力

オブザーバビリティの先に期待する能力として、異常検知は特に人気のある能力です。
異常を早く見つけることができれば、システムに異常がある期間を短縮できます。

異常検知は長い歴史があり、多くの実装が存在しています。
例えば、GrafanaはPrometheusで異常検知を行うライブラリを提供しています。

しかし、異常検知は未だに利用しづらい分野でもあります。
たとえば、「How Industry Tackles Anomalies during Runtime: Approaches and Key Monitoring Parameters」には、シンプルなルールベースの異常検知が好まれている理由として、「計算コストが低い」「ドメイン知識を入力しやすい」などが挙げられています。

このような課題を乗り越えることが必要です。

異常時に期待する能力

前章は平常時に期待する能力を見てきました。
異常が起きた時にも活用したいですね。

異常の原因を発見する能力

異常の原因を発見することは、RCA(根本原因分析)とも呼ばれ、異常に関する問題としては花形です。
しかし、原因と一口に言っても特定する対象は多くあります。
異常のあるサービスを特定することが目的だったり、異常なノードの発見を目的にしたり。
他にも、URLやデプロイ、パラメータ、コードなど、原因と言えそうなものは何でも対象になります。

たとえばMeta(Facebook)は、アプリで実行した操作などからクラッシュ原因を特定しようとしています(Scalable Statistical Root Cause Analysis on App Telemetry)

また、「Unsupervised Detection of Microservice Trace Anomalies through Service-Level Deep Bayesian Networks」では、正常なトレースを基にサービス間のコールグラフを事前に学習した後、正常時との乖離をリアルタイムに分析することで異常の原因を特定しています。

異常を解決してくれる能力

異常の原因を発見するだけでなく、治す能力にも期待したいところです。
ノードに問題が起きている場合に再起動したり、デプロイに問題がありそうならロールバックするなど、異常を自動で解決してくれると助かります。

たとえば、Deoxysは観測した情報をもとにダウンタイムを最短にする操作を選択し、実行するそうです。

異常の原因を一緒に考えてくれる能力

LLMの勃興により現実的になったのが、「一緒に考える」という能力です。
機械が答えを出すのではなく、人間と機械が一緒に作業するのです。
たとえば、「機械に調査の指示を出し、調査結果をもとに人間が次の指示を考える」、という関係です。

Nissistは、LLMにトラブルシューティングガイドを入力することで、オンコールエンジニアとLLMが協力できるようになっています。
オンコールエンジニアがLLMに状況を説明すると、「調査のためにこのコマンド打って」と返答し、コマンドの結果をLLMに伝えると、更に別のコマンドを考えてくれる。というループを重ねます。
会話を繰り返し、状況が改善できるまで考えてくれる、というものです。