Railsアプリのパフォーマンス監査する上での5つのポイント

BY Derek Haynes

March 17, 2020

パフォーマンスについて話す前に、エントロピーについて話しましょう。エントロピーは通常、宇宙の全てが最終的に秩序から無秩序に変化していくという考えに言及します。エントロピーはその変化の測定値です。

エントロピーのように、Rails アプリケーションのパフォーマンスは無秩序になっていきます。

データベースクエリの N+1 問題、ページネーションの考慮がなされていない実装、インデックスの欠落など。

このパフォーマンス低下は時間とともに大きくなり、突然遅いアプリケーションとなって現れるのです。

slow sloth

どこからこのパフォーマンスの負債に対応していけばよいのでしょうか。全てが遅いというわけではありませんよね。Railsのパフォーマンスチェックを開始しましょう。

以下に記載する5つのパフォーマンス監査観点を10分前後で読むことで、アプリケーションがどのような状態にあるのか、そしてどこにフォーカスして対応を行うべきなのかが見えてきます。

それぞれのチェック観点では、実際に運用しているアプリケーションを例に解析していきます。各チェック観点の対応がなされていることを確認することができると思います。

PSA: Do not practice shotgun optimization

Railsを含むほぼ全てのアプリケーションは80対20の法則(パフォーマンスの問題の殆どは少量のアプリケーションコードによってもたらされている)が適用できます。これは素晴らしいことです。ほとんどの場合、コードベースをパフォーマンスハッキングで汚す必要がないということです。全てを最適化する必要はありません。

やるべきことは、運用監視ツールを用いて、パフォーマンスの問題点を見つけ出すことのみです。この記事では、Scout を利用し、パフォーマンス監査を行います。

運用監視ツールを利用せず対応ができるでしょうか。運用環境のバージョンの違いよる挙動の差異は、コードのリロード、些細なデータベース操作、トラフィックなしの状態、個別ユーザーのための開発環境に比べ、相当異なります。そのため運用監視ツールを利用しない選択肢はお勧めできません。

1. What's the general profile of the app?

アプリケーションの動作が遅いためこの記事を読まれていることと思います。では、まずあなたのアプリケーション応答時間を見ることから始めていきましょう。

Scoutではこちらがアプリケーションを参照するメインの画面になります。

この監査では、表示期間を初期設定から7日間に変更します。多くのアプリケーションには営業日のスループットが高いなどの時期的な傾向があり、表示期間を長く設定することでアプリケーションの標準的な状態を明らかにすることができます。

積み上がったバーのそれぞれの要素は各レイヤーを表しています。(例: データベース、外部からの HTTP 呼び出し、Ruby)。合計されたアプリケーションの平均的な応答時間が表示されていることになります。

サンプルアプリケーションはどうでしょうか。

非常に良い状態と言えます。

このアプリケーションはトラフィックと応答時間のピークが正午に来ていることから、平日に利用されているものと考えられます。

このピーク時間に応答時間は40ミリ秒 から 70 ミリ秒 へと増えますが、特にスケーリングの問題があるとは言えません。お客様はより重い処理を実行する場合はあまりアプリケーションが利用されていない時期を見計らって行うかもしれません。この点に中止、後ほど掘り下げていきましょう。

2. Where does the time go?

    一般的には、いくつかのレイヤーのみがWebリクエストへの応答時間のほとんどを担っています。時系列のチャートを見ることでこれらを絞り込むことが出来ます。これはどこにフォーカスし時間を割けばよいのかのヒントになります。

    リクエストがキューに保持される期間はあるか

    応答時間チャートには、QueueTimeという特別なチャートが存在します。ここではリクエストがロードバランサーに到達してからアプリケーションサーバー(例:Puma)で最初に処理が開始されるまでの時間を測定します。queue time

    この値は20 ミリ秒に維持する必要があります。もしこれが、20ミリ秒 を超えるようであれば、いずれかのレイヤーに容量の問題があると言えます。(アプリケーションサーバー、またはデータベースであることが一般的に最も多いです。)

    サンプルアプリケーションはどうでしょうか。

    3. Are we dealing with a cheetah or a sloth?

      サンプルアプリケーションのパフォーマンスプロファイルから素晴らしいイメージを得ることができました。それでは応答時間の数値を見て、どのくらいの問題が存在するのか見ていきましょう。時系列のScoutチャートの下に一連のスパークライン(個別グラフ)があります。ここに表示されている数値は表示期間内での平均値を表します。(今回の例の場合、7日間)response time sparkline

      はじめに、”Response TIME – MEAN”(平均応答時間)のスパークラインから見ていきましょう。応答時間を判断する目安は次のとおりです。

      リクエストごとの応答時間

      分類

      50ミリ秒未満

      速い

      50ミリ秒未満

      普通

      300ミリ秒以上

      遅い

      JSONコンテンツのみを返却するAPIサーバーの場合、応答時間はより小さくなります。恐らく、そのケースでは100ミリ秒は遅いと言えます。

      サンプルアプリケーションはどうでしょうか。

      応答時間は速いです。しかし平均応答時間だけでは全ての状態が良いとは判断しきれません。

      4. What's the spread of response times?

        単一の高スループットなレスポンスは、平均時間を大幅に短縮させることができます。平均時間ははじめに目を付ける箇所としては優れていますが、全体像を示してくれているとも限りません。より全体にわたってアプリケーションのパフォーマンスを把握するためには、95パーセンタイルの応答時間も大切になってきます。

        95th

        95パーセンタイルの応答時間は、応答時間の95%以下がこの数値よりも速いことを示しています。逆に、5%の応答時間がこの閾値を上回っていると言えます。95パーセンタイルの応答時間は、平均応答時間の4倍以下である必要があります。この比率が4:1を上回る場合、アプリケーションのコントローラーのアクションは大幅に応答時間を遅くしてしまう問題が含まれていると言えます。

        サンプルアプリケーションはどうでしょうか。

        95パーセンタイルの応答時間(162ミリ秒)は、平均応答時間(51ミリ秒)の3.2倍ほどです。これは4:1の比率以内には収まりますが、最大値に十分近いと言え、なにかしらの遅くなる原因がアプリケーションのコントローラーアクションに存在すると考えられます。

        5. How much traffic is the app handling?

        5.一般的にスループットが大きいほど、パフォーマンスは厳しくなると言われています。スループットが増加するにつれて、一般的にベースとなるサービスは複雑になっていき、パフォーマンス対応を行う際に、ビジネス上のトレードオフを考慮しなければならないシーンが多くなります。(例:エンドポイントが、高額で契約してくれている単一の上顧客に対し遅い場合など。)

        一般的な指標:

        1分あたりのリクエスト(rpm)

        規模

        50回以下

        小さい

        50回から500回以下

        平均

        500回を超える

        サンプルアプリケーションはどうでしょうか。

        平均スループットは240rpm最大350rpmです。これはスループットの点に関しては平均的なアプリケーションと言えます。しっかりと見ていくべき箇所があります。

        Your 5-point Rails performance audit cheatsheet

        Rails アプリケーションの5つの監査チェックリスト

        これで、アプリケーションのパフォーマンスを健全に保つためのしっかりとした観点がわかりましたね。これらはこの記事の中で登場した確認ポイントです。

        1. アプリケーションの標準的な状態とは。一日の中に明らかに多く利用されるタイミングがあるか。ピークタイムにアプリケーションは激しく遅くなることがあるか。
        2. どこに時間を要しているのか。主な原因となる要素はいくつかしかない(Ruby やActiveRecordなど)。容量の問題が示唆されるようなQueueTime 20ミリ秒を超えるタイミングがあるか。
        3. 応答時間は速いのか(50ミリ秒未満)、普通なのか(300ミリ秒未満)、遅いのか(300ミリ秒以上)。
        4. 95パーセンタイルの応答時間は平均応答時間の4倍以上になってはいないか。そうではなく、応答時間が一般的に良好であっても、多少は遅い問題のある箇所が存在するかもしれません。
        5. アプリケーションは小さいのか(50 rpm未満)、普通なのか(50-500 rpm)、大きいのか(500 rpmを超える)。アプリケーションが大きければ大きいほどパフォーマンス対応は大変になります。

        What's Next

        もしご興味ありましたら、support@scoutapm.comまでご連絡ください。

        ここまで、閲読頂きありがとうございます!犬のイラストをクリックしていただきますと無料でScout関連商品をお届けします

        doggo-chill.png