ジョインしたチームのマイクロサービスたちを再計装した話 / Getting started tracing instrument micro service with OpenTelemetry

- 2023/10/19 OpenTelemetry Meetup -
ジョインしたチームのマイクロサービスたちを再計装した話
– OTel 導入事例 1 –
#oteljp
逆井(SAKASAI) @ k6s4i53rx
逆井(さかさい) 啓佑

View Slide

ー 2023/10/19 OpenTelemetry Meetup ー
アジェンダ
● 自己紹介
● 開発してるプロダクトについて
● 参画したチームのサービスにおける計装の課題
● OpenTelemetry とは
● OpenTelemetry で分散トレース再計装した (事例紹介)
● OpenTelemetry で今後やっていきたいこと
● まとめ
今回は
分散トレース
事例を話します

View Slide

● 自己紹介
● まとめ
アジェンダ

View Slide

intro_po.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
belongs: "株式会社NTTデータ"
kind: "バックエンドエンジニアと SRE"
# Go で決済サービス開発
# Kubernetes(GKE) のお守り係
event: # 幾つか Otel で登壇
# 分散トレーシングとOpenTelemetryのススメ
# OpenTelemetryとOSSを使ったObservability基盤の構築
# OpenTelemetryを用いたObservability基盤の実装 \
　　　 with AWS Distro for OpenTelemetry
お前だれ...？
逆井啓佑
さかさい
逆井(SAKASAI) @ k6s4i53rx

View Slide

● 自己紹介
● まとめ
アジェンダ

View Slide

開発してるプロダクトについて
決済事業者
Payment Service Provider (PSP) としての機能を有し、
加盟店（ECサイト）における決済のデジタル化を促進して、新規価値 / 新しい購買体験創出に寄与する。
決済サービス
消費者加盟店
(ECサイト等)
決済中継業務
精算業務
売上管理業務
不正利用検知

View Slide

決済事業者
GWサービス
決済事業者
GWサービス
決済事業者
GWサービス
決済事業者
GWサービス
FE
サービス
決済コア
サービス群
(有象無象)
(有象無象)
決済事業者
等
Google Kubernetes Engine
■ スタック（一部抜粋）
● Google Cloud / GKE
● MSA
● 他にも...
○ Service Mesh ( Istio )
○ Prometheus / VM / Grafana
○ ( 今回の趣旨と離れるので別場で... )
■ スクラム開発 (SAFe)
● スクラム15 チーム程度
(100 人弱くらいで結構大規模？)
※ 決済中継機能にフォーカスしたイメージ図

View Slide

決済事業者
GWサービス
決済事業者
GWサービス
決済事業者
GWサービス
決済事業者
GWサービス
FE
サービス
決済コア
サービス群
(有象無象)
(有象無象)
決済事業者
等
● MSA
● 他にも...

View Slide

決済事業者
GWサービス
決済事業者
GWサービス
決済事業者
GWサービス
決済事業者
GWサービス
FE
サービス
決済コア
サービス群
(有象無象)
(有象無象)
● MSA
● 他にも...
決済事業者
等
決済事業者
GW 開発チーム
にアサイン

View Slide

● 自己紹介
● まとめ
アジェンダ

View Slide

ジョインしたチームの決済事業者 = “コンビニ事業者”
● スマホで ”コンビニ払い” 指定。発行された払込票を使ってコンビニで支払う決済方式
● サービス構成はもう少し細かく書くと以下のような感じ
参画したチームのサービスにおける計装の課題
← 拡大図
コンビニ
A 社 GW
コンビニ
B 社 GW
コンビニ
C 社 GW
コンビニ共通
サービス
決済コア
サービス群
(有象無象)
コンビニ A
コンビニ B
コンビニ C
※ 一部イメージや省略箇所あり

View Slide

● サービスインに向けた E2E 負荷試験 / ボトルネックの解析が行われていた
● マイクロサービスアーキテクチャで複雑なため分散トレーシングを使いたい

View Slide

● サービスインに向けた E2E 負荷試験 / ボトルネックの解析が行われていた
● マイクロサービスアーキテクチャで複雑なため分散トレーシングを使いたい
● しかし、サービス一気通貫でトレースができなかった
○ スクラムチーム間でのオブザーバビリティ格差...
● 決済コアサービスは計装されていたが、自チームのサービスでトレースが途切れていた
○ 決済コアサービスは共通的なコンポーネントで、よく性能解析がされていた

View Slide

よく調べると、
過去の仙人の
計装の形跡があった。
Kafka からの
Msg Consume 部分のみ
コンビニ共通
サービス
決済コア
サービス群
(有象無象)
コンビニ
B 社 GW
コンビニ
C 社 GW
コンビニ
A 社 GW
計装済で
トレースが
伝搬されていた
後段の
サービスたちは
計装の形跡は
無かった。
内部スパン
は無かった。
HTTP Client で
伝播はない(後述)。
👍 🤔 😧 😌

View Slide

コンビニ共通
サービス
決済コア
サービス群
(有象無象)
コンビニ
B 社 GW
コンビニ
C 社 GW
コンビニ
A 社 GW
トレース (イメージ図)
解像度
が高い
処理 A
処理 B
…
-
処理 C
…・・

View Slide

コンビニ共通
サービス
決済コア
サービス群
(有象無象)
コンビニ
B 社 GW
コンビニ
C 社 GW
コンビニ
A 社 GW
処理 A
処理 B
…
-
処理 C
…・・
解像度
が高い
解像度
が低い
目 grep の方が良い

View Slide

コンビニ共通
サービス
決済コア
サービス群
(有象無象)
コンビニ
B 社 GW
コンビニ
C 社 GW
コンビニ
A 社 GW
処理 A
処理 B
…
-
処理 C
…・・
コンビニ決済処理
解像度
が高い
解像度
が低い
目 grep の方が良い
ちゃんと再計装しよう。

View Slide

アジェンダ
● 自己紹介
● まとめ

View Slide

OpenTelemetry とは
● テレメトリー収集・送信の標準仕様を定めている
○ ログ・トレース・メトリクス・ダンプ・プロファイル (Primary Signals) 等
● あらゆる言語の計装ライブラリを提供
○ Go, Java, Python, C++, JavaScript,...
https://opentelemetry.io/docs/instrumentation/
○ 言語によっては、auto instrumentation (自動計装) あり
● OpenTelemetry Collector の仕様策定や開発も行なっている (後述)
○ 標準 Distro. と Contribution Distro. がある
○ Contribution Distro には各社ベンダーのコンポーネントが含まれる

View Slide

Service
Jaeger
Tempo
モニタリング
SaaS
計装
Service
Jaeger
Tempo
計装
※ Jaeger は既に自前の計装ライブラリは非推奨とし、Otel 推奨しています。
モニタリング
SaaS
アプリケーションを Otel を用いて標準計装するメリットとして、
● モニタリングバックエンドの切り替えが容易
○ Otel (OTLP) に対応していることが前提となるが、メジャーどころは対応してきている
● プロプライエタリの緩和
ただし、モニタリングベンダーの提供しているエージェントに比べて、機能劣後やメンテナンス性を比較・評価す
る必要はあるかと思います。

View Slide

OpenTelemetry Collector とは
● テレメトリーの受信・送信・処理を行うエージェント
○ プラガブルな Receiver / Processor / Exporter / Connector で構成されている
○ どのような種類のコンポーネントがあるかは Registry を参照
：https://opentelemetry.io/ecosystem/registry/?s=&component=all&language=collector
著：@IT 「OpenTelemetry」とは――「Observability」（可観測性：オブザーバビリティ）とテレメトリーの基礎知識より

View Slide

As this distribution contains many components, it is a good starting point to try various conﬁgurations. However, when
running in production, it is recommended to limit the collector to contain only the components necessary for an
environment https://github.com/open-telemetry/opentelemetry-collector-releases/tree/main/distributions/otelcol-contrib#recommendation
● 　　Contribution Distro. には全てのコンポーネントが含まれているため商用利用は非推奨
● 標準 Distro. に含まれないコンポーネントを使いたい場合は、
○ 使うコンポーネントを含む Custom OpenTelemetry Collector をビルドする
■ ビルドツールは公式で提供されている：OpenTelemetry Collector Builder (ocb)
○ モニタリングベンダーより提供されている Distro. を使う
■ ADOT Collector (AWS), splunk-otel-collector (Splunc) などなど...
先述の通り、OpenTelemetry Collector には 2 つの Dstribution が存在しています。
　・標準 Distro. : https://github.com/open-telemetry/opentelemetry-collector-releases/tree/main/distributions/otelcol
　・Contribution Distro. : https://github.com/open-telemetry/opentelemetry-collector-releases/tree/main/distributions/otelcol-contrib

View Slide

OpenTelemetry Collector とは
OpenTelemetry Collector のセットアップの一例として、
K8s に deployment としてデプロイする際のマニフェスト
● 以下のような構成
○ アプリケーションのトレース計装は Otel
○ トレースバックエンドは AWS X-Ray
● Otel Collector で、OTLP で受信、X-Ray 形式で送信
○ Receiver: otlp
○ Exporter: awsxray
ADOT Collector
のコンテナイメージ
を使用した例
7
33.3
※ ADOT Collector はデフォルトで X-Ray Exporter が含まれる

View Slide

マルチクラウド構成を見据え、なるべくプロプライエタリ避けたかった
エコシステムが充実している点 ( Otel Collector や自動計装など )
ひとたび Otel で計装をすれば容易にバックエンドを切り替えられる点
● 後述するが、ローカルは Jaeger / 実環境は Cloud Trace を利用
OpenTelemetry の謳っている “OpenTelemetry’s Collection” Vision
● テレメトリーを紐付けて一元的に管理することはオブザーバビリティにおいて重要
( 過去の仙人が OpenTelemetry を使って計装していた形跡があり乗っかった )
■ OpenTelemetry を使うに至った背景について

View Slide

● 自己紹介
● まとめ
アジェンダ

View Slide

簡単に OpenTelemetry Go でアプリをトレース計装する方法についておさらい
❶ トレーシングのセットアップ
● エクスポーター、リソース、サンプラー、プロパゲーターの設定などなど
※ もう少し詳しくはこちらを参照ください → "分散トレーシングとOpenTelemetryのススメ" @ SpeakerDeck
❷ リクエストからトレース情報を Extract
● otelhttp, otelgrpc, otelgin, otelecho など
❸ Span の生成
❹ リクエストにトレース情報を Inject
OpenTelemetry で分散トレース再計装した (事例紹介)
とあるサービス例
Server Client
処理処理処理
トレーシングのセットアップ
S ：Span
S S S
❶
❸
❷ ❹
Otel のライブラリを使った
手続的な計装手順

View Slide

コンビニ共通サービスの再計装
コンビニ共通
サービス
コンビニ
B 社 GW
コンビニ
C 社 GW
コンビニ
A 社 GW
HTTP
Client
処理処理処理
S
❶
❸
❷ ❹
S S
S
S
Consume
✔
✔
✖
❶ トレーシングのセットアップ済 by 過去仙人
❷ Kafka からトレース情報を Extract 済 by 過去仙人
○ otelsalama を使用
○ 上流で Kafka の Msg にトレース情報を Inject
❸ Span を各処理で生成
❹ 各 GW のリクエストに
　トレース情報を Inject する設定
✖

View Slide

Client
処理処理処理
S
❶
❸
❷ ❹
S S
S
S
Server
✖
✖
✖
❶ トレーシングのセットアップ未
❷ リクエストからトレース情報の Extract 未
○ Web FW として echo を使っていたため
○ otelecho を使用
❸ Span を各処理で生成
❹ 決済事業者への IF なので未実施
コンビニ GW サービスの再計装
コンビニ
B 社 GW
コンビニ
C 社 GW
コンビニ
A 社 GW
コンビニ共通
サービス
HTTP

View Slide

これらの再計装により以下のようなトレースを取得できるようになった。
新たに計装した
サービスの Span
コンビニ決済処理 …
↑ 元はこれ
トレースとログ
を紐付けたり、
GCP Resource Detector
も使っています。

View Slide

計装に際して工夫した点 ①：スパン生成のラフガイドラインを作った
● 今後も同じような GW サービス / 業務が量産されていく
● チーム内のサービスでは Span Kind に基づき以下の箇所で Span を生成することにした
● （最初はログと一緒に Span 生成してたけどとても煩雑だった。
　次に全関数で Span 生成するようにしたけどこれも多くて、下の感じに落ち着きました。。。）
Span の種別：Client / Server / Internal / Producer / Consumer が定義
https://opentelemetry.io/docs/concepts/signals/traces/#span-kind
サーバー
(echo / gin)
ハンドラー
ユースケース
(業務ロジック)
クライアント
外部サービス
との接続
Datastore
CloudSQL … 等
Kind
Server
Kind
Internal
Kind
Internal
Kind
Clinet
Kind
Clinet
※ 上は最低限。ここ以外にもよしなに Span 生成

View Slide

● ガイドラインも作って、Span をチーム内の全サービスで、
いい感じに切っていきましょう！というコンセンサスが取れた
● 開発はローカル環境で docker compose を立ち上げて行っているが、
Cloud Trace へのトレースの送信は、権限の問題で GKE 環境でのみ可能
○ Span を確認するためだけにわざわざイメージをビルドし、K8s にデプロイし...めんどい
● ローカル環境ではトレースバックエンドで Jaeger を立て、そこでトレーシングの検証を
計装に際して工夫した点 ②：環境ごとにトレースバックエンドを切り替えられるように

View Slide

計装に際して工夫した点 ②：環境ごとにトレースバックエンドを切り替えられるように
● 環境変数で "OpenTelemetry のセットアップ時のエクスポーターを変更" する実装
○ GKE　　："CLOUD_TRACE_PROJECT"
○ ローカル："JAEGER_ENDPOINT" ※ "http://localhost:4317" とか
● 分散トレーシングの検証もローカル環境で手軽に実施できるように
Cloud Trace
トレース
Otel を使った標準的な計装で、
簡単にトレースバックエンド
を切り替えることができた。
(otel collector を導入すると、それすらもアプリ側は考える必要がなくなりますので早く入れたい)
ローカル
実環境

View Slide

絶賛解析中。
改善できたら
別場で共有したい。
▶▷▶ 結果として。
● トレースを導入し性能解析を行い、
高負荷時に datastore のアクセスが低頻度で遅延していることがわかった
▶▷▶ 意識的な変化も。
● ログ一覧の目 grep の世界 -> Waterfall Graph で直感的 / 多角的な解析
● (導入して間もないが)、性能に問題がありそうなときに、
「トレースはどう？」、「トレース ID はこちらです」といった新たな切り口での会話が生まれ始めている
● "計測をし、自分達のサービスの定常状態をきちんと理解する" を経験

View Slide

● 自己紹介
● まとめ
アジェンダ

View Slide

OpenTelemetry で今後やっていきたいこと
たくさんありますが、ここでは 2 つ挙げます。
(既に実運用実践してる方いると思うので、ぜひお話しさせてください！！)
1. OpenTelemetry Collector の導入
2. 分散トレースは手に入れた。次は継続的プロファイルを武器に...

View Slide

1. OpenTelemetry Collector の導入
　エコシステムとして便利なコンポーネントたくさん。且つ簡単に使用可能。
参考：https://opentelemetry.io/ecosystem/registry/
(OpenTelemetry でせっかく計装してるならこれを使わない手はない...)
Cloud Trace
Collector
トレース
● Tail Sampling Processor によるトレースサンプリング
○ 全サンプルだと多い
○ ランダムサンプルだと、要らないのあったり、欲しいの無かったり
○ 今後急増が見込まれるデータ量のコスパを最適化したい
● Span Metrics Connector を使ったメトリクス計測
○ 収集したトレースからアプリケーションメトリクス（レイテンシーやエラー率など）を生成し、
メトリクスバックエンド（Prometheus など）に送信
○ SLO /SLI などを定めるにあたり定常状態を継続的に観測する

View Slide

2. 継続的プロファイルを武器に
● プロファイルは「プログラム実行時に取得できるリソースのデータ (CPU 時間 / メモリ割当 / ロック/ etc) 」
● 󰢃 三本柱ビリティ( = ログ・トレース・メトリクスがあれば O11y OK です 👍 という考え方 )
● 近い将来、プロファイルも OpenTelemetry で計測できるかもしれない
○ プロファイルのデータモデルも OpenTelemetry で検討が進んでいる
○ 2023/09、otep ( OpenTelemetry Enhancement Proposal ) にデータモデルの PR #OTEP-237
● 今回分散トレースは使えるようになってきた
● 分散トレースでプロダクト全体の性能を大きく見て、
サービスのボトルネックを特定したら、サービス内部をプロファイルで細かく見ることが重要
○ Span をあまり切っていないのもプロファイルをやる前提で考えているため

View Slide

● 自己紹介
● まとめ
アジェンダ

View Slide

● 本セッションでは OpenTelemetry "最初の一歩" を踏み出し始めた事例を紹介
● OpenTelemetry を使って分散トレーシング計装
○ チーム全員がトレースを武器に、性能改善できるよう文化（プラクティスとして）
○ トレースだけでなくテレメトリー。そのためにもテレメトリーを標準的に扱える OpenTelemetry は興味深い
● プロダクトの問題解決のために
やっていきたいことも多くあるので、OpenTelemetry 継続的にやっていきます
まとめ
現場で OpenTelemetry もっと使い回している方々沢山いると思うので、
ぜひ、事例紹介・共有をお願いいたします！！

View Slide

記載されている会社名、商品名、
またはサービス名は、各社の商標登録または商標です。

View Slide

ジョインしたチームのマイクロサービスたちを再計装した話 / Getting started tracing instrument micro service with OpenTelemetry

ジョインしたチームのマイクロサービスたちを再計装した話 / Getting started tracing instrument micro service with OpenTelemetry

逆井（さかさい）

More Decks by 逆井（さかさい）

Other Decks in Technology

Featured

Transcript