💎

Kaigi on Rails 2023 に登壇しました

2023/11/01に公開

Leaner 開発チームの黒曜(@kokuyouwind)です。

Kaigi on Rails 2023 に参加し、「APM をちゃんと使おうとしたら、いつのまにか独自 gem を作っていた話」というタイトルで登壇しました。

https://kaigionrails.org/2023/talks/kokuyouwind/

「ブログを書くまでがカンファレンス」という話もあるので、簡単にですが感想と発表補足をまとめます。

動画アーカイブ

セッションごとの動画が後日アップロードされるはずですが、現状でも当日のライブ配信アーカイブが閲覧できます。

下の埋め込みは自分の発表からの時間指定になっています。

セッション動画が公開されたため差し替えました。

https://www.youtube.com/watch?v=hlnorJ64UPY

発表スライド

自分の発表資料は slides.com というサービスでスライドを作っています。

https://slides.com/kokuyouwind/kaigi_on_rails_2023

埋め込み表示ができませんが、上記リンクから開くと発表時のスライドがそのまま見られます。

一応 Speaker Deck にもアップロードしていますが、 PDF 出力時にフォントが化けてしまっているためちょっと見づらいです。

発表の簡単な概要

APM を Leaner でどう使っているかの紹介と、トレースを取りやすくするためにAPM Traceableを作った話をしました。

https://github.com/kokuyouwind/apm_traceable/

gem を作ったといっても大したものではなくて、以前Rails アプリの重い処理を Datadog APM で改善した話に書いたものをそのまま gem に切り出した形です。

https://zenn.dev/leaner_dev/articles/20221220-datadog-manual-trace

どちらかというと、 APM を使ってパフォーマンスの問題を検知し、それを APM 以外の調査も含めてどう改善したか、という事例に主眼をおいた話になりました。[1]

なかでも XML Parse に時間がかかっている原因が NameError に起因する DidYouMean の処理時間だったというのは、あまり見られない興味深い事例だったのではないでしょうか。

発表の補足

今回は 15 分の発表時間に APM の導入、自作 gem の解説、事例紹介を全部詰め込んだのでかなりカツカツで、削った話も多くありました。

以下、いくつか発表の補足を書いておきます。

メソッドのトレースについて

メソッドのトレースを取りやすくするために「メソッド呼び出しをスパンとして追跡する処理」を自作したわけですが、実はNew Relicではメソッドトレーサーが実装されており、 add_method_tracer とすると今回自作した処理とほぼ同様の処理が行われます。

では Datadog にはないのかというと、発表後に調べて見つけたのですが既に Issue が立っているようです。

https://github.com/DataDog/dd-trace-rb/issues/1197

この Issue の会話を見ると、 Datadog 側としても課題は認識していて社内で実装に取り組んでいるらしいのですが、その後なんらかの事情があるのか立ち消えてしまったようですね。

懇親会で「Datadog の人を紹介するから、今回作ったコードを公式に取り込んでもらったほうがいいんじゃない?」と声をかけてもらい Twitter で繋いでもらったため、公式側でも再度話を動かしてもらえるかも知れません。

https://twitter.com/chikahirotokoro/status/1718214000977363329

またその会話スレッド絡みで、 Falcon などで有名な Samuel Williamsさんからも自作のトレース gem を紹介していただきました。

https://twitter.com/ioquatix/status/1718922888689201613

https://github.com/socketry/traces

こちらはトレース無効時のオーバーヘッドが全くないという点で優れているようです。

個人的には記法が既存コードと変わりすぎて書き換えがやや大変なのと、トレース無効化時のパフォーマンスが重要ではないという点で自作したほうを使い続けるつもりですが、いまからトレース用の gem を追加したい方はこちらも検討できそうです。

プロファイラーについて

発表中では APM で問題を特定したあと、詳細な調査にStackProfを利用したと紹介しました。

発表後に「APM 上で同様の情報を見られないの?」という質問を受けたのですが、実は Datadog にあるContinuous Profilerを使えば APM 上で各メソッドの実行時間やメモリ使用量詳細を取ることができます。これを使えば手元で再現して StackProf を使う手間もないですし、そもそも重要メソッドに手動で trace_methods を仕込んでいく必要もなく大変便利ですね。

ではなぜこれを使わなかったかというと、単純に料金が結構高いからです。ごくたまに発生するパフォーマンス問題のためだけに常時契約するのはためらわれます。

個人的にはよほど応答性能が重要でパフォーマンス監視・改善に常任で人を置いているようなサービスか、運営母体が大きく多少コストを割いてでも運用を省力化したいようなサービスでない限りは、問題発生ごとに手元でプロファイラを使うほうがコストパフォーマンスに見合うと考えています。良い機能なんですけどね。

会社の宣伝について

あまりに発表時間がカツカツだったので、 1 枚くらいさらっと挟む予定だった会社の紹介スライドすら削ってしまいました。そのうち怒られそうなので、ここにさらっと宣伝を挟んでおきます。

Leaner Technologies、実は Web エンジニアを絶賛募集中です。興味がある人は ↓ の応募フォームでも自分の Twitter DM でもいいので気軽にご連絡ください。

https://careers.leaner.co.jp/engineering

Kaigi on Rails 感想

今回は直前まで発表の構成がまとまりきらず枠を 1 分以上オーバーしてしまう状態になっており、発表当日のお昼休みを使ってスライドの調整と発表練習をしていたりしました。とはいえ最終的にはほぼジャスト 15 分に収まって一安心でした。

発表内容についてもありがたいことに休憩時間や懇親会などでよかったとお声がけいただき嬉しかったです。

またカンファレンスでは聞いているセッションの内容を実況しているのですが、そちらについても見ている・参考になっていると話しかけていただきました。[2] RubyKaigi でもそうですが、自分の理解にも繋がっているのでセッション実況は引き続きやっていきたいです。

初のオフライン開催でしたが、全体的に運営の手際がよく非常に盛り上がった楽しいカンファレンスでした。ぜひ来年もスピーカーで参加できるよう、 360 日の Rubyist [3]を頑張っていきます!

脚注
  1. CfP 時点ではもっと gem の話に主眼を置くつもりだったのですが、結果的にタイトル詐欺気味になってしまいました。 ↩︎

  2. なんならアイコン見せて自己紹介すると「Speaker の人」ではなく「Twitter もとい X 実況の人」と認識されることのほうが多かったです。 ↩︎

  3. 365 日 - RubyKaigi の 3 日 - Kaigi on Rails の 2 日 = 360 日の Rubyist ↩︎

リーナーテックブログ

Discussion