Managed Service for OpenTelemetry:Alibaba Cloud エンドツーエンドトレーシングのベストプラクティス

Alibaba Cloud エンドツーエンドトレーシングソリューション

Managed Service for OpenTelemetry を含む Alibaba Cloud ARMS は、ユーザー クライアント (Web、Android、iOS など) 、クラウド ゲートウェイ (ALB、MSE、Ingress、ASM など) 、バックエンド アプリケーション (Java、Go、Python、.NET など) 、クラウド コンポーネント (データベース、メッセージキュー、大規模言語モデルなど) にわたるエンドツーエンドトレーシングをサポートしています。以下の図をご参照ください。

トレースインストルメンテーション： 主要言語向け ARMS エージェントと多言語カバレッジ向けオープンソース

Java、Go、Python などの主要言語については、プロプライエタリエージェントを使用できます。このエージェントは、より高いトレース品質、優れたパフォーマンス、強力な安定性、向上した使いやすさを提供します。より多くの言語をサポートするために、Managed Service for OpenTelemetry は、OpenTelemetry、SkyWalking、Zipkin、Jaeger の 4 つの主要なトレーシング フレームワークと完全に互換性があります。このサービスは、10 以上の言語のトレースインストルメンテーションとデータ レポートもサポートしています。以下の表をご参照ください。

ARMS と Managed Service for OpenTelemetry のデータは完全に相互運用可能です。多言語シナリオでこれらを併用できます。

ARMS は 2024 年に JavaAgent 4.0 をリリースし、OpenTelemetry エコシステムを完全に採用しました。このエージェントのコアは OpenTelemetry フレームワーク上に構築されており、リソース モニタリング、パフォーマンス診断、アプリケーション セキュリティのための追加データを提供します。より豊富なデータに加えて、ARMS JavaAgent 4.0 は、柔軟なトレース サンプリング ポリシー、GUI ベースのエージェント管理、包括的なセルフ モニタリング、動的機能デグラデーションなどの高度な機能をサポートしており、エンタープライズ本番環境に最適です。

トレースの収集と処理： Alibaba Cloud エコシステムとの緊密な統合によるワンクリック トレース アクセス

クラウド移行時の一般的な課題は、複雑な依存関係全体でサービスの可用性を維持することです。エンドツーエンドトレーシングは、リクエストの遅延やエラーを引き起こすノードを迅速に特定することでこの課題に対処し、障害復旧速度を向上させ、ビジネスへの影響を軽減します。では、クラウド製品からトレース データを取り込むにはどうすればよいでしょうか。

Managed Service for OpenTelemetry は、約 10 の Alibaba Cloud 製品と緊密に統合されており、内部でのトレースインストルメンテーションとデータ レポートが可能です。サポートされているクラウド製品のコンソールでトレーシング スイッチを有効にすることで、対応するトレース データを表示でき、データ収集が大幅に簡素化されます。

以下では、3 つのクラウド製品でトレーシングを有効にする方法について説明します。

• ALB: [リスナーの詳細] ページの [トレース] エリアでスイッチを有効にします。

• MSE: インスタンスを作成する際に、[Managed Service for OpenTelemetry] を選択します。

• リアルユーザーモニタリング： アプリケーションの作成時に、アプリケーション設定で[トレース設定]を選択します。

製品機能が異なるため、トレースインストルメンテーション方法も異なります。データ収集方法は、主に次の 2 つのカテゴリに分類されます。

• 直接または転送されたトレース レポート： たとえば、Real User Monitoring は内部インストルメンテーションを使用し、Exporter を通じて直接データをレポートします。これにより、より詳細で柔軟なインストルメンテーションが可能になります。

• ログからトレースへの変換： たとえば、ALB ゲートウェイはバックエンドでアクセスログを消費し、それらをトレース データに変換します。この方法は侵襲性が低くなります。

どちらの方法にもトレードオフがあります。直接または転送されたトレース レポートは、より標準的なアプローチとして一般的に推奨されます。ただし、ハイパフォーマンスなシナリオや、レガシーシステムの変更が困難な場合は、ログからトレースへの変換が代替手段となります。これには、TraceId などのトレースコンテキストをログに追加する必要があります。

以下の表は、現在トレーシングをサポートしているクラウド製品、プロトコル、接続ガイドを示しています。

トレースコンテキストのパススルー： プロトコルの統一と ARMS エージェントによるマルチプロトコル変換

単一のアプリケーション コンポーネントの場合、インストルメンテーションが成功すれば、コンソールでそのトレース データを収集して表示できます。ただし、真のエンドツーエンドトレーシングでは、統一されたプロトコルでアップストリームとダウンストリームのトレースを接続し、途切れのないチェーンを確保する必要があります。これには、技術面および調整面での課題があります。

Alibaba Cloud Observability は、OpenTelemetry W3C プロトコルに基づくエンドツーエンドトレーシングを提供します。さらに、より多くのプロトコルとコンポーネントへのサポートを段階的に拡大し、より完全で柔軟なトレーシング エコシステムを構築していきます。

完全なエンドツーエンド呼び出しチェーンは、次の 3 つのフェーズで構成されます。

• フロントエンドアプリケーション: rum-browser が browser.request:/api/shipping リクエストを開始します。

• ゲートウェイアプリケーション: ingress-nginx がトラフィック転送を実行します。

• バックエンドアプリケーション: frontend-proxy、frontend(nodejs)、ShippingService(shippingservice)、quoteservice(php)、CurrencyService(currencyservice cpp) を順に呼び出します。

トレース詳細ページでは、各サービスのスパンがウォーターフォールチャート形式で表示され、呼び出し階層と期間の分布が示されます (合計期間： 24 ms)。右側のパネルでは、選択したスパンの属性 (アプリケーション名、インターフェース名、IP アドレス、statusMessage、Attributes リストなど) を表示できます。

既存のアプリケーションのエンドツーエンド プロトコル スタックを統一することは、新しいアプリケーションの場合よりも困難です。特に、SkyWalking から OpenTelemetry への移行など、技術スタックを切り替える場合はなおさらです。既存の運用システムを稼働させたまま新しいシステムを検証する必要があり、最大の課題は、2 つの異なるトレーシング システムがトレースの連続性を妨げることなく共存できるようにすることです。

これに対処するため、プロプライエタリエージェントには互換性の最適化が含まれており、デュアル エージェントが共存できるようになっています。これにより、移行が完了するまで両方のシステムが正しく安定して動作することが保証されます。以下の図は、このシナリオを示しています。

プロプライエタリエージェントは、マルチプロトコル検出とパススルーをサポートしています。アップストリームとダウンストリームのシステムの変更が困難な場合、ARMS エージェントを使用してプロトコル変換を行うことができます。たとえば、アップストリーム アプリケーション A が Jaeger プロトコルを使用している場合、ARMS エージェントは Jaeger コンテキストを受信し、Jaeger と Zipkin B3 の両方のコンテキストをダウンストリームにパススルーします。その後、ダウンストリーム アプリケーション B は Zipkin B3 プロトコルを使用でき、TraceId のパススルーを実現して、完全なトレースを接続できます。