YAMAGUCHI::weblog

噛み付き地蔵に憧れて、この神の世界にやってきました。マドンナみたいな男の子、コッペです。

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

はじめに

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

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

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

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を提供すべきだと考えています。

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

おわりに

まだまだこれからもオブザーバビリティに関する議論はこれからも続くと思います。これからオブザーバビリティ界隈がどう盛り上がってくるか、楽しみです。

あときっと @songmu さんもオブザーバビリティに関する記事書いてくれるはず。

書かなかったこと

  • SREに関わる話(SLI・SLOやError Budgetの話)
  • サービスメッシュの話
  • メトリクスの標準化の話
  • E2Eモニタリングの話
  • 細かな製品の話
    • OpenCensus、Stackdriver、Istioなど

参照

過去に読んだ記事などのリストです。

書籍もいくつか

*1:オブザーバビリティという語の初出はTwitter Engineering blogだと記憶しています

*2:ソフトウェアのテスト可能性の中にもオブザーバビリティ(可観測性)が出てきますが、私は昨今の「オブザーバビリティ」はその延長であると解釈しています。

*3:実際は予期せぬ入力によって、予期せぬ出力が得られることがありますが、それを修正していくこと自体がソフトウェアの開発サイクルに入っていると思うので、ここでは担保されているものとします。