分散トレーシングとは、分散システムのサービス要求をトラッキングし、レイテンシやパフォーマンスのボトルネックなどを可視化する手法です。
現代ビジネスのデマンドは情報技術の爆発的な発展をもたらし、一元化されたレガシーコンピューターシステムが強力で複雑な分散型 IT 環境に進化しています。 ところが、今日のクラウドベースのネットワークとリモートアクセスデータ処理の機能強化に伴うこの複雑さの増大によって、リスクも大きくなります。
相互依存関係が入り組んでいるため、複雑なシステムでは問題が発生する可能性が高くなります。 1 つの部分に起きた障害がシステム全体に連鎖する可能性があり、問題の特定と修正も一元化されたシステムに比べてはるかに困難な場合があります。 同時に、システムが複雑なほど、ある部分の変更が他の部分にどのような影響を与えるかを予測することが難しくなり、最も無害な調整でさえ予想外の結果をもたらします。 さらに、複雑なシステムを徹底的にテストすることは飛躍的に難しくなり、問題が検出されずにすり抜けてしまう可能性が高まっています。 その解決策をもたらすのが分散トレーシングです。
分散トレーシングは 2010 年に Google が導入した Dapper 論文から始まったと言えます。この論文は、大規模分散システムのトレーシングインフラストラクチャの礎となりました。 興味深いことに、Lightstep (後の ServiceNow Cloud Observability) の創設者である Ben Sigelman は Dapper の作成に尽力した人物です。 Dapper に続いて、Twitter は 2012 年に最初のオープンソース分散トレーシングプロジェクトである Zipkin をリリースしました。 2015 年、Uber は Dapper に着想を得た Jaeger を立ち上げました。
2016 年、Sigelman はブログ投稿「Toward Turnkey Distributed Tracing (ターンキー分散トレーシングを目指して)」を書きました。これが後に「OpenTracing マニフェスト」として知られるようになります。 この画期的な文書は OpenTracing を単一の標準として紹介し、トレーシングエコシステム内で標準化が行われていないことに対処し、OpenTracing が Cloud Native Computing Foundation (CNCF) の下のプロジェクトになり、最終的に 2019 年に OpenTelemetry と合併するための基盤を築きました。
OpenTelemetry バージョン 1.0 は 2021 年にリリースされ、それ以来トレーシング、測定基準、ログの事実上の標準となっています。 2010 年の Dapper から現在の OpenTelemetry 機能まで、10 年余りの間に、分散トレーシングは単一のバックエンドシステムから広く使用されるエンドツーエンドソリューションへと進化し、最終的には最新の包括的な可観測性プラクティスへの下地を作りました。
分散トレーシングにより、組織はあらゆるアプリケーション、特にマイクロサービスアーキテクチャを使用して構築されたアプリケーションをプロファイリングして監視できます。 このアプローチでは、分散システム内の個々のサービスが相互にどのようにやり取りするかを可視化し、個々の要求のシステムフロー上の進捗状況について正確に把握します。
要求のジャーニーを追跡し、各部分にかかる時間を測定することで、分散トレーシングはパフォーマンスのボトルネック、レイテンシの問題、潜在的な障害の特定に役立ちます。 そのため、分散トレーシングは DevOps チームと IT チームにとって重要なツールであり、システムの最適化、トラブルシューティング、メンテナンスをより効果的に行うことができます。
分散トレーシングは、次の 3 つのコアコンポーネントを中心に構築されています。
- スパン
スパンはシステム内のサービスによって実行される作業の 1 単位であり、開始時間と終了時間の間隔を区切りとし、ログやタグなどのメタデータが含まれる場合があります。 スパンはトレースの構成要素であり、ワークフローのさまざまな部分を表します。 ルートスパン (親スパンともいう) は独自のスパン (子スパン) を持つことができ、この子スパンもスパンを持つことができます。 - トレース
トレースは 1 つまたは複数のスパンで構成され、分散システム内を移動するサービス要求の完全な実行パスを表します。 トレースはツリーとして描かれることが多く、そのルートノードはユーザーのインタラクションを表し、他のノードは要求の処理と応答の準備に関わるさまざまなマイクロサービスを表します。 - タグ
タグは、スパンに付与されたメタデータ要素です。 タグはコンテキストと分類を示します。
トレース/スパン構造は要求中心の視点を提供し、個々のマイクロサービス間のギャップを埋め、システムのパフォーマンスについて統一された視点をもたらします。 この情報により、組織はユーザーエクスペリエンスを理解して改善するための準備を整えることができます。
トレーシング、ログ記録、測定基準は可観測性において重要な役割を果たしますが、これらは同じ概念ではありません。 それぞれに異なる目的があり、その概念の違いと補完する性質を理解することは、包括的なシステム監視とデバッグに不可欠です。
- トレーシング
分散トレーシングは、分散システムのコンポーネントを通過する要求の詳細を示し、パフォーマンスの調整とトラブルシューティングにおいて役割を果たす各種サービスを通じて要求のフローをキャプチャします。 ログ記録や測定基準とは異なり、分散トレーシングは特定の要求のジャーニーに焦点を当て、マイクロサービス間のやり取りを明確に把握できます。 - ログ記録
ログ記録とは、ユーザーアクション、システムエラー、その他のアクティビティなど、システム内の特定の個別イベントを記録することです。 タイムスタンプ付きのログは特定の時点にシステムで発生したことに関する詳細な情報を提供します。この情報はデバッグや監査に不可欠なものです。 分散トレーシングは要求のフローを追跡しますが、ログ記録はより静的なイベントのスナップショットを提供するため、システムのさまざまな部分間の関係を必ずしも示すものではありません。
測定基準は、特定の時点または一定期間におけるシステムの状態を表す数値であり、応答時間、エラー率、システムリソース使用率等が含まれます。 測定基準は分散トレーシングにおいて重要な役割を果たし、分散システム内のさまざまなサービスのパフォーマンスを定量化可能な方法で監視および分析します。 これらの数値はトレースとログから推定され、「一目でわかる」情報を提供したり、応答時間、エラー率、システムスループットなどの特定の側面に関する詳細なレポートを作成したりすることもできます。
重要業績評価指標を要約する測定基準のレンズを通してトレースデータとログデータを検討することで、組織は分散アーキテクチャを包括的に理解し、迅速な診断と実用的なインサイト取得を可能にし、効果的なシステム最適化を促進できます。
マイクロサービスはソフトウェアアーキテクチャ設計の一種で、緩やかに結合され、独立して展開可能なサービスの集合としてアプリケーションが構造化されています。 各マイクロサービスは特定の機能領域に焦点を当て、より広範なシステム内の個々のコンポーネントとして機能します。 このモジュラー型アプローチは、柔軟性と拡張性を高め、開発スピードを向上させることができます。 分散トレーシングのコンテキストでは、マイクロサービスは要求が通過する個々のノードとして重要な役割を果たします。
要求が 1 つのマイクロサービスから別のマイクロサービスに移動すると、分散トレーシングはこれらのインタラクションの詳細を各ステップでの所要時間まで含めてキャプチャします。 この情報には、要求が多数のサービスをどのように流れていくかが詳細に示され、ボトルネック、レイテンシ、潜在的な障害が特定されます。
分散システム内でマイクロサービスがどのように相互作用するかを理解することは一筋縄ではいかない場合があります。分散トレーシングによってその相互作用に関する貴重なインサイトが提供されるため、組織はパスを可視化し、システムパフォーマンスを監視し、発生する可能性のある問題をトラブルシューティングして、より堅牢で効率的なシステムアーキテクチャを促進できるようになります。
特にマイクロサービスや動的アーキテクチャのコンテキストにおいて、分散トレーシングは分散型システムを扱う組織にとって不可欠なツールとなっています。 分散トレーシングは、要求と各サービスとのすべてのやり取りを包括的にトラッキングして記録することで、監視、デバッグ、パフォーマンスの最適化に関する重要なインサイトを提供します。 属性をトレースに追加してさらに明確にすることができます。また、各スパンはスパンの親子関係などの詳細なメタデータで記録されるため、要求がサービス内やサービス間でどのように移動するかを完全に把握できます。
そのため、現代のアプリケーション環境の複雑さを管理するために分散トレーシングに目を向ける組織が増えています。 今日の複雑なアプリケーションスタックには多数の潜在的な障害ポイントが存在するため、問題の根本原因を特定することは難しく、時間がかかり、エラーが発生する可能性があります。 分散トレーシングはこのプロセスを簡素化し、問題を迅速かつ正確に特定できるようにします。これにより、優れたユーザーエクスペリエンスを提供する企業の能力が直接強化されます。
同時に、分散トレーシングは、データストレージとコンピューティング能力の管理が困難になるポイントにまでデータ量が増加する「カーディナリティ」の問題に対する効果的な解決策にもなります。
分散トレーシングのメリットは、マイクロサービスのパフォーマンスについての理解を強化し、迅速な問題解決を促進し、顧客満足度を向上させることにもつながります。 各マイクロサービスのパフォーマンスの詳細を示すことで、組織は安定した収益源を確保しながら、戦略とイノベーションに多くの時間を費やすこともできます。
分散トレーシングによって提供されるデータは重要ですが、あくまでも単なるデータに過ぎません。 そのデータが何を意味するかを明確に理解していなければ、意思決定プロセスにプラスの影響を与えることはできません。 データの真の価値は、数値から導き出すことができる実用的なインサイトにあります。しかもそれが最新で、関連性が高く、信頼性がある場合に限ります。
このデータをインテリジェントに分析し、状況に応じて理解することで、組織は問題を特定し、原因を明らかにし、効果的なソリューションを実装できます。 分散トレーシングはどのようにして単なるデータ収集にとどまらず、さまざまなシナリオに対する深いインサイトを提供するのでしょうか？ 次の点を考えてみましょう。
分散トレーシングは、レイテンシやスループットの低下など、ソフトウェアの健全性低下の症状を認識する上で重要な役割を果たします。 これは診断ツールのように機能し、観測可能な影響とその根本原因を結びつけ、観察された変化の原因についての仮説の検証を可能にします。
サービスが利用できなくなると、説明を要求されます。 トレーシングは、組織が機能停止の前に行われた変更 (内部または外部) を特定するのに役立ちます。 ソフトウェアのバグ、ユーザーによる変更、パフォーマンスの問題につながるインフラストラクチャの変更などの違いはあるにせよ、分散トレーシングを使用すると、機能停止の前後のシステムの状態を判断し、原因を明確に特定できます。
個々のサービス内の変更を理解することが不可欠です。 展開でもバージョンの更新でも、分散トレーシングは異なるステージ間のパフォーマンスを分析し、各スパンにバージョン情報をタグ付けします。 この詳細ビューは、サービスのパフォーマンスに影響を与える変更を診断するのに役立ちます。
システムは静的ではなく、システム内で操作するユーザーも静的ではありません。 ユーザーの行動の変化などの外部要因がサービスパフォーマンスの変化を促進する可能性があります。 インサイトフルトレーシングでは、タグを使用して要求やユーザー機能の重要な部分をキャプチャし、ユーザーがアプリケーションをどのように操作しているか、また、これらの操作が予期しない要求をどのように生成するかをより深く理解できます。
リソースは有限であり、時には単に行き渡るだけの十分な量がない場合もあります。 分散ネットワークにおけるリソースの競合は、パフォーマンスに大きな影響を与える可能性があります。 分散トレーシングは、CPU、コンテナ、データベースなどの共有リソースがどのように使用されているかを把握するためのインサイトを提供します。 適切にタグ付けされたトレースを使用すると、集計分析が可能になり、パフォーマンスの低下が特定のリソース使用状況と相関するタイミングと場所を特定し、リソース計画と競合解決に役立ちます。
動的な依存関係とはアップストリームの変更がサービスのパフォーマンスに影響を与える可能性があることを意味します。 エグレスオペレーションやバージョン番号のタグ付けなど、インサイトに富んだ分散トレーシングにより、アップストリームサービスがパフォーマンスに与える影響を可視化できます。 これらの関係を理解することは、その変更の影響に適応したり、軽減したりするのに役立ちます。
オープンソースの分散トレーシング標準は、標準化された方法でさまざまなサービスにわたるトレーシングデータの収集、管理、分析をガイドする基本的フレームワークです。 この標準によって相互運用性が促進され、ベンダーロックインが軽減されるため、開発者は最小限の調整でさまざまなトレーシングバックエンドとツールを切り替えることができます。 また、複雑な分散システム内でさまざまなプラットフォーム、言語、アプリケーションを連携させるための共通基盤も提供します。
最も広く使用されているオープンソースの分散トレーシング標準には、次のものがあります。
Cloud Native Computing Foundation (CNCF) の一部である OpenTracing は、最も初期のオープンソース分散トレーシング標準の 1 つです。 このフレームワークには、分散コンテキストの伝播をサポートする API が含まれており、開発者は (特定のベンダーにロックインされることなく) アプリケーションコードにインストルメンテーションを追加できます。 OpenTracing は、さまざまなプラットフォームで一貫したトレースセマンティクスを提供しましたが、その後アーカイブされ、CNCF はこのプロジェクトのサポート提供を終了しています。
OpenCensus は複数のエクスポーターをサポートするように設計されており、ユーザーは分析のためにトレースデータをさまざまなバックエンドに送信できます。 この Google 発祥のフレームワークは、分散トレーシングと測定基準の自動および手動収集を可能にする明確な API とライブラリのセットを提供します。 可観測性のための統一されたソリューションを提供することで、OpenCensus は重要な統計データの収集と管理のプロセスを簡素化します。 OpenCensus もやはり廃止されています。
OpenTelemetry は、OpenTracing と OpenCensus の統合プロジェクトであり、両方の標準の優れた機能を組み合わせています。 Lightstep が共同で設立した OpenTelemetry は、API、ライブラリ、エージェント、インストルメンテーションの統合された広範なセットを提供し、クラウドネイティブソフトウェアの完全な可観測性フレームワークを提供します。 OpenTelemetry は、アプリケーションのインストルメンテーションを簡素化し、さまざまな一般的なフレームワークとライブラリのビルトインサポートを提供します。 拡大するコミュニティと幅広い業界サポートに支えられ、分散トレーシング、ログ記録、測定基準の可観測性標準になることを目指しています。
分散トレーシングの機能性と成功には、さまざまな機能が不可欠です。 各機能が果たす役割は次のとおりです。
可観測性バックエンドのアラートメカニズムを使用すると、チームは問題を示す可能性のある特定の測定基準や動作のしきい値を設定できます。 これらのしきい値に達すると、該当する担当者にアラートを送信して、潜在的な問題を迅速に特定して解決できるようになるため、システムの信頼性が向上します。
分散トレーシングは、さまざまなサービスやコンポーネントを通じて、要求のジャーニー全体を包括的に可視化します。 このエンドツーエンドのインサイトは、システム内のボトルネック、非効率性、異常を特定するのに役立ち、パフォーマンス調整とエラー分析のための詳細なコンテキストを提供します。
分散トレーシングは、システムの動作に関する正確な情報を提供することで、問題のデバッグと特定にかかる時間を大幅に短縮します。 チームはトラブルシューティングではなく機能開発やイノベーションに多くの時間を費やすことができるため、この効率性はコスト削減につながります。
複数の地理的な場所やクラウドプロバイダーにまたがる分散コンピューティングが普及するにつれて、分散トレーシングはこれらの複雑な環境をまたぐ連携を容易にします。 これにより、さまざまな地域やクラウドプラットフォームにわたるシステムのパフォーマンスを整然と視覚化できるため、一貫した監視と分析が可能になります。
分散トレーシングにより、各サービスのパフォーマンスをリアルタイムで監視してトラッキングし、サービスがどのように相互作用しているかを把握し、最適化が必要な領域を特定できます。
コレクターは、テレメトリデータ (トレース、測定基準、ログ) の収集、処理、エクスポートにおいて重要なコンポーネントとして機能します。 ベンダーにとらわれない統一されたデータ収集と送信のオプションを提供し、さまざまな可観測性バックエンドとのシームレスな連携を可能にします。 コレクターの柔軟性により、インストルメンテーションコードを変更することなく、トレーシングをさまざまな環境に適応させることができます。
サンプリングは、(各要求ではなく) 要求のサブセットを収集して、トレーシングバックエンドに送信されるデータの総量を削減する機能です。 これにより、分散トレーシングシステムは、リソースを大量に消費することなく大規模に運用できると同時に、貴重なインサイトを提供できます。
システムが成長するにつれて、分散トレーシングは複雑さとデータ量の増加に対応する必要があります。 スケーラビリティ機能により、トレースは大規模な環境に対応し、システムの規模にかかわらず一貫したパフォーマンスインサイトを提供します。 もちろん、データの取得は最初のステップに過ぎません。組織がデータを理解できるようにするには、システムの成長と進化に合わせて分散トレーシングと並行して拡張できるプラットフォームへのアクセス権が必要です。
最新のアプリケーションは、さまざまな言語、フレームワーク、テクノロジー、クライアント (Web ベースとモバイルの両方) で構成されています。 分散トレーシングは、マルチプラットフォームのフルスタック環境をまたいで運用できるため、テクノロジースタックがどれだけ多様であろうと、開発者はテクノロジースタック全体から必要なインサイトを得ることができます。
前述したように、分散トレーシングのメリットは、組織の分散システムに対する可視性の向上に結びついています。 しかし、分散トレーシングにおける可視性と分散トレーシング自体の可視性が価値を持つのは、他のメリットが実現する場合に限られます。 分散トレーシングの主なメリットには次のようなものがあります。
分散トレーシングの主なメリットの 1 つは、購入などの重要なユーザーアクションの実行に必要な期間を測定できることです。 要求パスウェイを追跡することで、ユーザーエクスペリエンスに悪影響を与える可能性のあるバックエンド障害を特定して修正することができます。
ほとんどの組織は Service Level Agreement (SLA) の範囲内で事業を展開し、顧客やその他の内部部門に対するパフォーマンスコミットメントを正式に規定しています。 分散トレーシングツールは、個々のサービスからパフォーマンスデータを収集するため、SLA を遵守しているかどうかを評価するチームにとって便利なツールです。
サービスレベル目標 (SLO) は、サービスの期待されるパフォーマンスと可用性を定義する特定の測定可能な目標であり、組織がサービスレベルを測定するのに役立つサービスレベルインジケーターによってサポートされています。 分散トレーシングを適切に展開すれば、監視する特定のシグナルを選択し、事前定義された範囲を超えたエラーやデータについてアラートを設定することで、SLO を追跡して達成する機会を提供します。 これにより、関連するインシデントに迅速かつ効果的に対処できます。
分散トレーシングは、さまざまなサービス間の複雑な原因と結果の関係に関するインサイトを提供します。 この理解は、企業がシステム全体のパフォーマンスを最適化するのに役立ちます。
複数のチームが要求の履行に関わるさまざまなサービスを監督する環境では、分散トレーシングにより、エラーが発生した場所と対処する必要があるチームを明確にすることができます。 この明確さは、チーム間のコラボレーションを強化し、責任の所在の特定に費やす時間を大幅に短縮し、組織内の全体的な生産性に貢献します。
アプリケーションのパフォーマンスに問題が発生した場合、サポートチームは分散トレーシングを使用して、問題がバックエンドにあるかどうかを特定できます。 影響を受けるサービスからのトレースを分析することで、エンジニアは問題を特定して解決できます。 エンドツーエンドの分散トレーシングツールを使用することで、同じプラットフォーム内のフロントエンドのパフォーマンス問題を調査することも可能になり、潜在的な問題の平均検出時間 (MTTD) と平均復旧時間 (MTTR) の両方を短縮できます。
分散トレーシングには多くのメリットがありますが、潜在的な障害があり、実力を最大限に発揮できない可能性もあります。 これらの課題を理解することは、分散トレーシングを効果的に実装することを目指す組織にとって重要です。 最も顕著な課題をいくつか示します。
一部の分散トレーシングプラットフォームが抱えるハードルの 1 つは、手動インストルメンテーションの必要性です。 つまり、組織は要求のトレースを開始するために既存のコードの変更または修正が必要になる可能性があるということです。 このような手動介入は、貴重なエンジニアリングリソースを費やしてしまうだけでなく、コードの改訂時にアプリケーション内にエラーが発生する可能性もあります。
従来の分散トレーシングは、多くの場合バックエンドサービスに制限され、要求が最初のバックエンドサービスに到達したときにのみトレース ID が生成されます。 エンドツーエンドの分散トレーシングプラットフォームを利用しないと、フロントエンドで対応するユーザーセッションの可視性が不明瞭なままです。 この制限により、問題のある要求の根本原因を特定し、フロントエンドチームとバックエンドチームのどちらで問題を解決する必要があるかを判断することが難しくなります。
この点に関しては、OpenTelemetry などのフレームワークを採用することで、フロントエンドトランザクションの可視性が限られているという課題や、インストルメンテーションに関連する問題が軽減または解消されます。 これらの課題は、OpenTelemetry をコアコードベースに組み込む多くの業界テクノロジー (Kubernetes など) に固有のものです。
現代のビジネス IT 環境が規模と複雑さの面で拡大し続ける中、分散トレーシングのメリットはますます明らかになっています。 受賞歴のある ServiceNow AI Platform を活用した ServiceNow Cloud Observability は、トレーシングの新しい標準を確立し、分散システムの要求全体を完全に可視化します。
既存ツールとの連携。 測定基準とトレースをブリッジして統一されたテレメトリを作成。 組織の MTTR を大幅に削減。 そしてこれらすべてを通じて、使用量の増加に合わせてコストを拡大することなく、ビジネス成果に合わせて価格設定を調整し、価値を高めます。
Cloud Observability は分散トレーシングに革命を、ビジネスに利益をもたらします。 詳細は今すぐ ServiceNow へお問い合わせください。