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

Kaigi on Rails 2024での登壇資料になります。
https://kaigionrails.org/2024/talks/ymtdzzz/

Transcript

1. モノリスでも使える！ OpenTelemetryでRails アプリのパフォーマンス分析を始めてみよう 2024.10.25 Fri. Kaigi on Rails@有明セントラルタワーホール & カンファレンス（東京） @ymtdzzz
2. Yosuke MATSUDA (@ymtdzzz) 株式会社SmartHR プロダクトエンジニア 2
3. • 想定参加者 ◦ アプリケーションのパフォーマンス改善やエラー調 査を行なう人 ▪ それをもっと楽にしたいと考えている人 ◦ トレースに興味はあるが、使ったことはない人 本日の内容 3
4. • ゴール：トレースを知ってもらい、使ってみたくなる！ ◦ パフォーマンス調査の難しさ ◦ ログ＋メトリクス＋ トレース 👈🆕 ▪ 何が嬉しいのか ▪ OpenTelemetryの位置付け ▪ 他ツールとの違い ◦ Railsアプリへの導入方法と実践（デモ） ◦ コスト、構成の選び方について 本日の内容 4
5. パフォーマンス調査の難しさ 5
6. 例えば エンドユーザー 最近◦◦の処理が遅いんだ けど･･･ 6
7. 例えば SRE 最近このパス遅いんですよ ね〜（SLOを見せながら）見 てもらえます？ 7
8. • エンドツーエンドの粒度 ◦ ユーザーから見た 遅さ、使いにくさ ▪ パブリックLBのレイテンシー ▪ 500エラー、不具合の調査 など 調査はエンドツーエンドの粒度から始まる （ことが多い） 8 私たちはそれを実装レベルの粒度までブレークダウンして 調査する必要がある
9. 調査開始時点ではなにもわからない（当然） 9 スロークエリか？ N+1かも？ いやいやあのマネージド サービスが遅いんだよ 最近誰か改修して たな
10. ボトルネックの調査（可能性の絞り込み） 10 調査完了 調査開始 ボトルネック特定 テレメトリ中心の 仮説検証 コード中心の 仮説検証 解決方法の検討と 優先度付け コード読むかぁ M回 N回
11. ボトルネックの調査（可能性の絞り込み） 11 調査完了 調査開始 ボトルネック特定 テレメトリ中心の 仮説検証 コード中心の 仮説検証 解決方法の検討と 優先度付け コード読むかぁ M回 N回 テレメトリ（ログやメトリクス）から可 能性を絞る ※事実からの分析＝コア分析ループ
12. ボトルネックの調査（可能性の絞り込み） 12 調査完了 調査開始 ボトルネック特定 テレメトリ中心の 仮説検証 コード中心の 仮説検証 解決方法の検討と 優先度付け コード読むかぁ M回 N回 絞りきれなかった可能性に対し て仮説検証を繰り返す （コスト大・属人的） ローカルで再現 計測コードを仕込 んでデプロイ コードの理解度に依存
13. コードを見る前にどれだけ可能性を潰せるかが勝負 13 調査完了 調査開始 ボトルネック特定 テレメトリ中心の 仮説検証 コード中心の 仮説検証 解決方法の検討と 優先度付け コード読むかぁ M回 N回
14. テレメトリ分析の難しさ 14
15. ログの難しさ 15
16. • 離散的なイベント情報 →関連付けが苦手 ◦ アクセスログとアプリログの紐付け ◦ nginxのログとRailsログの紐付け • timestampやip, user_id等で手動紐付け （職人芸） ログの難しさ 16
17. • 集計データの根拠 としてログを手動で調べる 手間 • メトリクス粒度 の悩み ◦ パス別、ブラウザ別にLatency出したいんだけど ◦ ログベースのカスタムメトリクス作るか・・・ ◦ →ほんとにこれメトリクスで取るべき情報なのかな？ メトリクスの難しさ 17
18. • 処理の過程についての情報が限られる ◦ ログ仕込むのはつらい（イベント情報なので） • ログをはじめ、テレメトリ相互の紐付けに手作業が 必要 テレメトリ分析の難しさ 18 （ログ・メトリクスによる） ログとメトリクスで実装の粒度までブレークダウン するのは結構難しい
19. ログ＋メトリクス＋ トレース 19
20. トレースから得られる情報（例 1） 20
21. トレースから得られる情報（例 2） 21
22. 分散トレーシング（トレース）とは？ 22
23. 1つのリクエスト が、アプリケーションを構成するさまざ まなサービスによって処理される過程を追跡する方法 (*) 分散トレーシングとは (*)オブザーバビリティ・エンジニアリング　（ Charity Majors、Liz Fong-Jones、George Miranda　著、大谷 和 紀、山口 能迪　訳（2023）．　オライリー・ジャパン）, 64p 下線は引用者による 23
24. 基本的なデータ構造 24
25. 基本的なデータ構造 25 追跡の単位（リクエストなど）
26. 基本的なデータ構造 26 プロセスの単位
27. 基本的なデータ構造 • 親子関係をデータで持つことで到達順序は自由 27
28. 基本的なデータ構造 • 親を辿ってプロットする 28
29. アプリケーション側の計装 • 手動計装 ◦ SpanのStart, Endをコードで実装 • 自動計装 ◦ gemで自動出力 ▪ 実際はmonkey patch、又はActiveSupport::Notification を利用してStart, Endを差し込んでいる ◦ 今回のデモはこちら 29 計装：アプリケーションからテレメトリを出力 及び収集できるようにすること
30. 収集フロー 30 HTTP Header(*) TraceID: ~~ SpanID: ~~ (*) HTTP以外も伝播可能（ gRPC, AMQPのような非同期メッセージングまで）
31. 他ツールとの違い 31
32. • Profiler ◦ MiniProfiler/rack-mini-profiler ◦ tmm1/stackprof • N+1 Detection ◦ flyerhzm/bullet パフォーマンス関連のツールは色々ある 全て強力で有用なツール！ 32
33. 分散トレーシングの強みは？ 33 それもあるが･･･ • ログ、メトリクスの補強？ Profilerでも取れるわよ
34. 34 テレメトリの関連付け （correlation）
35. • 離散的なイベント情報 →関連付けが苦手 ◦ アクセスログとアプリログの紐付け ◦ nginxのログとRailsログの紐付け • timestampやip, user_id等で手動紐付け （職人芸） 再掲）ログの限界 35
36. ログとトレースの関連付け（ before） 36
37. ログとトレースの関連付け（ after） 37
38. テレメトリのポテンシャルを引き出す • ログとの紐付け ◦ ログとトレースに相互 • メトリクスとの紐付け（ Exemplar） ◦ 集計データの根拠として詳細なログやトレースを閲覧可能 シームレスに粒度を変えながらの調査が可能になる 38
39. ポテンシャル最大化した先：オブザーバビリティ 最早ボトルネックの特定にコードは不要 39 数秒〜数分 調査完了 調査開始 ボトルネック特定 テレメトリ中心の 仮説検証 解決方法の検討と 優先度付け N回
40. とはいえ、今日はトレースとパ フォーマンスの話に絞ります 🙏 40
41. • 汎用的 ◦ 言語、FWによらない ◦ 監視ツールや他テレメトリとの統合 • 直感的 ◦ 関連付け、ビジュアライズにより トレースが調査の入口になる 41 デバッグ範囲を絞り込んだ上で必要に応じて 詳細なツールへ（ Profilerなど） 話を戻して、他ツールとの違いについて
42. 分散トレーシングは、正しく実装するのは非常に難しく 時間がかかる (略) 分散システムにおけるサービス間の パフォーマンスを把握したり (略) 大掛かりなサーバーレ スインフラがある場合も、分散トレーシングを考えてもよ いでしょう でも、敷居高いのでは？ 出典）入門　監視　（Mike Julian　著、松浦 隼人　訳（2019）．　オライリー・ジャパン）, 106p 下線、太字は引用者による 42
43. トレーシングのツールは継続的に改善されてきていま す。数年後にはこの警告も意味がなくなっているかも しれません 。 注釈より 2024年現在はどうなのよ？ 43 出典）入門　監視　（Mike Julian　著、松浦 隼人　訳（2019）．　オライリー・ジャパン）, 106p 下線、太字は引用者による
44. 分散トレーシングと OpenTelemetry 44
45. 分散トレーシングの導入ハードルの高さ（数年前） Dapper （Google） 2010 2012 2017 2019 OSS SaaS ※現在はServiceNow ※o11y関連のプロダクト開始年に 合わせてマッピング Splunk APM （ソース） Jaeger ソース Grafana Tempo 45
46. • 技術選定コストが高い ◦ ライブラリ（実装コストに直結） ▪ 例えばFaradayの計装: Jaegerのclient使うよりもOpenCensus のFaradayMiddleware使う方が楽　とか ◦ バックエンド・データストア ▪ SaaSの選択肢が少ないので自前で構築･･･ ▪ 対応フォーマットは？ ▪ コストは？ 分散トレーシングの導入ハードルの高さ（数年前） 46
47. 数年前の分散トレーシング（ OTel登場前） 導入・運用コスト＞ メリット ※個人の見解です ※規模によります 47
48. OpenTelemetryの登場（2019.5） Dapper （Google） 2010 2012 2017 2019 OSS SaaS ※現在はServiceNow ※o11y関連のプロダクト開始年に 合わせてマッピング Splunk APM （ソース） Jaeger ソース Grafana Tempo 48
49. • OpenTracingとOpenCensusを統合 • オブザーバビリティの実現に必要な ほぼ(*1) 全てを提供 ◦ トレース、ログ、メトリクス(*2) ◦ API仕様（Specification, OTLP） ◦ 言語別のSDK、instrumentation library ◦ デモやドキュメント OpenTelemetryの登場（2019.5） (*1)ほぼ･･･閲覧用のUIやストレージなど、バックエンドは今のところ提供していません (*2)ログとメトリクスは2024.10現在betaな機能が多いです 49
50. • OpenTelemetryという標準仕様の登場 ◦ ライブラリやプラグインがOpenTelemetryに集約 ◦ →技術選定、キャッチアップコストの軽減 • 監視・o11y系SaaSのOpenTelemetry対応 ◦ 今使ってるSaaSの1機能として使える時代になった ◦ →移行性の向上（恐らく後述する市場競争要因にも） 導入ハードルが下がってきた 50
51. 最近の分散トレーシング（ OTel登場後） 導入・運用コスト＜メリット ※個人の見解です 51
52. • 様々なマネージドサービスへの依存 ◦ 通信の複雑さ • RailsのようなThe One Person Framework、豊富な Gem ◦ 処理のカプセル化 ◦ 巨大なコードベース モノリスでもそう言える？ 「一目見て」何が起きているかわかるのはとても強力 52
53. OpenTelemetryのはじめかた 53
54. • Railsアプリケーションを計装する ◦ トレースを出せるようにする • バックエンドを用意する ◦ データを貯めて、閲覧できる場所を用意する ◦ SaaS、またはOSSを組み合わせて自前で構築 やること 54
55. 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. パフォーマンス調査実践（デモ） 56
57. • ECサイト（Rails製） • 商品購入にはログイン が必要 ◦ Email / SNS（ID連携） デモアプリ - Kaigi on Rails STORE https://github.com/ymtdzzz/kaigi-on-rails-2024-otel 57
58. • 数量限定セール施策 を開始 • ログイン処理が遅く ユーザーからのクレーム増(*) • あなたはログイン処理のパフォーマンス改善 を任された ◦ 認証領域についてはあまり詳しく無い ◦ データ量も増えており、スロークエリに悩まされている デモアプリ (*)元々ログインは遅かったが、瞬間風速の高い施策はそこまで多く無く、問題にはなっていなかった 　なお、認証を長期間維持する仕組み（リフレッシュトークンなど）、ゲスト購入については今回は考えない 58
59. トレースを体験してみよう！ 59
60. デモタイム 60
61. 状況の確認： ID連携による認証の遅さ ※デモ補足用 • http://localhost:3030 にアクセス 61
62. 状況の確認： ID連携による認証の遅さ ※デモ補足用 • 「（先着10名限定）1000型超ウルトラワイドモニター」 を選んで、 「OpenIDConnect連携」でログイン 62
63. 状況の確認： ID連携による認証の遅さ ※デモ補足用 • 5秒程度経過後、商品詳細画面に遷移できることを確認（遅い！） 63
64. 調査：ログの確認（ Grafana） ※デモ補足用 • http://localhost:3001 にアクセス 64
65. 調査：ログの確認（ Grafana） ※デモ補足用 • Explorerからログの検索をする • アクセスログなどは確認できるが、ボトルネックの特定は困難 65
66. コードを読みに行く前に、トレー ス！ 66
67. 調査：トレースの確認（ Grafana） ※デモ補足用 • ExplorerからTempoでトレースを検索する • Duration > 1sで遅いトレースを検索 67
68. 調査：トレースの確認（ Grafana） ※デモ補足用 • トレース詳細から、jwks.jsonのGETリクエストがボトルネックだとい うことがわかる 68
69. ここで初めて実装を調べる ※デモ補足用 • 「ID連携 jwks」とかでググる ※ここは雰囲気でOK 69
70. ここで初めて実装を調べる ※デモ補足用 • jwks.jsonへのGETについてわかったこと ◦ OIDCによるID連携時に必要な処理 ◦ 処理自体はomniauth_openid_connect gemで実装 ◦ 毎回返ってくるデータは同じ ▪ KeyIDがローテしなければ全く同じデータ になる • 解決策の検討 ◦ 起動時にキャッシュする ◦ KeyIDに該当するJWKが見つからなければ取得し直してキャッ シュを更新する 70
71. キャッシュ後の動作確認 ※デモ補足用 • config/initializers/devise.rb ◦ キャッシュを有効化（ 今回は雑にモンキーパッチ ） ◦ docker compose restart web 71
72. キャッシュ後の動作確認 ※デモ補足用 • 早くなった！ ◦ 5s → 25ms（200倍）※体感できるように大げさに遅延させてます 72
73. 補足）トレースとログの関連付け ※デモ補足用 • スパン詳細から「 Logs for this span」 • トレースに紐付くログを双方向で引いて これる • 役立つシーン ◦ エラーからユーザー影響 を調べる ◦ ステータスコードから根本原因を調 べる 73
74. • 認証に詳しくなかったとしても ◦ コードのどこを調べるべきかわかる ◦ ボトルネックを確認した上で対応できる • トレースが無かったら・・・？ ◦ もっと時間かかったかも デモのまとめ 74
75. バックエンドの料金 75
76. • SaaS（監視・o11y専門） • SaaS（パブリッククラウド） • OSS（自前構築） バックエンドの選択肢 ※一部抜粋 76 Amazon X-Ray Cloud Trace Grafana Tempo SaaSが一番手っ取り早い →でも高い･･･？
77. • テレメトリの送り方の標準ができた（ OTel） • 監視・o11y系SaaSの競争激化 ◦ データはどれも同じような形 ◦ データの見せ方 、料金で勝負！ （持論）OpenTelemetryによる市場競争 77
78. • ホスト数 • トレース、スパン ◦ 件数（Spans） ◦ データ量（Bytes） SaaSでの主な課金指標 78
79. • 無料枠 ◦ Freeプラン ▪ 例：100GBまで無料 ◦ ホスト数に応じた無料枠 ▪ 例：150GB/ホスト, 100万Spans/ホスト • 変わり種 ◦ ビルトインのサンプリングルールを使ったトレース（Span）の 件数への課金が無料 SaaSの柔軟な料金体系 79 見積もりした上で、まずは SaaSでトレースの 検証を始めてみましょう！
80. 構成時のポイント 80
81. • バックエンド ◦ SaaS（監視・o11y専門） ▪ NewRelic, Splunk, Datadog … ◦ SaaS（パブリッククラウド） ▪ X-Ray, Cloud Trace … ◦ OSS（自前構築） ▪ Prometheus, Grafana … • 計装 ◦ OpenTelemetry ◦ SaaSベンダー独自形式 構成における選択肢 81
82. • バックエンド ◦ SaaS（監視・o11y専門） ▪ NewRelic, Splunk, Datadog … ◦ SaaS（パブリッククラウド） ▪ X-Ray, Cloud Trace … ◦ OSS（自前構築） ▪ Prometheus, Grafana … • 計装 ◦ OpenTelemetry ◦ SaaSベンダー独自形式 選定時の選択肢 82 • 既に使っている SaaSがある ならそれを使おう
83. • バックエンド ◦ SaaS（監視・o11y専門） ▪ NewRelic, Splunk, Datadog … ◦ SaaS（パブリッククラウド） ▪ X-Ray, Cloud Trace … ◦ OSS（自前構築） ▪ Prometheus, Grafana … • 計装 ◦ OpenTelemetry ◦ SaaSベンダー独自形式 選定時の選択肢 83 • SaaSの乗り換え可能性な どを考慮して決定 （移行コストはそこまで大き くない）
84. 鉄則：導入と運用が一番楽な構 成を選ぶ 84
85. ディシジョンツリー（参考） 85
86. 例1）既に使っている SaaSがある • 一番始めやすい構成（全部 SaaS） 86
87. 例2）他SaaSへの移行も考慮したい • アジリティ高めの構成（バックエンド SaaS、計装OTel） 87
88. 例3）大規模な分散システム （SaaSが高すぎた場合） • Self-hosting（バックエンド OSS、計装OTel） 88
89. • トレース ◦ ログ、メトリクスを補完する情報 ◦ 関連付けにより、テレメトリ全体 を強化 ▪ オブザーバビリティ へ • OpenTelemetryにより導入ハードルが下がった • トレース使っていきましょう まとめ 89
90. トレースに興味を持ってくれたら 嬉しいです！ 90
91. ありがとうございました！ 91