お疲れ様です。今日は「なぜOpenTelemetryが必要なのか」について私の理解をお話したいと思います。私はOpenTelemetryを実際に利用しているわけではありません。
先日、PyCon APAC 2023に参加し、山口能迪さんの「Pythonアプリケーションのオブザーバビリティ強化」の発表を聞いたり、発表後に質問をしたりして理解が深まったため、この記事を書いています。なので、もし勘違いや間違いが含まれていれば、教えていただけるとありがたいです。
- OpenTelemetryの必要性がわからない私
- オブザーバビリティが下がりやすい状況
- オブザーバビリティ低下対策のはじめの一歩
- オブザーバビリティを高める第二ステップ
- 高いオブザーバビリティを維持するためのOpenTelemetry
- まとめ
OpenTelemetryの必要性がわからない私
さて、まず、この記事を書いてる私の状況から話をします。どうでも良い人はこのセクションを飛ばしてください。
OpenTelemetryの登場背景がわからない
OpenTelemetryについてですが、単語自体は数年前から聞いたことがありました。しかし、私は「これをいつ導入するのか」「何の目的で導入するのか」がよくわかっていませんでした。オブザーバビリティを高める、つまりシステムの状態を把握しやすくすることが重要だというのは理解しています。でも、以前は「なぜ、システムの状態が把握しにくい状況が起きるのか」「どういう状況から必要性が出てきてるのか」 「OpenTelemetryがなければどうなるのか」という点がわかりませんでした。なぜ、OpenTelemetryという技術が登場し、今に至っているのかの背景がうまく理解できていませんでした。
それがようやく理解できたので、今回の記事に至っています。
モノリス中心の開発現場が多かった
で「なぜ、私がわからなかったのか」というと「私はモノリスのアプリケーションに関わることが多かったから」でした。これまで関わってきたシステムやサービスで、複数サービスやプロセスが連携するものはありました。ただ、最近はモノリスのアプリケーションを作ったり、小規模なサービスを立ち上げに関わることが増えています。気づけば分散システムに関わったのは片手で数えられないくらい前になりました。
モノリスのアプリケーション開発現場において、アプリケーションの保守や運営、追加開発においては、「オブザーバビリティ」は高めやすい状況になります。なぜなら、ほとんどのコードが一つのリポジトリの中にあることも多いですし、ライブラリや外部のサービスを利用していても、機能の少なさから依存関係がわかりやすかったりします。言語の数も多くないですし、また、Sentryを使っているとトレーサビリティも高めやすいように思います。Djangoを使っている場合は、django-debug-toolbarやdjango-silkのようなデバッグ用のトレースモジュールもあります。
オブザーバビリティが下がりやすい状況
マイクロサービスとオブザーバビリティ
では、オブザーバビリティが低くなりやすい、または高めにくい状況って何でしょうか。多数のマイクロサービスで構成されているサービスが、そのような状況に陥りやすいように思います。最近、私もマイクロサービスについて考える機会が増えたことでこの課題、システム全体の状態、つまりオブザーバビリティに関心が向き始めています。
オブザーバビリティに関連して、「マイクロサービスがなぜ導入されるのか」についても簡単に触れます。前提として、モノリスは1人当たりの生産性が高く、エンジニアが少数の場合は有効です。特に素早く市場に投入し、ユーザーに価値を提供して実際にそのサービスが求められているかを検証したい段階では、モノリスが選択されることに特に疑問がありません。
開発速度の向上とオブザーバビリティの課題
しかし、ユーザーに求められていることがわかった場合や、テストがうまくいった段階で、多くの人に関わってもらいながら、1人当たりの生産性をなるべく下げずに全体の開発速度を上げたいという考えや属人性を排除したいという考えが高まります。他にも部分的に新しい技術を採用したいという話も出てきます。
このような流れから、マイクロサービスとして機能や責任を分解しながら大きなサービスを作っていくことが検討されます。この考え方や流れは、書籍「プロダクションレディ マイクロサービス」でも触れられております。
マイクロサービスを導入するメリットはありますが、それによる課題も生まれます。例えば、ログやレポートがバラバラの場所に保存されてしまって探すのが大変になったり、特定のサービスで何か問題が発生した際に、全体で何が起こっているのか、どの機能に影響があるのかがすぐには把握できない状況になったり。このような状況では障害の原因調査が難しくなります。つまり、サービス全体の「オブザーバビリティ」が低くなります。
オブザーバビリティ低下対策のはじめの一歩
「オブザーバビリティが低い状態」は、本当に困りますよね。ユーザーに対してサービスを提供している場合、ユーザーに何がどんな影響を与えているのか、何がうまく利用できていないのかを迅速に把握して、次の行動に素早く移りたいわけです。オブザーバビリティが低いと、状況把握が難しくなり、対応方針の検討や対策を誤る可能性が高くなったり、障害対応に時間がかかっていくわけです。それは困ります。
データをしっかり保存する
このような状況を解決するための第一歩は、きちんとログを取って、データをしっかり集めるところから始めるわけです。これは、マイクロサービスに限った話ではないんですが、実際には様々なツッコミどころのあるログに遭遇することもあるわけです。私も昔やりまして、様々な経験や指導を経て今に至っている訳ですが、これは基本中の基本なので、まずデータをちゃんと出して記録する必要があります。そういえば、先日参加したDjango Congress JP 2023でもそんな話を聞いたので紹介しておきます。
他にもメトリクスを集めるというのも重要です。データを保存するところからオブザーバビリティの改善が始まる訳です。
オブザーバビリティを高める第二ステップ
データを一箇所に集めて見やすくする
さっき言ったようにオブザーバビリティを高めるためには、まず「ログやメトリクスをしっかり取る」ことから始めるわけです。それが一通りできたとすると、次の課題はデータ管理に移ります。特に古いシステムでは、ログがいろいろなディレクトリに散らばっていたり、複数台のサーバーを一つ一つ手作業で確認しないといけない状況がありますよね。これは流石に辛すぎるので、AWSのCloudWatch LoggingやGoogleのCloud Loggingなどを使って、データを一箇所に集めて、ブラウザから閲覧できるようにする訳です。コンテナで運用する場合は、最初から一箇所に集めたりしますね。
サービスごとにデータ管理が異なる課題
ただ、そこから別の問題が出てきます。サービスごとにログやメトリクスの集約場所や方法が異なるケースが多々あるのです。そうような場合、障害調査も「このデータはどこにあるの？」とか「どうやって見るの？」といった基本的な問題から始まってしまいます。さらに、いろいろなサービスが絡むと、どのデータを集めているのかも曖昧になってくる。この問題は、マイクロサービスになるほど深刻になっていきます。
結果として、障害調査が特別なノウハウの必要な状況になってしまいます。なので、全体を知っている人がいないとなかなか状況が把握できず困った状況になります。これはよくない状況ですね。
ここまで来てようやく OpenTelemetoryという概念が重要になります。
高いオブザーバビリティを維持するためのOpenTelemetry
OpenTelemetoryの話に移ると、まず、山口さんの発表がOpenTelemetoryを理解する近道になると思います。私はまだ手を動かしていないため、その前提で聞いてください。
OpenTelemetryを簡単に
簡単に言えば、OpenTelemetryは、ログやメトリクスなどを取得して貯めるための標準的なフレームワークです。これを使えば、いろんなサービスのデータを一箇所で集約しやすくなります。そして、これはオープンな仕組みであるため、特定のベンターにロックされるのを防ぐ効果もあります。
OpenTelemetryの嬉しい点
OpenTelemetoryの考え方としては、このデータを一箇所に集めます。その場所がOpenTelemetry Collectorと呼ばれます。そして、それを閲覧するUIのサービスとして様々なものを利用できるようになります。つまり、データの保存場所をOpenTelemetryにして、各種サービスではなくせるということです。
ここにデモのアーキテクチャの図が存在しているので、ここのデータフローを見るとわかりやすいです。
集めたデータは、具体的にどこで見れるの？というと、UIとしてこのようなベンダーが提供してるサービスが使えるようです。（画面までは具体的に見れてません）
OpenTelemetryの課題と解決策
ただ、OpenTelemetoryを利用する際の問題もあるそうですね。それはOpenTelemetoryは設定もドキュメントも多くて、何をどう設定するのが良いか把握するのが難しいことらしいです。その問題を解決するために、自動計装という解決策が出てきたそうです。これを紹介するのが、 PyConAPACでの山口さんの発表でした。
実は私自身、まだ実際に手を動かしていないので、詳細は山口さんの発表を聞いてください。以下にリンクを貼っておきます。
まとめ
サービスが分散していると、その都度ダッシュボードが違ったり、何をどこで取っているのかすらわからなくなり、システムの状態把握が難しくなりますよね。こういう状況を改善する際の一つの方法がOpenTelemetryの利用です。信頼性はユーザー目線で考えるべきで、全体の品質をどう担保するか、それには「SRE」（Site Reliability Engineering）という考え方が関わってきます。そして、それを維持していくために特定のベンダーに依存するのは望ましくありません。その考え方に関連する概念がOpenTelemetryであると理解しました。
PyCon APACでの発表を聞くことで、これまでに読んできた本や様々な経験から色々と学んでいた内容の点と点がつながった感じがします。だから、この経験と理解をブログにまとめておきました。同じようなことを考えている人もいるかもしれないですからね。
今後は、実際にOpenTelemetryを触ってみたり、山口さんが紹介されてた書籍を読んでみたいと思います。
この記事が誰かの参考になれば幸いです。
