「オブザーバビリティ・エンジニアリング」読書メモ
こんにちは、Azukaritai の小松です。AzukaritaiのSREロールでは、四半期ごとにテーマを決めて、SREに関連するさまざまなトピックについてチームで学習を進めています。2023Q1は、「オブザーバビリティ」にフォーカスし、まずO'reilly から出ている「オブザーバビリティ・エンジニアリング」をみんなで読んで、オブザーバビリティについての概略を理解しようということになり、それに取り組んでいます。
この note 記事では、Azukaritai SREロールで、この本を読んで学んだことの記録を兼ねて、理解したことをまとめています。
「オブザーバビリティ」とは?
「オブザーバビリティ」は、日本語にすると「可観測性」となるようです。「オブザーバビリティ」という概念は、元々、1960年のRudolf E. Kàlmànの論文で登場したもので、制御理論において、外部出力の知識からシステムの内部状態をどれだけうまく推測できるのかの尺度として定義されたもので、その後、機械エンジニアや物理システムを管理する人たちが、どれだけ外部から、システム内部の状態を把握できるか、という性質を表す言葉として使われてきたものということです。
SREにおけるオブザーバビリティは、この伝統的な概念を借用し、現代のインターネットベースのオンラインサービスの本番環境の挙動について、どれだけ詳細かつ具体的に内部の挙動について把握可能か、を表す尺度として元いられているようです。
現代的なソフトウェアシステムは、クラウドネイティブであり、様々なマイクロコンポーネントに分割されてその連携によってサービスを実現し、またその連携の組み合わせの中には、サードパーティによって提供されるサービスのコンポーネントも登場したりします。ユーザーの接続環境も多様であり（PC・スマートフォンがあったり、ブラウザベンダーも複数あったり、接続元も世界中いろいろな国からアクセスがあったり）とにかく非常に複雑で、細かくその実際の挙動を観測するというのは、簡単なことではありません。
一方で、そういう複雑な実行環境であるからこそ、何か問題が発生した時に、その対処を適切に行うのも非常に難しくなってきています。少し前のモノシリックなシステムであれば、まだコントロールできたかもしれませんが、現代的なシステムにおいては、従来の方法では歯が立たない状況が増えてきています。そういう状況に対処可能なアプローチとして、それぞれのユーザーがソフトウェアシステムを利用する際にどのようにシステムが動いているかの情報を詳細に記録し、またそれを必要に応じて柔軟に利用・分析できるようにしし、障害対応や、プロダクトの改善などの様々な課題解決のアプローチを抜本的に変えよう、「オブザーバビリティ・エンジニアリング」というのはそういう手法・取り組みであると、この本を読む中で理解することができました。
「モニタリング」との違い
このオブザーバビリティ・エンジニアリングの前半で特に強調され、何度も言及されているのが「オブザーバビリティ」と「モニタリング」の違いについてでした。どうやら、オブザーバビリティを実現するためのソリューションを提供するベンダーが、従来のモニタリングツールの延長上に、より豊富なメトリクスを、ダッシュボード上でずらっと可視化したり、単により詳細な記録を保存できる機能を提供したりしつつ、それをオブザーバビリティのためのツールとして宣伝し販売することが行われがちで、その結果、モニタリングとオブザーバビリティの違いが曖昧になりがちという背景があるようです。
この本で説明されている、モニタリングとオブザーバビリティの違いをざっくりとまとめると以下のようになるかと思います。
モニタリング
あらかじめ事前に、観測するメトリクスを明確にして設計する
イベントに紐づくソースデータというよりは、単位時間あたりの集計値としてその推移を記録・可視化
メトリクスが事前に設定した、閾値を超えた場合にアラートが飛ぶようにし、アラートが飛んだら、エンジニアが確認して対処することを想定
オブザーバビリティ
事前に観測するメトリクスを設計するのではなく、システムの内部で発生しているすべての状況を記録することを基本とする
問題に気づくためのものというよりは、問題が発生したりその兆候を見つけたときに、それを深掘り（デバッグ）するための詳細な情報へのアクセスを提供することがメイン
ただ、オブザーバビリティの考え方のもとに、詳細な情報を記録して、それに基づいて指標を計算して、アラートが飛ぶような構成も存在していたり、システム内部で発生しているイベントについての詳細な記録（ログやトレース）も、すべて記録するのは、それを記録できるようにするための準備にも手間がかかったり、記録の保管や、それを検索可能にするためのインデックスのためのストレージや計算環境の維持のためにも膨大なコストがかかって現実的ではなかったりということで、実際の現場では、部分的にしか記録が残っていなかったり、サンプリングのアプローチが使われていたりするようで、そういう状況も、モニタリングとオブザーバビリティの差異が曖昧になることに繋がっているように思いました。
「SLO」との関係
SRE本にも出てくるSLO（サービスレベル目標）とオブザーバビリティとの関係も、重要な要素でした。SRE本には、SLI / SLO を設定しましょう、とか、エラーバジェットの考え方で、プロダクトの改善と、安定化のバランスをとりましょう、といったような考え方が紹介されていつつ、SLI / SLOは、ユーザー体験に直結するものを考えて設計しましょう、と書かれているのですが、具体的にどういう指標を設定し、それをどのように観測できるようにし、運用するか、というところまでは具体的に書かれていませんでした。
この本には、オブザーバビリティツールが、ユーザーがシステムを利用するプロセスの全体を記録するアプローチを取ることで、よりユーザー体験のレベルを適切に表現できるSLIを設計できるというようなことが書かれています。具体的には、ユーザーがソフトウェアを利用する中でなんらかのエラーに遭遇する割合であったりとか、個別の操作をした後の応答時間などについて扱う上で、システムの個別の構成要素で把握できる指標以上の、ユーザー体験を軸にした適切な指標を利用できるようになるということが書かれていました。
こちらについてはなるほどな、と思いつつも、やはり実際に運用しようとすると色々と一筋縄ではいかなさそうなので、実際に試してみたいなと思いつつ、この本の中でも、より詳細な情報が、オライリーの別の本「Implementing Service Level Objectives」に書かれているよ、と紹介されていました。この本の和訳本がちょうど2023年7月に刊行されるようなので、早速読んでみたいなと思っています。
具体的な構成要素、技術
この本の第II部（第6章〜第9章）で、オブザーバビリティを実現するために必要なさまざまな構成要素となる技術が紹介されています。いくつか、キーワードベースで、本を読んで理解したことをまとめてみます。
構造化イベント
オブザーバビリティを実現する構成要素のうち最も基本的なものの一つが、構造化イベントです。従来は、システムの内部で発生した詳細な情報は「ログ」として、コンソールであったり、ログファイルなりに順次出力されていました。この従来のログは「非構造化ログ」と呼ばれ、テキストファイルの形式で、人間がみてわかるようにフォーマットされている一方、その情報を事後的に分析して活用しようとすると、一筋縄ではいかないというものでした。
構造化イベントは、人間が目で見てわかるようにするためのものではなく、プログラムが構造を解析して、記録を蓄積し、のちに分析したり、検索したりすることを行いやすくすることに主眼をおいて記録するというものです。
フォーマットはバイナリであったり、JSON形式のテキストファイルあったりとさまざまな形があるようですが、まず、オブザーバビリティツールが活用できる形で情報を残すということが最初のステップとして重要になるようです。
分散トレース
構造化イベントは、システムの構成要素のそれぞれの箇所で、さまざまな情報を分析可能な形で記録するというアイデアですが、そういう個別のイベントの情報は、システムの構成要素である個別のマイクロサービスであったりとか、サードパーティのサービスであったり、いろいろな箇所で個別に発生し記録されるようになります。分散トレースは、そういった個別のイベントの情報を、ユーザーごとのサービスに対するアクセスを軸に、一連の流れを確認できるように結合するための仕組みです。従来のモノシリックなソフトウェアシステムにおいては、単一のシステムのログを見ればある程度のユーザーの振る舞いを追いかけることができたりというのがありましたが、近年の、クラウドネイティブ化、マイクロサービス化が進んだシステム構成においては、1件のユーザーリクエストがどのように処理されて、その結果をユーザーが受け取るか、という流れにおいても、さまざまなコンポーネントが関連し、その流れを追いかけて確認することが簡単ではなくなっています。分散トレースはそういった状況においても、複数のコンポーネントがどのように連携し動作しているかを個別に把握できるようにしてくれるようです。
OpenTelemetry
さまざまなコンポーネントが絡むシステムにおいて、システムの実行時の情報（テレメトリーデータと呼ぶらしい）を、オブザーバビリティツールに集約して記録する時に、その情報のやり取りの仕方の方式が、オブザーバビリティツールのベンダーごとにバラバラだと、途中で別のベンダーのオブザーバビリティツールに切り替えることを考えた際に、計装の作業をやり直す必要があるために切り替えが現実で
亡くなってしまったり（ベンダーロックイン問題）、そもそも、サードパーティのサービスについては、自社で使っているオブザーバビリティツールと互換性がなく、情報の記録ができない、などの問題が発生してしまいます。
そうした問題への対処として、ベンダー非依存のテレメトリーデータの計装方法としてオブザーバビリティのコミュニティが生み出した成果として、 OpenTelemetry標準というものがあるようです。OpenTelemetryは、いろいろな構成要素から成るようで、そのメインの部分としては各言語向けの計装ライブラリとして提供されている計装APIの部分のようです。
イベント解析
OpenTelemetryなどを用いて収集される大量のテレメトリデータは、データストアに送られ、そこに蓄積されます。既存のAPMやモニタリングツールで蓄積される情報と、オブザーバビリティの考え方において蓄積される情報とでは、それをどのように活用するか、というところの考え方も大きく変わってくるようです。
この本で改めて強調されている、既存のモニタリングやAPMの手法と、オブザーバビリティに基づく手法との違いとして、既存のモニタリングやAPMでは、既知の問題・障害のパターンについての知識が、デバッグ・トラブルシュートにおいて最重要であり、そういった知識に基づいて手順書が書かれて共有されたり、あるいは、運用経験の長いシニアエンジニアの経験あるいは経験に基づく直感が、早期の問題解決に欠かせない要素になってくるといったことが起こりがちということが指摘されています。
一方で、そういった手法の限界として、全く新しいパターンの障害に対しては有効でないということや、属人的な運用体制につながるというところから、結果として、信頼性の低下や、チーム・人材の疲弊などの問題につながるということが指摘されています。
オブザーバビリティにおける、デバッグ・トラブルシュートのアプローチは、既知の経験に基づく先入観を排除し、オブザーバビリティツールが捕捉している情報から、何かしらのシンプルの異常値を検出し、その原因となる事象について仮説をたて、それをテレメトリーデータに基づいて検証する、という「コア分析ループ」を繰り返すというアプローチで行われるということです。また、このシンプルな仮説検証の試行を、膨大な情報に対して、網羅的に行うことで、未知のパターンの問題に対する、その原因の特定、解決への道筋の提供までの時間を短くできるようで、そのためには、総当たりを行う部分を、自動化するなどのアプローチが有効なようです。
まだ、この辺りは実際にやってみないとなかなか理解するのが難しいなと思ったので、今後実践しようと思います。
規模・コストとの兼ね合い
オブザーバビリティツールは、大量の情報をデータストアに蓄積し、そのデータ集合に対する、高度で高速な分析手段を提供する必要があり、大規模に運用されるソフトウェアシステムに対してオブザーバビリティを実現しようとすると、かなりのコストがかかることが想像されます。この本の中では、具体的なツールベンダーのサービスの利用料まで紹介されていませんが、ベンダーのツールを導入するにしろ、オープンソースベースのプロダクトを組み合わせて構築するにしても、いずれにしても、コストの問題は、大きな要素となるようです。
この本の中では、データ量の増大に伴うコストの増加に対して、サンプリングのアプローチが紹介されています。本の前半では全ての、詳細な情報を観測できることが重要なように書かれていましたが、コスト面で妥協が必要な状況において、得たい成果を維持しながら、情報に優劣をつけながらサンプリングする方法がいくつか提示されています。
どう導入するか
この本の最後の部（第V部）においては、オブザーバビリティの考え方を組織の中で導入する上で重要になるテーマがいくつか紹介されています。オブザーバビリティツールの導入は、多くの状況において、人員も、時間も、コストもそれなりにかかる一大プロジェクトになります。導入する上で、組織の中で、オブザーバビリティが投資に見合う価値があることをどう共有し、導入に必要な合意や協力を取り付けるか、ということについて、いろいろと具体的に書かれていました。この本を書いているチームが、Honeycomb というオブザーバビリティツールの開発ベンダーであるということもあり、書かれている内容はオブザーバビリティのメリット的なところばかりになっている感じはありますが、それでも、なかなか組織において具体的などういう経済的なメリットにつながるか、という視点で整理されていてわかりやすいところはあります。具体的には、以下のような点が挙げられていました。
（稼働時間とパフォーマンス向上による）収益の増加
インシデント対応の迅速化によるコスト（人件費）削減
インシデントの事前回避によるコスト削減
従業員の離職率の低下によるコスト削減
最後に挙げられているポイントを見て、なるほどなと思ったところとして、オブザーバビリティツールに限らず、エンジニアに期待される役割（コードを開発する、バグを出さない、品質を高める、本番環境を安定的に運用する、障害を起こさない）の遂行をサポートするようなツールの導入にある程度の費用がかかる場合、それをエンジニア自身が導入を働きかけようとする場合にある種の後ろめたさみたいなものが出てきてしまうというのは色々な場面であるなということに思い至りました。特に、あまりお金がなく、高額なコストのかかるサービスを導入して、それが投じた費用以上の価値を出せるという経験をあまり持っていないチームにおいてはそれが起こりがちなんだろうな、などと思ったりもしました。
また、第20章にはオブザーバビリティを導入することに関係する利害関係者についての記述があります。オブザーバビリティは単に、エンジニアがソフトウェアシステムの障害対応や障害の事前回避、パフォーマンスチューニングを行う上で必要な情報を得られるようにするというだけでなく、もっと幅広い役割の人が活用できるものであると説明されています。わかりやすいところで言うと、カスタマーサポートの担当者が、顧客からの問い合わせ対応を行う際に、その顧客がどのようにソフトウェアシステムを利用していたか、具体的にどう言うエラーに遭遇していたかと言う詳細な情報にアクセスできるようになるということであったり、カスタマーサクセスの担当者が顧客がどのように製品を活用しているか、あるいは活用できていないか、についての詳細な情報を得られるようになることで、彼らの活動の改善に活かせるようになる、などの記述があります。
ローコードテスト自動化ツールのmablの売り文句の中でも、E2Eテストの民主化と言うキーワードがあり、さまざまなところで、これまでエンジニアしかわからないとされていて、非エンジニアのさまざまな役割の関係者が、エンジニアを通じて情報にアクセスしたり、何かを変えたりしていたものが、この民主化によって、より迅速・機動的に物事を進められるようになるトレンドが来ているのかな、と感じたりもしました。
まとめ・おわりに
と言うことで、この本を一通り読んでみて感じたことを書き殴ってみました。結構なページ数の本で、実際に導入して取り組んでみないとよくわからないな、と思う内容も多かったのが正直なところでしたので、できるところから、オブザーバビリティの実践についていろいろと試してみたいなという気持ちが高まりました。今後実際にいくつか試してみようと思います。また、いろいろ実践して知見が得られたら、こちらのnoteで記事にしていきたいと思います！