「Observability（オブザーバビリティ）」「可観測性」とは何か――クラウドネイティブにおける監視で必要な理由と考慮点、お薦めのOSSの組み合わせ：Cloud Nativeチートシート（13）

Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、「Observability（オブザーバビリティ）」「可観測性」について概要と考慮点、お薦めのOSSの組み合わせを紹介する。

[堀内保大, 岡本隆史, 宇都宮雅彦, 正野勇嗣，＠IT]

※岡本、正野、宇都宮はNTTデータ所属

　Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。連載第9回から第12回までは「サービスメッシュ」「Istio」を紹介してきました。今回から複数回に分けて「Observability（オブザーバビリティ）」「可観測性」にフォーカスして解説します。

　今回は、Observabilityの概要と、その構成要素や考慮点を紹介し、次回以降Observabilityを構成する各要素に活用できるオープンソースソフトウェア（OSS）とその使い方を説明していきます。

目次

• クラウドネイティブなシステムの監視の課題とObservability
• Observabilityの構成要素（シグナル）
• メトリクスとは？
  • メトリクスの要素――「REDメソッド」「USEメソッド」
  • クラウドネイティブなアーキテクチャにおけるメトリクスの難しさ
• ログとは？
  • ログレベル
  • パースとログフォーマット
  • クラウドネイティブなアーキテクチャにおけるログの難しさ
• トレースとは？
  • 呼び出し依存関係のグラフによる可視化
  • 分散トレーシング
• その他のObservabilityシグナル
• Observabilityの各シグナルの取得にお薦めなOSSの組み合わせパターン
• 現時点のObservabilityが抱える課題とそれに対するアプローチ
  • 複数のシグナルを扱う必要がある困難
  • ログやトレースからメトリクスの生成

クラウドネイティブなシステムの監視の課題とObservability

　Observabilityとは、システムを観測可能、つまり「いつ、何が、どこで起こっているのかを観測可能に保つ」考え方です。Observabilityを備えることで、複雑かつ動的にスケールするサービスでも、ワークロードの状態を正しく理解できるので、問題の検出やその根本原因の特定を行えます。

　昨今、Observabilityという概念はクラウドネイティブな技術スタックの一つとして言及、検討されることが増えています。「CloudNative Difinition」や「マイクロサービスアーキテクチャパターン」の中にもそれぞれの技術要素の一つとして、Observabilityという単語が登場します。このことからも、クラウドネイティブな分散アーキテクチャを考慮する上で重要な概念となっていることが分かります。

　なぜObservabilityはこういったクラウドネイティブ技術と一緒に語られることが多いのでしょうか？　クラウドネイティブなシステムにおける監視の課題は、Kubernetesを例に取ると下記のようなシステムの複雑さによる課題があり、これらの課題をはらんだシステムを安定的に運用するには適切な技術を用いて「いつ、何が、どこで起こっているのかを観測可能に保つ」必要があるからです。

• 分散した多くのコンポーネントが多層に組み合わさる（複数のNode上で稼働する複数のPod）
• 下記2点の背景から、自動的にPodやNodeなどのコンポーネントをトラッキングする仕組みが必要
  • コンポーネントの実行単位であるPodの数がオートスケールによって動的に変動したり、フェイルオーバー時にPod IDが変更されたりするので追跡が困難
  • コンポーネントの追加や変更が頻繁にある
• コンポーネント同士の呼び出しがあると個々のコンポーネントの影響範囲をたどる必要がある

　ここまでふわっと「観測可能に保つ」という表現でObservabilityについて説明しましたが、具体的にはどのような観点でそのような技術を使えばいいのでしょうか？

　Observability自体はこれまでも多く議論され、いろいろな表現で説明されてきましたが、実は「Observability Whitepaper」（※）というドキュメントがCloud Native Computing Foundation（CNCF）から公開されており、Observability自体や要素の定義、ベストプラクティスがまとまっています。

※CNCFのTAG（Technical Advisory Group：特定の技術に対して、技術ガイドを提供するグループ）として、「Observability TAG」が発足しています。2021年にクラウドネイティブのObservabilityの集大成として、用語や定義とベストプラクティスの明文化がされたObservability Whitepaperを公開しました。

　本稿では、こちらのWhitepaperを適宜参考にしながら、Observabilityの要点を押さえていきます。

Observabilityの構成要素（シグナル）

　Observabilityをどのように実現していくかを考える上で重要なのが「何を観測すべきか」という点です。Whitepaperではシステムが生成する出力を「シグナル」と定義しています。このシグナルを観測することで、外部から「システムがどうなっているか」を推測できます。

　Observabilityのシグナルの3本柱として広く認識されているのが、「メトリクス」「ログ」「トレース」です。Whitepaperには下図で表現されています。

Observabilityの3本柱（メトリクス、ログ、トレース）

　これらのシグナルが3本柱とされている理由には、複雑化したクラウドネイティブなアーキテクチャにおいて問題箇所の把握が従来型の監視だけでは難しく、ログやトレースとひも付けなければ問題の特定に至らないといった事情があります。それぞれ独立した要素ではなく、適宜ひも付けたり、変換したりしながら探索、可視化できることが重要です。上図で、各シグナルがそれぞれオーバーラップしているのはこういった理由からです。

　ここからは、3本柱とその他取り上げられることのあるシグナルについて、それぞれのシグナルが何を指しているのか」「どういった観点が重要なのか」について簡単に説明ます。

　なお、それぞれのシグナルのより具体的な使い方や実現技術（OSSなどのツール）については、別途次回以降の連載で触れます。

メトリクスとは？