概要

みなさんNew Relic APMについてご存知でしょうか？
恥ずかしながら私自身検証・導入するまではあまり知らなかったのですが、導入してみるとこんな便利な機能だったなら早く入れておけばよかったと思うほどでした。

そもそもなぜNew Relic APMを使用することになったのか、について少しだけ触れておきます。
実はある監視導入案件にて既に稼働中のWordPressがサイトダウンするもののその原因は不明という事態が発生していました。
それを弊社の監視システムで導入しているNew Relicで原因究明して欲しいという依頼をいただいたので、初めてNew Relic APMを導入し分析したところ、簡単にいろんなデータが取れて非常に便利だったのでそれを共有しようと本記事を作成してみました。

本記事では主に以下を記載しています。

  • APMとは？
  • New Relic APMの導入手順
  • New Relic APMを用いた分析について

なお、本記事ではNew Relic APM以外のサービス、リソースについては解説しませんので、あらかじめご了承ください。

 

APMとは？

APMとは、Application Perfomance Monitoringの略称で、New Relicに限った用語ではなく一般的な用語になります。
中でもNew Relicの機能として存在するNew Relic APMは、RubyやJava、Python、PHPといったプログラミング言語で作成されたアプリケーションのパフォーマンスデータを収集し、分析に役立てることができるサービスとなっています。

参考）
APMによるアプリのパフォーマンス改善 | New Relic Documentation

 

通常のインフラ監視とAPMの違い

通常のインフラ監視の際にJavaやPHPのプロセス監視などを導入することがあると思います。
ではこれらとの違いは何なのでしょうか？

通常のインフラ監視はプロセスの生死や、プロセス数が多すぎないかといったことを監視します。
しかし、これだけではアプリの動作が重くなっているかといった状態に柔軟に対応できない事がある他、その原因も別途ログを調査するといった形を取らないと具体的に追求することは難しいと思われます。

こういった際にAPMを導入しておけば、どこがボトルネックになっているか等をサーバにログインせずともNew Relicコンソール上から容易に調査することができます。

参考）
アプリケーションのパフォーマンスが遅い場合のトラブルシューティング | New Relic Documentation

 

New Relic APMの導入

早速ですが、New Relic APMの導入をしていきましょう。
APMの導入と初めて聞いたとき「なんかめんどくさそう」という印象が強かったのですが、やってみるとかなり簡単です。

環境
今回は下記環境に導入をしていきます。

OS：Amazon Linux 2023
DB：RDS for MySQL (version 8.0.39)
MW：Apache (version 2.4.62)、PHP (version 8.1.31)
CMS：WordPress (version 6.7.2)

※ あらかじめAWSとNew Relicのインテグレーション済み

1.New Relicコンソールの左ペイン「Integrations ＆ Agents」を選択し、PHPをクリック
2.「On a host (tar archive)」を選択
※状況に応じてAnsible等を選択してください。

ここで「On a host (CLI)」や「On a host (package manager)」のほうがより楽そうだけどどうなんだ、と思われるかもしれません。
これに関してはインストール時に使用するリポジトリがAmazon Linux 2023に対応していないため失敗してしまいます。
対応しているOSについては下記ドキュメントを参照ください。

参考）
PHPエージェントの互換性と要件 | New Relic Documentation

On a host (package manager)利用時の画面

URLに「el5」があることから古いリポジトリを使用していることがわかります。
※因みに https://yum.newrelic.com/pub/newrelic/ にアクセスしてリポジトリを探しても有用そうなリポジトリはありませんでした。

On a host (CLI)利用時のコンソールログ

===> Detecting services
Found service: php-fpm
Found service: httpd
===> Installing New Relic PHP Agent
Downloading newest PHP Agent Release
AGENT VERSION: 11.6.0.19
Found agent version: 11.6.0.19
Running PHP Agent installer
===> Configuring New Relic PHP Agent
nrinstall-20250308-182905-83662.log
nrinstall-20250308-182905-83662.sysinfo

===> Adding the New Relic PHP Agent repository
Adding the New Relic PHP Agent repository.
警告: /var/tmp/rpm-tmp.EoNYFq: ヘッダー V3 DSA/SHA1 Signature、鍵 ID 548c16bf: NOKEY
エラー: 依存性の欠如:
redhat-release >= 5 は newrelic-repo-5-3.noarch に必要とされています
http://yum.newrelic.com/pub/newrelic/el5/x86_64/newrelic-repo-5-3.noarch.rpm を取得中
! Installing php-agent-installer
Failed

New Relic installation complete

--------------------
Installation Summary

✔ Infrastructure Agent (installed)
✔ Logs Integration (installed)
! PHP Agent (incomplete)

Installation was successful overall, however, one or more installations could not be completed.
Follow the instructions at the URL below to complete the installation process.

⮕ https://xxxxxxxxxxxxxxxx

View your logs at the link below:
⮕ https://xxxxxxxxxxxxxxxx

--------------------

これもNew Relic installerがEL5用のリポジトリをインストールしようとして失敗してます。
ただこれ、PHP-FPMとApacheの再起動を実行するとちゃんと見れるようになったりします。
でもちゃんとインストールできてるのかという部分に気持ち悪さはどうしても残るので避けることをオススメします。

3.あとは画面に従ってコマンドを実行し、導入する

※ 注意 1 ※
「Name your application」の部分に入力する名前は、特に理由がないのであれば重複のないユニークなものにすることを推奨します。（コンソールにもそのように記載されています）
というのもAPMのパフォーマンスはこのアプリケーション名ごとに確認することになるのですが、重複していると他のサーバの情報も紛れてきて読み取りづらくなってきます。

ただ、仮に重複してしまったとしても下記のコマンドで修正できるので落ち着いて対応しましょう。

# newrelic.iniファイルを編集してアプリケーション名を指定
$ NR_PHP_INI=$(php --ini | grep newrelic.ini) ; echo $NR_PHP_INI
$ sudo vi $NR_PHP_INI

## newrelic.appnameを検索して修正
newrelic.appname = "任意のアプリケーション名"

# php-fpmを再起動とステータス確認
$ systemctl list-unit-files -t service | grep php
$ systemctl status php-fpm (上記結果に応じてサービス名を変更)
$ sudo systemctl reload php-fpm
$ systemctl status php-fpm

# Apacheの再起動とステータス確認
$ systemctl status httpd
$ sudo systemctl reload httpd
$ systemctl status httpd

※ 注意 2 ※
導入の過程でPHP-FPMやApacheのrestartをするコマンドがありますが、reloadでも取得開始できることを確認しています。
restartの場合には少なからずサイトの瞬断が発生するため、既に運用中で瞬断は発生させられないといった場合にはreloadを使用するのが良いです。

導入が完了すると左ペイン「APM ＆ Serverless」を選択すると先程命名したアプリケーション名があり、データが取得され始めているはずです。
※ 場合によっては表示までに少し時間がかかります。

 

New Relic APMを用いた分析

実際にサイトダウン時の分析に主に利用していた4つの項目について紹介します。

1. Summary

Summaryを開くと画像のようなデータを取得していることが分かります。
これらの項目について簡単に説明します。

参考）
APM 概要ページを使用したトラブルシューティング | New Relic Documentation

Web transactions time

サービスがWebリクエストを受信してからレスポンスを送信するまでの応答時間を測定します。

《補足：New Relicにおけるトランザクションについて》
一般的にトランザクションとは複数の処理を1つの処理として実行・管理する処理方式のことを指しますが、New Relicではトランザクションを以下のように定義しています。

New Relic では、 transactionはソフトウェア アプリケーション内の 1 つの論理作業単位として定義されます。 具体的には、その作業単位を構成する関数呼び出しとメソッド呼び出しを指します。 APM の場合、これは多くの場合、アプリケーションが Web リクエストを受信してから応答が送信されるまでに発生するアクティビティを表すweb transactionを指します。

New RelicのAPMにおけるトランザクション | New Relic Documentation

Apdex score

Webアプリケーション/サービスのレスポンスタイムに対するユーザーの満足度を測定するスコアで、 0～1の値で表されます。
スコアが1に近ければ近いほど、アプリのパフォーマンスが良いことを意味しています。

デフォルトでは0.5以上で良いと判定されますが、SETTINGSの「Application」からApdex Tの値を変更することで調整できます。

Throughput

1分間に処理されるリクエスト数を測定します。

Errors

エラーが発生したトランザクションの割合を測定します。

 

2. Transactions

トランザクションの処理にかかった時間やスループット等を確認することができます。

参考1 ）
Transactionsページ：特定のパフォーマンス問題を突き止める | New Relic Documentation
参考2 ）
遅いトランザクションを診断する | New Relic Documentation

Time consumed by top Web transactions

実際に処理が完了した際に、全体に対してどのトランザクションがどのくらい時間を要しているのかをトランザクションごとに割合表示します。

なお、割合が100%超えて表示されていますが、実際の処理ではトランザクションが並行処理されているものを一切考慮せず、そのまま足し合わせているため100%を超えた割合も表示されることがあります。

Transaction traces

実際に時間の掛かっているトランザクションを確認することができます。分析の際にはこのあたりを一番よく確認していました。

これらのトランザクション名はリンクになっており、クリックするとそのトランザクションの時間詳細を確認することができます。

画像のように合計処理時間の25%以上を占めた（子ノードのない）セグメントは低速スパンとして色がつきます。

また「Database queries」タブを選択すると処理に時間のかかっている実際のクエリも確認することができます。

参考3 ）
トランザクショントレースの概要 | New Relic Documentation
参考4 ）
現場トレースを深く掘り下げる | New Relic Documentation

 

3. Databases

このページではサーバからデータベースに向けて実行回数の多いクエリやその実行時間などを確認することができます。

参考）
遅いデータベース クエリを診断する | New Relic Documentation

またスロークエリの確認もすることができます。

データベース全体のスロークエリではなく、あくまでもAPMをインストールしているサーバからデータベース宛に投げたクエリの中でのスロークエリだとは思いますが、データベースに対して何も設定していないのにここまで表示してくれるのは素直にすごいと思います。

なお、このクエリのリンクをクリックするとクエリの詳細を確認することができます。

どのデータベースに向けて、どのトランザクションの中で実行されたかといった詳細も確認できます。

 

4. WordPress

APMを導入したサーバにWordPressを導入していれば、自動的にWordPressというページも作成されモニタリングされます。

ここでは使用率の高いhooksやプラグイン、テーマについての詳細が確認できます。

《補足：自動導入を無効にする》
この自動導入はPHP Agent v5.3以降ではデフォルトで有効になっているため、自動導入を無効にしたい場合には下記コマンドを実行してください。

# newrelic.iniファイルを編集してアプリケーション名を指定
$ NR_PHP_INI=$(php --ini | grep newrelic.ini) ; echo $NR_PHP_INI
$ sudo vi $NR_PHP_INI

## newrelic.framework.wordpress.hooksを検索して修正
newrelic.framework.wordpress.hooks = false

# php-fpmを再起動とステータス確認
$ systemctl list-unit-files -t service | grep php
$ systemctl status php-fpm (上記結果に応じてサービス名を変更)
$ sudo systemctl reload php-fpm
$ systemctl status php-fpm

# Apacheの再起動とステータス確認
$ systemctl status httpd
$ sudo systemctl reload httpd
$ systemctl status httpd

参考）
WordPressに特化した機能 | New Relic Documentation

 

補足：WordPressダッシュボード

Dashboards > Create a dashboard > Browse pre-built dashboards > 「wordpress」と検索 > WordPress Full Stack
と選択することで画像のようなダッシュボードが一瞬で作成されます。
※ PHP Application Name、MySQL Entity Name、Host Instanceを選択して使用してください。

非常に見やすくなっているのでこちらも活用してみるといいかもしれません。

参考）
WordPressフルスタックインテグレーション | New Relic Documentation

※1 上記URLにはMySQLクイックスタートを実施するよう記載がありますが、RDSを使用している場合にはAWSとNew Relicを結びつけるインテグレーションのみ実施できていれば特に設定は不要です。
※2 Apacheクイックスタートについても特に設定不要です。
※3 デバッグログ設定については必要に応じて設定してください。

 

まとめ

ここまで目を通していただけた方には、非常に簡単な導入のみでアプリケーションのボトルネック分析などに使用できることがわかっていただけたかと思います。
顧客の要件としては必要なかったとしても、インフラ環境を引き渡したあとには何かしらのアプリケーションは導入されるはずなので、New Relic APMを入れておく準備はしておいたほうが後々のためになるのかもしれません。（導入工数もかからないですし）
それにこういったことをしておくことがゆくゆくは顧客との関係継続につながるのでは、と改めて思いました。

何度も言うようですが導入はとても簡単なので、ぜひみなさんも試してみてください！