本記事は Kong Blog の記事を翻訳し転載しています。
2025年4月9日 読了時間8分
Madan Thangavelu
Uberエンジニアリング担当シニアディレクター
ソフトウェア開発は、モダン システムで高まる要求に応えるべく、常に新しいパラダイムとともに進化してきました。最も大きな変化の 1 つは、マイクロサービスの採用です。2010年代初頭に登場したこのアーキテクチャ パターンは、モノリシックなアプリケーションから、ネットワークを介して相互にやり取りする小規模で独立したサービスへと移行しました。この変化にともない、開発ライフサイクルのあらゆるステージに対応する新しいツールとフレームワークが必要になりました。コンテナ管理のための Kubernetes / Docker のような成熟したフレームワーク、クラウドアプリケーションの入出力を管理するための APIゲートウェイなど、業界標準となっているものも数多くあります。
そのようなフレームワークの一つで、クラウドネイティブの世界で急速に注目を浴びているのが OpenTelemetry です。オープンソースのオブザーバビリティの標準である OpenTelemetry は、開発者がマイクロサービスのアーキテクチャ全体のモニタリング、トレース、ロギングにアプローチする方法に革命をもたらしています。
このブログでは、OpenTelemetry の目的とコンポーネントについて詳しく説明し、どのようにインストルメンテーションを簡素化するかを探り、なぜそれが最新のクラウドネイティブ アプリケーションにおけるオブザーバビリティのデファクトスタンダードになっているのかに焦点を当てていきます。
分散トレーシングとは?
分散トレーシングは、分散システム内の複数のサービスを通過するリクエストのフローを追跡するために使用される方法です。これは、モダン アプリケーション、特にマイクロサービス アーキテクチャを使用して構築されたアプリケーションのパフォーマンスと動作を理解するための重要なツールです。マイクロサービス アーキテクチャでは、リクエストがレスポンスを返すまでに何十、何百もの異なるサービスを経由する可能性があります。
分散トレーシングの歴史
分散システムにおけるトレースという概念は、2010年にGoogleが開発した大規模な分散トレースシステムである Dapper によって初めて導入されました。これに続いて、Twitterは2015年に Zipkin をオープンソース化し、これは広く採用された最初のトレース ソリューションの1つになりました。
初期のトレーシングシステムは、スタンドアロン アプリケーションのパフォーマンス トレースと同様に、主に分散システムのレイテンシとパフォーマンスの問題の診断に重点を置いていました。やがてトレーシングはパフォーマンス監視を超えて進化し、分散ロギング、コンテキスト伝搬、集約分析などの分野に拡大しました。これについて、この記事でさらに詳しく説明します。
一方、Googleは、分散メトリックとトレースを収集するためのライブラリセットである OpenCensus をオープンソース化しました。同じ頃、さまざまな分散トレーシング ツールと互換性のあるトレース ロギング用に標準化されたAPIを開発することを意図して、OpenTracing が登場しました。2020年、 OpenCensus と OpenTracing は統合され、OpenTelemetry が誕生しました。OpenTelemetry は、メトリクス、トレース、ログを単一の強力なオブザーバビリティ ソリューションにまとめた統合フレームワークです。
分散トレーシングの基本
APIリクエストがクラウドに入ると(通常はゲートウェイまたはロードバランサーを経由)、複数のサービスを横断する旅が始まり、最終的にクライアント(デバイスまたは携帯電話で動作するソフトウェア)にレスポンスを返します。
このプロセスを一元的に可視化するには、次のようなコールパターンを想像してください。
これは、複雑なビジネス アプリケーションにおいて、リクエストがたどる可能性のあるルートを表しています。ただし、特定のリクエストの正確なコールパスを確立することが重要です。例えば、ユーザー サービスが /get-user API を公開している場合、ユーザーがメンバーでない限り、/get-user/get-membership-details API を呼び出すべきではありません。
以下は、そのようなリクエストに対して可能なすべてのコールパスを示したものです。
この図は、1 つのリクエストに対してあり得る 3 つのコール グラフを示しています。
任意のリクエストの結果を正確に再構築するには、分散トレースシステムが必要です。各サービス (A、B、C など) は、実行した作業に関するコンテキストをトレース システムに提供する必要があります。次に、分散トレースシステムは、完全なリクエストパスを再現するために、これらすべての情報を蓄積して、システムを通過する個々のリクエストの正確なフローを可視化することを可能にします。
分散トレーシングの主要概念
- トレース (traceID) :トレースは、単一のリクエストの処理に関連するすべてのサービスにわたる完全な過程を表します。リクエストがシステムを通過するパスの概要を示します。各トレースには、一意の traceID が関連付けられています。
- スパン (spanID): トレースは複数のスパンで構成されます。スパンは、サービス内の単一の作業単位を表し、APIリクエストの処理、データベースとのインタラクション、外部APIのコールなど、一意の spanID を持ちます。各スパンは、より大きなトレースの一部です。span は、多くの spanAttribute をコンテキストに追加することもできます。
- コンテキストの伝搬： リクエストがあるサービスから別のサービスに移動すると、コンテキスト（traceID や spanID など）が一緒に渡され、各サービスがプロセスの一部を全体のトレースに関連付けることができます。これにより、リクエストの全行程を追跡することができます。
- レイテンシとパフォーマンスの洞察： トレース内のスパンを可視化することで、特定のサービスにおけるボトルネック、パフォーマンスの問題、または障害を特定できます。例えば、リクエストが遅い場合、トレースによって、どのサービスが遅延を引き起こしているかを突き止めることができます。
APIゲートウェイと分散トレーシングの新しい利用法
APIゲートウェイは、分散トレーシング、特に大規模なクラウドネイティブ アプリケーションにおいて重要な役割を果たします。クライアント リクエストのエントリーポイントとして、APIゲートウェイは多くの場合、着信したリクエストを受信して処理する最初のシステムです。通常、リクエストの完全なコンテキストはこの段階でのみキャプチャされます。
効果的なオブザーバビリティを実現するには、APIゲートウェイでトレースを開始し、適切にtraceIDを割り当てることが不可欠です。traceID が API 識別子と共に割り当てられると、そのリクエストのすべての下流の アクティビティとインタラクションを追跡し、システムへの最初のエントリ ポイントにリンクすることができます。これにより、リクエストの開始から終了までの全行程が、単一のまとまったトレースでキャプチャされます。
何百ものマイクロサービスを扱う大企業では、分散トレーシングは、パフォーマンスを追跡し、システムの信頼性を最適化するためのインフラストラクチャの基礎となる要素です。しかし、トレーシングだけでなく、コンテキスト伝搬の概念は、その利点をアプリケーション開発の他の多くの分野に拡張する強力なツールとして浮上しています。
コンテキスト伝搬とは、リクエストにメタデータを挿入する機能を指し、メタデータはさまざまなシステム(メッセージキュー、ストリーム処理、API呼び出しなど)またはプロトコル(gRPCやHTTPなど)間で伝送されます。リクエストがシステム内を移動すると、各サービスまたはコンポーネントがメタデータに独自のコンテキストを追加し、リクエストの過程全体をより細かく把握できるようになります。
この機能により、以下のようにさまざまな新しいユースケースが生まれました。
- エンド ツー エンド(E2E)テスト：コンテキスト伝搬のバゲッジに「E2Eテスト」マーカーを使用して着信リクエストをタグ付けすることで、さまざまなシステムがこれらのリクエストを独自の方法で処理できます。たとえば、サービスによって、モック データで応答したり、意図しない副作用を防止したり、特別な処理ロジックを適用したりすることができます。これにより、本番システムに影響を与えることなく、スタック全体にわたって包括的なE2Eテストを実行し、実環境をシミュレートすることが可能になります。
- ルーティング デリゲート： マイクロサービス アーキテクチャで、地理的な場所、顧客の種類、その他の人口統計学的要因など、顧客の特定の属性に基づいてトラフィックを異なる方法でルーティングする必要がある場合は、この情報をテレメトリのバゲッジに挿入できます。これにより、システムはコンテキストに基づいてさまざまな環境またはクラスターにリクエストを動的にルーティングでき、ユーザーベースのさまざまなセグメントに対して、よりカスタマイズされた処理パスを提供できます。
システム全体にコンテキストを伝搬するこの機能により、インテリジェントで効率的なシステム動作の可能性が大きく広がります。進化し続けるテクノロジーにともなって、さまざまな領域にわたるコンテキスト伝播に関する、さらに革新的なアプリケーションが登場する可能性があります。
ログとメトリクスを採用した強力な進化
分散トレーシングが最初に登場したとき、主な目的は、ソフトウェア スタックを通じてリクエストフローを追跡し、レイテンシを測定することでした。しかし時を経て、業界では、トレースをロギングおよびメトリクスと組み合わせることでオブザーバビリティが大幅に向上することが認識されるようになりました。トレースされたリクエストが遅い、または低パフォーマンスだと特定された場合、次の論理的な手順は、根本的な原因をデバッグするために深く掘り下げることです。
これを実現するには、トレースを、その API リクエストのライフサイクル中に生成された関連するログおよびメトリクスと紐付ける必要があります。OpenTracing 自体はログやメトリクスの収集と保存を処理しませんが、重要なメタデータ（traceID、spanID、および追加の span属性など）をログやメトリクスといったオブザーバビリティのほかの要素に統合するために必要な API およびエクスポーター を提供します。この統合が、より包括的な洞察と迅速なトラブルシューティングを可能にします。
OpenTelemetryがインストルメンテーションの簡素化に果たす役割
OpenTelemetryが登場する以前は、分散システムの監視とデバッグには、複数の(多くの場合、互換性のない)ツールとフレームワークが必要でした。サービスをインストルメント化する作業は、特にメトリクス、トレース、ログにさまざまなオブザーバビリティ ソリューションを統合する場合に、煩雑で断片的でした。
OpenTelemetryは、テレメトリ データを収集するための単一の統一されたフレームワークを提供することでこの課題を解決し、インストルメンテーション プロセスを大幅に簡素化します。OpenTelemetryは、トレース、ロギング、監視のために個別のソリューションをマニュアルで構成および管理する代わりに、複数のサービスと言語にわたって動作する一貫したアプローチを提供することで、プロセスを合理化します。
OpenTelemetryの主要コンポーネント
- ベンダーに依存しないAPI： テレメトリ データを送信するための標準化されたインターフェースを提供する、複数のプログラミング言語の仕様で、ベンダーや基盤となるプラットフォームに関係なく、アプリケーションを簡単にインストルメント化できます。
- SDK (ソフトウェア開発キット)： ベンダーに依存しないAPIをさまざまな言語で実装するライブラリとツールのセットで、開発者はテレメトリ データ収集をコードに簡単に統合できます。
- コレクター： テレメトリ データを受信、処理、およびエクスポートするためのプロキシとして機能するベンダーニュートラルなコンポーネント。コレクターはOTLP、Jaeger、Prometheusなどさまざまな形式のデータを受け取ることができ、そのデータを複数のバックエンド オブザーバビリティ システムに送信して、さらに解析することができます。
- エクスポーター： コレクターからJaeger、Zipkin、Prometheus、その他ベンダー固有のオブザーバビリティ プラットフォームなどのバックエンド システムにテレメトリ データを送信するコンポーネントで、一元的な監視と分析を可能にします。
相互運用性とエコシステムの拡大
OpenTelemetry の主な利点は、幅広いオブザーバビリティ ツールと統合できることです。ベンダーに依存しないため、組織は分析と可視化するにあたり、優先するバックエンドを使用できます。メトリクスには Prometheus、トレースに Jaeger、ログに Elasticsearch を使用している場合でも、OpenTelemetry はこれらやその他のシステムにデータをエクスポートすることができます。
OpenTelemetry プロジェクトは急速な成長と採用を遂げており、Kubernetes などの主要なクラウドネイティブ プラットフォームや、AWS、Google Cloud、Microsoft Azure などのクラウド プロバイダーが OpenTelemetry ベースのインストルメンテーションをサポートしています。エコシステムが拡大し続けるなか、より多くのインテグレーションとすぐに使えるソリューションが利用可能になり、OpenTelemetry は、モダン アプリケーションの頼りになるオブザーバビリティ フレームワークとしての地位をさらに確固たるものにしています。
業界における採用
OpenTelemetry の発表以来、小規模なスタートアップから大企業まで、業界を問わず急速に採用が進んでいます。クラウドネイティブ アプリケーションを構築する企業は、オブザーバビリティに対する標準化されたアプローチを得ることの価値を認識しており、OpenTelemetry はまさにそれを提供しています。
OpenTelemetry を採用することで、組織はマイクロサービス アーキテクチャのパフォーマンスと健全性に関するより良い洞察を得ることができ、トラブルシューティングの迅速化、システムの信頼性の向上、ユーザー エクスペリエンスの向上につながります。
まとめ
分散システムが進化し続けるなか、堅牢なオブザーバビリティ ツールの必要性はこれまで以上に重要になっています。このシフトの最前線に立つ OpenTelemetry は、インストルメンテーションを簡素化して、オブザーバビリティ スタック全体にわたる相互運用性を高める、強力なオープンソースのフレームワークを提供します。OpenTelemetry を採用することで、組織はアプリケーションに対する深い洞察を得ることができ、問題をより速くトラブルシューティングし、本番環境でシステムをスムーズに実行することができます。
もし、将来性のあるオブザーバビリティ戦略をお考えであれば、OpenTelemetry は、検討すべきフレームワークといえるでしょう。
著者について
Madan Thangavelu氏は、Uber の Kong チャンピオン 兼 エンジニアリング担当シニアディレクターです。ソフトウェア業界で15年以上の経験を持ち、フィンテック、モバイルセキュリティ、大規模な消費者向けアプリケーションで豊富な経験を持っています。Madan氏は、Uber の APIプラットフォームを立ち上げ、世界中で数百万もの同時接続を処理しています。現在は、Uber Riderのフラッグシップ アプリの開発を指揮し、フルフィルメント、運賃、APIフレームワークなどの主要なビジネス プラットフォームを監督しています。「Uber の APIプラットフォームのエンジニアリング リーダーとして、APIコミュニティと学びを共有することを楽しんでいます。Kong には、そのような情報から恩恵を得られる素晴らしいコミュニティがあります。」
Kong Champion や、プログラムについてご関心がおありの方は、Kong Champion のページをご覧ください。
原文：Tracing, Logging, Metrics: Unifying Observability with OpenTelemetry
