オブザーバビリティの実現にログデータが重要な理由

想像してみてください。組織が運用するプラットフォームで問題が発生しているようです。サービスが停止したのかもしれませんが、定かではありません。幅広いユーザーが影響を受けているのか、重要なユーザーのみがサービスを利用できないのかもわかりません。いずれにしても重大な問題です。ユーザーは苛立ち、プラットフォームを利用できない不満をX (旧Twitter)で拡散し始めています。しかし、従来のサイロ化した監視ツールはいずれも落ち着いています。各種のダッシュボードは、すべてが順調で、プラットフォームのコンポーネントはどれも円滑に機能し、調査すべき問題はないと知らせています。

これは決して珍しい話ではありません。ではなぜ、このようなことが起きるのでしょうか。それは、従来の監視アプローチでは今日の環境にうまく対応できないためです。プラットフォームの標準的なメトリクスをポーリングによって定期的(数分単位など)に取り込み、トランザクションのトレースデータをサンプリングする方法では、場合によっては、利用可能なデータ全体の5%程度しか収集できず、ログに含まれる豊富なインサイトを取りこぼしてしまいます。このアプローチは大きな盲点を生み、プラットフォームに問題があるかどうかを判断するために必要なデータが欠落して、「ダッシュボード上ではすべて順調」という状態に陥るのです。さらに、ログから十分な情報が得られないと、トラブルシューティングが長引くことにもなります。

OpenTelemetryを導入してオブザーバビリティを実現すれば、オブザーバビリティの3本の柱と言われるメトリクス、トレース、ログの3種類のテレメトリを収集および分析して、最新のデジタルプラットフォームを適切に管理できます。ポーリングのアプローチを廃止し、ストリーミング技法によってメトリクスをリアルタイムで取り込み、独自に追加したメトリクスと組み合わせることで、プラットフォームで問題が起きているかどうかをすばやく判断できます。また、サンプリングを行わず、すべてのトレースを完全忠実な状態で収集および分析することにより、問題の発生箇所を正確に突き止め、ログから根本原因を探り出すことができます。特に最後の点は、今日のデジタル環境で重要度が増しています。ログデータを活用すれば、プラットフォームに悪影響を及ぼしている問題の根本原因をすばやく特定できます。ログデータにはコンテキストに関する情報が含まれており、そのコンテキスト情報こそが、問題の真の原因を理解する手がかりとなります。

あまり知られていないかもしれませんが、ログデータを調べれば、プラットフォームに関するさまざまな疑問の答えが得られます。システムの動作のコンテキストや、ITチーム、マーケティングチーム、ビジネスチームにとって有益なインサイトも獲得できます。さらにAI/機械学習機能を組み込めば、獲得したコンテキストやパターンに基づいて予測を行い、今後障害を引き起こしそうな要因を特定したり、データの異常やパターンを検出したりすることもできます。データを相関付けてプラットフォームに関する疑問を解消すると、そこからまた新たな疑問が浮かび、さらにデータから答えを得るといった連鎖が生まれます。Splunkではこれを「雪だるま効果」と呼んでいます。

このブログでは、ログデータを組織レベルで活用するうえで直面しがちな課題について取り上げます。組織の環境が大規模になるほどさまざまな困難が伴いますが、構造化データと非構造化データの両方の管理について深い知識と長い実績を持つSplunkを使えば、包括的なオブザーバビリティを実現し、ログが持つ潜在力を最大限に引き出すことができます。

ログとは？

ログは、コンピューターシステムや通信システムが自身の状態やその変化に関する情報を伝えるために生成する、任意の長さの英数字文字列による記録です。今日の最新のプラットフォームを管理するうえでログやログデータが重要なのは、こうした情報が含まれるためです。一方で、ログデータには、標準や一般的な規則が存在しないという課題があります。データの記述方法は開発者やベンダーによってさまざまで、取り込み方法、解釈方法、利用方法にも統一性がありません。あるシステムのエラーコードが別のシステムではまったく違う意味になることもあります。さらに、ログはシステムごと、アプリケーションごと、そして今日の最新のプラットフォームではマイクロサービスごとに異なり、柔軟性が高すぎて複数の解釈が生じることがあります。

ログデータ活用の課題

ログデータの活用を難しくする要因はいくつかあります。

1. 非構造化データ：組織全体で見ると、データは非常に膨大かつ多様で、前述のとおり保存方法に関する統一された基準がありません。1つのシンプルなIPアドレスが、異なるデータセットのさまざまなフィールドに収められていることもあります。多くのデータは構造化されていないため、データの意味について構造から探ることはできません。逆に言えば、データが表現する内容に制限がないということです。そのため、どのようにしてこれらの大量データを効果的に抽出し、そこから意味やコンテキストを引き出すかが問題になります。
2. 収集：多様かつ大量のデータを収集するため、組織は、それぞれ独自のアプローチに基づく複数のツールやエージェントを使用しています。この場合、ツールによっては、あらかじめ決められた重要データしか収集されなかったり、処理できるデータ量に制限があったりして、データによる可視性が大きく低下する可能性があります。また、データが各ツールや収集エンジン内にとどまるため、サイロ化することにもつながります。
3. 相関付け：複数のツールを使ってデータを収集し、異なる場所に保存している場合、データの相関付けが大きな問題になります。さまざまな場所に分散する大量のデータを、大規模に相関付けるにはどうすればよいでしょうか。これを手動で行おうとすると、貴重な人的リソースを浪費することになります。また、その作業は困難を極めるため、頻繁には行えないでしょう。
4. 保存：大量のデータを保存するためのストレージと機構にはコストがかかります。複数のツールを使用している場合はなおさらです。さらに、データをセキュリティ脅威から保護する必要もあります。
5. パフォーマンス：データの取り込み、処理、アクセスのスピードは、特に組織レベルでデータ活用を推進する場合、重要な課題です。

これらいずれの課題も、放置すると同じ結果に行き着きます。つまり、データが活用されず、データに含まれる重要な情報やコンテキスト情報を見逃すことになります。

ログ、データ、コンテキストの関係

オブザーバビリティの世界でよくある誤解は、Kubernetes、Java、アプリケーションのログなど、特定のタイプのログのみが重要であるというものです。しかし実際には、カスタマイズしたデータセットを含め、環境内のあらゆる種類のデータセットが非常に重要です。そのため、Splunkが「ログ」と言うとき、それは、環境内にあるあらゆる種類のデータセットを意味します。真のオブザーバビリティはコンテキストによって支えられ、コンテキスト情報はこうしたあらゆるデータから引き出されます。そのため、プラットフォームの可視化においてコンテキストを獲得し、根本原因をすばやく突き止めるために、オブザーバビリティの3本の柱の1つであるログが重要になるのです。

データの価値を引き出してコンテキスト情報を獲得するために必要な要素

Splunkは、オブザーバビリティとセキュリティのどちらの用途でも、ログやその他の主要データの活用について20年以上の実績を持ち、評価の高いデータプラットフォームを提供しています。オブザーバビリティ実現のためにログの価値を引き出し、メトリクスやトレースと包括的に統合して、容易に相互参照できるようにすることで、迅速なトラブルシューティングによる根本原因の特定を支援します。Splunkのデータプラットフォームは、以下の独自の原則に基づいて構築されています。

• 読み込みにおけるスキーマ：Splunkのデータプラットフォームでは、取り込むデータの形式を意識する必要がありません。すぐにデータを取り込んで活用を開始できます。
• SPL：Splunkが長年にわたって開発してきたこの実績あるプログラミング言語を活用すれば、データに対する迅速なサーチ、クエリの実行、グラフ化、計算の実行、データの補強によるコンテキストの強化、Machine Learning Toolkitを使った異常の検出、データの今後の動きの予測など、幅広い処理を実行できます。 
• 相関付け：環境全体でデータを活用するうえで大きな課題の1つとなるのは、異なるデータセットの相関付けです。たとえば、あるユーザーIDが別のデータセット内にあるか調べたい場合、Splunkなら簡単に対応できます。読み込みにおけるスキーマのアプローチにより、複数のデータセットを一元的に扱えるため、SPLによるサーチ時にデータをすばやく相関付けできます。
• 大量データの取り込み：Splunkでは、この処理を「GDI」(Getting Data In)と呼び、あらゆる形式のデータを取り込むことができます。Splunk、テクノロジーベンダー、Splunkコミュニティが開発した2000以上のテクニカルアドオンとAppがSplunkbaseで提供されているため、それらを使って作業をさらに効率化することもできます。取り込みでは、エージェントを利用する以外に、エージェントレスのアプローチ(後述)を採用することもできます。

• 保存：Splunkは複数の保存方法に対応しているため、組織にとってデータを最も安全かつ低コストで保存できる方法を選択できます。
• パフォーマンス：Splunkのデータプラットフォームでは、特許取得済みのテクノロジーにより、環境内のさまざまなタイプのデータセットを高速に取り込み、処理、保存、分析、および表示することができます。

データの活用方法

Splunkに取り込んだデータは、さまざまな用途に活用できます。

• 迅速なトラブルシューティング：環境内で発生した問題の原因を、データに基づいてすばやく特定できます。Kubernetes Podのメモリーで繰り返される問題、存在しないオブジェクトの参照、開発者独自のエラーメッセージ、アプリケーション内のユーザーパスとインフラ層で発生した問題との関係などを調べたいときに、すべてのデータを利用でき、データソースが相関付けられていれば、簡単にデータをたどって、問題の症状ではなく、根本原因を突き止めることができます。
• 分析：ログとデータを活用して、組織のプラットフォームに関する主要なコンテキストを、設定と動作の両方の観点から把握できます。Splunkでは、このコンテキスト情報に基づいて、ユーザーがプラットフォーム内でどのような操作を行ったかを分析し、プラットフォームの利用状況や最新のマーケティングイベントでの目標の達成状況などに関するインサイトを獲得できます。SplunkのSPLを使えば、データセットをさらに詳細に分析できます。
• セキュリティ：上記のデータを再利用して、プラットフォームをセキュリティの観点で可視化することもできます。Splunkには、すぐに導入できるユースケースが豊富に用意されているため、プラットフォームに対する脅威をすばやく特定し、問題に対処して、最終的にはDevSecOpsを実現できます。

データの取り込み(GDI)

あらゆるデータを取り込めるだけでも十分なメリットがありますが、Splunkではさらに、取り込み前にデータを制御、フィルタリング、処理することもできます。それを実現するのが、Splunk Edge Processorです。Splunkで使う構文はSPLに統一されているため、1つの構文を幅広いデータ入力に適用できます。目的ごとに複数の言語を覚える必要はありません。Splunk Edge Processorではさらに、大規模ストリーミングデータに対応する強化版のSPL「SPL2」を利用できます。SPL2の新機能について詳しくは、こちらをご覧ください。Splunk Edge Processorを利用すれば、不要なデータをフィルタリングによって排除したり、ストレージを節約するためにデータを重複排除したり、取り込み前にデータを加工したりして、ストリーミングデータにETLと同じような処理を簡単に行うことができます。これによって、環境をより効率的に可視化し、データ活用をさらに強化できます。また、Splunkでは、Metric Pipeline Management (MPM)テクノロジーを使って、メトリクスの取り込みにおいても同様の優れた管理機能を実現できます。 

ログ、データ、メトリクス、トレースの統合

データをメトリクスとトレースの両方と包括的に統合することで、組織のプラットフォーム全体を詳細に可視化し、単一のユーザーインターフェイスで表示できます。たとえば、メトリクスによって問題が検出されたときは、関連するログデータまで簡単にドリルダウンしてコンテキストを確認し、問題の根本原因を調べることができます。同様に、トレースの調査でも、関連ログデータの自動フィルタリングによって簡単にドリルダウンできるため、根本原因をすばやく特定して、問題の平均解決時間を短縮できます。もちろん、逆方向の調査も可能です。選択したログから、対応するトレースやメトリクスに戻ることで、リクエスト実行時の処理に関する追加のコンテキスト(リクエストを処理したマイクロサービスとコードのバージョンなど)や、メトリクスの観点でのシステムの動作状況(Kubernetes Podでの「ノイジーネイバー(うるさい隣人)」問題など)を確認できます。また、Splunkでは、ログからメトリクスを生成することで、データに基づいて重要情報を追跡し、レポートを作成することもできます。さらに、Splunkには機械学習/AIエンジンが組み込まれているため、データを分析して異常を検出したり、パフォーマンスのベースラインを設定したり、トラブルシューティングでアシスタントを利用して根本原因をすばやく特定したり、過去のデータに基づいて今後のパフォーマンスを予測したりすることもできます。

まとめ

データを活用することは、最新のプラットフォームを可視化するために不可欠です。また、トラブルシューティングと問題解決を迅速化して、プラットフォームの可用性を高く維持するためにも役立ちます。これにより、開発チームは、トラブルシューティングやコードの修正にかかる時間を節約して、イノベーションの推進に集中できます。

このブログはこちらの英語ブログの翻訳、 山村 悟史によるレビューです。