Rails + New Relic ならレスポンスタイム等のパフォーマンス監視が簡単にできるよ

前回の「いまどき Rails で何かつくるなら、VPS より Sqale（スケール）だと思うの」に続いて、今回も Rails で何かつくってみようという人向けのエントリーです。

下記のようなレスポンスタイムを表すグラフ等が見られるようになる Web サービス「New Relic」を紹介します（上記 Sqale の環境にも導入できます）

べつに Rails じゃないと使えないわけではないのですが、Rails だと導入があっけないくらい簡単で、Rails を使って開発する人には特にオススメなので。

-New Relic : Web Application Performance Management (APM) & Monitoring

**Rails + New Relic ならレスポンスタイム等のパフォーマンス監視が簡単にできるよ

用語の整理パフォーマンス監視とリソース監視とサーバ監視
レスポンスタイムとユーザ体験
サーバサイドのレスポンスを 200ms 以内で返すという目標
New Relic の導入
非常に悩ましい無料プランと有料プランの差
New Relic でリソース監視もできる
GrowthForecast 等のオープンソースのツールとの使い分け -おわりに <<

*1. 用語の整理パフォーマンス監視とリソース監視とサーバ監視

さて、タイトルにパフォーマンス監視と書きましたが、似たような用語がいくつかあるので、あらかじめ整理しておきます。

**(1) リソース監視

だいたい監視っていうと、CPU 使用率とかメモリ使用率とかロードアベレージとかそういうのをチェックすることを思い浮かべる人が多いかもしれません。

これはきちんと正常に動作しているか、負荷がかかり過ぎていないかを調べるという目的のためにやります。で、上記のような項目を監視することをリソース監視といいます。

**(2) パフォーマンス監視

正常に動作していることを前提として、さらにどのくらいのパフォーマンスを出しているのか。具体的にはどのくらいの速度でレスポンスを返しているかを監視することをパフォーマンス監視といいます。

リソース監視と較べて、目的がもっとビジネス寄りで、パフォーマンスを上げてもっと良いサービスにしたいとか、何かの機能追加がきっかけでやたら重くなっていないかとか、パフォーマンスチューニングの前後で特に気にしたりとかそんな感じで監視します。

**(3) サーバ監視

厳密な定義があるのかどうか分かりませんが、よく見かける文脈では、リソース監視の内容ととパフォーマンス監視の内容と、あとサーバが生きてるのか死んでるのかの死活監視とを合わせてサーバ監視と呼ばれています。

*2. レスポンスタイムとユーザ体験

また、パフォーマンス監視をして、どのような結果だったらどのように対応すれば良いのかの参考として、レスポンスタイムとユーザ体験との関係についても触れておきます。

この点、Web サイトにおけるユーザビリティの第一人者である Jakob Nielsen さんによる説明がよく参照されているようなので、引用。

**0.1秒

ユーザがオブジェクトを「直接」操作していると感じる時間の限界。操作したインターフェイスが 0.1秒以内に操作結果を示せば、ユーザは待ち時間を感じず、その対象を直接操作しているように感じる。

**1秒

ユーザが待ち時間を感じつつも、軽快に操作できる時間の限界。0.2秒から1秒の時間で反応を返せば、ユーザは「コンピュータが計算している」と感じはするが、ユーザの操作に対象が直接反応したと感じる。1秒以上ユーザを待たせるのであれば、カーソルの形状を変えるなどして、計算中であることを知らせるべき。

**10秒

実行中のタスクに対してユーザの注意を引き付けることができる限界。10秒以上待たせるのであれば、何パーセント進捗したのかをユーザに明示するべき。

上記の文章は1993年のもので、当時の Web は現在とはずいぶん事情が異なりますが、2012年の現在においても十分に参考に値する数字であり、考え方であると... <<

（上記文章は、次の雑誌から引用しました）

WEB+DB PRESS Vol.70

作者: 成田一生,高津戸壮,はまちや2,佐藤裕介,久森達郎,大窪聡,本田謙,和田英一,天野祐介,藤吾郎(gfx),奥野幹也,川添貴生,Dr.Kein,近藤宇智朗,後藤秀宣,mala,中島聡,森田創,堤智代,A-Listers,WEB+DB PRESS編集部
出版社/メーカー: 技術評論社
発売日: 2012/08/24
メディア: 大型本
購入: 8人クリック: 89回
この商品を含むブログ (15件) を見る

*3. サーバサイドのレスポンスを 200ms 以内で返すという目標

前述の Jakob Nielsen さんの説明に対して、自分の経験上では、よほどシンプルなサービスでない限り、0.1秒以内にレスポンスを返すことは難しいと思います。とはいえ、ブラウザのレンダリングを含めて、1秒でスパンッ！と表示されると、おお早ええ！と感じると思うので、そこを目指したい。

いいね！ボタンやツイートボタン等を設置すると、そのボタンの表示に数秒かかったりするので「ブラウザがすべて表示してしまうまで」の時間はあまり監視していないのですが、画面のメイン部分が 1秒以内に表示させるようにするため、サーバサイドのレスポンスは、200ms くらいで返したいと考えています。

情報が少し古いですが、クックパッドで 200ms 以内にサーバサイドのレスポンスを返すという目標を立てているという事例もありました。

-AWS クックパッドの運用事例

*4. New Relic の導入

ちょっと前置きが長くなってしまいましたが、Rails3 でかつ Bundler を使っている人向けに New Relic の導入方法に簡単に触れておきます。それ以外の人でもやり方は公式サイトに書いてあります。

**(1) ユーザー登録

New Relic の公式サイトから、sign up

**(2) gem をインストール

Rails3 で Bundler を使っている人にとっては、いつものやり方です。Gemfile に

|ruby| gem 'newrelic_rpm' ||<

と書いて、bundle install すればおｋ

**(3) 設定ファイルを設置

公式サイトにログインして newrelic.yml をダウンロードしてくる。Rails の config ディレクトリに置く。

以上です。1、2分したら、グラフが描画されます。もう、ほんと、あっけないくらいです。

*5. 非常に悩ましい無料プランと有料プランの差

ただ、導入は非常に簡単なのですが、非常に悩ましいのが無料プランと有料プランの差です。できることの差が結構ありまして。いや、それだけなら有料プランを選べば良いのですが、これがなかなかどうして結構料金が高いのです。

無料プランだと、監視データを保持できる時間が30分しかなくて、1週間分見たかったら、月額24ドルの Standard プランにする必要があります。さらにその上の、監視データを無制限に保持できる Pro プランだと月額149ドル...

また、データベースで処理するクエリの中で、どのクエリに時間がかかっているかを監視できる機能が非常に便利なのですが、これも Standard プラン以上でないと利用できません。

自分がどのプランを選ぶかは、1か月の体験期間中に Pro プランと同様のことができるので、その間に検討するのがよいと思います。

ちなみに僕自身は現在無料プランを利用していますが、それはいま個人で運用している Web サイト babyshark が、サーバサイドのレスポンスをだいたい 150ms 前後で返すことができていて、いまはそこまでパフォーマンスの改善に注力する必要性を感じていないからです（その分のエネルギーを他へ回す）

それが、もっとアクセスが増えたり機能を追加したりして、サーバサイドのレスポンスタイムが 500ms を超えるようになってきたら、遅いクエリ等を監視できる Standard プランに上げて、どんどんチューニングを施していきたいと考えています。

*6. New Relic でリソース監視もできる

あ、それと、New Relic はメインはパフォーマンス監視なのかもしれないですが、yum 等で専用のパッケージを入れると、下記のようなリソースも監視できます。

-CPU 使用率 -メモリ使用率 -ロードアベレージ -Disk I/O -Network I/O -プロセス

リソース監視は無料プランでもできます。

*7. GrowthForecast 等のオープンソースのツールとの使い分け

ところで、リソース監視ならば以前から Munin 等オープンソースのツールが広く使われていますし、パフォーマンス監視も、最近では GrowthForecast と Fluentd を組み合わせたりするのが流行っているようです。