Scoutを活用したActiveRecordのスロークエリ検出

BY Derek Haynes

March 05, 2019

Railsアプリに安定したトラフィックが流入し始めると、SQLのスロークエリという問題が生じることがあります。find_by_sqlなどのシンプルなものを利用して、大きく改善を図ることが可能ですが、そもそもアプリが遅くなっている原因をどうしたら簡単に調べることができるのでしょうか?

PostgreSQLやMySQLなどでもスロークエリログを取ることは可能ですが、生のデータストリームから、施策を打てるような情報を見つけ出すのは困難です。クエリを生成しているLOCはどこか?常にこんな風に遅いのか?それとも一定の期間だけなのか?呼び出し元となっているのはcontroller-actionか、それともバックグラウンドジョブなのか?こうしたアプリケーションの文脈が、スロークエリログには欠けています。

こんなときは、ぜひScoutを試してみてください。

Scoutやscout_apmgemはデータベースの最適化の施策を優先するのに役立ちます。gemがインストールされ、データベース監視のアドオンが有効化されると、Scoutが継続してSQLクエリの分析をします。スロークエリはインサイトとしてアプリのダッシュボードに浮かび上がってきます。

slow_queries_dash.png

クエリは三つの主要な範囲で分析されます。これは、アプリの改善に最も役立つデータベースの最適化にフォーカスするのに役立ちます。

  1. どのクエリが最もアプリに影響しているか?これは、各クエリの所要時間の合計時間を元にしています。この所要時間は、クエリのスループットによって増加した平均のクエリレイテンシです。
  2. どのクエリが、webのエンドポイントとバックグラウンドジョブの中で重大なボトルネックとなっているか?一つのクエリがトランザクションの所要時間の大きな割合を占めている場合、これを調査すると、パフォーマンス改善に役立ちます。
  3. どのクエリが一貫して遅いのか?これらは、レイテンシの高い平均を持つクエリです。

スロークエリのクエリインサイトをクリックすると、controller-actionを呼び出した場合のクエリ呼び出し時間の情報が表示されます。

slow_query_breakdown.png

ここから、クエリが発生した各トランザクショントレースと、クエリを生成しているソースコードの場所を確認することができます。

trace_slow.png

TL;DR

本番環境にあるRailsアプリは全て、スロークエリを抱えていますが、どの部分に最適化する時間を割くべきか把握するのは難しいと思います。Scoutは、そうした労力の優先順位をつけ、ソースやgitコミットまでクエリを追跡するのに役立ちます。

Scoutの14日間トライアルを活用し、ActiveRecordのスロークエリを探してみてはいかがでしょうか。