はじめに

先日、はてなさんの主催するハンズオンに参加しました。
https://mackerelio.connpass.com/event/342156/

オフラインのハンズオンで、先日リリースされたMackerelの分散トレーシング（旧：Vaxila）機能の説明だけではなく、
OpenTelemetryの概念や分散トレーシングのなかで問題のあるレスポンスやクエリ、エラーの原因解析などかなり丁寧なハンズオンでした。

参考：Mackerelはアプリケーションパフォーマンスモニタリングへ対応します
https://mackerel.io/ja/blog/entry/announcement/20250203

本記事では、ハンズオンの概要とハンズオンを踏まえ分散トレーシングを自分たちのサービスに取り入れていく際に大事なことを少し考察してみたいと思います。

ハンズオンの概要

ハンズオンでは、ローカルで作ったDockerコンテナベースのアプリケーションのテレメトリをMackerelに送付し、分散トレーシング機能を使いながらアプリケーションの改善を行っていきます。
したがって、下記のような環境を用意する必要があります。

前提条件

ローカルPCにGitがインストールされていること
ローカルPCでDockerが利用可能なこと
Mackerelのオーガニゼーションが開設されていること
※2025年2月時点では分散トレーシング機能はβ版のため、無料で使うことができます

ハンズオン資料は公開されており、READMEがかなり詳細に記載されているため、読み進めるだけでも勉強になります。
https://github.com/mackerelio/mackerel-handson/tree/main/tracing

ハンズオンの流れ

1. 分散トレーシングのデモ
HotRODという架空のタクシー配車アプリを使って、ハンズオンは進みます

レイテンシーの分布

トレースごとのサマリーを表示することができ、メソッドやレイテンシーを確認できます

トレースの集計もることができます。トレース一覧のスパンの属性について、その値のバラつきを表示します。たとえばhttp.route属性はリクエストパス、http.status_code属性はレスポンスのステータスコードを示しますが、どのようなリクエストパスが多いのかや、レスポンスのエラー率などを見ることができます。

リクエストが集中すると、遅延が発生するアプリのようです。
個別のリクエストを見ると、SQL SELECTが原因ではないかという推測ができます。

エラーログの解析

同じアプリを改良していくと、エラーが発生するようになったので、課題という欄を選択すると、エラー情報が出てくるようになりました。

routeの処理があからさまに遅いです。

どうやら、ここでexcenptionが発生しているようです。

推測される理由も表示され、ここから原因を特定することができます。

このように、分散トレーシング機能を使って、原因を推測することができるようになっています。

2. トレースをもとにRuby on Rails アプリを改善

次のハンズオンでは、エラーの発生しているアプリを修正していきます。

method_sampleに問題がありそうだと視覚でもわかりやすくなっています。

どの行に問題があるかも見えました

コードを見ると、改善点が示されています（デモなので、わかりやすく・・・）

エラーはなくなりましたが、まだmethod_sampleは遅いです。

なんか怪しい属性があるので、ここを修正してみます。

修正するとmethod_sampleは改善されましたが、細かい処理が大量に出ていますので、探ってみると、どうやらSQLの書き方に問題がありそうです。

これを改善して、レイテンシーが改善されました。

データベースのクエリごとの集計もこのようにみることができます。

こんな形で、ハンズオンはここまでになります。
詳しいハンズオンの進め方は公式資料を見ていただくとよいかと思います。

分散トレーシングを業務に取り込んでいく際に考慮すべきこと

上記のハンズオンを踏まえたうえで考慮すべきことを書いていきます。実際はもっとあると思いますが、いったん思いついたことを記載しておきます。

可読性の高いコード
分散トレーシングを導入するしないに限らず、可読性の高いコードは意識されていると思いますが、デモのようにエラーメッセージがわかりやすくなっているとは限りません。普段からエラー処理やエラーメッセージを理解しやすくしておく必要があります。
開発と運用の組織が分かれていなくても、自分以外の人がコードを見る可能性は十分にあります。万が一自分が開発チームから離れた際も後続のメンバーのことを考えてこれらの処理を考えていく必要があります。
分散トレーシングを集中的に取り組むタイミング
トレーシングを日常的に取り組むこともあると思いますが、濃淡はあると思います。リリース直後のタイミングは集中的に取り組み、安定してきたら少し頻度を減らす、ということも考えたほうがよいでしょう。
Mackerelに限らず、トレースやログを保管するとそれだけでストレージ料金がかかっていくこともあるので、リリース直後と、安定化したタイミングでOpenTelemetry Collectorの収集間隔を変えたり、ログやトレースの保持期間を短くするなどの工夫が必要になります。
テレメトリの保持期間
分散トレーシングを過去にさかのぼって行うこともできますが、その分ストレージの容量を増やすことになるので、どのくらい遡れるようにするかは決めておく必要があります。
OpenTelemetry Collectorの可用性
OpenTelemetry　Collectorの可用性にも注意が必要です。サイドカーコンテナを利用する場合や、モノリシックなインフラに置かれたサービスの計装であればインフラの可用性と同期しますが、OpenTelemetry Collectorを別のインフラに置く場合などはそれ自体の監視や運用も必要になってきます。
テレメトリのセキュリティ
今回のハンズオンではあまり触れてなかったのですが、OpenTelemetryで外部のツールに送る場合のセキュリティを考慮する必要があります。
HTTPSの暗号化はもちろんのこと、外部のツールのエンドポイントにExporterの通信を絞る、といったセキュリティの考慮も必要となります。

そもそもアプリケーションやインフラ構成で分岐がありすぎてドキュメントをあっちゃこっちゃしてOpenTelemetryでの計装を始めるまでがつらいのをなんとかしたい・・・（ここはMackerel関係ないので検閲されましｔ）

まとめ

Mackerelらしく非常にグラフィカルで直感的で理解しやすいインターフェースを志向していることはよくわかる一方で、インフラ監視のインターフェースと比較するとまだまだ洗練されてはいないように思えました。
ただ、Mackerelの開発のみなさんもそこは認識しているようで、これから新機能や改善を行っていくようなので、正式リリースまでには私ももっとOpenTelemetryを理解して使えるようにしていきたいと思います。

フィードバックフォームもあるようなので、ぜひ気づいたことがあればフィードバックを送ってみるのが良いと思います。
https://docs.google.com/forms/d/e/1FAIpQLSdgVvOwLW-OU6cd06M9eT-QMSrBrPRubCzLnjnt8NX5VUTpPQ/viewform