トレースとは何ですか？
分散トレーシングの定義
分散トレーシングは、アプリケーションの全パスにわたるすべてのユーザーリクエストのエンドツーエンドのコードレベルの記録（トランザクション）を提供するテレメトリーデータの一種です。
分散トレーシングは、アプリケーションの健全性、依存関係、システムコンポーネント間の相互作用を可視化します。これは、クラウドネイティブ環境におけるオブザーバビリティとアプリケーションパフォーマンス監視（APM）に欠かせないコンポーネントです。
トレースは、サイトリライアビリティエンジニア（SRE）、ITOps、DevOpsチームが、システム内のさまざまなマイクロサービスを通じたリクエストのエンドツーエンドの動きと動作を理解するのに役立ちます。トレースを使用することで、開発者はパフォーマンスやユーザーエクスペリエンスに影響を与えるボトルネックやその他のコード問題を見つけ、効率化を図ることができます。
分散トレーシングと従来のトレーシング
分散トレーシングは、リクエストが分散環境を通過する様子を監視する方法です。
設計上、分散アーキテクチャーには複雑なサービスのネットワークが含まれます。リクエストは多数のマイクロサービスに渡って送信され、それぞれが特定のタスクを実行します。その結果、分散システムにおけるリクエストのトレースは複雑な作業となり、モノリシックアプリケーションで使用される従来のトレースでは不可能です。
従来のトレースから得られる洞察は限られており、拡張性がありません。従来のトレーシング方法では、リクエストごとにトレースをランダムにサンプルするため、トレースが不完全になります。
なぜトレースはアプリケーション開発において重要なのでしょうか？
トレーシングは、ソフトウェアエンジニアが多数のマイクロサービスにわたってリクエストを追跡できるため、アプリケーション開発にとって重要です。すべてのステップを視覚的に追跡できるため、トレーシングは非常に貴重となります。さまざまなアプリケーションのエラーをトラブルシューティングすることで、バグやパフォーマンスの問題を解決するのに役立ちます。
トレースは、次のことに役立ちます。
- 問題をより早く特定する：分散システムでは、トラブルシューティングはモノリシックのシステムよりもはるかに困難です。分散トレーシングは、アプリケーションエラーの根本原因と場所をより早く特定し、混乱を最小限に抑えるのに役立ちます。
- デバッグを簡素化：トレースは、リクエストがさまざまなマイクロサービスとどのように相互作用するかを包括的に把握できるため、最も複雑なアーキテクチャーでもデバッグプロセスを支援します。
- コラボレーションの向上：分散環境では、異なるチームが異なるサービスに取り組むことがよくあります。トレースは問題が発生した場所を特定し、その問題を解決する責任のあるチームを示します。
- 開発のスピードアップ：トレーシングにより、開発者はユーザーの行動に関する貴重な洞察を得て、アプリケーションのパフォーマンスを最適化し、アップデートや新規導入をリリースする取り組みを合理化できます。
トレーシングの仕組み
トレーシングは、マイクロサービスアーキテクチャーのさまざまなサービスを横断するリクエストのテレメトリーデータを収集、分析、可視化することによって機能します。
トレース（およびその他のテレメトリー）データを生成する前に、アプリケーションのインストルメンテーションを行う必要があります。インストルメンテーションは、トレースデータを追跡するためのコードを追加するプロセスです。OpenTelemetry（OTel）などのオープンソースプラットフォームは、マイクロサービスアーキテクチャーをインストルメントするためのベンダー中立のSDK、API、およびその他のツールを提供します。
データ収集
エンドツーエンドの分散トレーシングツールは、ユーザーがリクエストを開始するとデータの収集を開始します。各リクエストがシステムに入ると、識別情報（トレースID）が追加されます。この識別情報は、さまざまなサービスやコンポーネントを通過するときに渡されます。
リクエストのジャーニーにおける各ステップも記録されます。最初のスパンは親スパンと呼ばれ、それに続く各スパンは子スパンと呼ばれます。各子スパンは、元のトレースID、固有のスパンID、タイムスタンプ、ステータス、およびその他の関連するメタデータでエンコードされます。スパンは、環境全体にわたるサービスの流れに沿って階層的に編成されます。
APMの場合、アプリケーションをインストルメントし、トレース収集を有効にすると、アプリケーションのパフォーマンスを監視するために使用できるトレースアプリケーションメトリック（数値）を収集できるようになります。これには以下が含まれます。
- リクエストレート — 1秒あたりのリクエスト数
- エラー率 — 失敗したリクエストの数
- レイテンシー — リクエストの応答にかかる時間
- 期間 — リクエストにかかる時間
- スループット — アプリケーションが一定期間内に処理できるリクエストの量
トレース分析
リクエストが完了し、トレースですべてのデータが収集されると、データは集約されます。開発者は、トレース識別子、タイムスタンプ、その他のコンテキスト情報などのスパンのデータを使用して、リソースのボトルネック、レイテンシーの問題、またはエラーを見つけることができます。
監視と可視化
アプリケーションメトリックをトレースすると、アプリケーションのパフォーマンスを監視するのに役立ちます。変化があった場合、SREチームとDevOpsチームはすぐに行動を起こすことができます。
人工知能（AI）や機械学習を使えば、監視プロセスを部分的に自動化でき、エンジニアは潜在的な問題が発生する前に警告を受けることができます。またAIアシスタントは、他のソースからのオブザーバビリティデータと相互に関連付けることで、トレース分析をより深く掘り下げ、根本的な問題を迅速に調査するのに役立ちます。
最後に、すべてのスパンがウォーターフォールグラフで可視化されます。親スパンが上部に、子スパンが下部にネストされます。このグラフは、アプリケーションがリクエストに応答しようとしている間に実行していた処理を俯瞰したものです。そうすることで、エンジニアは分散システムのどの部分でパフォーマンスの問題、エラー、またはボトルネックが発生しているかを理解できます。
OpenTelemetryにおけるトレースのためのオープンスタンダード
OpenTelemetryは、ツール、API、SDKで構成されるオープンソースのオブザーバビリティフレームワークです。OTelを使用すると、SRE、DevOps、ITチームは、トレースを含むテレメトリーデータを単一の統合形式でインストルメントし、収集、エクスポートして分析できます。
Cloud Native Computing Foundation（CNCF）は、テレメトリーデータを収集してオブザーバビリティプラットフォームにルーティングするための標準化されたプロトコル、スキーマ、およびツールを提供するためにOTelを開発しました。トレースに重点を置いたOTelは、以前の2つのCNCFプロジェクトであるOpenTracingとOpenCensusの統合によって生まれました。これらは、コードのインストルメンテーションおよびテレメトリーデータのオブザーバビリティバックエンドへのルーティングに関する単一スタンダードを設定するために設計されていました。
2つのプロジェクトが統合された2019年以来、オープンソースコミュニティと企業の両方がOTelを採用しています。これは、OTelが単一の統合されたインストルメンテーション形式を提供し、将来も利用できるためです。
OpenTelemetryとそのオープンスタンダードが登場する前は、オブザーバビリティデータは一貫性がなく、相関関係を把握するのが困難なことが多くありました。分散環境では、DevOpsとITは、複数のプログラミング言語にわたって組織のさまざまなアプリケーションとサービスをサポートする、さまざまなライブラリをインストルメントする必要がありました。多くの場合、各コードインストルメンテーション、APM、またはトレーシングツールは独自のものであり、分散トレーシングに無数の問題を引き起こしていました。スタンダードがなく、すべてのアプリケーションからトレースを収集し、エクスポートするための単一のツールがない場合、パフォーマンスの問題やエラーを見つけるエンジニアの仕事は困難になります。
一方、OTelを使用すれば、エンジニアは異なるサービスからのトレースデータを追跡するためにコードを再インストルメントする必要はなく、変更のたびにテレメトリーデータを手動で再ルーティングする必要もありません。OpenTelemetryに準拠した、オブザーバビリティと監視ツールのオープンソースフレームワークが1つだけあります。
異常検知や生成AIに関するAIとのより深い統合など、新しいテクノロジーが出現するにつれて、OpenTelemetryは、エンドツーエンドの分散トレーシングのための、単一のサポートされた統合フレームワークを提供し続けます。
トレースに関するOTelのスタンダードには以下が含まれます。
- トレースデータ収集のためのAPIと規則の単一セット
- スパンは、トレースのコア単位として定義される
- スパンの命名と属性追加のためのセマンティック命名規則
- 異なるサービス間のスパンをリンクするコンテキストメカニズム
- さまざまなプログラミング言語のサポート
ElasticでのOpenTelemetryについてさらに詳しく
トレース、メトリック、ログ、プロファイル
テレメトリーデータ（ログ、メトリック、トレース）は、分散環境におけるアプリケーション、サーバー、サービス、またはデータベースの動作の完全なオブザーバビリティを提供します。オブザーバビリティの三本柱とも呼ばれるログ、メトリック、トレースは、すべてのユーザーのリクエストとトランザクションの完全で相関性のある記録を作成します。
3つのデータタイプはそれぞれ、環境に関する重要な情報を提供します。これらを組み合わせることで、DevOps、IT、SREの各チームはシステム全体のパフォーマンスをリアルタイムかつ履歴的に追跡できるようになります。
トレース
トレースは、コンテキストを提供するための分散システム全体にわたるリクエストのパスの詳細な記録です。トレースは、サイロ化されたデータをまとめ、ユーザーのあらゆるアクションを記録することで、エンジニアがボトルネックを発見し、複数のアプリケーションを使用するアプリケーションをデバッグして監視し、またシステムコンポーネント間の依存関係や相互作用を理解するのに役立ちます。
ログ
ログファイルは、イベントとシステムメッセージのタイムスタンプ付きレコードです。通常、ログはトラブルシューティングとデバッグに使用されます。これらは、システムの動作に関する洞察を提供し、問題の特定に役立ちます。
さらに、ほとんどのプログラミング言語にはログ機能が組み込まれています。そのため、開発者は既存のログフレームワークを引き続き使用する傾向があります。
メトリクス
メトリックは、一定期間にわたるシステムの状態またはパフォーマンスを表す数値で、主要なパフォーマンス指標です。DevOpsおよびその他のチームは、それらを使用してシステムの健全性を監視し、傾向を特定し、アラートをトリガーします。
プロファイル：現代のオブザーバビリティの未来の第4の柱
メトリック、ログ、トレースは、どこで何が起きているかについて貴重な洞察を提供します。また、システムがそのように動作する理由を理解することも重要です。なぜパフォーマンスのボトルネックや無駄なコンピューティングがあるのでしょうか？ここで継続的なプロファイリングが役立ちます。これはシステムの包括的なビューを実現するのに役立ち、コードレベルまでのより深いレベルの可視性を提供します。
分散トレーシングを実装する方法
分散トレーシングは、複雑なシステムや分散アプリケーションの監視とトラブルシューティングに不可欠です。分散トレーシングを実装する前に、トレーシングの目標とニーズを定義し、重要なサービスとリクエストパスを特定することが重要です。分散トレーシングの実装を成功させるための5つのステップは次のとおりです。
- OpenTelemetry（トレース、メトリック、ログを収集するための、現在の標準的なフレームワーク）などのトレーシングツールを選択する。既存のテクノロジースタックと互換性があり、将来にも対応できるものでなければなりません。
- インストルメントサービスおよびアプリケーション。これには、コードベースにトレーシングコードを追加し、アプリケーションでトレース（スパン）を定義することが含まれます。
- データ収集のリクエストを開始してトレースを収集する。分散トレーシングに欠かせないコンテキストの伝達を通じて、トレースが正確かつ完全であることを確認します。
- 監視、分析、可視化のためにトレースをエクスポートし、選択したバックエンドまたはクラウドトレースサービスプロバイダーに送信する。
- パフォーマンスのボトルネック、非効率性、エラーを特定する。トレースデータは、エラーを検出し、パフォーマンスの遅いサービスを発見し、サービス間のデータフローを可視化するのに役立ちます。
eブックをダウンロードし、アプリケーションパフォーマンス監視（APM）を使用して分散トレーシングを実装する方法を学ぶ
Elasticを使用したAPMと分散トレーシング
アプリケーションパフォーマンス監視（APM）は、現代のオブザーバビリティにおいて重要な役割を果たします。機械学習によってコンテキストを提供し、根本原因分析を改善することで、すべてのテレメトリーデータを把握できます。
Elastic Observabilityと検索のパワーを活用して、エンドツーエンドの分散トレーシングでコードの品質を向上させましょう。マイクロサービス、サーバーレス、モノリスのアーキテクチャーを横断する、分散されたトランザクションを捉えて分析しましょう。AWS Lambdaや自動インストルメンテーションに対応しているほか、Java、.NET、PHP、Python、Goなどの人気言語にも対応しています。顧客データやデプロイマーカーなどの注釈をトランザクションに追加することで、ダウンタイムを最小化し、顧客エクスペリエンスを最適化できます。