OpenCensusからOpenTelemetryへの移行

アプリケーション開発

本稿はJCB Advent Calendar 2024の12月24日の記事です。

こんにちは。デジタルソリューション開発部の長谷川です。

担当しているアプリケーションではトレース・メトリクスを用いてアプリケーション利用状況の可視化を行っています。これにより障害対応やボトルネック分析の迅速化を実現しているのですが、この度トレース・メトリクスの収集で利用するパッケージをOpenCensusからOpenTelemetryへ移行しました。

OpenTelemetryは、OpenCensusとOpenTracingの統合プロジェクトで、より広範な機能と高い拡張性を提供しています。また、クラウドプロバイダーやバックエンドサービスからの充実したサポートを受けることも可能であり、長期的に開発効率の向上とシステムの可観測性の改善が見込めるため移行を実施する運びとなりました。

本記事では移行の進め方や、苦労した点について記します。

トレース・メトリクスの収集と照会の構成

JDEPではアプリケーションで収集したトレース・メトリクスの可観測性バックエンドとしてDatadog※を利用しています。

アプリケーションからDatadogへのOpenTelemetryのトレース・メトリクス連携は以下の構成で実施しています。

※Datadog: クラウドベースのSaaS型運用監視サービス

移行の進め方

移行は以下の流れで進めました。

  1. アプリケーションの実装を改修
  2. OpenCensus版とOpenTelemetry版でトレース・メトリクスを比較
  3. 差分の原因調査・解消

OpenTelemetryは、一部の利用パッケージにおいて、移行の開始時点でトレースはサポートされているものの、メトリクスはサポートされていないものがあったため、先にトレースのみを移行する段階的な移行を実施しました。

本記事ではトレースのみの移行対応について記載します。

移行で苦労した点

トレースの移行においては以下の点で想定外に苦戦し、対応が長期化しました。

  1. 被疑箇所が多く調査に時間がかかる
  2. 原因箇所によっては対応のリードタイムが発生する
  3. 段階的な移行による実装ミスの発生、メトリクスのデグレード検証コストの増加
被疑箇所が多く調査に時間がかかる

トレースで想定外に差分が発生した場合、被疑箇所は大まかに4種類ありました。

  • 被疑箇所①: アプリケーション内のトレースの生成箇所（手動計装もしくはパッケージによる計装）
  • 被疑箇所②: アプリケーション内のトレーサー及びエクスポーター
  • 被疑箇所③: Datadog Agent
  • 被疑箇所④: Datadog Backend

どこでトレース情報の加工が行われ、もしくはトレース情報が欠落したのか、以下の手順で地道に調査する必要がありました。

  1. 被疑箇所①及び被疑箇所②についてデバッグ
  2. 1で原因が特定できなかった場合、被疑箇所③についてdatadog-agentの公開ソースコード及びリリースノートやイシューを確認
  3. 1及び2で原因が特定できなかった場合、Datadogカスタマーサポートへ問い合わせを実施

特に2について、移行初期段階では移行メンバーのDatadog Agentの理解が乏しく、想定外に時間がかかりました。

原因箇所によっては対応のリードタイムが発生する

JDEPではJDEP上のアプリケーション間でDatadog Agentを共有しています。

そのため、OpenTelemetryの移行に伴い発生したトレースの差分を解消するためにDatadog Agentのオプションやバージョンを変更したい要求が発生しても、他のプロジェクトへの影響も確認し慎重に進める必要がありました。

アプリケーション間でDatadog Agentを共有しSREチームに管理してもらうことで、通常アプリチームはDatadog Agentの仕組みを理解せずとも利用可能になるといった恩恵は大きいです。しかし、影響範囲の広さにより大きなリードタイムが発生してしまうこともあります。

対応を開始する前はその点について意識できておらず、スケジュールの調整が必要になりました。

段階的な移行による実装ミスの発生、メトリクスのデグレード検証コストの増加

トレースのみの移行を実施したことにより、トレースのために利用するパッケージと、メトリクスのために利用するパッケージが混在することになりました。

例えばRESTサーバのトレース・メトリクス情報の収集において、トレースのためにotelhttp、メトリクスのためにochttpを利用する状態になりました。

handler = otelhttp.NewHandler(
    handler,
    containerName,
    otelhttp.WithFilter(func(*http.Request) bool { return true }),
    otelhttp.WithSpanNameFormatter(tracer.TransportSpanNameFormatter),
    otelhttp.WithPropagators(
        b3.New(b3.WithInjectEncoding(b3.B3MultipleHeader))))
handler = &ochttp.Handler{Handler: handler}

※http.Handler生成の処理を一部抜粋

上記に伴い、「何の機能を利用したくてこのパッケージを利用しているのか」を理解して実装する必要が生じ、特に移行に関わっていないメンバーの理解が定着するまで実装ミスが発生しました。

また、移行対象ではないメトリクス側に影響を及ぼしていないかも慎重に確認する必要があり、移行を実施していないメトリクスの確認についても移行を実施するのと同等の検証を実施する必要が生じました。担当するアプリケーションでは多くのメトリクスを実装していたため、段階的ではない移行に比べて総合的な検証コストが大幅に増加しました。

まとめ

本記事ではOpenCensusからOpenTelemetryへの移行について、移行の進め方に焦点を当ててご紹介しました。

これから移行を実施する方々の参考になれば幸いです。

終わりに

JCBでは我々と一緒に働きたいという人材を募集しています。 詳しい募集要項等については採用ページをご覧下さい。

本文および図表中では、「™」、「®」を明記しておりません。 記載されているロゴ、製品名は各社及び商標権者の登録商標あるいは商標です。

また、記事の内容は、公開時点の情報に基づいています。最新の情報については、Google Cloud の公式ドキュメントをご確認ください。

©JCB Co., Ltd. 20︎21