オブザーバビリティ（o11y、可観測性）とは？

IDC Japan株式会社は、2023年の国内クラウド市場は売上ベースで前年比29.6％増、2023年～2028年の国内クラウド市場規模の年間平均成長率を16.3％と推計しています。これにより、2028年の市場規模は2022年の約2.1倍に達する見込みと予測します。その要因としては、従来型ITからクラウドへの移行が進んでいることなどが考えられます。一方、企業のDXへの投資は拡大しつつあり、今後はDXが国内クラウド市場を牽引していくという予測もあります。このような状況を受けて、今後はクラウド利用が前提となる、クラウドネイティブ型システムが主流になっていくことは想像に難くありません。

クラウドネイティブ型システムを定義すると、クラウドでのアプリケーション実行やソフトウェア開発などを前提としたシステムとなります。複数のマイクロサービスを組み合わせて1つのアプリケーションを構築することで、複雑かつ動的で伸縮自在のエラスティック（elastic）な分散システムの構成になっています。アプリケーションを機能などの細かい単位で切り分ける構造から、マイクロサービスアーキテクチャとも言われています。似たような言葉で、アプリケーションの実行に必要なクラウドリソースを動的に割り当てるサーバーレスアーキテクチャがあり、用途に応じて使い分けるのが一般的です。

マイクロサービス化したアプリケーションは、コンテナサービス上で稼働します。コンテナとはOS上に論理的な領域を作成することで、アプリケーションの動作に必要なライブラリなどを統合し、OSなどのリソースを論理的に分けることにより、複数のコンテナでリソースを共有して使えるようになります。1つのOS上で複数のアプリケーションが動作する、PCやスマートフォンなどをイメージするとわかりやすいかもしれません。ちなみに、コンテナをシステム的に実行させるソフトウェアをコンテナオーケストレーションと言います。代表的なところでは、Googleが社内で利用していたコンテナ管理ツールを汎用化した、Kubernetesなどが知られています。

クラウドネイティブ型システムに話を戻します。すべて同一のモジュールで作り上げる従来のモノリシック型のシステム構成に比べ、クラウドネイティブ型の分散したシステム構成は機能の追加や変更、スケーラビリティや可用性の確保が容易になるなど、とくにシステムの開発と運用の業務において大きなアドバンテージが生じます。つまり、データドリブンな経営や事業運営、スピーディなDXの推進といった次世代のビジネス展開には、従来型IT（モノリシック型システム）からクラウドネイティブ型システムへの移行が必須と理解してよいでしょう。

従来の監視手法であるモニタリングでは、事前に監視対象として設定したログやCPU、メモリーなどのリソース、メトリクスを収集し、エラーを検知します。しかし、複雑で動的にスケールするクラウドネイティブ型システムでは、従来のモニタリングでは通用しなくなりつつあります。なぜなら、インシデントが発生した場合に原因の特定が困難になるといった問題が起こるためです。

従来のモノリシック型のシステム構成では、アプリケーションのスローダウンや異常停止などが発生した際、構成が明確であり変化することも少ないため、原因の特定は容易でした。しかし、クラウドネイティブな分散システムはサービスが稼働するインフラが多岐に分散し、インシデントが発生した際には全マイクロサービスの動きを追従する必要があります。加えて、各アプリケーションが動的に変化することもあるため、従来のモニタリングでは原因を突き止めるのはきわめて難しくなってくるのです。

こうした問題を解決するために、昨今注目を集めているのが「オブザーバビリティ（Observability）」です。Observe（観察する）とAbility（能力）を組み合わせた造語であり、日本語に翻訳すると「可観測性」や「観察する能力」となります。Oとyの間にある11文字のアルファベットを略して、「O11y」「o11y」と表記されることもあります。オブザーバビリティという言葉自体の歴史は長く、1960年にルドルフ・カルマンが線形力学系の分野で初めて「システム内部の状態を外部出力の情報から推測できる度合いを示す指標」として使用しました。その用語が、近年同じ意味合いでICT分野でも使われるようになってきました。

オブザーバビリティ（observability）は、従来のモニタリングを包含するエンジニアリングの概念です。従来のモニタリングは、ログに吐き出されるエラーメッセージの監視に加え、ログでは判別できない詳細なエラーをAPM（アプリケーションパフォーマンス監視）で監視するなど、「何が起きているのかを見続けること」のみでした。しかし、オブザーバビリティは利用者のUX（User experience：ユーザー体験）を意識して、未知の領域も含めたサービス全体を可視化することで、「予期せぬことが起きたときに、なぜそれが起きたのかを突き止める、UXを損ねる事態が生じる前に対処すること」を目指しています。

従来のモニタリングとの違いは、エンドツーエンドでのフルスタック監視の実現により、未知のインシデント対応、アラート対応が可能になることです。その概要をたとえるなら、ビルなどに設置された異常を検知する「監視カメラ」がモニタリングで、ビル内を巡回して異常の予兆に気づき、原因を突き止め、未然に異常を防ぐ「ガードマン」がオブザーバビリティのようなものでしょうか。

オブザーバビリティを実現するには、データの収集、データの分析、データの可視化という3つのアクションが必要です。そこで、オブザーバビリティではCPU使用率などのリソース状況、レイテンシなどのサービス状況といった定量的な指標となる数値である「メトリクス」、アプリケーション処理で発生するリクエスト構造や各コンポーネントの処理時間である「トレース」、OSやミドルウェア、アプリケーションなどが出力する個別イベントである「ログ」というテレメトリーデータを活用します。

それぞれについて、もう少し説明を加えていきます。「メトリクス」とは、定期的に取得したシステムCPU使用率やメモリー使用量、ネットワークトラフィックなどをグループごとにまとめたデータのことです。メトリクス自体は単なる数値のため、時系列に並べてグラフなどで可視化します。メトリクスは、システムのパフォーマンス測定に適した指標であり、時系列のグラフは従来のモニタリングでも広く利用されてきました。

「トレース」とは、マイクロサービスを構成する複数サービスをアプリケーション処理で発生するリクエスト構造や、各コンポーネントの処理時間などで横断的に監視する機能です。トレースによりマイクロサービス間を横断していくリクエストの追跡や問題箇所の特定、デバッグが容易になります。

「ログ」とは、OSやミドルウェア、アプリケーションが出力するイベントの履歴です。一般的にログは、イベントの内容や付随データをタイムスタンプと一緒にプレーンなテキストの形式で出力します。いつ、何が、システムのどこで起きたのかを把握するためには欠かせないデータがログです。

つまり、メトリクスで「何が起きているか」を秒単位で検知し、トレースで「どこで問題が起きているか」を判別し、ログで「なぜ問題が発生したのか」を究明します。各データを相関づけて連携することで単なるデータ収集ではなく、「どこまで容易に状況を捉えて、事象を正確に把握できるか」「どこまで容易に観測できるか」を担保することがオブザーバビリティの重要なポイントです。そのほかにも、どのようにアプリケーションが実行され、どこでどの程度のリソースが割り当てられたことを示すデータである「プロファイラ」、システムのクラッシュ時に出力されるメモリーデータの「ダンプファイル」を利用する方法もありますが、一般的にメトリクス、トレース、ログがオブザーバビリティの3本柱と呼ばれます。

オブザーバビリティの実現により、ソフトウェアエンジニアやDevOps、SRE（サイト信頼性エンジニアリング）などの担当者がテレメトリーデータを活用できるようになります。なお、SLO（サービスレベル目標：Service Level Objective）などを指標にすることで、よりデバッグが正確かつ容易になります。これにより、いくつかのメリットが得られます。まず、システムのリアルタイムな状態把握や切り分けにより問題への迅速な初動対応が実現され、システムの可用性の向上が図られ、ダウンタイムの短縮やMTTR（平均修復時間）が改善できることです。加えて、アプリケーションのセキュリティも強化できます。そして、ユーザーに対するサービスレベルの維持を容易にすることで、UXも向上できるでしょう。

最近のトレンドとして、オブザーバビリティのプラットフォームにICT運用を目的とした人工知能である「AIOps」を実装するケースも増えています。AIOpsの目的は人に代わってAIが膨大なテレメトリーデータから、どんな問題が起きているか、どこで起きているか、なぜ発生したのかを究明することです。AIOpsの実装により分析などが自動化でき、さらなるオーバーヘッドの削減が実現できます。

オブザーバビリティを実現する統合監視ツール／製品は、各ベンダーから提供されています。一般的な統合監視ツールは、システムのデータをリアルタイムで収集する機能やデータを分析する機能、分析結果を可視化する機能を持ち、複雑で動的にスケールする環境でも、いつ、何が、どこで起きているのかを把握できるようになります。しかし、これらの統合監視ツールを運用に落とし込むのは容易なことではありません。なぜならインシデントの状況を把握できても、それが影響を及ぼす範囲や適切な回復策の見極めが難しく、その結果、属人的なナレッジやドキュメント頼りになってしまうためです。現在、日本では慢性的なデジタル人材不足が深刻化し、さらに複雑化、高度化するICTにアジャストできる質の高いプロフェッショナルも希少化しているため、なおさら運用のハードルは高くなります。

オブザーバビリティを実現する統合監視ツールをお探しなら、手軽に利用できるオープンソースソフトウェアの導入を検討してみてはいかがでしょうか。たとえば、ラトビアのZabbixLLCが開発した総合システム監視ソフトウェア「Zabbix」は、世界的な実績を持つ非常にすぐれたオープンソースソフトウェアです。サーバーからネットワーク、アプリケーションまで一元的な監視が可能。エンドツーエンドのネットワーク監視はもちろん、ログ監視、死活監視（Ping監視）、サービスポート(TCP)監視、CPU使用率監視、メモリ使用率監視、ディスク使用率監視、プロセス監視、トラフィック監視、Web監視などにも対応しています。

機器間の結線情報を束ねて構造情報に変換する「 T-View 」機能などを活用することで、ネットワークを軸にしたシステム全体を俯瞰した稼働状況の可視化も実現可能です。

しかし、オープンソースソフトウェアの導入・運用には専門手的な知識が不可欠です。うまく使いこなすためにZabbixを熟知する信頼できるパートナーの選定が重要になります。

ドコモビジネスが提供するZabbixを用いた統合監視ソリューションが「ZABICOM」です。Zabbixのプレミアムパートナーとして数多くの実績を持つドコモビジネスが、検討段階のコンサルティングから導入、運用、保守までトータルにサポートします。

お客さまに最適な導入プランをご提案します。

新規、移行、コスト削減など、お困りの内容についてZabbix導入から運用設計までコンサルティングします。

最適な監視サーバー構成の選定、調達、構築を支援。監視サーバクラスタ(Act-Act/Act-Standby)、プロキシー、クラウド構成などさまざまな環境に対応します。

監視に必要なエージェントソフトを監視対象サーバーにインストール、各種設定をします。

監視項目に従った監視設定の作成支援をします。

ご要望に応じた個別カスタマイズも対応可能です。

お客さまのNMS(旧Zabbixを含む)から新規構築したZabbix監視システムへの移行を支援します。

ZABICOM(Zabbix)に関するお問い合わせ(使用方法、不具合、故障など)の問題解決をサポートします。

さらにZabbixのトレーニング体制も充実。「Zabbix LLC 認定の研修トレーナー」 を擁しており、スキルアップに向けた認定研修プログラムを定期的に開催しています。

オブザーバビリティのポイントは、UXを意識し、UXを損なう前の迅速な対処にあります。ドコモビジネスの「ZABICOM」なら、きっとスマートに実現できるはずです。