AppSignalで実現するNGINX自動パフォーマンス監視：リアルタイムインサイトとMagic Dashboards活用ガイド

NGINXのパフォーマンスを正確に把握するのは、決して簡単なことではありません。追跡すべきデータポイントが非常に多く、どの指標が自分にとって重要で、どの指標を無視してよいのか判断に迷うことも少なくないでしょう。

この記事では、AppSignalを活用してNGINXを監視し、アプリケーションパフォーマンスの可視性を高める方法を詳しく解説します。

すべてのメトリクスを「マジック」に

AppSignalでは、スループットからレスポンスタイムまで、さまざまなパフォーマンスメトリクスを組み合わせたカスタムダッシュボードを作成できます。ただし、手動でダッシュボードを構築するには時間がかかり、どのメトリクスが本当に重要なのかを見極めるのも容易ではありません。

そこでAppSignalは、このプロセスを自動化するMagic Dashboardsを提供しています。AppSignalをインストールすると、エージェントがインフラを自動スキャンし、NGINXダッシュボードを含む最重要のダッシュボード群を自動生成します。

Magic Dashboardsは、アプリケーションのダッシュボードリストに自動的に表示されます。一度セットアップすれば、アプリケーション固有の要件に合わせて、表示するメトリクスを自由にカスタマイズすることも可能です。

Magic DashboardsでNGINXメトリクスを可視化する

ここからは、高トラフィックによる障害がアプリケーションの可用性を脅かす場面で、Magic Dashboardsがどのように役立つかを具体的に見ていきましょう。

シナリオ:突入するトラフィック急増

「SnapGram」という写真共有アプリケーションを運営していると想像してください。ユーザーは写真をアップロードしたり、他のユーザーの写真を閲覧・いいねしたりできます。アプリは少数のコアユーザーに支えられ、比較的安定しており、可用性の問題は一切ありませんでした。

ところが、ある大手競合サービスが突如として「猫とカプチーノの写真の共有を禁止」。ユーザーが一斉にSnapGramへ流入し始めます。わずか数時間のうちにアクティブユーザー数は数百人から数千人へと急増し、突然何千人ものユーザーが「SnapGramが使えない」と不満を訴え始めました。

しかし、アプリケーションのログを確認しても、システムは正常に動いているように見え、エラーインシデントの急増もありません。はたして原因はどこにあるのでしょうか?

答えは、NGINX Magic Dashboardが示してくれます。

• スループット:アプリケーションが受信しているリクエスト数を即座に把握できます。グラフを見ると、SnapGramが「インターネットを壊しかねない」ほど大量のリクエストを受けていることが一目瞭然です。
• リクエストタイム:こちらも上昇傾向にあり、SnapGramの応答に以前より時間がかかるようになっています。
• コネクション:アプリケーションへの接続状態を示すこのチャートからは、多くのユーザーがSnapGramの応答を待ち構えている——つまり需要に追いつけていない——ことがわかります。

さらに、需要に対応しきれない結果として、ステータスコードチャートではタイムアウトが急増しています。アクセスを試みた大多数のユーザーがタイムアウトエラーを受け取っているのです。

重要なのは、この問題がアプリケーションプロセスがリクエストを受け取る前段階で発生しているという点です。そのため、ログ分析だけでは異常に気づけません。確認できるのは、SnapGramがなんとか処理できたごく一部のリクエストだけだからです。

問題の解決へ

原因がコードではないと判明したので、次はサーバーを追加起動してSnapGramの可用性を改善し、増加したトラフィックに対応できる体制を整えます。新しく追加された各サーバーは、Magic Dashboardのアップストリームレスポンスタイムおよびアップストリームステータスコードのグラフに個別のマーカーとして表示され、プロセス単位の詳細なインサイトが得られます。

さらに負荷を軽減するため、アップストリームキャッシングも有効化します。キャッシュされるリクエストが増えるにつれてアプリケーションへの負荷が減り、リクエストタイム(およびアップストリームリクエストタイム)も順調に低下していきます。

SnapGramが安定し、ユーザーのリクエストが適切に処理されるようになると、不満の声は自然と収まり、ユーザーは再び猫やカプチーノの写真の共有を楽しんでいくでしょう。

より多くのメトリクス=より大きな効果

SnapGramの事例は、読み取りやすいメトリクスへのアクセスが、アプリケーションの安定運用とNGINX統合の価値最大化にいかに役立つかを示す一例にすぎません。

NGINX Magic Dashboardsで追跡できる主なメトリクスは以下の通りです。

• リクエストタイム:NGINXサーバーがリクエストに応答するまでの時間(毎分平均値と95パーセンタイル)
• スループット:NGINXサーバーが処理したリクエスト数
• リクエスト長:クライアントからNGINXサーバーが受信したリクエストのバイト長(毎分平均値と95パーセンタイル)
• レスポンス長:NGINXサーバーがクライアントへ送信したレスポンスのバイト長(毎分平均値と95パーセンタイル)
• ステータスコード:NGINXサーバーが送信したレスポンスのステータスコード別カウント
• コネクション:NGINXサーバーが現在処理中のコネクション数(1分ごとに計測、接続状態別に分類)
• アップストリームステータスコード:NGINXがプロキシする上流サーバーが返したレスポンスのステータスコード別カウント
• アップストリームレスポンスタイム:上流サーバーがリクエストに応答するまでの時間(毎分平均値と95パーセンタイル)
• アップストリームキャッシュステータス:上流サーバーからプロキシされたキャッシュ済みリクエスト処理時のキャッシュ状態(HIT・MISSなど)

NGINXとAppSignalの連携を始める準備ができたら、NGINXメトリクスドキュメントでAppSignal統合の設定方法をぜひご確認ください。

開発者に選ばれる理由

Magic Dashboardsは、AppSignalが提供する数多くの開発者志向機能のほんの一例です。開発者の皆さまにご愛用いただいている理由は、他にもあります。

• 直感的で操作しやすいインターフェース
• シンプルで予測しやすい料金体系
• 開発者による開発者のためのサポート体制

さらに、新規トライアルユーザーの方には、オランダ名物ストロープワッフルの詰め合わせボックスを無料プレゼント中です。データ送信を開始したら、ぜひご連絡ください。特製パッケージをお届けします🍪!

著者プロフィール:コナー・ジェームズ(Connor James)

AppSignalの開発者マーケティングマネージャー。ポッドキャストの熱心なリスナーで、カンノーリへの愛が深すぎて、名前を「Connoli」に変えようか本気で検討中。colorの綴りには「u」が入るべきだと信じている。マイクの前、ステージの上、あるいはオフのときはソファでくつろぐ姿が見られるかもしれません。

コナー・ジェームズの記事一覧はこちら