O11yによる可視化で実現する_チーム独立型パフォーマンス改善.pdf

Transcript

1. 徳富 博（プラットフォームエンジニアリングチーム） O11yによる可視化で実現する、 チーム独立型パフォーマンス改善 @yannKazu1 Datadogイベント Ruby on Rails × Observability
2. 自己紹介
3. 自己紹介 徳富 博 - 所属: タイミー プラットフォームエンジ ニアリングチーム - 好きな技術: Go, Ruby, TypeScript, AWS, … - 野菜を育ててます
4. 今日お話しすること 属人化しがちなパフォーマンス改善を、機能開発チームで 自律的に回せる仕組み • 課題の整理 • DBM & Profilerによるパフォーマンスボトルネックの 可視化 • モジュラーモノリス × チーム自律改善
5. 課題の整理
6. Railsの光と影 ✨ 光：Rails の高い生産性と開発スピード • 多くの処理を暗黙的に肩代わりしてくれるため、少ないコードでアプリケーションを構築できる • Active Record により、SQL を意識せず Ruby らしい記述で DB 操作ができる ⚠ 影：暗黙的な挙動が生むパフォーマンスの罠 • Rails が裏側で多くの処理を行うため、 どこでコストがかかっているか見えにくい • 特に Active Record は、SQL を書かずに済む反面、 ◦ 思わぬタイミングで 重いクエリ が発行される ◦ N+1 クエリや不要なデータ取得が起きやすい • 問題は「動いている間は気づきにくく」、 負荷が上がってから顕在化しがち
7. Railsは暗黙的に色々やってくれる分、パフォーマンス改善には 経験が必要 ↓ • ボトルネックの発見・改善には経験と深い知識が必要 • 「あの人に聞かないとわからない」状態に陥りやすい → 属人化・SRE依存が起きる 結果何が起こるか？
8. SREチームがパフォーマンス改善をする際の課題 • SREチームは機能開発がメインの仕事ではない • そのため仕様は把握しているが、深いドメイン知識は各機能開発 チームに劣る • ロジック変更を伴う改善は影響範囲の把握が難しいことがある • パフォーマンス改善に仕様変更が必要になることがある。しかし仕様 のオーナーは機能開発チームのため、調整コストが高い
9. この課題はプロダクトが大きくなるほど限界が顕著に • コードベースの肥大化 → 全体を把握するのは不可能 • 機能ごとの仕様の複雑化 → 「直せるけど壊すかも」リスク • SREがボトルネックに → 改善速度が頭打ち
10. 目指す姿 以下を実現し、各機能開発チームが自律的に改善できる状態へ • 自分たちで問題を発見 • 専門的なチューニング知識がなくても、何がボトルネックになって いるかを自分たちで判断できる状態にする • チーム内で独立して改善
11. 問題と解決の方向性 Railsの場合内部が見えにくい → 経験が必要 → 属人化・SRE依存 😰 では、どうすれば？ ↓ Datadogを見れば原因箇所が視覚的にわかる状態にする ↓ 経験・勘に頼る ❌ → 誰でも改善できる状態にして属人化排除！ 🎉
12. この状態を作るために、何を可視化するか？
13. DBM & Profilerによるパフォーマンスボトルネックの可視化
14. なぜDBMとProfilerに注目したか 可視化対象の選定基準 1. チューニングが難しい（経験 (勘)や知識が必要） 2. 発生頻度が高い（改善効果が大きい） ↓ 領域 ツール よくある問題 データベース DBM スロークエリ、インデックス不足 アプリケーション CPU / メモリ Profiler メモリ・ CPU負荷 この2つを可視化すれば、多くの問題に対応できる
15. 解決策① DBMの導入 DBMで見えるようになったこと • Explain Plan の自動取得 and 可視化 • Wait Events
16. DBMとトレース連携するとトレースから遅いクエリを特定し、その実行計画を確認できる
17. 実行計画がビジュアライズされているので問題箇所が知識がなくても特 定しやすい(①でビジュアライズ切り替え可能)
18. さらにAIによる改善提案も見れる(②をクリックすると見れる)
19. Before / After • Before 😓 「なんか遅い」→ APMを見る→ 詳しい人に聞く → explain 手動実行 → 原因特定に数時間〜数日 ↓ • After 🎉 APMを見る→ DBMでExplain Planを見る(AIによる改善法 を参考にみる) → 原因特定まで数分
20. 解決策② Profilerの活用 指標 何が分かるか メモリアロケーション どこでメモリを消費しているか CPU Time どこで処理時間を使っているか GC どのタイミングで GCが発動したか GVL待ち どれだけ処理が GVLで待たされているか ※ GVL：IO wait中など以外は 1スレッドしか動けな い制約 課題：大量データ処理時など、どのコードがリソースを消費しているか分からない 😰 Profilerで見えるようになること ↓ 「ここが怪しい」が可視化され、誰でも分かる状態に
21. どのコードで、どれくらい待ち時間（Wall Time）・CPU Time・メモリ が使われているかを、Flame graphを使ってコード単位で把握できる https://docs.datadoghq.com/ja/profiler/connect_traces_and_profiles/?tab=ruby
22. 処理の依存関係よりわかりやすくビジュアライズした状態で表示することも可能 https://docs.datadoghq.com/ja/profiler/connect_traces_and_profiles/?tab=ruby
23. どのスレッドが、いつ、何に時間を使ったかを可視化(CPU Time, GC, Wating for GVL) https://docs.datadoghq.com/ja/profiler/connect_traces_and_profiles/?tab=ruby
24. Profiler導入の Before / After • Before 😓 「なんかメモリ使いすぎ」「処理が遅い」 → 手当たり次第にコードを読 む → 仮説ベースで修正 → 効果あるか分からない → 詳しい人に相談 → 原因 特定に数日〜諦め ↓ • After 🎉 Profilerでフレームグラフを確認 → 「このメソッドがメモリ食ってる」「ここ でCPU使ってる」が一目瞭然 → ピンポイントで修正 → 原因特定まで数分〜数 時間
25. モジュラーモノリス × チーム自律改善
26. 弊社アーキテクチャの前提 Railsモジュラーモノリス採用している • 機能単位でモジュール分割 • エンドポイント/モジュール単位でチーム責務を分離 ↓ このディレクトリ（コード）はどのチームがオーナーかが概ね決まっている (1月9日時点の集計で、直近1ヶ月に変更されたコードの約7割はコードオーナー が決まっている)
27. CodeOwnershipによるチーム情報の付与 CodeOwnership gem を活用 • Datadog APM・Logのタグとして担当チーム情報を送信 • どのエンドポイント・処理がどのチームの責務を明確化
28. CodeOwnershipによるチーム情報の付与
29. APMにコードオーナー情報を付与する実装例（Controller) module DatadogTaggable extend ActiveSupport::Concern included do before_action :set_datadog_tags end private def set_datadog_tags span = Datadog::Tracing.active_span return unless span code_owner = CodeOwnership.for_class(self.class)&.name || 'unknown' span.set_tag('code_owner', code_owner) rescue StandardError => e Rails.logger.warn("Failed to set code_owner tag: #{e.message}") end end このModuleをControllerで includeするだけ！ ※ Sidekiq等の実装は下記ブロ グをご参照ください https://tech.timee.co.jp/entry/2 024/12/14/100000
30. チームごとの関心のある情報だけを絞り込む ことも可能に 例えば... • code_owner でフィルタしてレイテンシーの劣化などがないかを定期的に 確認できるようになる　　　　　　　　　　　　　　　　　　　　　 ↓ 定期的に観測 → 問題発見 → 改善のサイクルが回る
31. このようにしてSREを介さず各チームが独立して改善できる状態している まとめると ... 1 自チームの関心のある情報で絞り込み可能にし異常検知 2 DBM / Profilerでパフォーマンス改善方法を特定 3 チーム内で改善・デプロイ 4 効果測定 🎉 → SREを介さず、各チームが自律的に改善サイクルを回せる (難易度の高い課題には引き続き SREチームが協力してサポート )
32. Start with visibility, Scale with ownership!