Magic Dashboards で Ruby アプリのパフォーマンス監視を強化

アプリケーション チームは、顧客エクスペリエンスがどのようなものかを理解する必要があります。これは、一般的な観点（ユーザビリティと応答性の観点）だけでなく、日々の分単位の観点からも当てはまります。

特に、分散システムを使用する場合、エラーは避けられません。サイトのトラフィックは 1 日を通して変動し、システムの依存関係のいずれかにいつでも問題が発生する可能性があります。

この記事では、マジック ダッシュボードを使用して、Ruby on Rails アプリケーション内のパフォーマンスの問題を監視し、解決します。

ただし、マジック ダッシュボードに入る前に、アプリを設計するときに何に注意すべきかを見てみましょう。

Ruby アプリを構築する際に考慮すべきこと

アプリケーションの所有者またはチームのメンバーは、顧客が問題を起こす前にアプリケーションに問題があるかどうかを知りたいと思うでしょう。これにより、直ちに是正措置を講じることができ、ユーザーへの混乱を避けることができます。

アプリケーションに関する重要な質問がいくつかあり、いつでも答えられるようにしておく必要があります。

• ページの応答時間は許容範囲内ですか? Google によると、最近では 2 秒よりも遅いと、顧客はサイトを離れて他の場所に移動してしまうとのことです。
• ユーザーは何かエラーを経験していますか?ある場合、どのような種類のエラーがありますか?エラー率とは何ですか?
• 現在進行中の運用上の問題がアプリケーションに影響を及ぼしていますか?これは、ネットワーク、ストレージ、またはセキュリティ サービスに関係している可能性があります。ご存知のとおり、クラウド プロバイダーではサービス停止が発生し、アプリケーションの健全性にも影響を及ぼします。

可観測性は重要ですが、多くの場合、エンジニアはそれを最後に考えます。さらに、運用準備のための時間がすでにスケジュールに組み込まれています。これは製品発売前の週末と呼ばれます。

冗談はさておき、監視すべきものが存在する前に、まずアプリを構築する必要があります。これは、開発ライフサイクルの終わり近くまでパフォーマンス テストを遅らせることにつながります。製品のコードが完成していないときは、パフォーマンス テストにあまり時間をかけたくありません。後で最初からやり直すことになるからです。

セキュリティテストについても同様です。実施するのが早すぎると、テスト後でも製品が本番環境に入る前に脆弱性が侵入する可能性があります。

したがって、監視が重要であることはわかっていますが、これらの懸念はすべて正当な点です。モニタリングは、プロセスの後半になるまで、それに値する注目を集めることはありません。それが、AppSignal が魔法のダッシュボードを作成した理由です。

AppSignal のマジック ダッシュボード

AppSignal は、メトリクス、ダッシュボード、アプリのパフォーマンスの重要性を理解していますが、エンジニアがリリース前にこれらに取り組む時間が最小限であることも理解しています。

当社のマジック ダッシュボードは、アプリと統合コンポーネントを接続するだけで、メトリクス コレクションと関連するダッシュボードが自動的に作成されるため、「マジック」と呼ばれています。

Magic Dashboards:Ruby on Rails アプリの例

マジック ダッシュボードを使用して、Ruby on Rails アプリ内のパフォーマンスの問題を監視し、解決する方法を見てみましょう。

私たちのアプリケーションは、暗号通貨の価格予測に単純な機械学習 (ML) モデルを使用します。非同期ジョブは、最新の価格データでモデルを毎日更新し、時間の経過とともに精度を向上させます。以下のアーキテクチャ図に示すように、この Rails アプリには Web ページと REST API の両方があります。

Rails アプリをデプロイすると、Rails Puma Web サーバーと Sidekiq 非同期ジョブ用にマジック ダッシュボードが自動的に作成されます。マジック ダッシュボードでサポートされているその他の統合には、MongoDB や Erlang VM などがあります。

Puma マジック ダッシュボードを使用して、スレッド、プール容量、および Puma ワーカーに基づいてパフォーマンスを評価できます。 Sidekiq マジック ダッシュボードは、キューの長さ、キューのレイテンシ、ジョブの継続時間、ジョブのステータス、メモリ使用量を監視します。

Magic ダッシュボードは、Sidekiq ジョブの実行や分単位のプローブなどのイベントベースのメトリクスの使用に基づいて検出および作成されます。分単位のプローブ機能を使用すると、Ruby ブロックまたはクラスを登録してカスタム メトリクスを AppSignal に送信できます。 Magic ダッシュボードは、サポートされているコンポーネントに対してすぐに使用できる統合を提供しますが、このメカニズムを利用してカスタム メトリクスを AppSignal に送信できます。

カスタム Minutely プローブの例

Sidekiq 統合はすでに組み込まれていますが、独自のバックグラウンド ジョブ メカニズムを監視したいと想像してください。次のクラスの例を使用できます。プローブ クラスは接続を取得し、各呼び出しでこの接続を使用して必要なメトリクスを取得します。

Appsignal::Minutely.probes.register への呼び出し プローブとその実装の名前という 2 つのパラメータを取ります。パラメータはラムダまたは呼び出しメソッドを実装するクラスのいずれかです。

AppSignal の構成とシステム要件

Rails アプリケーションで AppSignal を使用するだけで、魔法のダッシュボードを取得できます。 AppSignal をまだインストールしていない場合は、Gemfile に appsignal gem を含めてバンドル インストールを実行します。

次に、appsignal install を実行します。 コマンドを使用して環境を構成します。この構成は構成ファイルまたは環境変数に保存でき、アプリケーションを AppSignal アカウントおよびダッシュボードに接続します。

サーバーをインストールして実行すると、次のようなメールがいくつか届きます。

この例のシステム要件は次のとおりです。

• AppSignal gem 2.9.0 以降。これには、詳細なプローブのサポートが含まれます。
• Puma の統合 - バージョン 3.11.4 以降が必要です。
• Sidekiq の統合 - Redis gem 3.3.5 以降が必要です。この統合には、AppSignal gem 2.9.5 以降が推奨されます。

価格予測 API のパフォーマンス テスト

上記のサンプル アプリケーションは、Ruby FANN gem を使用して実装された単純なニューラル ネットワークを使用して、翌日のビットコイン価格を予測します。過去 10 日間の価格変化の割合がモデルへの入力として使用されます。

REST API は現在、明日の価格を予測するだけであるため、パラメーターを受け取りません。出力は、以下に示すような単純な JSON ドキュメントです。

Sidekiq ジョブは、毎日の初めに市場価格を取得し、ML モデルを更新します。このジョブは 5 分ごとに実行されるようにスケジュールされており、停止やエラーにすぐに対応できるようになります。

この記事のコードはすべて GitHub で見つけることができます。 この記事やソフトウェアの内容は投資アドバイスではないことに注意してください。仮想通貨に関する投資決定を行う前に、 財務アドバイザーに相談してください。

JMeter を使用して、パフォーマンス テストのために REST API の負荷をシミュレートします。これにより、マジック ダッシュボードを使用してトラフィックを生成し、パフォーマンスを評価できるようになります。最初のテストでは 5 つの同時クライアントを使用し、それぞれが 100 件のリクエストを行います。

統計によると、応答時間は平均 342 ミリ秒とかなり高い範囲にありますが、P99 は 852 ミリ秒です。もっと改善できるようです。

Puma Magic ダッシュボードを使用して Rails アプリのパフォーマンスを向上させる

Puma マジック ダッシュボードにはスレッド プール容量のグラフが含まれており、テスト実行中にスレッド プール容量がゼロに達していることがわかります。これにより、一部のリクエストが他のリクエストよりも時間がかかる理由が説明されるため、puma スレッドの数を 10 に増やします。

ダッシュボードやこのグラフの作成には何も行っていないことに注意してください。 AppSignal がこれを自動的に作成しました。

puma スレッド数を増やしてテストを実行すると、応答時間はより安定し、ダッシュボードではプール容量が許容レベル内に留まっていることが確認されます。

今度はダイヤルを上げます。 JMeter の同時クライアント数は 50 に増加し、立ち上がり時間は 5 秒になります。このテストでは、応答時間が短く、API エラーが多数発生していることがわかります。 Puma マジック ダッシュボードには、利用可能な Puma スレッドがゼロに達していることが再び表示されます。

API コードを見ると、モデルが毎回データベースからロードされていることがわかります。これはあまり効率的ではないため、新しい日次価格を取得するだけでなく、ML モデルを実行して予測をデータベースに保存するように Sidekiq ジョブを変更します。

この変更をデプロイします。

Sidekiq の Magic Dashboard による API パフォーマンスの向上

それでは、Sidekiq マジック ダッシュボードを確認してみましょう。残念ながら、コードにはバグがありますが、少なくともそれをすぐに特定して修正することができます。

Sidekiq PriceUpdateJob を使用する 現在は、API が変更され、データベースから予測価格を取得するだけで済むようになりました。これにより API のパフォーマンスは向上しますが、依然として API エラーが発生し、応答時間が長くなります。

Puma Magic ダッシュボードに戻る

ダッシュボードを一目見ると、追加のワーカーを使用するように Puma がまだ構成されていないことがわかります。 Puma ワーカーは、複数のスレッドを実行できる OS レベルのプロセスです。合計スレッド数は、ワーカー数と最大スレッド数を乗算して計算されます。まず、2 つのワーカーを使用しますが、使用可能なスレッドはまだ使い果たされています。したがって、ワーカー数を 4 人に増やします。

API のパフォーマンスは非常に良好になりました。平均応答時間は 419 ミリ秒で、API エラーはありません。

マジック ダッシュボードは、利用可能なスレッド容量がまだあることを確認します。

AppSignal の魔法のダッシュボードを使用すると、Puma Web サーバーの容量を即座に把握できます。 Sidekiq ダッシュボードと Active Worker ダッシュボードは、アプリケーションの非同期ジョブについて同様の洞察を提供します。

Magic Dashboards から学んだこと

Rails アプリケーションのパフォーマンス テスト中に、Puma マジック ダッシュボードを使用すると、スレッド数が希望するスループット レベルに不十分であることを簡単に特定できました。スレッド プールの容量、経時的なワーカー数、スレッドの合計数が表示されます。

Sidekiq ジョブにはパフォーマンスの問題はありませんでしたが、マジック ダッシュボードのおかげで、展開後にエラーがあったことをすぐに特定でき、迅速に修正して再展開することができました。これらのモニタリング機能はすべて、AppSignal によって自動的にセットアップされました。

Ruby および Rails アプリ向けの AppSignal のダッシュボード機能

AppSignal のダッシュボードには「Web」アプリケーションや「バックグラウンド」ジョブなどの名前空間があるため、アプリケーションの多数の監視ビューを作成できます。組み込みの概要ダッシュボードには、スループット、応答時間、最新のエラーなど、アプリケーションの健全性の概要が表示されます。

他のダッシュボードと同様に、表示するグラフや指標を編集したり、選択したグラフのレイアウトや構成を変更したりできることに注意してください。

異常検出は強力な機能です。これにより、空きメモリやエラー率など、メトリック値が特定の値を超えたり下回ったりしたときに通知を送信するしきい値を定義できます。

まとめ:AppSignal を使用して Ruby アプリを今すぐ監視する

可観測性とパフォーマンスは、アプリケーションの成功にとって重要です。ただし、私たちはこれらのトピックに対処するのに最後の瞬間まで待つことがよくあります。

AppSignal のマジック ダッシュボードは、すぐに使用できる広範なメトリクス、ダッシュボード、分析情報を提供し、自動的にセットアップされます。これにより、アプリケーションのパフォーマンスを迅速に調整し、運用可能な状態に到達することができます。

AppSignal for Ruby について詳しくは、こちらをご覧ください。

次回まで、コーディングを楽しんでください!