エンジニア大好き「推測するな、計測せよ」。これは、Plan 9, UTF-8やGoの作者としても知られる、Rob Pike氏の Rob Pikes's 5 Rules of ProgrammingのRule 3.に由来すると認識している。以下に原文を引用する。
Rule 3. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.
Rob Pike's 5 Rules of Programming
訳すと以下のようになる。
「計測せよ。計測するまでチューニングをするな、そしてそこが支配的じゃないならチューニングするな。」
要は「チューニングする前に計測せよ」という主張で「推測」と言う言葉は出てこない。なので「推測するな、計測せよ」というのは、かなり意訳になっている。もちろん「当て推量でやみくもにチューニングし始める前に、計測せよ」と言う話ではあるので、誤りではない。
ただ、この「推測するな、計測せよ」と言う和訳に対して「そもそもどこを計測すべきかは推測しないといけないのでは？」という突っ込みがまま見られる。
それに対して最近考えていることが「計測する前に観察せよ」と言う言葉。元のRuleになぞらえて英訳するとこう。
"Observe. Don't measure for monitoring until you've observed."
そう、当エントリではオブザーバビリティの話をする。
死活監視からメトリクスへ
「入門監視」と言う本がある。原著は2017年、邦訳は2019年に出版された本だ。監視をインフラエンジニア任せにせず、アプリケーション開発者こそが監視を行うことでシステムをより良くできるという主張のもと、監視に関するプラクティスが示されている。そして、この本に通底するテーマに「死活監視からメトリクスへのパラダイムシフト」がある。
システムの状態が健全か否かのOK・NGの二値を定期的にチェックする旧来の死活監視やチェック監視だけではシステムを健全に監視することは困難である。極力数値化してメトリクスに対する閾値を設けて監視しましょう、と言う主張がされている。
これにはITシステムの重要性が増して健全性が強く求められるようになったこと、同時に、監視システムが成熟して長期間の時系列データ保持が現実的になったことなどが背景にあった。
主張としては至極全うであり、この本はつまり「計測せよ」と言っている。
メトリクスから構造化イベントへ
「オブザーバビリティ・エンジニアリング」と言う本がある。「入門監視」より新しく、原著は2022年、邦訳は2023年に出版されている。
この本は、入門監視同様にサービス開発者がサービスの健全性を観察すること、そして、そのための基盤を民主化することの重要性を説いている。そしてこの本に通底するテーマが「メトリクスから構造化イベントへのパラダイムシフト」である。つまり、メトリクスだけでは、もはや不十分だ、ということだ。
これは、ITシステムに対する要求がさらに高まり、システム構成が複雑化する中で、必要なメトリクスを集計しきれない、集計しているメトリクスではカバーしきれない、そもそも何を計測すべきかすぐにはわからないと言った局面が増えてきていることが背景にある。
メトリクスは死活監視に比べると情報が増えたのは確かだが、集計されて情報量が落ちた値でもある。それよりも生に近い都度都度のイベント情報を保存し、検索や集計や調査しやすくする、つまり観察しやすくすることがオブザーバビリティの肝である。
たとえば、システムのアクセス数やエラー数をメトリクス化して監視をしていても、生のイベント情報が残っていなければ、その数値をさらに、APIパスやユーザーセグメント、レスポンスを返したバックエンドシステムのバージョンなど任意のディメンションで絞り込んで再集計することはできません。なのでイベントにさまざまな付加情報を付けて構造化して保存することが重要なのです。
計測する前に観察せよ
本書では、オブザーバービリティとは未知の未知(unknown unknown)に対処するためのシステム特性で、モニタリングは既知の未知に(known unknown)に対応するための手法だと整理されています。
未知の事象に遭遇したときにはオブザーバビリティ特性を活かして調査をおこない、その上でそれを計測できるのであれば、メトリクス化して監視をおこなえば良いということです。未知の未知を既知の未知に変えていく営みです。ただ、システムの複雑化により、明確で単純な監視に落とし込める局面がほとんどではないため、今後、トラブルシュートの多くでオブザーバビリティ基盤への依存度は高まっていくことになります。
「取れるメトリクスはなるべく取っておけ」と言われることもあり、一定の妥当性は認めますが、すべてのディメンションでメトリクスを集計しようとすると組み合わせ爆発してしまい、全てを取ることは不可能です。やみくもに計測する前に観察が必要です。そのために、構造化イベントを極力取得して観察可能にしておきましょうということ。これが、冒頭の「計測する前に観察せよ」と言う話につながります。
これは「両利きの経営」で提唱されている探索と深化の関係にも似ていて、オブザーバビリティ基盤でしっかり「探索」をおこない、そこで発見した監視項目を「深化」させていけば良いとも考えらえる。
ちなみにアプリケーション開発者からすると、アプリケーション上でメトリクスを集計するよりも、単純にイベントを構造化ログの形で出力する方が簡単で導入しやすいというメリットもある。
まとめと宣伝
私は以前、Mackerelでプロダクトマネージャーを務めており、「入門監視」の出版にも翻訳レビューと付録Cの執筆で関わらせてもらっていた。それらの開発から離れた後、その後の、オブザーバービリティへの変遷をどのように捉えているかについてまとめてみたのが本エントリである。以前、所属企業の方のブログでも、以下の記事を書いていたので、良ければ合わせて参考にして欲しい。
と言うのも、10月22日(火)の、Mackerel Tech Day - モニタリング・オブザーバビリティの変遷とこれからの展望！というイベントでパネルディスカッションのパネリストとして参加させてもらうことになったからだ。Mackerelも10周年を迎え、こういった節目の大事なイベントに招待いただいて登壇の機会をいただけることを大変嬉しく思う。
私は会場現地で参加予定で、まだ現地参加枠も空いているようです。皆様会場でお会いしましょう。
