ログ監視の今後と新たな監視アプローチ

これまでのログ監視による運用

これまでの多くのITシステム監視ではログ監視が重要な役割を果たしてきました。

主にアプリケーションログを監視し、特定のキーワードのメッセージが出力された場合にアラートを発報し、キーワードに応じたアクション（調査やエスカレーション、コマンド実行など）を取るという手法です。

この方法はメッセージとアクションを紐づけるため、運用をあらかじめ設計することができるメリットがありました。しかし、現在はITシステムも組織も変わりつつあり、また変わらざるを得ない状況でもあります。

まずITシステムのクラウドシフトが進んでいます。

クラウドシフトは以前から話題になっていますが、私が実際見聞きするところでは、これまで限定的にシフトしていたところ、本腰を入れ始めたという企業が多くなってきた印象です。

クラウドシフトをなぜ行うのでしょうか。インフラの弾力化、自動化は当然として、アプリケーションのアーキテクチャもモジュール化しクラウドマネージドサービスを活用、果てはマイクロサービス化を目指している、ということをよく聞きます。

もう一つ、組織の面では2025年の崖も現実味を増しています。これには様々な観点がありますが、DXのため上記のクラウドシフトを推進するということもありますし、IT人材不足の対応のために組織体制、外注比率の見直しや、機械学習や自動化を用いたIT運用高度化を進められています。

これからのITシステムに対するログ監視の有効性

このような状況において、これまでのログ監視のアプローチがこれからも有効であるでしょうか？

いくつかの課題が考えられます。

分散システム

クラウドシフトが進むにつれ、ITシステムは分散システムと変わっていきます。例えばこれまでは単一のアプリケーションサーバーだけで完結していた処理が複数のサービス（例えばログイン処理、カート処理、発注処理など）に分散されるようになります。

この観点で考えてみましょう。

問題発生頻度の増加

分散システムにすることでコードの疎結合が進みリリース頻度を向上できるメリットがあります。一方でリリース頻度によりITシステムの安定性が下がるというデメリットもあります。また、構成が複雑になれば、それだけ問題が発生する頻度も向上します。

複雑化

ユーザーのセッションが、これまでは一ヶ所で完結していたものが、複数個所のサービスにまたがり実行されるようになります。ログも複数個所で分散されます。そのときログを集約すれば良いという単純な話では済まず（もちろん集約は大前提です）、調査が困難になります。サービス間は疎結合なため、コンテキストを共有していないからです。

「サービスCで問題発生」とログが発生したとき、どのユーザーのどのトランザクションで発生したのでしょうか？全体的なトランザクションの中でどのタイミングで発生したのでしょうか？また、そのトランザクションは結局、成功したのでしょうか、もしくは失敗したのでしょうか？このような疑問に答えることが非常に難しくなります。

想定外の事象

分散システムにおいて、サービスが多くなり、また各々個別にリリースを続けると、もはや全体像を管理、把握できる者はいなくなります。そうなると小さなコードの変更が場合によっては想定外に影響を及ぼす可能性もあります。つまり、これまではある程度予測された事象に対して、取り得るアクションを想定しログ出力できていたものが、予測不可能な事象にも備えなければなりません。そのような事象に対して意義あるログは出せるでしょうか？

つまり、分散システムにおいては問題発生の頻度が高く、さらに情報も断片化されるためトラブルシューティングの難易度や工数が増大するということです。

全対応

ログ監視はその性質上、「アラートされたものには常に対応」というアプローチを取ることになります。

メッセージによっては静観対応もありますが、いずれもメッセージの内容確認というアクションは発生し、人的リソースを使用します。

障害発生時には得てしてアラートも大量に発生するものです（いわゆるアラートストーム）。例えば通常は1時間に数件のアラート対応の想定で人員を配置していた場合に、障害により1,000件のアラートが発生すると全てのアラートを確認することは不可能です。そうなると運用チームやエスカレーション先もアラート対応でオーバーフローし、麻痺します。さらに、これから先は人員不足の未来があるため、力技で乗り越えるということも難しくなっていきます。

これらの課題を考えると、手を打たなければMTTR（平均解決時間）の悪化によるユーザーエクスペリエンスの低下（そして満足度の低下）と組織の疲弊が推測されます。

監視の進化

一方、監視の考え方もツールも進化しています。いくつか重要な点を見ていきたいと思います。

オブザーバビリティ

大きな観点として「オブザーバビリティ」というものがあります。オブザーバビリティのポイントは以下の通りです。

オブザーバビリティとは、インフラ、アプリ、カスタマーエクスペリエンスのフルスタックにおいて完全な可視性とコンテキストを提供する、モニタリングへの最新のアプローチです。

オブザーバビリティではメトリクス、トレース、ログの「オブザーバビリティの3つの柱」（後述）を使い、フルスタックでの問題の検出やトラブルシューティングを行います。これにより何が変わるか見ていきましょう。

SLO/SLI

オブザーバビリティで得られるデータを用いることでSLO、SLIの計測が可能になります。

SLOとは「Service Level Objective（サービスレベル目標）」の略で「サービスがほとんどの時間帯で達成すると期待されるレベル」、SLIとは「Service Level Indicator（サービスレベル指標）」の略であり「定量的に測定可能な、サービスレベルに関するユーザーの満足度の指標」です。

参考：SLO、SLIとは

SLOの例として、「ショッピングカートのチェックアウト成功率99.99%」、「商品検索のレスポンスタイム3秒以下」などが考えられます。

ログ監視では全量対応してきましたが、SLOではサービスレベルを定義し、リアルタイムで収集したSLIのデータに基づき、SLOを下回る場合、または下回ると予測できる場合にアクションを起こします。このメリットとしては以下が考えられます。

• ユーザー影響を可視化できる

従来は計算機リソースが十分に確保されているかと、ITシステムがエラーを起こしているかに着目してきました。ITシステム上エラーがないことが重視され、ユーザーに影響がなくてもエラーは即時修正されなくてはならず、また、エラーとして通知されなければ、たとえユーザーがITシステムを使えなかったとしても問題ないとされていました。

また、コンテナでは計算機リソースは弾力性を持ち、マイクロサービス間の通信はリトライされ得るため、従来の監視方法は役に立たなくなっています。一方、SLO/SLIでは実際のリクエストデータを分析し、リアルなサービス提供状況を可視化します。これによりアクションのための優先度が明確になります。

• 対応結果を即時確認できる

ログ監視では対応後、問題が解消したかを確かめるため、ある程度の期間待機していました。そして期間経過後、問題が再発しなかったため恐らく大丈夫であろう、として体制を解除します。ステークホルダーとしても、既に対応完了したか？というのも担当者に聞かなければならなかったでしょう。

一方、SLO/SLIでは障害内容にはよりますが改善結果がリアルタイムで可視化され効果が分かります。SLOのダッシュボードに対応履歴（デプロイなど）を同時に表示することにより、ステークホルダーでの情報共有を容易にすることもできます。

• 予測できる

SLIは時系列の数値データです。つまり機械学習を用いた予測も可能になります。これまでは問題が発生してから対応していたものが、悪化が予測されるため事前に対応するというプロアクティブな対応も可能になります。

• 失敗できる余地が生まれる

通常、SLOは99.x%などが設定され、エラー発生を許容します（100%のSLOは達成不可能であり、また設定すべきではありません）。これによりリリースを積極的に行い、SLOに影響が出た場合に修正を行うという迅速性、柔軟性が生まれます。なお、これを適切に管理するためのエラーバジェットという考え方があります。

^{SLOダッシュボードの例}

後編では、オブザーバビリティを使用した場合のトラブルシューティング方法、オブザーバビリティを実践する場合の主なチャレンジ、そしてオブザーバビリティ以外の進化した監視方法を見ていきます。

※後編はこちら → オブザーバビリティのトラブルシューティングと進化した監視方法

もしSplunkのオブザーバビリティソリューションにご関心がある場合は是非お問い合わせいただくか、Splunk Observabilityの製品ページをご覧ください。