オブザーバビリティ（可観測性）がなぜ必要だと考えるのか

はじめに

こんにちは、Stackdriver担当者です。本記事は完全に個人の意見です。（念押し）

GCP的に担当製品がわかりやすいのでStackdriverの担当と書いてますが、仕事での担当領域的には「オブザーバビリティ (Observability、可観測性)」です。この「オブザーバビリティ」という言葉が近年SREの文脈で語られることが増え、また今年に入って「入門監視 ("Practical Monitoring" の日本語訳)」が刊行されたことで、日本でもより多く耳にするようになりました。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

発売日: 2017/08/12
メディア: 単行本（ソフトカバー）

入門監視 ―モダンなモニタリングのためのデザインパターン

作者:Mike Julian
発売日: 2019/01/17
メディア: 単行本（ソフトカバー）

その「オブザーバビリティ」がなぜ必要だと考えるのか、自分なりに言語化してみました。

TL;DR

ハードウェア性能とシステムの開発スピードの向上、アプリケーションのコンポーネント化、パブリッククラウドサービスの普及により、システムの系全体の中でのアプリケーションの占める割合が大きくなった結果、オブザーバビリティの重要性が高まっている。

「オブザーバビリティ」の定義

「オブザーバビリティ」は昨今の盛り上がりによって耳にすることは増えたものの、その定義が明確に書かれていることが少ないので何を指しているのか、という疑問も同時に耳にします。しかし自分はそれは「マイクロサービスとはなにか」という疑問と同じ性質のもので、ある程度中心となる定義が徐々に認識されていき、定義の輪郭は人々によって違いがあるものではないかと考えています。

オブザーバビリティ（Observability、可観測性）という言葉は、最近のITシステム界隈では新しい概念として受け取られ、バズワードとして受け取られがちですが*1、自分は大学の学科が機械系だったこともあり、言葉そのものは馴染みがあるものとして受け取っていました。機械制御の分野ではオブザーバビリティ（可観測性）を次のように定義しています。

システムの出力からある時点でのシステムの内部状態を一意に知ることが出来る

これはコントローラビリティ（Controllabiliity、可制御性）と対をなす概念で、可制御性とは

システムへある入力を行うことで任意の最終状態に到達できる

と定義されています。

では、オブザーバビリティがITシステムの文脈で用いられる場合、一体どう定義できるでしょうか。この定義があやふやなのでバズワードと捉えられるのだと思いますが、私は次のような定義だと考えています。

オブザーバビリティとは、システムが運用する上で必要な内部状態の情報を取得できる状態にあること

つまりこれはシステムが持つ性質の性質の一つであり、たとえば

テスト可能性（Testability）
コンポーネント化可能性（Composability）
メンテナンス性（Maintenancability）

といった性質と同様に語られるべきものだと思います。*2

オブザーバビリティとモニタリング

基本的にITシステムは、自前で実装するプログラムや既存のアプリケーションの構成で作られるため、可制御性は担保されていると考えられるでしょう。*3

翻って、オブザーバビリティに関しては、アプリケーションのロジックには寄与しません。あくまでシステムに関わる側がシステムの内部状態を知る、あるいは振り返るためにログ、メトリクス、トレース、プロファイルといった出力を得られるように付加的に確保するものです。しかしながら、そうした性質を能動的に獲得していくことがオブザーバビリティには求められています。

オブザーバビリティと比較して挙げられる言葉で「モニタリング（Monitoring、監視）」があります。 "monitoring" は "monitor" の動名詞なので、語をそのまま捉えれば「監視をすること」です。これは運用者側の行為を捉えたものであり、システムの性質ではありません。

そういう意味で私は「オブザーバビリティ」と「モニタリング」は比較されること自体がおかしくて、本来は「モニタリングを円滑に行うためにオブザーバビリティを確保する」という形で、それぞれ車の両輪のようにお互いがあって成立する言葉だと考えています。

ではあえてなぜいまオブザーバビリティなのか

では、モニタリング（監視）自体は古くから行われていることなのに、あえてなぜいまオブザーバビリティという言葉が重要となっている（と考えられる）のでしょうか。それにはいくつかの理由があると考えています。

コンピューター性能の向上

計算資源がまだ潤沢でなかった時代では、アプリケーションそのものを動かすことですら性能的な制約が大きく、それ以外の負荷（外形監視やプロファイリング）を恒常的に行うこと（≒サンプリング）が制約上難しかったことがまず挙げられるでしょう。

また資源に対してハードウェア的な制限（ディスク、メモリ、ネットワーク）やOSやランタイム（JVMなど）といったアプリケーションの外側にあるもの（以下、簡単のため「インフラ」と呼ぶ）のシステム内での比重が特に大きかったこともあり、必然的にそちらに焦点を当てた監視が主流とされていました。

しかしながらコンピューター性能が向上し、システム全体においてのアプリケーションの比重が大きくなるにしたがって、アプリケーションそのものの監視の重要度も大きくなってきました。またアプリケーション以外に監視のためだけにエージェントを常駐させたり、外形監視を頻度高く行うことも可能となってきました。

アーキテクチャーの複雑化

またDevOpsが進み、それに伴ってコンポーネント化やコンテナ化が進む中で、昨今のようにマイクロサービスを導入する企業も少なくありません。そこまで行かなくても、アプリケーション、ミドルウェア、データベースと言った形でコンテナ化され、需要に合わせてインスタンス数を増減するといった構成も普通に採られるようになりました。

システム全体が分散したコンポーネント間の通信によって成立するようになり、あるリクエストを成立させるための一連のフローを追跡するためには、これまで見ていたようなインフラを主体とした監視よりも、コンポーネント間の依存関係と各コンポーネントでのボトルネックを視覚化するような監視の重要性が高まってきました。

実際2010年にDapperの論文が発表されてから、分散トレーシングは広く普及し、現在多くのAPM（Application Performance Management）バックエンドで採用されています。

これは、私はユニットテストの延長、あるいは実データを用いた結合テストの類だと考えています。実際コンポーネント間の依存関係が複雑になればなるほど、全体を通したテストを行うことは難しくなります。アプリケーション開発において、個々のコンポーネントではそれぞれ単体テストやシナリオテスト、あるいは負荷テストを継続的に行うことはだいぶ普及しているように思います。しかしながら、それらが複雑に絡み合ったシステム全体のテストはなかなか行えません。ステージング環境などでブラックボックステストを行っても、ユーザーではなく開発側が想定したシナリオで行っているため、実際にユーザーが行うリクエストを用いたテストはできません。

そういった背景において、ユーザーが作るリクエストを用いたテストとしてのオブザーバビリティという考え方ができるのではないでしょうか。

また同時に、複雑化したシステムを、少ない人数で効率よく運用するDevOpsであれば、そのための自動化のシグナルとして、システムから得られた指標を元にすることも必要になり、そのためにもオブザーバビリティは必要となるでしょう。

パブリッククラウドサービスの普及

マイクロサービスアーキテクチャに限らず、Kubernetesをインスタンスのオーケストレーションに利用する事例が増え、GCPのGKEをはじめ各社がKubernetesのマネージドサービスを展開し、アプリケーションがコンテナオーケストレーションの結果で捉えられる機会が増えています。さらに踏み込んで、Function as a Service のような形で、インフラを意識せずアプリケーションをモジュールとしてデプロイしていくことが当たり前になってきています。

このようなパブリッククラウドサービスを前提としたシステムになると、インフラそのものの管理よりも、その上で動くアプリケーションを動かすという方向に視点が移動します。監視をしていた対象が物理的なマシンから、一段抽象化されたコンテナであったり仮想マシンに変わり、インフラの運用者の役割も

管理しているインスタンスの状態の管理
インスタンス上で動いている個々のアプリケーションコンテナの状態の監視
連携しているコンテナ同士の状態の監視

という、いわば調停役のようなものに変わってきます。実際、パブリッククラウドを用いる場合、運用者はハードウェアを直接見ることはなく、個々のモジュールの役割に似た各種サービス（ストレージ、ロードバランサー、データベース、アプリケーションランタイムなど）が想定したとおりに稼働しているかを監視することが主な仕事となります。結局最終的にシステムに関わる人間全員が成し遂げたいことは「システム全体を健全な状態に保つ」ことなので、パブリッククラウドサービスに載せていくことでこのような視点の移動が起きるのは必然だと思います。

その上で、クラウドサービスの上に載せるアプリケーションにおいては、状態を知るためのオブザーバビリティ（ログ、メトリクス、プロファイル、トレースなど）の確保が肝心となってくるでしょう。つまりアプリケーション開発者がオブザーバビリティに必要なコードをアプリケーション内に書く（instrumentation: インスツルメンテーション）ことになります。

一方で、クラウドプラットフォームも、インフラを隠蔽した以上、運用担当者がその状態を意識できるように、各種サービスのオブザーバビリティをきちんと確保し、必要な情報を提供することがますます求められるでしょう。

システム運用者は、アプリケーションとクラウドプラットフォームの両者から得られる情報を整理し、管理していくことが仕事の上で大きな役割となります。

クラウドプラットフォームがモニタリングSaaSを提供する意義

自分はStackdriverというモニタリングSaaSを担当しています。他にも独立系のモニタリングSaaSは数多く存在していますが、そんな中でなぜクラウドサービス事業者がモニタリングSaaSを提供すべきなのでしょうか。

先にも述べたように、クラウドプラットフォームがインフラのインフラになっているいま、私はクラウドプラットフォームしか提供できない情報を提供する責務があるとともに、それをどういう形で確認すると運用者や開発者にとって有益であると想定しているかを示すためにもモニタリングSaaSを提供すべきだと考えています。

そうした形で提示することで、たたき台としてフィードバックが得られやすくなることも期待できるでしょう。先にも定義したように、オブザーバビリティというのはモニタリング製品を使うことではなく「必要な情報をどう取得するか」という部分に意味があると思うので、たたき台があることで多くの人が製品を利用することを通じて、必要な情報について考え、「問題解決のためにどういう情報がなぜ必要なのか」がフィードバックされることで、より運用しやすい環境が作られやすくなると思います。

オブザーバビリティについてワイワイやりたい

以上、つらつらと書いてきましたが、まだまだオブザーバビリティという言葉は普及段階です。ここから皆が手探りで進めて行くことになるかもしれません。しかし「オブザーバビリティ」それ自身はまったくの新しい領域というわけではなく、これまで「モニタリング」を行う上ですでに自然と行っていたような内容も多く含まれています。それらを踏まえつつ、今の時代のアーキテクチャーに合った形の指標の取り方を多くの人で共有できれば、普及を加速できるのではないかと思っています。

discord.gg

そういうことを@johtaniさん、@songmuさん、@ladicleさんなんかと話していて、なんか面白いことができそうという話になったので、勇み足かもしれませんが、「オブザーバビリティ」について意見が交わせられるような場が出来ればと思い、Discordのサーバーを立ててみました。まだ #general チャンネルしかありませんが、会話をする中自然と増えてくるかなーと思います。特にここで話したいと思っていることは

オブザーバビテリティに関する問題とその解決案

です。イベントを企画してもいいのですが、平日夜だったり週末になってしまい参加しづらい人もいるでしょうし、地理的な条件で参加出来ない人もいるので、まずはオンラインメインでできないかなと考えています。オンラインで話したような内容をオンラインで共有できるような形にして、皆が参照できるようにして、そこからまた話が発展していけば最高です。オフラインイベントは、他の関連しそうなイベントにお邪魔したり、自分たちで開催するにしても、そこまで頻度の高さは考えずにできればいいなと思います。

とはいえ、最初からいろいろ考えてもしょうがないので、まずはオブザーバビリティに興味がある人が集まって、どのようなことに興味があるのか知りたいです。ぜひご参加ください！