今注目される「オブザーバビリティ（observability、可観測性）」とは
クラウドネイティブNow
廣石 真也
富士通株式会社
ソフトウェアオープンイノベーション事業本部 アプリケーションマネジメント事業部
マネージャー
はじめに
最近、「オブザーバビリティ（observability）」という言葉を耳にすることが増えました。監視やモニタリングのソリューションを従来から提供する企業（SplunkやNewRelicなど）がオブザーバビリティについて紹介するページを公開したり、Gartner社が2023年の戦略的テクノロジのトップ・トレンドに「オブザーバビリティの応用」を挙げるなどで注目を集めています。
オブザーバビリティは”観測”を意味する「observe」に"能力”を意味する「ability」を繋げた「observability」という言葉であり、簡単に言えば「ログ」「トレース」「メトリクス」などを収集することを指します。皆さんから「ログやトレースなら今でもすでにシステム保守用に取っているよ。何を今さら難しい言葉を使って騒いでいるのか。」という言葉が聞こえてきそうです。確かに「observability」という言葉自体は1960年にすでに登場しています。では、なぜ今「observability」が注目されているのでしょうか？
本ページではオブザーバビリティについて解説します。
オブザーバビリティが求められる背景
オブザーバビリティ（observability）という言葉がはじめて使われたのはThoughtWorks社のRudolf Kalman氏が1960年に発表した「On the General Theory of Control Systems（注1）」に遡ると言われています。この論文の冒頭では、システムが進歩や改良されてきた一方で、発生した問題の多くが対処されてきたが本質の解決になっていないことに対する解決策としてオブザーバビリティが語られています。
では、最近のシステムの進歩と改良が期待されていることとは何でしょうか？それは「クラウドネイティブ」の分散型システムが普及してきたことにあります。
独自にシステムを構築しなくても、クラウドサービスを利用することにより、システムで実現したいことを容易に手に入れることが可能となりました。各システムのサービスをAPIとして公開し、他社のサービスも活用してビジネスの可能性を広げていくAPIエコノミーの可能性も広がっています。システム自体も従来の3階層システムではなくマイクロサービス化することで、顧客のニーズに素早く対応できるようにモダナイゼーションする動きもあります。
しかし、このクラウドネイティブの動きによってシステムは複雑化し、運用管理が複雑になり、トラブル発生時の原因究明に時間がかかることが危惧されたことで注目されているのが、複雑化したシステムを観測可能とする今回のテーマのオブザーバビリティです。
オブザーバビリティが注目されていることを受けて、2023年10月にCloud Native Computing Foundation（CNCF）から「Observability Whitepaper」（注2）というホワイトペーパーが公開され、オブザーバビリティの定義やベストプラクティスがまとめられています。クラウドネイティブにおけるオブザーバビリティはまだ発展途上であるため、今後ドキュメントも改版されていくと思われますが、本ホワイトペーパーを参考にオブザーバビリティの概要を説明します。
-
注1
-
注2
監視・モニタリングとの違い
こ従来の監視・モニタリングは異常が発生した場合の状況を予測して以下のような場合にアラームを通知します。オブザーバビリティを語る際に、旧来の監視・モニタリングのことを一般的に「しきい値」により異常を検出することだと語られます。
- シスログにエラーメッセージが出力された
- メモリ使用量が90%を超えた
- 応答性能が想定の80%を下回った
上記のようなしきい値の設定は、システム要件を元にシステム運用者が監視設計するのが一般的でした。
クラウドネイティブで複雑化したシステムでも従来の監視・モニタリングは必要ですが、すべての異常を事前に予測することは困難です。また、各種サービスが複雑に連携されている場合には、一部のサービスの異常が他のサービスの異常を引き起こし、さらに別のサービスの異常を引き起こすというカスケード異常と呼ばれる異常の連鎖が起きた場合には、異常を追跡して原因を特定するのも難しくなります。
このため、オブザーバビリティではサービス利用者を意識して、UX（ユーザーエクスペリエンス）を含めたサービス全体を可視化し、サービスが正常に稼働している状態と比較した変化に早期に気づき、それがなぜ起きたのかを早期に解析し、異常が起きる前にサービス性の低下を未然に防止することが求められます。
オブザーバビリティを実現するには、システム運用者とアプリケーション開発者がサービス公開後の状態を意識合わせし、可視化が必要な情報をアプリケーションが出力する機能の作り込みも検討が必要となります。ホワイトペーパーでは「 Companies that once had a culture where Administrators and Developers had conflicting goals must change to a new culture where they now must work together as a single team aiming to build reliable software. 」と記載されており、運用者とアプリケーション開発者が密に連携する（いわゆるDevOpsの）組織文化への変更も必要となると説明しています。運用者とアプリケーション開発者間のコラボレーションを円滑化するサイト信頼性エンジニアリング（Site Reliability Engineering（SRE））という取り組みの必要性もよく語られます。新機能や修正を積極的に適用しようとするアプリケーション開発者と、システムの安定運用を維持することを優先する運用者の間を仲介し、オブザーバビリティシグナルを分析してビジネスやユーザー体験に与える影響から適切な新機能や修正の適用タイミングを設計します。
ホワイトペーパーでは収集する情報を「シグナル」と呼んでいます。従来の監視・モニタリングでは、監視するのはCPU使用率やメモリ使用量などのシステムリソースや応答性能などの性能情報が一般的でしたが、オブザーバビリティのシグナルはサービスごとに異なります。
例えば、Googleの以下のページでは、Webページのロードが1秒から3秒に増加すると、バウンス率が32%増加すると言われています。バウンス率は、日本では「直帰率」と呼び、ユーザーがWebサイトを訪れた時に、最初に参照したページだけを見てそのサイトを去ってしまった割合のことです。
ECサイトでは、ページのロード時間の低下がビジネス機会の喪失につながることになるため、商品紹介サイトのWebページのロード時間をシグナルとして扱うことが考えられます。このようにユーザーの実際の体感時間をモニタリングすることをReal User Monitoring （RUM）などと呼びます。
従来の監視・モニタリングとオブザーバビリティの違いを感じていただけたでしょうか？以下に違いをまとめてみます。
| 項目 | 監視・モニタリング | オブザーバビリティ |
|---|---|---|
| 情報収集対象 | サーバーのシステムリソースなど | ユーザーの体感情報など |
| 設計 | システム運用者が監視対象を設計 | システム運用者とアプリケーション開発者が収集情報を設計 |
| 分析 | 異常状態を予測して閾値でアラートを挙げる | サービス全体の状態をリアルタイムに可視化する |
| 行動 | 通知されたアラートに対して異常を調査するリアクティブな行動 | 可視化された状態を人間もしくは自動化された仕組みを使って正常状態との変化から事前に異常を未然に防止するプロアクティブな行動 |
主要なシグナル（primary signals）
一般的にオブザーバビリティのシグナルはメトリクス、ログ、トレースの「3つのオブザーバビリティの柱（Three Observability Pillars）」と語られますが、必ずしも3つとも必要というわけではないため、ホワイトペーパーでは主要なシグナルと呼んでいます。また、3つ以外にイベントやプロファイルやダンプなどオープンソースコミュニティなどを中心に色々なシグナルについて議論されています。
以下はホワイトペーパーに掲載されている図です。
-
出典
ここでは、ホワイトペーパーで説明されているシグナルの概要を説明します。
メトリクス（Metrics）
顧メトリクスは、データを数値で表現したものです。すでに数値データであるものと、数値として集約されたデータの主に2つのカテゴリに分類されます。
例えば数値データであるものとしては特定時刻のメモリ使用量やCPU使用率、数値として集約されたデータは1分間に受け付けたHTTPリクエスト数などです。ホワイトペーパーではメトリクスは以下の2つの方法で使用されるとされています。
- リアルタイムの監視とアラート（Real-time monitoring and alerting ）
視覚的なダッシュボードの概要と、ダッシュボードに表示された情報を詳細な情報にドリルダウンしていくような使用方法です。また、閾値を超えた、または異常な動作をしているというアラートまたは通知するためにも使用されます。 - 傾向分析と分析（Trending and analysis）
時間経過に伴う傾向分析や長期計画の目的にも使用されると同時に、インシデントが発生した後に、再発を防ぐための根本的な問題の修正と監視を考察する情報も提供します。例えばリクエスト数が増加するとCPU使用率が増加するなど。
一般的には「何が（what）」起きているかを示し、問題の根本原因を見つけるための大まかな概要と出発点を提供します。
トレース（Traces）
トレースはユーザーによって開始されたリクエストにより、トランザクション中にどのマイクロサービスやデータストアにアクセスして、どの程度アクセス時間がかかったかというトランザクション中に何が起きたかを示す情報です。
トレースはガントチャートで表現されたりします。一般的には処理が「どこで（where）」で起きているかを示し、問題個所の追跡に利用します。
ログ（Logs）
ログは、オペレーティング システム、アプリケーション、サーバー、または別のデバイス内で実行された操作と、操作結果を示します。
エラー（ERROR）、警告（WARNING）、情報（INFO）、デバッグ（DEBUG）などの種別があります。一般的には処理が「なぜ（why）」実行されてどんな結果を返却したかを示し、トラブルシューティングや異常原因の特定に役立ちます。
プロファイル（Profiles）
パフォーマンス・メトリクスを可能な限り詳細なレベルで理解することが重要となり、CPUプロファイルなどCPUの動きを詳細に把握するようなプロファイル情報が必要となる場合があります。
一般的にプロファイル情報を収集すると、オーバーヘッドが大きいため、本番環境での実行には適していないと考えられていました。しかし、サンプリング プロファイラーのツールに注目が集まり、本番環境でプロファイリングが利用されることも多くなりました。
ダンプ（Dumps）
ソフトウェア開発における、コアダンプファイルはクラッシュしたプロセスのトラブルシューティングに使用されます。オペレーティングシステムは、異常時の分析のためにクラッシュ時のプロセスのメモリのイメージを書き込みます。
プロセスがクラッシュするような異常では、処理の途中で予期せぬ異常で発生するためログに異常情報を出力することなく処理が中断されて異常の特定が困難です。このような場合に異常の特定に有益なシグナルがダンプとなります。
以上がホワイトペーパーで取り上げられているシグナルです。
典型的な利用イメージとしては、メトリクスで何（what）の異常を検知し、トレースでどこ（where）が原因か追跡し、ログでなぜ（why）異常が発生しているか確認するということになりますが、メトリクスで異常が発生する原因が分かることがあります。 上記以外にも「イベント」というシグナルの必要性を求める声もあります。
例えば、システムに導入したシステムの修正適用を実施したというイベントやシステムの計画メンテナンスのためにシステムを一時的に停止したというイベントが考えられます。確かにこれらのイベント時にサービスのスローダウンなどが発生する可能性は大いにありますので、イベントをシグナルとして扱った方が良いシステムはありそうです。このような、システムによって求められるシグナルは異なり、システム稼働中に追加で採取が必要なシグナルに気づくことも大いに考えられます。
今後に向けて
クラウドネイティブにおけるオブザーバビリティは標準化が始まったばかりですが、急速に進んでいます。オープンソースではOpenTelemetry（注3）でオブザーバビリティを管理する標準実装を提供しており、Java技術ではMicroprofile Metrics（注4）でMicroprofileのアプリケーションからOpenTelemetryを利用する仕組みの規約化が進んでいます。システム設計する上で、サービス提供後にユーザーの満足度を図る際に求められるシグナルを検討し、アプリケーションでシグナル収集を実装する際に、十分な情報を収集するのを手助けする技術やツールを探してみてください。
-
注3
-
注4
まとめ
ビジネスの拡大により、顧客ニーズに素早く対応することが求められる状況において、サービスの顧客体験を可視化するオブザーバビリティは今後更に必要となるでしょう。
しかし、オブザーバビリティを検討する際には、システム開発において運用者とアプリケーション開発者との縦割り組織の変更なども必要となり、むやみに収集する情報が多くなると、多くの情報から意味ある情報を探し出すことが難しくなる場合が考えられます。オブザーバビリティの目的を組織変更の必要性を含めて関係者間で十分に議論してください。
関連製品・サービス
当社が提供するデジタルトランスフォーメーションを支えるアプリケーションサーバー「Fujitsu Software Enterprise Application Platform」の詳細は下記ページをご覧ください。
本コンテンツに関するお問い合わせ
お電話でのお問い合わせ
Webでのお問い合わせ
当社はセキュリティ保護の観点からSSL技術を使用しております。
