OTLPでサクッと繋げられて、かつ思いのままにトレース分析できるツール
株式会社immedio / 井上拓磨
EM / EM / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|---|
Free | トレース監視 | 10名以下 | 2024年5月 | B to B |
| 利用プラン | Free |
|---|---|
| 利用機能 | トレース監視 |
| ツールの利用規模 | 10名以下 |
| ツールの利用開始時期 | 2024年5月 |
| 事業形態 | B to B |
アーキテクチャ
アーキテクチャの意図・工夫
OpenTelemetry Collectorを噛ませることで、各spanに対してフィルターおよび加工しています。おかげでHoneycombに流れる量をコントロールできています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
・トレース単体の分析の課題
導入前はGoogle CloudのCloud Traceによってトレース監視を行っていました。ただCloud Traceではスパンに対する属性値(例えばDBのクエリなど)が、長すぎる場合に途中で文字がカットされてしまう問題がありました。このため、各トレースで何が起きていたか正確に把握することが困難でした。
・トレース横断の分析の課題
Cloud TraceはGoogle Cloud配下にある場合、導入が簡単な一方で、機能的には他のトレース監視系ツールと比べると簡素なものでした。例えば、トレースの検索条件を保存できないので、毎回条件を手打ちするのが面倒だったりしていました。やっぱりよく使う検索条件は保存したいです。
どのような状態を目指していたか
- トレースの分析が十分にできること
- 組織が一定以上拡大したときも費用面での懸念がないこと
比較検討したサービス
- Sentry
- Datadog
- New Relic
比較した軸
- OpenTelemetry Protocol(OTLP)に対応していること
- OpenTelemetry Protocol(OTLP)の繋ぎこみが容易なこと
選定理由
分析のリッチさ(探索可能性の高さ)
例えばレイテンシーの高いAPIリクエストの対策をしたいとして、BtoB SaaSにおいては利用している企業IDが多いAPIリクエストについては対応の優先度が高い一方、利用企業IDが少ないAPIの改善は効果が薄いので優先度をコントロールしたい時があります。
例えばこのような場合下記のようなフローを踏みます。
- APIリクエストをエンドポイントごとにGROUP BYして、レイテンシーでリストアップ
- リストアップしたエンドポイント一覧で、最もレイテンシーが高いAPIを選ぶ
- 分散しているレイテンシーのうち、高いレイテンシーを記録しているリクエストにフォーカスして、それを利用している企業数を見る
- 利用企業が分散しているなら重要度を上げて対応
ここまでのフローが、一つのクエリからの流れでボタンぽちぽちするだけで分析できます。クエリからの流れで、というのが大事なポイントで、ツールによってはそれ専用のクエリを書き直したりするわけなのですが、これがHoneycombだと、クエリからそのまま欲しい結果まで辿り着くことまでできます。
なかなか画像抜きだと伝わりづらいですが、この体験はとても良いと同時に、Observability担保においては大事だと思っています。なぜなら、見たい結果をすぐ得られることは、Observabilityの重要な概念としてある「探索可能性(explorability)」を満たすからです。Honeycombはデータを柔軟に探索してインサイトを得るにはとても良いプラットフォームと考えています。
Honeycombは「Observability Engineering」の著者の一人が参加しているプロダクトということもあって、そのエッセンスを随所に感じます。例えばクエリした後、Bubble Up機能を使うとディメンジョンごとの統計を全て出してくれるのは、「さあこの結果からインサイトを得てくれ」というメッセージを感じます。
無料枠が太っ腹
「2000万 Event / 月」まで無料です。Eventは、トレースの文脈においては 1 span に該当します。Honeycomb においてはログやメトリクスも送信できるのでその場合はそれぞれの計測単位で 1 Event となるようです。
スタートアップにおいてはこの太っ腹な無料枠はとても嬉しいです。シリーズAのスタートアップにしては2000万スパンはむしろ少ない量だと思いますが、スロークエリやバグはあっても全体的な作りが良いためN+1などが発生せず、スパンの発生自体が抑えられていたのと、Otel Collecterによって連携するスパンを絞り込めていたので、スパンの効率がよかったのも、この無料枠内に抑えられた背景です。
またユーザー課金がないのも推しポイントです。Observabilityにおいては組織のエンジニアが自由にシステムを探索し、各々がインサイトを得られる状態を確保するのが良いと思いますが、ユーザー課金があるとそれを阻害するバイアスが働くかと思います。
OTLPに対応 / 繋ぎこみが容易
OTLP対応していることはマストでした。2024年3月当時、まだOpenTelemetry Protocolはそこまで日本においてメジャーな選択肢ではなかったと記憶してますが、当時から、各ベンダーが作るSDKを経由して計装するより、業界標準のプロトコルを利用していた方が、ベンダーロックインがなく、将来的な変化に強いと考えており、そのためにOTLPでのトレースログ受信に対応していることはマストでした。その点でHoneycombはOTELに標準で対応していました。
またHoneycombはOTLP経由での繋ぎ込みが圧倒的に容易です。OpenTelemetry CollectorのconfigにエンドポイントとAPIKeyを追記するだけで繋ぎこみの実装はほぼ終わりました。他サービスを見てみると、当時はOTLP自体がまだ新しいプロトコルだったこともあってか、対応するためにごちゃごちゃと実装させられることが多く、ドキュメントも複雑でわかりづらかった記憶があります。その点Honeycombは下記ドキュメントを見ていれば、さっと実装ができて感動しました。
https://docs.honeycomb.io/send-data/opentelemetry/collector/
導入の成果
改善したかった課題はどれくらい解決されたか
当初の課題だったトレース単体の分析やトレース横断の分析においては問題なく利用できています。特に不満な点はなく、課題は解消されたと言えます。
ただ正直、現状は高機能すぎて持て余しているところもあります。もっと自分たちで踏み込んで利用したいのですが、そこまでできていません。
どのような成果が得られたか
顧客起点ですが、特定のAPIの動作が遅いというフィードバックが来た際、トレースの内容を分析し、ボトルネックを突き止めることに役立ちました。
その他、特定の動作が遅いという問題があった際、ボトルネックを特定するのに役立っています。
導入時の苦労・悩み
ほぼありませんでしたが、サーバーがアメリカにあるので、画面を表示する時に少し遅さを感じる時がたまにありました。ただ現在はサーバーが追加されたのか、ほぼ気にならないです。
導入に向けた社内への説明
上長・チームへの説明
分析機能が強いこと
自分たちがやりたい分析が十二分にできること。
ベンダーロックインがないこと
業界標準のプロトコルを利用しており、もしこのサービスがダメになったとしても、繋ぎ先を変えるだけですぐに別のサービスに移行ができる。
費用対効果が高いこと
コストが上振れたとしても、Otel Collector側で出ていくspan量をうまく制御すれば、ROIが出るように流量を調整できること。
アラート機能がある
それまでレイテンシーのアラートを利用していたので、その機能も移行可能であること。
活用方法
特定のAPIが遅い事象が報告された時のボトルネックの発見に役立てています。
よく使う機能
- トレースの分析
- ダッシュボード
ツールの良い点
- 分析のリッチさ(探索可能性の高さ)
- 無料枠が太っ腹
- OTLPに対応 / 繋ぎこみが容易
ツールの課題点
- ドキュメントやツール本体が全て英語
ツールを検討されている方へ
分析については圧倒的にリッチなので、言語が英語であることや日本ではまだまだ市民権を得ていないことを懸念されないならオススメです。
今後の展望
もっと組織レベルで踏み込んで利用し、システムの改善に活かしたい。
株式会社immedio / 井上拓磨
EM / EM / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名
株式会社immedio / 井上拓磨
EM / EM / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


