クラウドネイティブ時代に入りつつある現在、情報システム運用関係者が日々の業務で使用する用語自体も変化しています。

　下記に挙げる用語は一例ですが、いくつご存じでしょうか。

• オブザーバビリティー
• モダナイゼーション
• APM（アプリケーション・パフォーマンス・モニタリング）
• SRE（サイトリライアビリティエンジニアリング）
• AIOps

　上記の内、オブザーバビリティについては、それに特化したテックカンファレンスなども開催されており、情報システム関係者から集めている注目度の高さが伺えます。

　そこで本記事では、情報システム運用のオブザーバビリティを高めたいと考える方に向け、オブザーバビリティの概要やメリット、注目されている理由についてわかりやすく解説します。

▼ 目次
・オブザーバビリティとは
・オブザーバビリティのメリット、期待できること
・情報システム部門がオブザーバビリティに注目している理由
・オブザーバビリティに求められる2つの要素

1. オブザーバビリティとは

「オブザーバビリティ（Observability）」は、「Observe （観察する）」と「Ability （能力）」の組み合わせから示す通り、日本語では「可観測性」や「観察する能力」と翻訳されています。ではその概念は、いつ頃に登場したのでしょうか。

　これは決して新しい概念ではなく、最初に提唱したのは「カルマンフィルター」で知られるRudolf E. Kálmán氏だと言われており、1960年に発表された「On the general theory of control systems（https://www.sciencedirect.com/science/article/pii/S1474667017700948?via%3Dihub）」に登場しています。

　その意味は「システム内部の状態を外部出力の情報から推測できる度合いを示す指標」であり、もともとは「自己調整システムの制御理論」に関して言及された言葉でした。

　現在IT業界で使われている「オブザーバビリティ」も、基本的な意味は同様です。

　つまり「システムの状態に係る出力情報を調査することによって、システム内部の状態を推測、把握する能力」です。

2. オブザーバビリティのメリット、期待できること

　オブザーバビリティを高める上で得られるメリット、期待できることは主に下記の 2 点です。

• システム状態の即時把握による、問題への迅速な初動対応
• ユーザーに対するサービスレベルの維持が容易になる

　すでにTwitter社では10年近く前からその重要性に気づいており、2013年7月には「Observability at Twitter（https://blog.twitter.com/engineering/en_us/a/2013/observability-at-twitter）」というブログ記事を発表しています。


　それでは、この概念が最近になって改めて注目されている理由は何でしょうか？

　それは「クラウドネイティブ型の分散システムが増えた結果、システムの内部状況が把握し難くなったため」と言えます。

3. 情報システム部門がオブザーバビリティに注目している理由

　決して新しくない概念「オブザーバビリティ」が脚光を浴びている理由を理解するためには、クラウドネイティブ時代における「分散システム」の問題をおさえておく必要があります。

　クラウドネイティブ型システムの大きな特徴は「特定の機能を提供する複数のマイクロサービスを組み合わせることで、1つのアプリケーションを構築する」という点にあります。

　このような構成のシステムを「分散システム」と言います。

　クラウドネイティブな分散システムは、アプリケーション開発と運用の両面で、大きなアドバンテージがあります。

• 分散システムは従来の「モノリシック型」のアプリケーションに比べ、機能の追加や変更が容易
• 分散システムでは、スケーラビリティや可用性の確保も容易
  • 例えば、Kubernetesではノード上で複数のPodが動作し、そのPodの中でアプリケーションコンテナなどが稼働します。ノードは物理マシンまたは仮想マシンに相当しますが、ノードのリソースが不足した場合にはノードを増やし、追加のPodを配置すればいいのです。このような複数ノードによるPodの配置は可用性を確保する上でも有効な考え方で、特定ノードのダウン時にサービスを継続できます。

　DXをスピーディに進めるには分散システムへの移行が重要だと言われるのは、これらが大きな所以です。

　このようにクラウドネイティブな分散システムはメリットがある反面、新たな問題も内包しています。

　それは、アプリケーションに障害が発生した場合、その原因がどこにあるのかがわかりにくいということです。

　物理サーバーや仮想マシンでアプリケーションを動かしていた従来の構成においては、アプリケーションのスローダウンや異常停止が発生した際の原因特定は、決して簡単だとは言えないにせよ、事象や原因にパターンがあり、原因特定作業も比較的シンプルでした。

　例えば、Webサーバー、アプリケーションサーバー、DBサーバーで構成される3層モデルのシステムの場合には、各レイヤのログの内容や処理時間等を追いかけていくことで、どこに問題があるのかがある程度までは特定でき、人手でも比較的短時間のうちに問題を解決できました。

　これは、アプリケーションの構成要素が少なく、構成が変化することもなかったからです。

　しかしクラウドネイティブ時代には、このような牧歌的な方法では通用しなくなります。

　分散システムで「内部で何が起きているのか把握する」には、アプリケーションを構成するマイクロサービスの動きをすべて追いかける必要があります。

　それらのマイクロサービスが稼働しているインフラは多岐にわたる可能性があり、調査対象が数千に上ることも珍しくありません。

　しかもどのインフラでどのアプリケーションが動いているのか、動的に変化することも少なくないのです。


　この問題に対応するために改めて脚光を浴びているのが、「オブザーバビリティ」なのです。

4. オブザーバビリティに求められる2つの要素

　オブザーバビリティを実現する（高める）には、大きく2つの要素が必要です。

• シグナルの収集
• 複数シグナルの関連受けと可視化

4-1. シグナルの収集

　シグナルの収集とは、アプリケーション稼働に関わる膨大な要素から、内部状況を把握するための情報を入手することです。

　Cloud Native Computing Foundation（CNCF）が発足した「Observability TAG（Technical Advisory Group：特定の技術に関する技術ガイドを提供するグループのこと）」は、2021年に「Observability Whitepaper（https://github.com/cncf/tag-observability/blob/main/whitepaper.md）」というドキュメントをGithubに公開していますが、その中ではこのような情報を「シグナル」と呼んでいます。

　オブザーバビリティを説明する WEB 記事の多くには、「オブザーバビティとモニタリングの違い」について着目している記事が見受けられますが、そもそもオブザーバビリティとモニタリングは、異なる次元の概念です。

　わかりやすく言うと、オブザーバビリティの方が上位概念であり、モニタリングはそれを構成する一要素なのです。

　「Observability Whitepaper」流に表現すると、モニタニングは「オブザーバビリティ向上のためのシグナル収集」と言うことができるでしょう。

　「Observability Whitepaper」によると、収集すべきシグナルは下記の5つのものが挙げられています。

• メトリクス
  • CPU使用率などのリソース状況や、レイテンシなどのサービス状況といった、定量的な指標となる数値データ
• ログ
  • OSやミドルウェア、アプリケーションなどが出力する、個別のイベント情報
• トレース
  • アプリケーション処理で発生するリクエスト構造や、呼び出される各コンポーネントでの処理時間などを可視化したもの
• プロファイラ
  • アプリケーション稼働時に、アプリケーションがどのように実行され、リソースがどこでどの程度割り当てられていたのかを示す情報。CPUプロファイラ、メモリ割当プロファイラ、ヒーププロファイラなどがある
• ダンプファイル（コアダンプ）
  • システムがクラッシュした際に出力されるメモリイメージ

　これらのうち、一般的に用いられているのは下記のシグナルで、これらはオブザーバビリティの「3つの柱」と呼ばれることもあります。

• メトリクス
• ログ
• トレース

　プロファイラがあまり用いられないのは、取得のためのオーバーヘッドが大きいからです。

　しかしサンプリングによるプロファイラ取得であればこの問題を回避でき、アプリケーションの遅延部分をより深く掘り下げられるため、今後はこれが主要シグナルに加わる可能性は決して低くないと言えます。

　一方でダンプファイルに関しては、大規模なアプリケーションでは数十GBに達する可能性もあることや、クラウドネイティブなシステムではダンプファイルを出力するインフラを「誰が所有しているのかが曖昧になる」などの理由から、シグナルとして利用するには高いハードルを越える必要があると言えそうです。

4-2. 複数シグナルの関連付けと可視化

　オブザーバビリティに必要なもう1つの要素は、「収集した複数のシグナルをどう関連付け、可視化するのか」ということです。

　これによって複雑なシステム内部の状態を把握しやすくし、問題発生時の原因究明を迅速化するのです。

　十分なシグナルを収集するのも決して簡単ではありませんが、こちらはそれ以上に本質的な課題だと言えます。

　そしてこれこそが、単なるモニタリングとの決定的な違いなのです。

　特定シグナルの可視化に関しては、メトリクスを動的に収集して可視化する「Prometheus」や、分散トレーシングを可能にした「Jaeger」といったOSSが存在します。

　またオブザーバビリティの支援ツールを提供するベンダーもすでに複数登場しています。

　しかし、シグナルの関連付けや可視化に関しては、シグナルフォーマットの標準化やAIopsの活用が求められると考えられます。

　当面は各種ツールを活用しながら、運用の専門家による高度なスキルも組み合わせることで、オブザーバビリティを高めていく、というのが現実的な選択肢になりそうです。

まとめ

　本記事のポイントをまとめると以下のようになります。

• オブザーバビリティとは「システム外部で取得できる情報から、どの程度までシステム内部の状態を推測・把握できるのか」という意味
• クラウドネイティブな分散システムへと移行することで、システム内部の構成は大幅に複雑化し、内部状況を把握することが困難になる。この問題に対応するため、「オブザーバビリティ」が改めて注目されるようになった
• オブザーバビリティは大きく2つの要素で構成されている
  • 1つは状況把握に必要な情報の収集。このような情報を「シグナル」と呼び、その中には「メトリクス」「ログ」「トレース」「プロファイラ」「ダンプファイル」が含まれる
  • もう1つは複数のシグナルを関連付けて可視化すること。これに関しては技術的にまだ十分に成熟しておらず、当面は各種ツールと共に専門家のスキルを活用していく必要がある

　

　昨今の企業システムは、オンプレとクラウドが同居するハイブリッドクラウド、複数のクラウドから成るマルチクラウド構成、仮想化、コンテナ化などにより複雑化しており、運用、監視、管理のためのシステムも同様に増え続けています。

　伊藤忠テクノソリューションズ（以下、CTC）の経験豊富な運用の専門家は、お客様の複雑かつ多様な管理が必要とされるシステムの包括的な支援だけでなく、オブザーバビリティについても支援できます。

　オブザーバビリティを実現したい、システム運用、監視、管理についてのお悩みを解決する方法を探されている方は、CTC までご相談ください。