Rubyアプリの監視を最も簡単に実現する方法：自動インストルメンテーション

アプリケーションのパフォーマンスを適切に監視できる体制を整えるのは、決して簡単な作業ではありません。通常であれば、まず「何を監視すべきか」を把握し、次にコードへインストルメンテーションを組み込み、最後に送信されてきた大量のデータを読み解くという手順を踏む必要があります。

しかし、必要な準備が整っており、RubyをネイティブにサポートするAPMを活用すれば、このステップはかつてないほど簡単になります。本記事では、その具体的な方法をご紹介します。

自動インストルメンテーション ― 手間ゼロのAPMセットアップ

コードのどの部分がパフォーマンス問題の原因になっているのかを突き止めるには、コードにインストルメンテーションを追加する必要があります。そうすることで、すべてのアクションを分解し、どの処理が最も遅いのかを正確に測定できるようになります。

AppSignalの自動インストルメンテーションなら、手作業をできる限り削減できます。CLIからいくつかのコマンドを実行するだけで、セットアップは完了です。

監視エージェントがインフラの各構成要素を自動的に検出し、インストルメンテーションを行います。これにより、AppSignalはデータを取り込んで処理・監視し、本当に必要なグラフやダッシュボードを表示できるようになります。

たとえばRubyのgraphql gemを使用している場合、AppSignalは受信したすべてのGraphQLリクエストを計測し、リクエスト内の全イベントの詳細な内訳を提供します。

標準対応（アウト・オブ・ザ・ボックス）のインストルメンテーション

AppSignalがサポートしているツールの一覧は以下のとおりです。かなりの充実ぶりです。

ご覧のとおりリストは非常に長いため、本記事ではすべてのツールを深掘りしては紹介しません。主要なカテゴリごとにポイントを押さえて解説します。

WebフレームワークとAPI

AppSignalは、Ruby on Rails、Padrino、SinatraにおけるWebリクエストのインストルメンテーションを標準でサポートしています。さらに、Grapeやgraphql gemを使用したAPIにも対応しています。

Ruby on Rails

Rails向けのAppSignal統合は、リクエスト内の例外とパフォーマンスを追跡することで機能します。リクエスト処理中にコントローラでエラーが発生すると、AppSignalがそれを自動的にレポートします。パフォーマンスの問題はリクエストの所要時間に基づいて検出され、アプリケーションのどの部分に最も時間がかかったかを詳示するイベントタイムラインが作成されます。

さらに、ロードバランサーやWebサーバーを経由してHTTPリクエストがRailsアプリに到達するまでの時間（キュー時間）も追跡可能です。デフォルトで有効になっていない場合は、リクエストキュー時間のトラッキングヘッダーを設定するだけで、AppSignalが自動的にキュー時間をグラフ化してくれます。

GraphQL

AppSignalはRuby用のgraphql gemをサポートしています。受信したすべてのGraphQLリクエストを計測し、リクエスト内の全イベントの内訳を提供します。パース、バリデーション、リゾルバの実行にそれぞれどれだけの時間がかかったのかをひと目で確認できます。もちろん、アプリのWebフレームワークからのイベントやデータベース呼び出しもこの内訳に含まれます。

処理に時間がかかるGraphQLクエリをデバッグしたいものの、ボトルネックがどこにあるのか分からない――そんな場合に非常に役立ちます。加えて、異常検知トリガー（Anomaly Trigger）もぜひ活用してください。クエリ時間が一定のしきい値に達した時点でアラートを発報できるため、問題の早期発見につながります。

Sinatra、Padrino、Grape

Sinatra、Padrino、GrapeはRubyのWeb/APIフレームワークで、さまざまな形でアプリの一部となります。スタンドアロンアプリとして使われることもあれば、大規模なRailsアプリにマウントされることもあります。Webサーバーへのマウント方法によっては、それぞれ異なるインストール手順が必要になる場合があります。

一度インストールしてしまえば、Sinatra、Padrino、Grapeへのリクエストはすべて自動的に計測されます。トラフィックがAPIに届くと、エラーとパフォーマンス測定値がレポートされます。各（API）エンドポイントはAppSignal上で個別のアクションとして扱われるため、どのエンドポイントでどのエラーが発生したのかを簡単に特定できます。Railsアプリと同様に、パフォーマンスの内訳から、どのデータベースクエリやアプリのどの部分が他よりも遅かったのかを把握できます。

データベース

Active Recordおよびその他のORM

リクエストがデータベースへのクエリにどれくらいの時間を費やしたのかを確認するには、インシデント詳細ページを開きます。ページ上部には、リクエスト内で記録されたイベントの種類がグループごとに内訳表示され、どの種類の操作に合計でどれほどの時間がかかったのかが一目でわかります。

さらに詳しく分析したい場合は、ページ下部にあるイベントタイムラインを確認しましょう。ここにはリクエスト内のすべてのイベントが発生順に時系列で並んでおり、実行された各クエリの概要と、どのクエリに最も時間がかかっているのかを正確に把握できます。

この統合機能によりデータベース呼び出しのトレースが表示されるため、問題の元凶（あるいは優れた功績）となっているクエリを特定できます 😉

N+1クエリ

「リクエスト内でN+1クエリが発生していて、それがレスポンス遅延の原因なのでは？」と心配になっていませんか？ AppSignalはN+1クエリを自動検出し、該当するイベントに対してイベントタイムライン上に警告を表示します。

Redis

Redis統合を利用すると、Redisへの呼び出しがイベントタイムラインに表示されます。

さらに、Redisに送信されたコマンド名や、クエリの送信先となったRedisインスタンスのアドレスも確認できます。

実行時間の長いRedisキャッシュ呼び出しをデバッグしたい方にとって、これは嬉しい機能です。さらに異常検知トリガーを設定すれば、極端に長時間かかるリクエストに対してアラートを送ることさえ可能です！

バックグラウンドジョブ

Sidekiq、Delayed::Job、Resque、Shoryuken、Queでバックグラウンドジョブがキューに入ると、AppSignalが自動的にエラーとパフォーマンス測定値をレポートします。すべてのActive Jobアダプターにも対応しており、SidekiqやDelayed::Jobなど一部のライブラリについては、ライブラリ自体から取得できる追加のメタデータまでレポートされます。

Action Mailerによるメール送信

Action Mailerを使用するRailsメーラーがdeliver_laterに設定されている場合、そのメール送信もActive Job経由でルーティングされるため、同じレベルのインストルメンテーションが自動的に適用されます。

WebSocket

RailsアプリでAction Cableを使用していますか？ AppSignalは、メッセージとサブスクリプションに関するエラーとパフォーマンス測定値を自動的にレポートします。すべてのメッセージが個別に計測されるため、長時間稼働するチャンネルでもすべてのアクティビティが漏れなく記録されます。アクションごとにグループ化して表示されるため、個々のアクションのパフォーマンス状況を明確に把握できます。

👋 この記事が気に入った方は、「Rubyパフォーマンス監視チェックリスト」に掲載されている他のRuby（on Rails）パフォーマンス関連記事もぜひご覧ください。

AppSignalを試してみよう：簡単で快適なモニタリング 🍪

私たちは過去7年間にわたり、数千人の開発者がコードを自動的にインストルメントできるよう支援してきました。あなたにもぜひ体験してみてほしいと思います。導入を検討される際はお気軽にご連絡ください。オランダ名物のストロープワッフェルの箱も無料でお送りします。

PS. 素晴らしいOSSプロジェクトで世界に貢献している開発者の方には、無料のAppSignalアカウントでお返ししています。大切に思うメンテナーの方々に、ぜひこの情報を広めてください！