「Observability(オブザーバビリティ)」「可観測性」とは何か――クラウドネイティブにおける監視で必要な理由と考慮点、お薦めのOSSの組み合わせ:Cloud Nativeチートシート(13)
Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、「Observability(オブザーバビリティ)」「可観測性」について概要と考慮点、お薦めのOSSの組み合わせを紹介する。
※岡本、正野、宇都宮はNTTデータ所属
Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。連載第9回から第12回までは「サービスメッシュ」「Istio」を紹介してきました。今回から複数回に分けて「Observability(オブザーバビリティ)」「可観測性」にフォーカスして解説します。
今回は、Observabilityの概要と、その構成要素や考慮点を紹介し、次回以降Observabilityを構成する各要素に活用できるオープンソースソフトウェア(OSS)とその使い方を説明していきます。
目次
クラウドネイティブなシステムの監視の課題と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には下図で表現されています。
これらのシグナルが3本柱とされている理由には、複雑化したクラウドネイティブなアーキテクチャにおいて問題箇所の把握が従来型の監視だけでは難しく、ログやトレースとひも付けなければ問題の特定に至らないといった事情があります。それぞれ独立した要素ではなく、適宜ひも付けたり、変換したりしながら探索、可視化できることが重要です。上図で、各シグナルがそれぞれオーバーラップしているのはこういった理由からです。
ここからは、3本柱とその他取り上げられることのあるシグナルについて、それぞれのシグナルが何を指しているのか」「どういった観点が重要なのか」について簡単に説明ます。
なお、それぞれのシグナルのより具体的な使い方や実現技術(OSSなどのツール)については、別途次回以降の連載で触れます。
メトリクスとは?
関連記事
- New Relicがアプリの問題解決で開発者を助ける新機能、「開発者は本来の仕事に集中できる」
New Relicの日本法人が可観測性プラットフォームで新機能「New Relic CodeStream」を発表した。 開発ツールを離れることなくソースコードの問題箇所を特定し、チーム内で情報を共有して迅速に解決できるという。 - AWS、障害注入試験に向くフルマネージドサービス「AWS Fault Injection Simulator」を正式リリース
AWSはシステムに意図的に障害を発生させる障害注入試験に向いたフルマネージドサービス「AWS Fault Injection Simulator」の一般提供を開始した。CPUやメモリの使用量の急増といった破壊的なイベントを発生させてアプリケーションに負荷をかけ、システムの反応を監視して、改善できる。 - ユーザーの幸福度を定量化――SLI、SLO実践の4ステップ
SREは計測、自動化など取り組むことが多く、求められる知識量も少なくない。また周囲の理解が得られなければ、組織でSLI、SLOを定義してSREを実践するのも容易ではない。組織でSREに取り組む最初の一歩をどう踏み出せばいいのか。
Copyright © ITmedia, Inc. All Rights Reserved.