2023/2/4 書名のコピペをミスって間違っていました…直しました
すいません＞各位
オブザーバビリティィィィィィイ！！！！！
なんか必殺技の名前っぽいですよね、オブザーバビリティ。
リング状のエネルギーが放出されて、回転しながら相手を切り刻むイメージです。
そんなことはサテオキ
この現代、バラバラに設計された、断片的な情報しか教えてくれないアプリケーションログと、よく分からない閾値に基づいた監視メトリクスと、設計意図の分からないダッシュボードと、運用メンバの経験と勘で運用するのは限界があるよなーというのは、全システム運用者の共通の課題認識ではないでしょうか。
そんな課題へのヒントがあればなーと思って、『オブザーバビリティ・エンジニアリング』を読みました。
「オブザーバビリティ・エンジニアリング」、5ページ目の時点でめちゃめちゃ良い問いかけのサンプルが載ってて、すでにこの時点で優勝
— magnoliak🍧 (@magnolia_k_) 2023年1月31日
第一部のハイライトは、5〜6ページにかけて並べれた質問のいくつかの質問。
例えば、以下のような質問が挙げられている。
- あなたのソフトウェアを使う任意の特定のユーザーが、任意の時間に体験していることを理解できるか？
確かにすぐに答えられないかもしれない。どの質問も改めて聞かれると、「頑張って調べれば分かるかもしれないけど、そんな観点で調べることを考えたこともなかった」ということに気づくと思います。
本書は、システム構成や、アプリケーションコードがどんどん複雑化する中、従来のモニタリングによる「既知の未知」だけでなく、オブザーバビリティという概念を導入することによって「未知の未知」への対応力を高めていきましょう、ということが解説された、包括的なオブザーバビリティに関する解説書です。
一般的に「従来の監視」では、モニタリングツールが計測するメトリクスに対する閾値チェックか、アプリケーションやミドルウェアのログを「ERROR」などのキーワードチェックでシステムに問題が発生していないかを計測してきました。
そこから、例えばアクセスログから応答時間の変動や、一歩進んで各種データ量の増減傾向（「このタイミングでこのデータはゼロ件のはずだ」「この日程が終わる頃には、○○件以上のデータが蓄積されているはずだ」等）の計測結果を使った監視が追加されていくこともあるかもしれません。
みんな可視化のために頑張ってきた、いろんな工夫を加えてきた……ただ、この手の個別に作り込まれた個々のアプリケーション固有の振る舞いに関する計測方法は、最初から設計に組み込まれるというより、発生したインシデント等のフィードバック（いわゆる再発防止！！なぜなぜ！！）に基づいて追加されるものだったり、決して包括的なものでもないし、網羅的なものでもないことが多かったりしませんか、どうですか。
じゃあこの複雑化した、色々なサービスや、コンポーネントが絡みあうプロジェクトに対してはどうしますか、何かできることは有りますか？という疑問が湧いた時に、「オブザーバビリティ」というキーワードが出てきた……という話に本書ではなっていくのだけど、正直第I部は概念的な話とかモニタリングの問題点といった話が続き、「うーん、で、どうやってそれが実現されるの？」という、ハテナが続く状態で読み進めていたのだけど、第II部の具体的な方法論へ突入し、構造化イベントの概念、構造化イベントを繋ぎ合わせるトレースの考え方、そしてOpenTelemetryを使った標準化……と、ここに来てようやく腹落ちしたというか、ようやく”オブザーバビリティ”というものが何か見えてきた……気がする。
なお、OpenTelemetryについては、下記のサイトが非常に参考になりました。
やっぱり何でも動く実装を見ることが大事ですね。
標準化されていることで、例えばJavaの実装の例では、以下のサイトに紹介されたようなライブラリやフレームワークはあらかじめ自動的に構造化イベントを取得する方法が用意されているとのこと。
第Ⅲ部は、組織としてオブザーバビリティ・エンジニアリングを実践していくための考え方、事例などが紹介されています。まぁ、ここは必要ですけど、その前にとりあえず動かせるものは動かして、手に馴染ませるのが大事かな、と思った。
従来のログが「点」を表現するものであり、その「点」と「点」をどうやって結びつけていくのかが解析の腕の見せどころだったのに比べて、構造化イベントは最初から「線」を表現することを目指していて、今度は「線と線から面へ」という、より先に進んだ解析ができるようになる訳で、そりゃ確かになーという気持ちと、「で、果たして既存のアプリケーションが既にたくさん積み上がっている中、どこから手をつけていくのか？」ということを考えさせれる1冊でした。
テーマがより深いアプリケーションの挙動の可視化と、振る舞いへの理解、なので、当然一定以上の複雑さを持つシステムじゃないとあまり恩恵も無いだろうし、実感も湧かないと思うので、いきなりこの本だけ読んで本質が理解できる訳ではなく、きっかけに過ぎないけど、それでも改めて自分たちの課題へ向き合うヒントとして、凄く学びの多い内容だった。
まずは、OpenTelemetryの言語別の実装を触ってみるところから始めてみます。
そういえば、”テレメトリー”という単語、その前に読んだ『はやぶさ2のプロジェクトマネジャーはなぜ「無駄」を大切にしたのか?』にも繰り返し出てきた。
二日連続で”テレメトリー”という単語が出てくる本を読んでた。どんだけ監視と運用が好きなんだ。
—-
その後、考えたことを追記
オブザーバビリティ、アプリケーションの振る舞いや、構造を全員が熟知している訳じゃないから、そのとっかかりとしてマーキングする、と言うと、アプリケーション構造設計が、直接監視設計に落ちる、という見方もできる
— magnoliak🍧 (@magnolia_k_) 2023年2月5日
アプリケーションの構造を、システマチックに可視化する方法はドキュメンテーションとか含めて色々な営みが有ったけど、完全な網羅には絶対にならないけど、「どう見て欲しいのか」を定義することに専念しましょう、という割り切りと発想はいいなと思った
— magnoliak🍧 (@magnolia_k_) 2023年2月5日
すべてを網羅した設計書、読まなくない？
問題が起きたときって、細かいコードの細部が見たい訳じゃなくて、全体的な構造が知りたい訳だけど、それがドキュメントに書かれていたとしても、それと実際に出たメッセージを紐づけるのってめちゃ大変だったりするんだけど、それが内部構造に踏み込んで「ここです！」って言ってくれるのはいいな
— magnoliak🍧 (@magnolia_k_) 2023年2月5日
限られた時間でダイレクトに問題のある箇所にアタッチできるエスパーみたいな人っているんだけど、全員がエスパーにはなれないんだよね
— magnoliak🍧 (@magnolia_k_) 2023年2月5日
テストデータで再現テストやりまーすとか言ってて、それいつ終わるのよ？って
