Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
OpenTelemetryでRailsのパフォーマンス分析を始めてみよう(KoR2024)
Search
Y.Matsuda
October 25, 2024
Programming
5
2.3k
OpenTelemetryでRailsのパフォーマンス分析を始めてみよう(KoR2024)
Kaigi on Rails 2024での登壇資料になります。
https://kaigionrails.org/2024/talks/ymtdzzz/
Y.Matsuda
October 25, 2024
Tweet
Share
More Decks by Y.Matsuda
See All by Y.Matsuda
Building Observability Infrastructure with OpenTelemetry and SaaS
ymtdzzz
2
350
ActiveSupport::Notifications supporting instrumentation of Rails apps with OpenTelemetry
ymtdzzz
1
280
OIDC仕様に準拠した Makuake ID連携基盤構築の裏側
ymtdzzz
3
2.3k
Other Decks in Programming
See All in Programming
.NET 9アプリをCGIとして レンタルサーバーで動かす
mayuki
0
740
N.E.X.T LEVEL
pluu
2
240
新卒研修で作ったアプリのご紹介
mkryo
0
230
WebAssembly Unleashed: Powering Server-Side Applications
chrisft25
0
2.1k
CSC305 Lecture 23
javiergs
PRO
0
110
Jakarta EE meets AI
ivargrimstad
0
580
気をつけたい!Desktop対応で陥りやすい罠とその対策
goto_tsl
0
180
Discord Bot with AI -for English learners-
xin9le
0
110
CSC509 Lecture 13
javiergs
PRO
0
150
flutterkaigi_2024.pdf
kyoheig3
0
440
PipeCDの歩き方
kuro_kurorrr
3
140
.NET Conf 2024の振り返り
tomokusaba
0
190
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Writing Fast Ruby
sferik
627
61k
BBQ
matthewcrist
85
9.3k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
150
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
410
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
4 Signs Your Business is Dying
shpigford
181
21k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
770
How to train your dragon (web standard)
notwaldorf
88
5.7k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
24k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
0
70
Designing the Hi-DPI Web
ddemaree
280
34k
Transcript
モノリスでも使える! OpenTelemetryでRails アプリのパフォーマンス分析を始めてみよう 2024.10.25 Fri. Kaigi on Rails@有明セントラルタワーホール & カンファレンス(東京)
@ymtdzzz
Yosuke MATSUDA (@ymtdzzz) 株式会社SmartHR プロダクトエンジニア 2
• 想定参加者 ◦ アプリケーションのパフォーマンス改善やエラー調 査を行なう人 ▪ それをもっと楽にしたいと考えている人 ◦ トレースに興味はあるが、使ったことはない人 本日の内容
3
• ゴール:トレースを知ってもらい、使ってみたくなる! ◦ パフォーマンス調査の難しさ ◦ ログ+メトリクス+ トレース 👈🆕 ▪ 何が嬉しいのか
▪ OpenTelemetryの位置付け ▪ 他ツールとの違い ◦ Railsアプリへの導入方法と実践(デモ) ◦ コスト、構成の選び方について 本日の内容 4
パフォーマンス調査の難しさ 5
例えば エンドユーザー 最近◦◦の処理が遅いんだ けど・・・ 6
例えば SRE 最近このパス遅いんですよ ね〜(SLOを見せながら)見 てもらえます? 7
• エンドツーエンドの粒度 ◦ ユーザーから見た 遅さ、使いにくさ ▪ パブリックLBのレイテンシー ▪ 500エラー、不具合の調査 など
調査はエンドツーエンドの粒度から始まる (ことが多い) 8 私たちはそれを実装レベルの粒度までブレークダウンして 調査する必要がある
調査開始時点ではなにもわからない(当然) 9 スロークエリか? N+1かも? いやいやあのマネージド サービスが遅いんだよ 最近誰か改修して たな
ボトルネックの調査(可能性の絞り込み) 10 調査完了 調査開始 ボトルネック特定 テレメトリ中心の 仮説検証 コード中心の 仮説検証 解決方法の検討と
優先度付け コード読むかぁ M回 N回
ボトルネックの調査(可能性の絞り込み) 11 調査完了 調査開始 ボトルネック特定 テレメトリ中心の 仮説検証 コード中心の 仮説検証 解決方法の検討と
優先度付け コード読むかぁ M回 N回 テレメトリ(ログやメトリクス)から可 能性を絞る ※事実からの分析=コア分析ループ
ボトルネックの調査(可能性の絞り込み) 12 調査完了 調査開始 ボトルネック特定 テレメトリ中心の 仮説検証 コード中心の 仮説検証 解決方法の検討と
優先度付け コード読むかぁ M回 N回 絞りきれなかった可能性に対し て仮説検証を繰り返す (コスト大・属人的) ローカルで再現 計測コードを仕込 んでデプロイ コードの理解度に依存
コードを見る前にどれだけ可能性を潰せるかが勝負 13 調査完了 調査開始 ボトルネック特定 テレメトリ中心の 仮説検証 コード中心の 仮説検証 解決方法の検討と
優先度付け コード読むかぁ M回 N回
テレメトリ分析の難しさ 14
ログの難しさ 15
• 離散的なイベント情報 →関連付けが苦手 ◦ アクセスログとアプリログの紐付け ◦ nginxのログとRailsログの紐付け • timestampやip, user_id等で手動紐付け
(職人芸) ログの難しさ 16
• 集計データの根拠 としてログを手動で調べる 手間 • メトリクス粒度 の悩み ◦ パス別、ブラウザ別にLatency出したいんだけど ◦
ログベースのカスタムメトリクス作るか・・・ ◦ →ほんとにこれメトリクスで取るべき情報なのかな? メトリクスの難しさ 17
• 処理の過程についての情報が限られる ◦ ログ仕込むのはつらい(イベント情報なので) • ログをはじめ、テレメトリ相互の紐付けに手作業が 必要 テレメトリ分析の難しさ 18 (ログ・メトリクスによる)
ログとメトリクスで実装の粒度までブレークダウン するのは結構難しい
ログ+メトリクス+ トレース 19
トレースから得られる情報(例 1) 20
トレースから得られる情報(例 2) 21
分散トレーシング(トレース)とは? 22
1つのリクエスト が、アプリケーションを構成するさまざ まなサービスによって処理される過程を追跡する方法 (*) 分散トレーシングとは (*)オブザーバビリティ・エンジニアリング ( Charity Majors、Liz Fong-Jones、George Miranda 著、大谷
和 紀、山口 能迪 訳(2023). オライリー・ジャパン), 64p 下線は引用者による 23
基本的なデータ構造 24
基本的なデータ構造 25 追跡の単位(リクエストなど)
基本的なデータ構造 26 プロセスの単位
基本的なデータ構造 • 親子関係をデータで持つことで到達順序は自由 27
基本的なデータ構造 • 親を辿ってプロットする 28
アプリケーション側の計装 • 手動計装 ◦ SpanのStart, Endをコードで実装 • 自動計装 ◦ gemで自動出力
▪ 実際はmonkey patch、又はActiveSupport::Notification を利用してStart, Endを差し込んでいる ◦ 今回のデモはこちら 29 計装:アプリケーションからテレメトリを出力 及び収集できるようにすること
収集フロー 30 HTTP Header(*) TraceID: ~~ SpanID: ~~ (*) HTTP以外も伝播可能(
gRPC, AMQPのような非同期メッセージングまで)
他ツールとの違い 31
• Profiler ◦ MiniProfiler/rack-mini-profiler ◦ tmm1/stackprof • N+1 Detection ◦
flyerhzm/bullet パフォーマンス関連のツールは色々ある 全て強力で有用なツール! 32
分散トレーシングの強みは? 33 それもあるが・・・ • ログ、メトリクスの補強? Profilerでも取れるわよ
34 テレメトリの関連付け (correlation)
• 離散的なイベント情報 →関連付けが苦手 ◦ アクセスログとアプリログの紐付け ◦ nginxのログとRailsログの紐付け • timestampやip, user_id等で手動紐付け
(職人芸) 再掲)ログの限界 35
ログとトレースの関連付け( before) 36
ログとトレースの関連付け( after) 37
テレメトリのポテンシャルを引き出す • ログとの紐付け ◦ ログとトレースに相互 • メトリクスとの紐付け( Exemplar) ◦ 集計データの根拠として詳細なログやトレースを閲覧可能
シームレスに粒度を変えながらの調査が可能になる 38
ポテンシャル最大化した先:オブザーバビリティ 最早ボトルネックの特定にコードは不要 39 数秒〜数分 調査完了 調査開始 ボトルネック特定 テレメトリ中心の 仮説検証 解決方法の検討と
優先度付け N回
とはいえ、今日はトレースとパ フォーマンスの話に絞ります 🙏 40
• 汎用的 ◦ 言語、FWによらない ◦ 監視ツールや他テレメトリとの統合 • 直感的 ◦ 関連付け、ビジュアライズにより
トレースが調査の入口になる 41 デバッグ範囲を絞り込んだ上で必要に応じて 詳細なツールへ( Profilerなど) 話を戻して、他ツールとの違いについて
分散トレーシングは、正しく実装するのは非常に難しく 時間がかかる (略) 分散システムにおけるサービス間の パフォーマンスを把握したり (略) 大掛かりなサーバーレ スインフラがある場合も、分散トレーシングを考えてもよ いでしょう でも、敷居高いのでは?
出典)入門 監視 (Mike Julian 著、松浦 隼人 訳(2019). オライリー・ジャパン), 106p 下線、太字は引用者による 42
トレーシングのツールは継続的に改善されてきていま す。数年後にはこの警告も意味がなくなっているかも しれません 。 注釈より 2024年現在はどうなのよ? 43 出典)入門 監視 (Mike Julian 著、松浦 隼人 訳(2019). オライリー・ジャパン),
106p 下線、太字は引用者による
分散トレーシングと OpenTelemetry 44
分散トレーシングの導入ハードルの高さ(数年前) Dapper (Google) 2010 2012 2017 2019 OSS SaaS ※現在はServiceNow
※o11y関連のプロダクト開始年に 合わせてマッピング Splunk APM (ソース) Jaeger ソース Grafana Tempo 45
• 技術選定コストが高い ◦ ライブラリ(実装コストに直結) ▪ 例えばFaradayの計装: Jaegerのclient使うよりもOpenCensus のFaradayMiddleware使う方が楽 とか ◦ バックエンド・データストア
▪ SaaSの選択肢が少ないので自前で構築・・・ ▪ 対応フォーマットは? ▪ コストは? 分散トレーシングの導入ハードルの高さ(数年前) 46
数年前の分散トレーシング( OTel登場前) 導入・運用コスト> メリット ※個人の見解です ※規模によります 47
OpenTelemetryの登場(2019.5) Dapper (Google) 2010 2012 2017 2019 OSS SaaS ※現在はServiceNow
※o11y関連のプロダクト開始年に 合わせてマッピング Splunk APM (ソース) Jaeger ソース Grafana Tempo 48
• OpenTracingとOpenCensusを統合 • オブザーバビリティの実現に必要な ほぼ(*1) 全てを提供 ◦ トレース、ログ、メトリクス(*2) ◦ API仕様(Specification,
OTLP) ◦ 言語別のSDK、instrumentation library ◦ デモやドキュメント OpenTelemetryの登場(2019.5) (*1)ほぼ・・・閲覧用のUIやストレージなど、バックエンドは今のところ提供していません (*2)ログとメトリクスは2024.10現在betaな機能が多いです 49
• OpenTelemetryという標準仕様の登場 ◦ ライブラリやプラグインがOpenTelemetryに集約 ◦ →技術選定、キャッチアップコストの軽減 • 監視・o11y系SaaSのOpenTelemetry対応 ◦ 今使ってるSaaSの1機能として使える時代になった
◦ →移行性の向上(恐らく後述する市場競争要因にも) 導入ハードルが下がってきた 50
最近の分散トレーシング( OTel登場後) 導入・運用コスト<メリット ※個人の見解です 51
• 様々なマネージドサービスへの依存 ◦ 通信の複雑さ • RailsのようなThe One Person Framework、豊富な Gem
◦ 処理のカプセル化 ◦ 巨大なコードベース モノリスでもそう言える? 「一目見て」何が起きているかわかるのはとても強力 52
OpenTelemetryのはじめかた 53
• Railsアプリケーションを計装する ◦ トレースを出せるようにする • バックエンドを用意する ◦ データを貯めて、閲覧できる場所を用意する ◦ SaaS、またはOSSを組み合わせて自前で構築
やること 54
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
パフォーマンス調査実践(デモ) 56
• ECサイト(Rails製) • 商品購入にはログイン が必要 ◦ Email / SNS(ID連携) デモアプリ
- Kaigi on Rails STORE https://github.com/ymtdzzz/kaigi-on-rails-2024-otel 57
• 数量限定セール施策 を開始 • ログイン処理が遅く ユーザーからのクレーム増(*) • あなたはログイン処理のパフォーマンス改善 を任された ◦
認証領域についてはあまり詳しく無い ◦ データ量も増えており、スロークエリに悩まされている デモアプリ (*)元々ログインは遅かったが、瞬間風速の高い施策はそこまで多く無く、問題にはなっていなかった なお、認証を長期間維持する仕組み(リフレッシュトークンなど)、ゲスト購入については今回は考えない 58
トレースを体験してみよう! 59
デモタイム 60
状況の確認: ID連携による認証の遅さ ※デモ補足用 • http://localhost:3030 にアクセス 61
状況の確認: ID連携による認証の遅さ ※デモ補足用 • 「(先着10名限定)1000型超ウルトラワイドモニター」 を選んで、 「OpenIDConnect連携」でログイン 62
状況の確認: ID連携による認証の遅さ ※デモ補足用 • 5秒程度経過後、商品詳細画面に遷移できることを確認(遅い!) 63
調査:ログの確認( Grafana) ※デモ補足用 • http://localhost:3001 にアクセス 64
調査:ログの確認( Grafana) ※デモ補足用 • Explorerからログの検索をする • アクセスログなどは確認できるが、ボトルネックの特定は困難 65
コードを読みに行く前に、トレー ス! 66
調査:トレースの確認( Grafana) ※デモ補足用 • ExplorerからTempoでトレースを検索する • Duration > 1sで遅いトレースを検索 67
調査:トレースの確認( Grafana) ※デモ補足用 • トレース詳細から、jwks.jsonのGETリクエストがボトルネックだとい うことがわかる 68
ここで初めて実装を調べる ※デモ補足用 • 「ID連携 jwks」とかでググる ※ここは雰囲気でOK 69
ここで初めて実装を調べる ※デモ補足用 • jwks.jsonへのGETについてわかったこと ◦ OIDCによるID連携時に必要な処理 ◦ 処理自体はomniauth_openid_connect gemで実装 ◦
毎回返ってくるデータは同じ ▪ KeyIDがローテしなければ全く同じデータ になる • 解決策の検討 ◦ 起動時にキャッシュする ◦ KeyIDに該当するJWKが見つからなければ取得し直してキャッ シュを更新する 70
キャッシュ後の動作確認 ※デモ補足用 • config/initializers/devise.rb ◦ キャッシュを有効化( 今回は雑にモンキーパッチ ) ◦ docker
compose restart web 71
キャッシュ後の動作確認 ※デモ補足用 • 早くなった! ◦ 5s → 25ms(200倍)※体感できるように大げさに遅延させてます 72
補足)トレースとログの関連付け ※デモ補足用 • スパン詳細から「 Logs for this span」 • トレースに紐付くログを双方向で引いて
これる • 役立つシーン ◦ エラーからユーザー影響 を調べる ◦ ステータスコードから根本原因を調 べる 73
• 認証に詳しくなかったとしても ◦ コードのどこを調べるべきかわかる ◦ ボトルネックを確認した上で対応できる • トレースが無かったら・・・? ◦ もっと時間かかったかも
デモのまとめ 74
バックエンドの料金 75
• SaaS(監視・o11y専門) • SaaS(パブリッククラウド) • OSS(自前構築) バックエンドの選択肢 ※一部抜粋 76 Amazon
X-Ray Cloud Trace Grafana Tempo SaaSが一番手っ取り早い →でも高い・・・?
• テレメトリの送り方の標準ができた( OTel) • 監視・o11y系SaaSの競争激化 ◦ データはどれも同じような形 ◦ データの見せ方 、料金で勝負!
(持論)OpenTelemetryによる市場競争 77
• ホスト数 • トレース、スパン ◦ 件数(Spans) ◦ データ量(Bytes) SaaSでの主な課金指標 78
• 無料枠 ◦ Freeプラン ▪ 例:100GBまで無料 ◦ ホスト数に応じた無料枠 ▪ 例:150GB/ホスト,
100万Spans/ホスト • 変わり種 ◦ ビルトインのサンプリングルールを使ったトレース(Span)の 件数への課金が無料 SaaSの柔軟な料金体系 79 見積もりした上で、まずは SaaSでトレースの 検証を始めてみましょう!
構成時のポイント 80
• バックエンド ◦ SaaS(監視・o11y専門) ▪ NewRelic, Splunk, Datadog … ◦
SaaS(パブリッククラウド) ▪ X-Ray, Cloud Trace … ◦ OSS(自前構築) ▪ Prometheus, Grafana … • 計装 ◦ OpenTelemetry ◦ SaaSベンダー独自形式 構成における選択肢 81
• バックエンド ◦ SaaS(監視・o11y専門) ▪ NewRelic, Splunk, Datadog … ◦
SaaS(パブリッククラウド) ▪ X-Ray, Cloud Trace … ◦ OSS(自前構築) ▪ Prometheus, Grafana … • 計装 ◦ OpenTelemetry ◦ SaaSベンダー独自形式 選定時の選択肢 82 • 既に使っている SaaSがある ならそれを使おう
• バックエンド ◦ SaaS(監視・o11y専門) ▪ NewRelic, Splunk, Datadog … ◦
SaaS(パブリッククラウド) ▪ X-Ray, Cloud Trace … ◦ OSS(自前構築) ▪ Prometheus, Grafana … • 計装 ◦ OpenTelemetry ◦ SaaSベンダー独自形式 選定時の選択肢 83 • SaaSの乗り換え可能性な どを考慮して決定 (移行コストはそこまで大き くない)
鉄則:導入と運用が一番楽な構 成を選ぶ 84
ディシジョンツリー(参考) 85
例1)既に使っている SaaSがある • 一番始めやすい構成(全部 SaaS) 86
例2)他SaaSへの移行も考慮したい • アジリティ高めの構成(バックエンド SaaS、計装OTel) 87
例3)大規模な分散システム (SaaSが高すぎた場合) • Self-hosting(バックエンド OSS、計装OTel) 88
• トレース ◦ ログ、メトリクスを補完する情報 ◦ 関連付けにより、テレメトリ全体 を強化 ▪ オブザーバビリティ へ
• OpenTelemetryにより導入ハードルが下がった • トレース使っていきましょう まとめ 89
トレースに興味を持ってくれたら 嬉しいです! 90
ありがとうございました! 91