GMO メイクショップ コアグループでエンジニアをしている池田です。
今回はOpenTelemetryを用いた分散トレーシング環境を構築したので、そのプロセスを綴っていきます。

• 導入の目的
• 前提
• • プロジェクトについて
  • 筆者について
• 構成
• • ローカル環境
  • 開発環境
• セットアップ
• Jaegerコンテナの準備
• • ポート
• 計装
• • トレースの構成要素について
  • トレーサーの定義
  • スパンの生成
  • サービス間でトレースデータを共有する
• ログ出力
• • Jaeger
  • AWS X-Ray
• aws-otel-collectorの設定
• 完成したもの
• • ローカル環境(Jaeger)
  • 開発環境(AWS X-Ray)
• まとめ
• 参考

導入の目的

今回OpenTelemetryを導入した目的は以下の通りです。 環境ごとに導入する目的が異なります。 ローカル、開発環境で基本は運用して、ステージング、本番では調査の時だけ稼働させる予定です。

• ローカル環境
• • ログを見やすくする
  • 標準出力しているログが見にくい
  • コンテナが分かれているため、コンテナごとにログを確認する必要がある
• 開発環境
• • ボトルネックとなる処理の可視化

前提

プロジェクトについて

• 言語: Go
• 環境
• • AWS
  • ecspresso

筆者について

• Go: 4ヶ月ほど経験
• AWS: SAA保有

構成

ローカル環境

ローカルでは手軽に導入が可能なJaegerを使います。 各サービスがJaegerのコレクターに対してgRPCで通信を行いトレースデータを送信します。 

開発環境

開発環境ではaws-otel-collectorを使用します。 アプリ本体のサイドカーとしてaws-otel-collectorを走らせ、アプリからaws-otel-collectorへgRPCで通信し、トレースデータを送信し、さらにそこからX-Rayへデータを送信します。 X-Ray画面上ではトレースIDでCloudWatchのログを抽出しています。そのため、CloudWatchにログ出力する際にトレースIDを付与しています。 

セットアップ

まず初めにセットアップ用のコードを書きます。 今回はGoなのでこちらを参考にします。

opentelemetry.io

今回はローカルでJaeger、開発環境でX-Rayとバックエンドが異なるので、少し工夫が必要です。 一部省略している部分はありますが、下記のように実装しています。

Jaegerコンテナの準備

jaegertracing/all-in-oneのイメージを使うと、すぐにJaegerを使用することができます。
コレクターとトレースログを見るためのUIが含まれています。

ポート

• 16686: トレースログ確認のためのUI
• 4317 : gRPC
• 4318 : HTTP

docker compose up -d で起動すると、Jaegerのコレクターとトレースログを見るためのUIが立ち上がります。

計装

トレースの構成要素について

計装するにあたり、こちらを読んでおくとトレースIDやスパンIDなどの理解が深まります。ぜひ読んでみてください。

qiita.com

zenn.dev

トレーサーの定義

トレーサーをグローバルな変数として定義します。
当プロジェクトでは上記のようにパッケージごとにトレーサーを定義することにしました。
こちらでもベストプラクティスとして推奨されているようです。

github.com

スパンの生成

定義したトレーサーを使用してスパンの生成を行います。

サービス間でトレースデータを共有する

異なるサービスを同様のトレースデータとして扱うためには、トレースIDなどのトレースデータをサービス間で受け渡す必要があります。 そのあたりの実装を自前で行うのは大変です。なので、ライブラリの力を借ります。 otelhttpやotelgrpcを使用すると、ミドルウェアとして組み込むだけで実現可能です。 当プロジェクトではコンテナ間の通信に、gRPCを使用しているため、otelgrpcを使用しています。

pkg.go.dev

以下のように組み込むだけで、自動計装が行えるかつ、トレース情報の受け渡しが可能です。

ログ出力

Jaeger

Jaegerのトレースログ上にログ出力するために必要な作業を行います。 下記のようなライブラリを用いて実装することも可能ですが、今回は自前で実装しました。

uptrace.dev

自前で実装するにあたり参考にしたのは、Jaeger公式がサンプルとして載せているコードです。 こちらではspan.AddEventというメソッドを使用して、スパンに対して追加の情報を付与しています。

github.com

上記を参考に実装しログに出力している内容をスパンのイベントとして出力することに成功しました。 一部省略している部分はありますが、下記のように実装しています。

AWS X-Ray

前述したように、X-Ray画面上でトレースIDでCloudWatchのログを抽出しています。 なので。ログ出力する内容にトレースIDを付与する必要があります。 contextからトレースIDの取得が可能なので、このような感じでトレースIDを取得して、ログ出力する内容に追加します。

aws-otel-collectorの設定

AWS環境でトレースログを収集するためのコレクターとしてaws-otel-collectorを使用します。

hub.docker.com

aws-otel-collectorイメージをベースとしつつ、設定内容を変えたいので、otel-config.yamlに設定内容を記述します。 その設定内容でecs-default-config.yamlを上書きします。

• receivers: トレースデータの受信についての設定
• processors: データを圧縮し、データ送信に必要な発信接続数を削減するためのバッチ処理を行なうための設定
• exporters: トレースデータの送信先についての設定

ECSのタスク定義では、上記の2ファイルから作成したイメージを使用します。 タスクの実行ロールにAWSXRayDaemonWriteAccessを付与する必要があります。 下記はタスク定義の一部です。

完成したもの

ローカル環境(Jaeger)

localhost:16686にアクセスすると、このようなトレースログを確認することができます。

実際のトレースログは都合上お見せできないので、画像は差し替えてます。

開発環境(AWS X-Ray)

AWSマネジメントコンソールでX-Rayの画面を見てみると、このように処理時間とCloudWatchから抽出したログを確認することができます。

まとめ

導入してみた感想としては、トレースID、スパンIDなどのOpenTelemetryの専門用語や概念から学ぶ必要があり大変でした。 ですが、勉強になることもたくさんあったのでやってみてよかったし、無事に導入できて安心しました。 このトレースログを活用して、ボトルネックの特定に役立てば良いかと思います。 また、当記事が私と同じようにOpenTelemetryを導入することになった人の役に立てば幸いです！

参考

• OpenTelemetryの公式ドキュメント
• • opentelemetry.io
• Jaeger公式ドキュメント
• • www.jaegertracing.io
• open-telemetry-goのわかりやすい解説
• • blog.cybozu.io
• インフラ系参考になる記事
• • aws-otel.github.io
  • zenn.dev
  • zenn.dev
  • zenn.dev
• X-Ray との切り替えに関して役立ちそうな記事
• • zenn.dev
• OpenTelemetryの無難な設定
• • zenn.dev

◆　他のBlogはこちらから⇒　https://tech.makeshop.co.jp/　◆

ご応募お待ちしています！