rack-mini-profilerとフレームグラフでRailsアプリのボトルネックを可視化する方法

あなたのRailsアプリは遅くなっていませんか？

本来シンプルに表示されるはずのビューの読み込みに数秒かかるなら、原因を掘り下げて調査すべきサインです。

原因としては、データベースへの呼び出しが多すぎたり、処理の遅いメソッドがあったり、あるいは誰かがコードに仕込んだまま忘れられてしまった無駄なループだったりします。

アプリの遅さの原因を突き止めるためのツールは数多く存在します。以前このブログでもrbtraceについて紹介しましたし、New Relicのrpm gemもアプリの高速化に役立ってくれました。

しかし、私がパフォーマンス問題の調査に最も愛用しているツールは、それ以上のことができるのです。導入するだけでコードが何をしているのかを表示してくれますが、プラグインを追加するとさらに強力になります。アプリのパフォーマンス問題を目で見て把握できるようになり、遅いアプリをより速く発見して修正できるようになるのです。

私のお気に入りのRailsプロファイラ

私のお気に入りのRailsパフォーマンスツールはrack-mini-profilerです。このgemをアプリに追加すると、各ページに小さなインジケーターが表示されるようになります。

そのボックスをクリックすると展開され、さまざまな有用な情報を確認できます。どのSQL文が実行されたのか、パーシャル（部分テンプレート）のレンダリングにどれだけ時間がかかったのかなどです。

MiniProfilerは、各ページの読み込みにかかる時間を常に意識させてくれるのが大きな魅力です。これにより、アプリのパフォーマンスについて直感的な感覚を養うことができます。どのページが遅く、どのページが速いのかが自然とわかるようになり、ページのレンダリングに異常に時間がかかっていることにすぐ気づけるようになります。そして、記憶に新しいうちにすぐ修正に取り掛かれるのです。

MiniProfilerにはさらに多くの機能があります。ただし、その前にflamegraph gemをインストールする必要があります。

そうすることで、アプリのパフォーマンスを見るまったく新しい方法が手に入ります。

フレームグラフ：名前の通りの面白さ

フレームグラフ（Flamegraph）は次のような見た目をしています。

名前の由来が一目瞭然ですね。

rack-mini-profiler gemとflamegraph gemをインストールすれば、任意のリクエストに対してフレームグラフを表示できます。HTTPパラメータとしてpp=flamegraphを追加するだけでOKです。

https://www.example.com/restaurants?pp=flamegraph

フレームグラフが表示されたら、ズームイン・ズームアウトしたりスクロールしたりしながら、興味深い箇所を探してみましょう。

フレームグラフの各「レイヤー」は、スタックトレースの1行に対応しています。

そして横軸は時間を表します。グラフの左端がリクエストの開始時点、右端がリクエストの完了時点です。

確かに見た目はクールですが、実際に何に活用できるのでしょうか？

フレームグラフの活用方法

X軸が時間を表しているため、アプリのどこがボトルネックになっているのかを非常に明確に把握できます。最も幅の広いレイヤーほど実行に時間がかかっている箇所です。そこが最初に調査すべき領域であり、そこを高速化できれば最大の効果が得られます。

ビューのレンダリングにどれくらいの時間を使っていますか？ コントローラのアクションでは？ データベースへのアクセスでは？ パーシャルの描画では？

こうしたことはすべて、視覚的に簡単に確認できます。

さらに、フレームグラフにはもうひとつ便利な使い方があります。

同じような高さのスパイク（尖った山）がいくつも並んでいるように見えませんか？

それは多くの場合、N+1クエリが発生しているサインです。どこかにincludesを付け忘れているか、APIへ大量の呼び出しを行っている可能性があります。includesを追加すれば、フレームグラフは次のように変わるはずです。

N+1のSQLクエリであれば、ほとんどのパフォーマンスツールで似たようなSQL呼び出しを探すことで比較的簡単に発見できます。しかし、SQL以外のN+1問題、たとえばAPIへの過剰な呼び出しなどは、気づくのがはるかに難しいものです。ログの品質があまり高くない場合は特にそうです。

フレームグラフを使えば、こうした問題も格段に見つけやすくなります。

見なくていい部分

フレームグラフは情報量が膨大で、圧倒されがちです。すべての情報を一度に受け入れざるを得ないため、「何を無視すればいいのか」を知っておくことが重要です。

通常、グラフの最下部と最上部のレイヤーはスキップして構いません。私はグラフの中間あたり、あるいは上から3/4あたりから探索を始めます。自分のコードはだいたいそのあたりに現れるからです。

グラフの上部は主にActiveRecordやIO関連の処理、下部はRailsフレームワークのコードが占めるため、あなた自身のコードは中間あたりに位置するのが自然だからです。

フレームグラフを使ったことはありますか？ 最適化すべき箇所を見つけるのに非常に優れた手段です。ぜひ試してみてください！ Gemfileにrack-mini-profilerとflamegraphを追加するだけで、コードのパフォーマンスに関する洞察が驚くほど深まるはずです。