はじめに

この記事はNew Relic Advent Calendar 2022の20日目の記事となります。

Rubyで構築されたAPIのパフォーマンスチューニングに挑んでいる者です。
先日負荷試験を実施し、試験結果の分析にNew RelicのAPMを活用するためにNew Relicさんと面会させていただきました。
そこで教えていただいたことや学んだことをこの記事にて共有します。

Distributed Tracing

各項目を説明していきます。

trace_duration
- レスポンスタイム
span
- DBへのクエリ実行・他サービスの呼び出し・関数の呼び出しをおこなった回数
- 多すぎる場合は何かしらの改善をすべき(N+1の検出等に役立てることができる)
traces
- Group similar tracesがオンの場合に表示される、グループにまとめられているトレースの数

APMのページ上部にあるGroup similar tracesのトグルをOFFにするとサンプリングが解除されて全てのデータが一覧で見れます
- デフォルトの設定だと、全体の10%サンプリングしたものが表示

時間がかかったクエリがサンプリングされ、一覧に並べられています。
レスポンスタイム(Duration)で照準・降順にして見ることができます。

デフォルトだとクエリの数値が難読化されています。
↓こんな感じ

SELECT * FROM users WHERE id = ?

このままだと検証やチューニングなど色々とやりづらかったりするので、難読化を解除します。
(今回、RubyのシステムをトレースしているためRuby Agentでのやり方のみ紹介します)

Ruby(Rails)アプリケーションのconfig配下にあるnewrelic.ymlを編集します。
transaction_tracer.record_sqlの値をrawに設定します。(デフォルトだとobfuscatedになっている)

common:
~~~

staging:
  transaction_tracer:
    record_sql: raw

production:
~~~

今回、検証で使うStaging環境のみ難読化を解除します。

ページ上部で表示するトレースの時間帯を指定することができます。

デフォルトだと過去30分の指定になっていますが、Set customで任意の時間にできます。
(ただし、次の項目で説明するifinite traceをしていない場合は8日より前のトレースを遡って見ることはできません)

デフォルトの設定だとトレースされたものが8日で消去されるようになっているが、消えないように設定することもできます。
ただし、料金モデルによってはできないこともあるので、要確認です。(公式のリンク)

今回、初めての負荷試験でNew Relicを活用し効率よく結果を見て分析することができました。
また知見が溜まったら記事にしようと思います。