分散トレーシングとは？仕組みやメリットを解説

分散トレーシングは、複雑化したシステムにおける障害発生時の原因究明に役立つものとして注目を集めています。しかし、どのように活用すればよいのか迷う人もいるかもしれません。

ここでは、分散トレーシングの仕組みやメリット、活用方法や適したツールを解説します。

分散トレーシングとは？

分散トレーシングとは、複数のシステムを通過するトランザクションを追跡し、収集する監視方法です。ユーザーからアプリケーションに対して何らかのリクエストが発生したときに、サービス間で実行される一連の処理の流れを追跡します。リクエストが完了すると、追跡記録をひとまとまりのデータとして保存します。

アプリケーションを通過するさまざまなリクエストとトランザクションの経過を記録するので、アプリケーションのパフォーマンスに悪影響を及ぼすボトルネックやバグの迅速な特定が可能です。素早い対処ができれば、安定したサービスレベルを維持できるでしょう。

分散トレーシングの必要性

昨今のシステムは外部システムとの連携が不可欠であり、それらが相互に影響し合うことにより複雑化した一途を辿っています。特にクラウドネイティブの環境ではより複雑化した構成も多くなっており、スムーズで素早い障害対応のために、分散トレーシングが必要になります。

従来のモノリシックなシステムであれば、エラーやトラブルが起こっても、その原因究明はさほど難しくありませんでした。一定の知見を持ったエンジニアであれば、CPUやメモリの使用率などインフラの状態やログからトラブルの原因にたどり着くことができました。

しかし、クラウドネイティブの分散型システムでは、数多くのマイクロサービスが複雑に関連し合うため、障害発生時における原因特定が非常に困難です。

この状況を解決する方法のひとつが、分散トレーシングです。分散トレーシングでは、ユーザーがアクセスするフロントエンドからバックエンドアプリケーションのそれぞれのレイヤーで発生したリクエストと処理を個々に追跡し、記録します。このひとつながりの処理には固有のIDが付けられて記録されるので、障害の原因を容易に特定できます。

分散トレーシングの仕組み

分散トレーシングの仕組みは、分散トレーシングのリクエストの処理方法を確認することで理解できます。まず、トレーシングの始まりは、ユーザーがアプリケーションの操作をした瞬間です。ユーザーが何らかの操作をすると、リクエストが出され、それに伴うさまざまなサービスが呼び出されたり、データストアへのアクセスが起こったりします。この一連のトランザクションを追跡し、管理するのです。

また、リクエストがひとつのサービスから別のサービスへ移動するたびにデータを収集し、リクエスト完了までの情報を「スパン」として記録します。スパンには、リクエストの内容に関する詳細なデータが含まれており、ひとつのトレース情報としてまとめます。それを可視化することで、リクエスト全体がどのように関連しているかが明確になるのです。

分散トレーシングのサンプリング方法

システム内を流れていくデータ量は膨大なため、すべてを記録することは現実的ではありません。そのため、ピックアップしたデータだけを収集し保存するサンプリングが必要です。分散トレーシングのサンプリング方法には2種類あります。それぞれの内容を見てみましょう。

ヘッドベースサンプリング

ヘッドベースサンプリングは、リクエストが発生した時点でサンプリングするかどうかを決定するタイプで、多くのモニタリングツールが使用するサンプリング方法です。一定時間に一定量のデータをサンプリングするため、アプリケーションへの負荷や保存するデータ量を抑えられます。ただし、リクエストが完了する前にサンプリングされるため、どのトレースが問題に遭遇するかを事前に知ることはできません。

テールベースサンプリング

テールベースサンプリングは、リクエストが発生して完了した後にサンプリングされ、スパンすべてを記録するタイプのものです（サンプリング条件を設定することも可能）。アプリケーションへの負荷が増大し、データ量も大きくなるデメリットはあるものの、すべてのエラーを漏れなく観測できるメリットがあります。

開発環境などでさまざまなリクエストに対する反応をトレースしたい場合は、テールベースサンプリングが有効です。

分散トレーシングのメリット

分散トレーシングには、さまざまなメリットがあります。代表的なメリットを見ていきましょう。

障害対応を迅速化できる

分散トレーシングを行うことによって、障害対応を迅速化できます。従来の方法では、縦割りされた各領域を、それぞれの担当チームが順を追って調査することになり、時間と労力がかかり、効率的とはいえません。

例えば、ユーザーが何かの操作をして反応が遅いといった場合、最初にブラウザ側のHTMLコンテンツ開発チームが異常の有無をチェックします。そこで異常が見られなかった場合は、次にアプリケーションの各サービスを手掛けるチーム、さらにバックエンドの担当チームが同様に異常の有無を確認します。

分散トレーシングを行えば、異常の原因がどこにあるかを素早く特定できるため、該当するチームがすぐに作業にとりかかれるのです。

チーム間の連携が改善できる

チーム間の連携が改善できる点も、分散トレーシングを行うメリットのひとつです。前述した従来の対応プロセスでは、障害発生時に自分たちの担当範囲に異常が見当たらない場合、ほかのチームに原因を求めがちです。しかし、原因を見落としていたといったケースも少なくありません。このような場合、チーム間に反発が生まれやすく、連携意識の希薄化にもつながります。

しかし、分散トレーシングによって障害の原因が素早く特定できれば、こうした反発や衝突を起こさず、相互に連携しながら復旧にあたることが可能です。また、関係者全員で、トランザクションが視覚化された同じ画面を見ることができるため、どこに問題があるのか、具体的にどんな作業を行えばよいか、といった建設的な検討を重ねられます。

生産性の向上が期待できる

分散トレーシングを導入することで、開発や運用の現場での作業の効率化が期待でき、生産性の向上がもたらされます。障害対応を迅速化でき、チーム間の連携も円滑に進めば、現場のエンジニアの作業負荷は軽減し、よりクリエイティブな作業にリソースを集中できるでしょう。

また、開発段階から分散トレーシングを組み込んでおくと、リリース後に問題が発生しても、サービスを止めずに対応可能です。こうした体制を整えておけば、開発者側も安心して新機能をリリースできるため、リリースの頻度が増え、多くのサービスをユーザーに提供し続けられます。

分散トレーシングの活用例

さまざまなメリットを持つ分散トレーシングですが、どのように活用すればよいのでしょうか。活用例をいくつかご紹介します。

複雑に関連したサービスを視覚化する

分散トレーシングは、複雑に関連したサービスを視覚化することに活用されます。分散トレーシングによって、アプリケーション上でどのサービスがどこのサービスとつながり、処理を進めているのかを記録することができます。そのため、複雑に関連し合ったアプリケーションサービスを可視化し、どこからどのようなリクエストがきて、どのサービスにリクエストを出しているかを、地図のように表示が可能です。アプリケーションを含めたシステムの状態を確認できるだけでなく、サービス全体がどのように動いているかを明確に把握できます。

目指すログにスピーディーにアクセスする

分散トレーシングは、目指すログにスピーディーにアクセスするために活用されます。ログは、何らかの問題があったときは、解決への第一歩になるデータです。しかし、ログを確認する作業は、システムのあちこちにログインし、タイムスタンプを照らし合わせて確認するといったかなりの手間がかかるものです。そこで、分散トレーシングを活用することで、必要なログに素早くアクセスできるようになります。

エンドツーエンドでボトルネックを把握する

分散トレーシングの活用例として、エンドツーエンドで全体の動きを把握し、どこにボトルネックがあるのかを迅速に特定することも挙げられます。分散トレーシングでは、フロントエンドからバックエンドまで、すべてのレイヤーでトランザクション情報を収集可能です。例えば、フロントエンドでは、ユーザーの操作情報を収集し、アプリケーション内でどのようなサービスがどのようにつながってどう動いたか、データストアとどういったやりとりをしたかが記録されます。そのため、ボトルネックを素早く特定することが可能です。

分散トレーシングにおけるNew Relicの強み

モニタリングツールは数多く販売されていますが、特に分散トレーシングに強みを持つのがNew Relicです。New Relicは、オブザーバビリティプラットフォームですが、元々はアプリケーション監視の機能から始まっています。そのため、分散トレーシングを含めたアプリケーション全体を監視する機能が強化されているのです。New Relicには、分散トレーシングといっしょに活用することで、障害の原因を迅速に把握できる機能を提供しています。その主な機能を見てみましょう。

Errors inbox

Errors inboxは、すべてのエラーを積極的に検出して、一括管理し表示する機能です。APMやブラウザ、モバイルなど、あらゆる領域から発せられるすべてのエラーをひとつの画面で俯瞰できます。

検出したエラーの発生回数やユーザーへの影響などを元に優先順位をつけて、迅速なエラー対応が可能になります。また、サービスに影響を与える重大なエラーに対しては、Slackなどで担当者にアラートを飛ばすことも可能です。

Logs in Context

Logs in Cotextはブラウザやモバイルなどのフロントエンドからバックエンドアプリケーション全体のエラーを補足し、コンテキスト（エラーログやスタックトレース）の分析を可能にします。クラウドネイティブの環境では、数多くのマイクロサービスが分散されています。これらを横断して性能の悪い・エラーが起きている処理と関連するログを一気通貫で確認できます。分散トレーシングやErrors inboxと併用すれば、障害の原因を素早く把握した上で、可視化でき、問題解決の迅速化に貢献します。

分散トレーシングを導入するなら、New Relicがおすすめ

分散トレーシングの導入を検討するなら、New Relicがおすすめです。New Relicは、複雑なコードを新たに書き込む必要はなく、アプリケーションにエージェントを組み込むだけで、手間をかけずに分散トレーシングを導入できます。

また、パフォーマンスレベルを数値化するだけでなく、アプリケーションに関連したエラーやログを紐付けて把握できるため、トラブル対応を素早く行える利点があります。これは、フロントエンドからバックエンドまでを可視化する、New Relicの優れた点です。

New Relicにおける分散トレーシングのイメージ

システム開発では、フロントエンドとバックエンドとで開発会社が異なったり、同じ会社の中でも別々のチームが担当したりといったケースは少なくありません。何らかの障害が発生した際に、フロントエンドチームとバックエンドチームで、見ている視点が異なるケースも起こりえます。New Relicなら、関係者全員が同じものを見ながら、議論や検討を重ねられ、建設的なコミュニケーションが期待できます。

効率的に分散トレーシングを導入するなら、New Relicを検討してみてはいかがでしょうか。