OpenTelemetryでRailsのパフォーマンス分析を始めてみよう（KoR2024）

by Y.Matsuda

Slide 1

Slide 1 text

モノリスでも使える！ OpenTelemetryでRails アプリのパフォーマンス分析を始めてみよう 2024.10.25 Fri. Kaigi on Rails@有明セントラルタワーホール & カンファレンス（東京） @ymtdzzz

Slide 2

Slide 2 text

Yosuke MATSUDA (@ymtdzzz) 株式会社SmartHR プロダクトエンジニア 2

Slide 3

Slide 3 text

● 想定参加者 ○ アプリケーションのパフォーマンス改善やエラー調査を行なう人 ■ それをもっと楽にしたいと考えている人 ○ トレースに興味はあるが、使ったことはない人本日の内容 3

Slide 4

Slide 4 text

● ゴール：トレースを知ってもらい、使ってみたくなる！ ○ パフォーマンス調査の難しさ ○ ログ＋メトリクス＋トレース 👈🆕 ■ 何が嬉しいのか ■ OpenTelemetryの位置付け ■ 他ツールとの違い ○ Railsアプリへの導入方法と実践（デモ） ○ コスト、構成の選び方について本日の内容 4

Slide 5

Slide 5 text

パフォーマンス調査の難しさ 5

Slide 6

Slide 6 text

例えばエンドユーザー最近○○の処理が遅いんだけど･･･ 6

Slide 7

Slide 7 text

例えば SRE 最近このパス遅いんですよね〜（SLOを見せながら）見てもらえます？ 7

Slide 8

Slide 8 text

● エンドツーエンドの粒度 ○ ユーザーから見た遅さ、使いにくさ ■ パブリックLBのレイテンシー ■ 500エラー、不具合の調査など調査はエンドツーエンドの粒度から始まる（ことが多い） 8 私たちはそれを実装レベルの粒度までブレークダウンして調査する必要がある

Slide 9

Slide 9 text

調査開始時点ではなにもわからない（当然） 9 スロークエリか？ N+1かも？いやいやあのマネージドサービスが遅いんだよ最近誰か改修してたな

Slide 10

Slide 10 text

ボトルネックの調査（可能性の絞り込み） 10 調査完了調査開始ボトルネック特定テレメトリ中心の仮説検証コード中心の仮説検証解決方法の検討と優先度付けコード読むかぁ M回 N回

Slide 11

Slide 11 text

ボトルネックの調査（可能性の絞り込み） 11 調査完了調査開始ボトルネック特定テレメトリ中心の仮説検証コード中心の仮説検証解決方法の検討と優先度付けコード読むかぁ M回 N回テレメトリ（ログやメトリクス）から可能性を絞る ※事実からの分析＝コア分析ループ

Slide 12

Slide 12 text

ボトルネックの調査（可能性の絞り込み） 12 調査完了調査開始ボトルネック特定テレメトリ中心の仮説検証コード中心の仮説検証解決方法の検討と優先度付けコード読むかぁ M回 N回絞りきれなかった可能性に対して仮説検証を繰り返す（コスト大・属人的）ローカルで再現計測コードを仕込んでデプロイコードの理解度に依存

Slide 13

Slide 13 text

コードを見る前にどれだけ可能性を潰せるかが勝負 13 調査完了調査開始ボトルネック特定テレメトリ中心の仮説検証コード中心の仮説検証解決方法の検討と優先度付けコード読むかぁ M回 N回

Slide 14

Slide 14 text

テレメトリ分析の難しさ 14

Slide 15

Slide 15 text

ログの難しさ 15

Slide 16

Slide 16 text

● 離散的なイベント情報 →関連付けが苦手 ○ アクセスログとアプリログの紐付け ○ nginxのログとRailsログの紐付け ● timestampやip, user_id等で手動紐付け（職人芸）ログの難しさ 16

Slide 17

Slide 17 text

● 集計データの根拠としてログを手動で調べる手間 ● メトリクス粒度の悩み ○ パス別、ブラウザ別にLatency出したいんだけど ○ ログベースのカスタムメトリクス作るか・・・ ○ →ほんとにこれメトリクスで取るべき情報なのかな？メトリクスの難しさ 17

Slide 18

Slide 18 text

● 処理の過程についての情報が限られる ○ ログ仕込むのはつらい（イベント情報なので） ● ログをはじめ、テレメトリ相互の紐付けに手作業が必要テレメトリ分析の難しさ 18 （ログ・メトリクスによる）ログとメトリクスで実装の粒度までブレークダウンするのは結構難しい

Slide 19

Slide 19 text

ログ＋メトリクス＋トレース 19

Slide 20

Slide 20 text

トレースから得られる情報（例 1） 20

Slide 21

Slide 21 text

トレースから得られる情報（例 2） 21

Slide 22

Slide 22 text

分散トレーシング（トレース）とは？ 22

Slide 23

Slide 23 text

1つのリクエストが、アプリケーションを構成するさまざまなサービスによって処理される過程を追跡する方法 (*) 分散トレーシングとは (*)オブザーバビリティ・エンジニアリング　（ Charity Majors、Liz Fong-Jones、George Miranda　著、大谷和紀、山口能迪　訳（2023）．　オライリー・ジャパン）, 64p 下線は引用者による 23

Slide 24

Slide 24 text

基本的なデータ構造 24

Slide 25

Slide 25 text

基本的なデータ構造 25 追跡の単位（リクエストなど）

Slide 26

Slide 26 text

基本的なデータ構造 26 プロセスの単位

Slide 27

Slide 27 text

基本的なデータ構造 ● 親子関係をデータで持つことで到達順序は自由 27

Slide 28

Slide 28 text

基本的なデータ構造 ● 親を辿ってプロットする 28

Slide 29

Slide 29 text

アプリケーション側の計装 ● 手動計装 ○ SpanのStart, Endをコードで実装 ● 自動計装 ○ gemで自動出力 ■ 実際はmonkey patch、又はActiveSupport::Notiﬁcation を利用してStart, Endを差し込んでいる ○ 今回のデモはこちら 29 計装：アプリケーションからテレメトリを出力及び収集できるようにすること

Slide 30

Slide 30 text

収集フロー 30 HTTP Header(*) TraceID: ~~ SpanID: ~~ (*) HTTP以外も伝播可能（ gRPC, AMQPのような非同期メッセージングまで）

Slide 31

Slide 31 text

他ツールとの違い 31

Slide 32

Slide 32 text

● Profiler ○ MiniProfiler/rack-mini-profiler ○ tmm1/stackprof ● N+1 Detection ○ flyerhzm/bullet パフォーマンス関連のツールは色々ある全て強力で有用なツール！ 32

Slide 33

Slide 33 text

分散トレーシングの強みは？ 33 それもあるが･･･ ● ログ、メトリクスの補強？ Profilerでも取れるわよ

Slide 34

Slide 34 text

34 テレメトリの関連付け（correlation）

Slide 35

Slide 35 text

● 離散的なイベント情報 →関連付けが苦手 ○ アクセスログとアプリログの紐付け ○ nginxのログとRailsログの紐付け ● timestampやip, user_id等で手動紐付け（職人芸）再掲）ログの限界 35

Slide 36

Slide 36 text

ログとトレースの関連付け（ before） 36

Slide 37

Slide 37 text

ログとトレースの関連付け（ after） 37

Slide 38

Slide 38 text

テレメトリのポテンシャルを引き出す ● ログとの紐付け ○ ログとトレースに相互 ● メトリクスとの紐付け（ Exemplar） ○ 集計データの根拠として詳細なログやトレースを閲覧可能シームレスに粒度を変えながらの調査が可能になる 38

Slide 39

Slide 39 text

ポテンシャル最大化した先：オブザーバビリティ最早ボトルネックの特定にコードは不要 39 数秒〜数分調査完了調査開始ボトルネック特定テレメトリ中心の仮説検証解決方法の検討と優先度付け N回

Slide 40

Slide 40 text

とはいえ、今日はトレースとパフォーマンスの話に絞ります 🙏 40

Slide 41

Slide 41 text

● 汎用的 ○ 言語、FWによらない ○ 監視ツールや他テレメトリとの統合 ● 直感的 ○ 関連付け、ビジュアライズによりトレースが調査の入口になる 41 デバッグ範囲を絞り込んだ上で必要に応じて詳細なツールへ（ Proﬁlerなど）話を戻して、他ツールとの違いについて

Slide 42

Slide 42 text

分散トレーシングは、正しく実装するのは非常に難しく時間がかかる (略) 分散システムにおけるサービス間のパフォーマンスを把握したり (略) 大掛かりなサーバーレスインフラがある場合も、分散トレーシングを考えてもよいでしょうでも、敷居高いのでは？出典）入門　監視　（Mike Julian　著、松浦隼人　訳（2019）．　オライリー・ジャパン）, 106p 下線、太字は引用者による 42

Slide 43

Slide 43 text

トレーシングのツールは継続的に改善されてきています。数年後にはこの警告も意味がなくなっているかもしれません。注釈より 2024年現在はどうなのよ？ 43 出典）入門　監視　（Mike Julian　著、松浦隼人　訳（2019）．　オライリー・ジャパン）, 106p 下線、太字は引用者による

Slide 44

Slide 44 text

分散トレーシングと OpenTelemetry 44

Slide 45

Slide 45 text

分散トレーシングの導入ハードルの高さ（数年前） Dapper （Google） 2010 2012 2017 2019 OSS SaaS ※現在はServiceNow ※o11y関連のプロダクト開始年に合わせてマッピング Splunk APM （ソース） Jaeger ソース Grafana Tempo 45

Slide 46

Slide 46 text

● 技術選定コストが高い ○ ライブラリ（実装コストに直結） ■ 例えばFaradayの計装: Jaegerのclient使うよりもOpenCensus のFaradayMiddleware使う方が楽　とか ○ バックエンド・データストア ■ SaaSの選択肢が少ないので自前で構築･･･ ■ 対応フォーマットは？ ■ コストは？分散トレーシングの導入ハードルの高さ（数年前） 46

Slide 47

Slide 47 text

数年前の分散トレーシング（ OTel登場前）導入・運用コスト＞メリット ※個人の見解です ※規模によります 47

Slide 48

Slide 48 text

OpenTelemetryの登場（2019.5） Dapper （Google） 2010 2012 2017 2019 OSS SaaS ※現在はServiceNow ※o11y関連のプロダクト開始年に合わせてマッピング Splunk APM （ソース） Jaeger ソース Grafana Tempo 48

Slide 49

Slide 49 text

● OpenTracingとOpenCensusを統合 ● オブザーバビリティの実現に必要なほぼ(*1) 全てを提供 ○ トレース、ログ、メトリクス(*2) ○ API仕様（Speciﬁcation, OTLP） ○ 言語別のSDK、instrumentation library ○ デモやドキュメント OpenTelemetryの登場（2019.5） (*1)ほぼ･･･閲覧用のUIやストレージなど、バックエンドは今のところ提供していません (*2)ログとメトリクスは2024.10現在betaな機能が多いです 49

Slide 50

Slide 50 text

● OpenTelemetryという標準仕様の登場 ○ ライブラリやプラグインがOpenTelemetryに集約 ○ →技術選定、キャッチアップコストの軽減 ● 監視・o11y系SaaSのOpenTelemetry対応 ○ 今使ってるSaaSの1機能として使える時代になった ○ →移行性の向上（恐らく後述する市場競争要因にも）導入ハードルが下がってきた 50

Slide 51

Slide 51 text

最近の分散トレーシング（ OTel登場後）導入・運用コスト＜メリット ※個人の見解です 51

Slide 52

Slide 52 text

● 様々なマネージドサービスへの依存 ○ 通信の複雑さ ● RailsのようなThe One Person Framework、豊富な Gem ○ 処理のカプセル化 ○ 巨大なコードベースモノリスでもそう言える？「一目見て」何が起きているかわかるのはとても強力 52

Slide 53

Slide 53 text

OpenTelemetryのはじめかた 53

Slide 54

Slide 54 text

● Railsアプリケーションを計装する ○ トレースを出せるようにする ● バックエンドを用意する ○ データを貯めて、閲覧できる場所を用意する ○ SaaS、またはOSSを組み合わせて自前で構築やること 54

Slide 55

Slide 55 text

Railsアプリケーションを計装する ● Gemを入れる ● initializerを書く（最小限のコード例） ● 環境変数を設定してサーバーを起動する $ bundle add opentelemetry-sdk opentelemetry-exporter-otlp opentelemetry-instrumentation-all # config/initializers/opentelemetry.rb require 'opentelemetry/sdk' require 'opentelemetry/instrumentation/all' OpenTelemetry::SDK.configure do |c| c.service_name = 'your-service-name' c.use_all() end 以上！バックエンドについては後ほど 55

Slide 56

Slide 56 text

パフォーマンス調査実践（デモ） 56

Slide 57

Slide 57 text

● ECサイト（Rails製） ● 商品購入にはログインが必要 ○ Email / SNS（ID連携）デモアプリ - Kaigi on Rails STORE https://github.com/ymtdzzz/kaigi-on-rails-2024-otel 57

Slide 58

Slide 58 text

● 数量限定セール施策を開始 ● ログイン処理が遅くユーザーからのクレーム増(*) ● あなたはログイン処理のパフォーマンス改善を任された ○ 認証領域についてはあまり詳しく無い ○ データ量も増えており、スロークエリに悩まされているデモアプリ (*)元々ログインは遅かったが、瞬間風速の高い施策はそこまで多く無く、問題にはなっていなかった　なお、認証を長期間維持する仕組み（リフレッシュトークンなど）、ゲスト購入については今回は考えない 58

Slide 59

Slide 59 text

トレースを体験してみよう！ 59

Slide 60

Slide 60 text

デモタイム 60

Slide 61

Slide 61 text

状況の確認： ID連携による認証の遅さ ※デモ補足用 ● http://localhost:3030 にアクセス 61

Slide 62

Slide 62 text

状況の確認： ID連携による認証の遅さ ※デモ補足用 ● 「（先着10名限定）1000型超ウルトラワイドモニター」を選んで、「OpenIDConnect連携」でログイン 62

Slide 63

Slide 63 text

状況の確認： ID連携による認証の遅さ ※デモ補足用 ● 5秒程度経過後、商品詳細画面に遷移できることを確認（遅い！） 63

Slide 64

Slide 64 text

調査：ログの確認（ Grafana） ※デモ補足用 ● http://localhost:3001 にアクセス 64

Slide 65

Slide 65 text

調査：ログの確認（ Grafana） ※デモ補足用 ● Explorerからログの検索をする ● アクセスログなどは確認できるが、ボトルネックの特定は困難 65

Slide 66

Slide 66 text

コードを読みに行く前に、トレース！ 66

Slide 67

Slide 67 text

調査：トレースの確認（ Grafana） ※デモ補足用 ● ExplorerからTempoでトレースを検索する ● Duration > 1sで遅いトレースを検索 67

Slide 68

Slide 68 text

調査：トレースの確認（ Grafana） ※デモ補足用 ● トレース詳細から、jwks.jsonのGETリクエストがボトルネックだということがわかる 68

Slide 69

Slide 69 text

ここで初めて実装を調べる ※デモ補足用 ● 「ID連携 jwks」とかでググる ※ここは雰囲気でOK 69

Slide 70

Slide 70 text

ここで初めて実装を調べる ※デモ補足用 ● jwks.jsonへのGETについてわかったこと ○ OIDCによるID連携時に必要な処理 ○ 処理自体はomniauth_openid_connect gemで実装 ○ 毎回返ってくるデータは同じ ■ KeyIDがローテしなければ全く同じデータになる ● 解決策の検討 ○ 起動時にキャッシュする ○ KeyIDに該当するJWKが見つからなければ取得し直してキャッシュを更新する 70

Slide 71

Slide 71 text

キャッシュ後の動作確認 ※デモ補足用 ● conﬁg/initializers/devise.rb ○ キャッシュを有効化（今回は雑にモンキーパッチ） ○ docker compose restart web 71

Slide 72

Slide 72 text

キャッシュ後の動作確認 ※デモ補足用 ● 早くなった！ ○ 5s → 25ms（200倍）※体感できるように大げさに遅延させてます 72

Slide 73

Slide 73 text

補足）トレースとログの関連付け ※デモ補足用 ● スパン詳細から「 Logs for this span」 ● トレースに紐付くログを双方向で引いてこれる ● 役立つシーン ○ エラーからユーザー影響を調べる ○ ステータスコードから根本原因を調べる 73

Slide 74

Slide 74 text

● 認証に詳しくなかったとしても ○ コードのどこを調べるべきかわかる ○ ボトルネックを確認した上で対応できる ● トレースが無かったら・・・？ ○ もっと時間かかったかもデモのまとめ 74

Slide 75

Slide 75 text

バックエンドの料金 75

Slide 76

Slide 76 text

● SaaS（監視・o11y専門） ● SaaS（パブリッククラウド） ● OSS（自前構築）バックエンドの選択肢 ※一部抜粋 76 Amazon X-Ray Cloud Trace Grafana Tempo SaaSが一番手っ取り早い →でも高い･･･？

Slide 77

Slide 77 text

● テレメトリの送り方の標準ができた（ OTel） ● 監視・o11y系SaaSの競争激化 ○ データはどれも同じような形 ○ データの見せ方、料金で勝負！（持論）OpenTelemetryによる市場競争 77

Slide 78

Slide 78 text

● ホスト数 ● トレース、スパン ○ 件数（Spans） ○ データ量（Bytes） SaaSでの主な課金指標 78

Slide 79

Slide 79 text

● 無料枠 ○ Freeプラン ■ 例：100GBまで無料 ○ ホスト数に応じた無料枠 ■ 例：150GB/ホスト, 100万Spans/ホスト ● 変わり種 ○ ビルトインのサンプリングルールを使ったトレース（Span）の件数への課金が無料 SaaSの柔軟な料金体系 79 見積もりした上で、まずは SaaSでトレースの検証を始めてみましょう！

Slide 80

Slide 80 text

構成時のポイント 80

Slide 81

Slide 81 text

● バックエンド ○ SaaS（監視・o11y専門） ■ NewRelic, Splunk, Datadog … ○ SaaS（パブリッククラウド） ■ X-Ray, Cloud Trace … ○ OSS（自前構築） ■ Prometheus, Grafana … ● 計装 ○ OpenTelemetry ○ SaaSベンダー独自形式構成における選択肢 81

Slide 82

Slide 82 text

● バックエンド ○ SaaS（監視・o11y専門） ■ NewRelic, Splunk, Datadog … ○ SaaS（パブリッククラウド） ■ X-Ray, Cloud Trace … ○ OSS（自前構築） ■ Prometheus, Grafana … ● 計装 ○ OpenTelemetry ○ SaaSベンダー独自形式選定時の選択肢 82 ● 既に使っている SaaSがあるならそれを使おう

Slide 83

Slide 83 text

● バックエンド ○ SaaS（監視・o11y専門） ■ NewRelic, Splunk, Datadog … ○ SaaS（パブリッククラウド） ■ X-Ray, Cloud Trace … ○ OSS（自前構築） ■ Prometheus, Grafana … ● 計装 ○ OpenTelemetry ○ SaaSベンダー独自形式選定時の選択肢 83 ● SaaSの乗り換え可能性などを考慮して決定（移行コストはそこまで大きくない）

Slide 84

Slide 84 text

鉄則：導入と運用が一番楽な構成を選ぶ 84

Slide 85

Slide 85 text

ディシジョンツリー（参考） 85

Slide 86

Slide 86 text

例1）既に使っている SaaSがある ● 一番始めやすい構成（全部 SaaS） 86

Slide 87

Slide 87 text

例2）他SaaSへの移行も考慮したい ● アジリティ高めの構成（バックエンド SaaS、計装OTel） 87

Slide 88

Slide 88 text

例3）大規模な分散システム（SaaSが高すぎた場合） ● Self-hosting（バックエンド OSS、計装OTel） 88

Slide 89

Slide 89 text

● トレース ○ ログ、メトリクスを補完する情報 ○ 関連付けにより、テレメトリ全体を強化 ■ オブザーバビリティへ ● OpenTelemetryにより導入ハードルが下がった ● トレース使っていきましょうまとめ 89