New Relicでソリューションを提供している佐々木です。
本日がNew Relic Advent Calendar 2019の最終日となりました。
最後の記事として、New Relicが今月リリースしたてほやほやの新機能をご紹介したいと思います。
#New Relic における分散トレーシング
分散トレーシングはマイクロサービスアーキテクチャの普及に伴って一般的になった概念です。
ユーザーからアプリケーションへのリクエストが発生した際に、複数のサービスにまたがって実行される一連の処理を追跡するプロセスのことを分散トレーシングと呼びます。
分散トレーシングによって、一般的に難しいとされている以下のような監視を行うことができます。
- 複雑なシステム上を行き来するリクエストのパスを追跡
- そのパス沿いのコンポーネントごとの応答時間を可視化
- パス上のどのコンポーネントがボトルネックとなっているかを把握
New Relic では、トレースの対象となるサービス内の処理の1つ1つを"スパン(Span)"という単位で記録し、スパンの関係性をツリー構造で表現しています。
分散トレーシングについてもっと詳細を知りたい方は、こちらのドキュメントを参照してください。
新機能: フロントエンドからの分散トレーシング
これまでNew Relicでは、Trace rootと呼ばれるトレースの開始地点に関して、サーバーサイド側からしか開始できなかったのですが、この度ユーザーがブラウザからページ読み込みをリクエストしたタイミングをTrace rootにすることができるようになりました！
この新機能によって、真のエンドツーエンドのトレースが可能になり、実際のユーザーの体感を把握しながらアプリケーションのパフォーマンスを詳細に分析することができるようになります。
それでは実際に設定をしてみます。
##1. サーバーサイド側の分散トレーシングを有効化
分散トレーシングはNew RelicのAPMエージェントが提供する機能なので、APMエージェントの導入が前提となります。
(他にZipkinやOpenTelemetryと互換性を持つTrace APIも提供していますが、今回は割愛します)
その後追加の設定として、エージェントが導入されたサーバーのNew Relic の設定ファイルに分散トレーシングを有効化するパラメータを記載するだけです。
パラメータは言語ごとに異なりますが、例としてJavaであれば、newrelic.yml内に
distributed_tracing:
enabled: true
と追記します。
##2. フロントエンド(Browser)側の分散トレーシングを有効化
New Relic BrowserのSaaS GUI上で操作をするので、アプリケーションがNew Relic Browserに監視対象として登録されていることが前提となります。
New Relic Browserの画面で対象のアプリケーションを選択し、"Application settings"メニューを開きます。
その中で、
- Agentの種類で"Pro+SPA"を選択
- Distributed TracingをOnにする
の2点を設定すれば完了です。
実際にこんな感じでトレースが見える
こちらがフロントエンドからの分散トレーシングの見え方例です。
一番上がブラウザから見たパフォーマンス、その下の"oops.jsp"と"v1/Coupons/IsValid"がそれぞれ、ブラウザにコンテンツを表示させるために実行されたサービスになります。
フロントエンドでのパフォーマンスは607ms、サーバーサイドが335msと、実際にユーザーが体感しているパフォーマンスも含めてトレースが取れています。
また、このトレースはエラーが含まれており、ブラウザ上で500エラーが発生してしまっていることが、画面右側のERROR DETAILSという箇所でわかります。分散トレーシングの利点の一つとしてトラブルシューティングが簡単にできるという点があります。実際にやってみましょう。
エラーが発生しているサービスは赤字で表示されるのですが、この例ではエラーの最下層はサービス"v1/Coupons/IsValid"だということがわかります。そのエラー詳細を見ると
と、該当のクーポンが存在しないよ、というエラーメッセージを確認でき、原因をすぐに突き止めることができます。
このように、フロントエンドのユーザー体験を意識しながらアプリケーションの振る舞いの詳細を知ることができるのがNew Relicの分散トレーシングです。簡単な初期設定だけですぐにデータを見ることができますので、ぜひお試しください！