/assets/images/32062/original/9178d6ef-9569-4fc7-8f84-ecd75cfcc597?1596514385)
GMOメイクショップ株式会社では一緒に働く仲間を募集しています
【エンジニアブログ】OpenTelemetryについて何も知らなかった人が分散トレーシング環境を構築してみた(Jaeger, X-Ray)
on 2024/07/08
GMO メイクショップ コアグループでエンジニアをしている池田です。
今回はOpenTelemetryを用いた分散トレーシング環境を構築したので、そのプロセスを綴っていきます。
導入の目的
今回OpenTelemetryを導入した目的は以下の通りです。 環境ごとに導入する目的が異なります。 ローカル、開発環境で基本は運用して、ステージング、本番では調査の時だけ稼働させる予定です。
- ローカル環境
- ログを見やすくする
- 標準出力しているログが見にくい
- コンテナが分かれているため、コンテナごとにログを確認する必要がある
- 開発環境
- ボトルネックとなる処理の可視化
前提
プロジェクトについて
- 言語: Go
- 環境
- AWS
- ecspresso
筆者について
構成
ローカル環境
ローカルでは手軽に導入が可能なJaegerを使います。 各サービスがJaegerのコレクターに対してgRPCで通信を行いトレースデータを送信します。
開発環境
開発環境ではaws-otel-collectorを使用します。 アプリ本体のサイドカーとしてaws-otel-collectorを走らせ、アプリからaws-otel-collectorへgRPCで通信し、トレースデータを送信し、さらにそこからX-Rayへデータを送信します。 X-Ray画面上ではトレースIDでCloudWatchのログを抽出しています。そのため、CloudWatchにログ出力する際にトレースIDを付与しています。
セットアップ
まず初めにセットアップ用のコードを書きます。 今回はGoなのでこちらを参考にします。
今回はローカルでJaeger、開発環境でX-Rayとバックエンドが異なるので、少し工夫が必要です。 一部省略している部分はありますが、下記のように実装しています。
Jaegerコンテナの準備
jaegertracing/all-in-oneのイメージを使うと、すぐにJaegerを使用することができます。
コレクターとトレースログを見るためのUIが含まれています。
ポート
- 16686: トレースログ確認のためのUI
- 4317 : gRPC
- 4318 : HTTP
docker compose up -d で起動すると、Jaegerのコレクターとトレースログを見るためのUIが立ち上がります。
計装
トレースの構成要素について
計装するにあたり、こちらを読んでおくとトレースIDやスパンIDなどの理解が深まります。ぜひ読んでみてください。
トレーサーの定義
トレーサーをグローバルな変数として定義します。
当プロジェクトでは上記のようにパッケージごとにトレーサーを定義することにしました。
こちらでもベストプラクティスとして推奨されているようです。
スパンの生成
定義したトレーサーを使用してスパンの生成を行います。
サービス間でトレースデータを共有する
異なるサービスを同様のトレースデータとして扱うためには、トレースIDなどのトレースデータをサービス間で受け渡す必要があります。 そのあたりの実装を自前で行うのは大変です。なので、ライブラリの力を借ります。 otelhttpやotelgrpcを使用すると、ミドルウェアとして組み込むだけで実現可能です。 当プロジェクトではコンテナ間の通信に、gRPCを使用しているため、otelgrpcを使用しています。
以下のように組み込むだけで、自動計装が行えるかつ、トレース情報の受け渡しが可能です。
ログ出力
Jaeger
Jaegerのトレースログ上にログ出力するために必要な作業を行います。 下記のようなライブラリを用いて実装することも可能ですが、今回は自前で実装しました。
自前で実装するにあたり参考にしたのは、Jaeger公式がサンプルとして載せているコードです。 こちらではspan.AddEventというメソッドを使用して、スパンに対して追加の情報を付与しています。
上記を参考に実装しログに出力している内容をスパンのイベントとして出力することに成功しました。 一部省略している部分はありますが、下記のように実装しています。
AWS X-Ray
前述したように、X-Ray画面上でトレースIDでCloudWatchのログを抽出しています。 なので。ログ出力する内容にトレースIDを付与する必要があります。 contextからトレースIDの取得が可能なので、このような感じでトレースIDを取得して、ログ出力する内容に追加します。
aws-otel-collectorの設定
AWS環境でトレースログを収集するためのコレクターとしてaws-otel-collectorを使用します。
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の公式ドキュメント
- Jaeger公式ドキュメント
- open-telemetry-goのわかりやすい解説
- インフラ系参考になる記事
- X-Ray との切り替えに関して役立ちそうな記事
- OpenTelemetryの無難な設定
◆ 他のBlogはこちらから⇒ https://tech.makeshop.co.jp/ ◆
ご応募お待ちしています！
【エンジニアブログ】OpenTelemetryについて何も知らなかった人が分散トレーシング環境を構築してみた(Jaeger, X-Ray)
/assets/images/32062/original/9178d6ef-9569-4fc7-8f84-ecd75cfcc597?1596514385)
/assets/images/32062/original/9178d6ef-9569-4fc7-8f84-ecd75cfcc597?1596514385){kind=avatar}
