【後編】AppSignalでRuby on Railsアプリのパフォーマンス・ログ・アップタイムを効率的に監視する

はじめに

本記事シリーズの前編では、シンプルなRuby on RailsアプリケーションをDigitalOceanのApp Platformにデプロイし、AppSignalと連携させることで、エラーがどのようにトラッキングされ、Errorsダッシュボードに表示されるかを確認しました。

後編となる本記事では、AppSignalを使ってRuby on Railsアプリケーションに以下の機能をセットアップする方法を詳しく解説します。

• パフォーマンス監視
• Railsのバックグラウンドジョブ監視(シンプルなAPI呼び出しの監視方法も含む)
• ロギング
• 通知アラート

それでは始めましょう!

AppSignalによるRailsアプリのパフォーマンス監視

稼働時間(アップタイム)モニターが「アプリは稼働中」と表示していても、すべてが順調だと思い込むのは危険です。実際には、遅いプロセス、最適化されていないデータベースクエリ、長時間かかるサービス呼び出しなど、水面下で問題が進行している可能性があります。

Webページの読み込みが遅いと訪問者のコンバージョン率が低下するという相関関係があることを考えると、これは非常に重要な問題です。要するに、放置すれば遅いプロセスはビジネスに大きな損失をもたらします。しかし、Ruby on Railsアプリには多くの構成要素があるため、「何を、どこを見ればよいのか?」というのが重要な問いになります。

そこで活躍するのがAppSignalです。AppSignalを使ってRailsアプリのパフォーマンスを追跡する方法を見ていきましょう。

レスポンスタイムの追跡

デフォルトのダッシュボードでは、Railsアプリの動作の速さ(または遅さ)をひと目で把握できる2つのグラフ、Throughput(スループット)とResponse time(レスポンスタイム)が提供されます。

• Throughput(スループット) - アプリが現在処理している1秒あたりのリクエスト数を測定します(アプリ全体で処理できるリクエスト数とは異なる点に注意)。基本的な目安として、1秒あたりのリクエスト数は多いほど良いと言えます。ただし、アプリサーバーが捌いているリクエスト数が多すぎると感じたら、サーバーリソースのスケールアップを検討すべきタイミングかもしれません。
• Response time(レスポンスタイム) - ブラウザへの応答にかかる平均時間(ミリ秒)。応答に時間がかかるほど、アプリの動作は悪化しています。目安としては、Rails Webアプリのレスポンスタイムが100ms未満なら高速、300ms以上なら遅いと判断できます。

ここで、7日間の期間でアプリのレスポンスタイムとスループットを追跡したいとしましょう。これはとても簡単です。左側メニューのPerformance配下にあるGraphsサブメニューに移動し、グラフ上部の時間フィルターボタンを使用するだけです。以下をご覧ください。

これにより、特定の日にアプリの動作が遅くなっていないかを簡単に確認できます。

また、この画面でResponse timeとThroughputグラフの下にあるEvent groupsグラフもチェックしておきましょう。

このグラフからは、コントローラーレイヤーとビューレイヤーそれぞれにおけるアプリの動作速度の詳細を確認できます。ここから、レスポンスタイムが遅くなっている原因を突き止め、適切に対処することが可能です。

次に、AppSignalを使ったデータベースクエリの追跡に話題を移します。

データベースクエリの追跡

レスポンスタイムとスループットを最適化することでアプリの速度を大きく改善できるのは一般的に事実ですが、多くの場合、動作の遅いアプリの最大の原因となっているのは、最適化されていない遅いデータベースクエリです。

悪名高いN+1クエリを例に取りましょう。前編で紹介した経費管理アプリでは、expensesコントローラーのindexメソッドは次のようになっています。

一見無害に見えますが、AppSignalダッシュボードのIssuesリストを見てみると、興味深いものが表示されます。

expensesコントローラーのindexメソッドでN+1クエリが検出されています。

問題のリンクをクリックしてさらに掘り下げると、次のようなIssue details画面に移動します。

AppSignalが問題の解説を提供してくれている点に注目してください。対処方法を示す、より詳しいブログ記事へのリンクまで含まれています。

続いて、AppSignalがバックグラウンドジョブの監視にどのように役立つかを見ていきましょう。

AppSignalでRailsのバックグラウンドジョブを追跡する

バックグラウンドジョブは、本番環境の多くのRuby on Railsアプリケーションで使われる一般的な機能であり、選択できるジョブキュー処理用のgemやライブラリも多岐にわたります。

AppSignalは、Sidekiq、Que、Delayed Job、Resqueなど、さまざまなバックグラウンドジョブ処理ライブラリのトラッキングと監視をサポートしています。

ここでは、ユーザーのダッシュボードに毎日の為替レートを表示する機能を作りたいとします。

これを実現するには、為替レートを提供する外部サービスへのAPI呼び出しが必要です(初期設定や支払いの手間が少ないサービスを利用します)。さらに、このサービスへの呼び出しを定期的にキューイングするバックグラウンドジョブも必要になります。

経費管理アプリで使用するバックグラウンド処理gemはGoodJobですが、用途に合ったものであれば何を使っても構いません。

為替レートを取得するバックグラウンドジョブを作成しましょう。

そして、GoodJobにこのジョブを数分ごと(または任意の間隔で)実行するcronを設定します。AppSignalはバックグラウンドサービスの存在を自動的に検出し、デフォルトのWebダッシュボードと切り分けるための便利なフィルターを提供してくれます。

事前に特別なツール設定をしなくても、AppSignalはAPI呼び出しを検出し、発生した問題を追跡してくれます。

AppSignalによるRailsバックグラウンドジョブの監視についてさらに詳しく知りたい方は、公式ドキュメントを参照することをおすすめします。ここからは、アップタイム監視に目を向けましょう。

アップタイム監視

多くのRails開発者が気にするもう一つのポイントは、エンドユーザーに対するアプリケーションの継続的な可用性です。ダウンタイムは収益の損失やその他の悪影響をもたらしかねません。

とはいえ、アプリの稼働状況を手動でポーリングしたくはないでしょう。そこで、AppSignalを使えばアップタイム監視を簡単に設定できます。

設定は非常に手軽です。まず、左側メニューのUptime monitoringリンクをクリックします。

次に、create uptime monitorボタンをクリックすると、下図のようなダイアログが表示されます。

重要な設定項目を入力してアップタイムモニターを完成させましょう。

• Name - アップタイムモニターに適切な名前を付けます。
• URL - アップタイム確認用ルートへの完全なURLを指定します。Rails 7.1以降、デフォルトのアップタイムルートはhttps://your-app-domain/upです。
• Region - 稼働状況をチェックしたいリージョンを選択します。
• Notification - アラートを受け取る通知チャンネルを選択します。

これで準備完了です。モニターを作成しましょう!

AppSignalのアップタイムモニターに関する注意点として、ポーリングはほぼ1分ごとに行われるため、プランの上限に達しやすいという点が挙げられます。ただし、これには非常に有効な回避策があり、詳細は公式ドキュメントで確認できます。

AppSignalのロギング機能に進む前に、アップタイム監視レイヤーを完成させるもう一つの重要な機能、無料の公開ステータスページを紹介します。

下図のようにcreating a public status pageリンクをクリックします。

次にNew status pageボタンをクリックすると、次の画面に移動します。

必要な情報をすべて入力してください。カスタムドメインを使用する場合は、カスタムドメインのDNS設定にcname.appsignal-status.comを指すCNAMEレコードを追加する必要がある点に注意してください。

AppSignalでのロギング

ロギングはAppSignalの比較的新しい機能ですが、待ち望まれていた機能の一つです。AppSignalを使えば、アプリケーション監視とロギングを別々のサービスとして運用する必要がなくなります。

ロギングを始めるには、最新バージョンのAppSignal gemを使用していることを確認してください。古いバージョンの場合は、次のコマンドで更新できます。

次に新しいイニシャライザーを作成し、以下のように編集します。

これで、次のようにアプリのログにアクセスできるようになります。

ログレコードを重大度で絞り込める便利なフィルター機能に加えて、ライブログにもアクセスできる点に注目してください。

AppSignalのRuby向けロギング機能の詳細については、公式ドキュメントを参照してください。

その他の注目機能

AppSignalには、他にも注目すべき機能が2つあります。異常検知とカスタムメトリクスです。

異常検知(Anomaly Detection)

例えば、アプリのメモリ不足が心配だとしましょう。利用可能なメモリに顕著な低下があった場合にメール通知を送るトリガーを簡単に設定できます。

Anomaly detectionリンクに移動して新しいトリガーを作成し、設定を行います。

• Metric - 今回のケースではメモリ使用量に関心がありますが、ユースケースに応じて他の任意のメトリクスを選択できます。
• Trigger details - ここでトリガーに関連する詳細を設定します。今回の例では、ホストのメモリが200MBを下回るとトリガーが発火するようにしています。

カスタムメトリクス(Custom Metrics)

AppSignalには、独自のカスタムメトリクスを収集して可視化するためのツールも用意されています。この機能だけで記事が一本書けるほどの奥深さがあります。詳しくは「How to Monitor Custom Metrics with AppSignal」やAppSignalの公式ドキュメントを参照してください。

まとめ

本シリーズの前編では、DigitalOcean上でホストされるRailsアプリをセットアップし、AppSignalを使ってエラーを監視しました。

後編となる今回は、パフォーマンス監視、アップタイム監視、ロギングなど、RailsアプリのためのAppSignalの優れた機能をいくつか紹介しました。

AppSignalには、本シリーズで取り上げた以外にもまだまだ多くの機能があります。ぜひあなたのRailsアプリで試してみることを強くおすすめします。

それでは、Happy coding!

P.S. Ruby Magicの記事を公開と同時にお読みになりたい方は、Ruby Magicニュースレターを購読して、記事を見逃さないようにしましょう!