tl;dr
オブザーバビリティにはあなたの直感よりもお金がかかるかもしれない。でもそれはアジリティを上げるために必要なコストである。同時にオブザーバビリティ関連ベンダーには、それらをリーズナブルに提供してもらうことを期待します。
オブザーバビリティ・エンジニアリング輪読会
8月からVPoEになりました。id:Songmuです。
社内の勉強会で輪読形式でオブザーバービリティ・エンジニアリングを読んでいます。毎週30分、参加者の中から発表者を割り当て、1~2章を読み進めるスタイルです。
ちなみに、ヘンリーではActive Book Dialogue(ADB)というフォーマットも取り入れて輪読会が運営されています。社内で同時並行で数本走っており、先日、CEOの逆瀬川が書いたソフトウェア見積もりに関する輪読会も同様の形式で実施しています。
発表者は、事前に社内のNotionにその章のアウトラインや論点などをまとめてから会に臨みます。私も何度か担当しましたが、発表者は担当章を読み込むので理解が深まります。私は読書メモを取る習慣はなかったのですが、事前にNotion上に要点をまとめることで理解が全然違うことに驚きました。ADB形式での輪読会、オススメです。
このオブザーバビリティ・エンジニアリングがそろそろ読み終わりそうなので、所感をまとめてみます。
オブザーバービリティ・エンジニアリングとは
この本で述べられていることは単純で、構造化イベントがオブザーバビリティの肝となる構成要素で、それを構造化ログ、特にOpenTelemetryのような標準的なテレメトリ手法で逐一記録しておけば、後から任意の集計や調査、デバッグがやりやすくなる、というものです。
従来のメトリクスは決め打ちの次元で集計された情報量が落ちた値であり、既知の未知に対する調査方法としては有効ですが、未知の未知には弱い。構造化イベントをすべて記録しておくことで、問題が発生した後からでも、過去に対して任意の次元で集計したり、あるリクエストに付随するサービス間の呼び出しをトレースしたり、関連イベントをクエリしたりできるようになります。
オブザーバビリティがあれば、現代的な複雑なアプリケーションに対してもプロアクティブなデバッグが可能になり、素早くフィードバックサイクルを回せ、アジャイルな価値提供が可能になる、ということです。
オブザーバビリティの3本柱という言葉には触れられているものの強く支持はされていません。あくまでイベントが肝で、それを構造化ログとして記録しておけば、あとからトレースもメトリクス集計もクエリもできるよ、という単純明快な主張で分かりやすく、同意できます。
サービス開発者の立場としてもOpenTelemetryの手法をフォローしておけば、多くのオブザーバビリティツール・サービスとの接続もやりやすくなるため、これが業界標準としてもっと広く使われて、エコシステムがより成熟することも期待したいと感じました。
理想的だがお金はかかる
しかし、同時に思ってしまうこととしては「それってカネがかかるよな」ということです。実際、本書には以下のように書かれています。
オブザーバビリティツールは、テレメトリデータのカーディナリティやディメンションを制限することなく、発生するすべてのイベントに関する豊富なテレメトリーを収集し、任意のリクエストに対するコンテキストをすべて伝え、この先のどこかの時点で使用できるようにするために保存する、このようなことを開発者に推奨しています。 p.16
実現のためには結局、逐一構造化イベントログをどこかしらに記録し保存する必要があるということです。
ログと聞くと費用面で頭を痛めているエンジニアの方も多いのではないでしょうか。ログやそれを保管するDWH、その他オブザーバビリティ関連費用は年々増加傾向にあり、企業によってはそれがクラウドコスト全体の数割にも及ぶ、などという話も聞きます。
それらは本当に高いのか
しかし、それは本当に高いのでしょうか。良く考えてみると、高頻度の書き込みに耐え、大量のデータを効率よく集計・クエリ可能な形で保管するのは大変で、コストがかかるに決まっています。それでもそれらの情報を記録しておくことがビジネス価値につながる、ということが本書の主張なのでした。
- 「たかがログになんでこんなにお金をかけなければならないのか」
- 「直接的なコンピューティングリソースにお金がかかるのは仕方がないが、付随的なオブザーバビリティ関連費用が高額になるのは腑に落ちない」
そんなことを思うかもしれません。しかし、それは私達エンジニアが忌み嫌っているはずの、運用・運営軽視の態度です。
例えば、昔はCIサーバーにお金をかける発想は乏しかったですが、今はそこにコストをかけるのは当たり前になり、そこに力をかけられるサービスのほうが生き残れるようになりました。
また、昔は新規サービス開発が終わったらチームを解体、縮小して運用するのが多く見られましたが、今では運用・運営に力を入れて継続的にサービスを改善していくことが当たり前になりました。
こういった比重の変化がオブザーバビリティでも進行しており、マインドチェンジが必要です。少なくともエンジニアが「思ったよりお金がかかるな」などと思ってしまうと、経営者はそこに踏み込んで投資はしてくれません。それがビジネス成長のために必要なコストで、更に言うと、そこをおろそかにしていると変化が遅くなり生き残れないリスクがある、ということを認識し、説明可能になる必要があるでしょう。
システム運用的なコストセンターマインドだと、とかく運用関連費用を削りたがってしまうことがあります。もちろんコスト最適化は大事ですが、必要な部分にコストをかける前に削り始めるのは良くありません。
まあでも高いよね
とは言え、オブザーバビリティ関連費用が高くつくのは否めません。その辺りについて本書は後半歯切れが悪くなるように感じられて味わい深かった。そこには大きく以下の2つの理由があるように感じました。
- オブザーバビリティが本来的にコストが掛かるものであるということ
- OpenTelemetry周りがまだ未成熟であること
コスト面では、前半では「情報は全て残せ」みたいに強気に言っていたのに、17章でデータサンプリングについてまるまる1章割くなどしています。
また、15章の「作るか、それとも買うか」の章も、筆者がオブザーバビリティベンダー所属であるから公平さを期して書いているのも分かるのですが、業界が未成熟であるがゆえの歯切れの悪さも感じてしましました。
16章の「効率的なデータストア」の章では、オブザーバビリティサービスを提供しているHoneycomb社内で実際にどのように、データを保持しているのかについて書かれています。これはエンジニアとしては読み応えがあり興味深い内容ですが、それと同時に、これは複雑で自前で運用はしたくないよなぁとも感じました。
やはり、多くのテレメトリ情報を扱う基盤は、自前運用が大変であることが想像できるので、どこかのベンダーに任せたい。それに加えて、ロックインされすぎないように、ベンダー間の相互運用性も求めたい。
相互運用性についてはOpenTelemetryを計装しておけば、多くのベンダーに接続できる流れになりつつあり、そのエコシステムのさらなる成熟を望みます。しかし、そのベンダーの選択肢については「ここに任せておけば安心」という有力ないくつかのサービスが存在するかと言うと、まだ足並みが揃っていないように感じます。
このあたりは、複数の有力なベンダーが同じ土俵の上で価格競争され、よりリーズナブルにサービスが提供される流れになることを期待しています。
ヘンリー社では
社内ではこのあたりは鋭意整備中ですが、Sentryで発番したtrace IDをTypeScriptやKotlinで書かれたサービスに引き回し、OpenTelemetryで計装するところまでは実現できています。それらとGoogle Cloud Logging, Cloud Trace, BigQueryなどを組み合わせて可視化、トレース、クエリ等を実現しています。
可能ならGoogle Cloudの機能で一通りまかないたいと思っているのですが、煩雑になってきているので、他社がどうしているかも知りたいところです。また、サードパーティのソリューションも検討しても良いとは考え始めています。このあたりのノウハウが他の会社の技術ブログ等で書かれると嬉しいです。
まとめ
ヘンリー社内での輪読会取り組み及び、オブザーバビリティ・エンジニアリングについて取り上げました。
ヘンリーはまだ数十人のスタートアップであり、輪読会やオブザーバビリティの取り組みにおいても、職種をまたがって実施しています。輪読会にはCEOや営業、CXメンバーが参加していますし、オブザーバビリティの取り組みではアプリケーションエンジニアが計装を実施しました。
小さいチームでクロスファンクショナルに活気を持って開発を進めていますし、お客様も増えてきていて拡大期に入ろうとしていて、もっと仲間を増やしたいと思っています。SRE、Webエンジニア、各職種を募集中ですので、興味のある方はぜひご連絡ください。
