こんにちは。SCSKの井上です。
複雑なマイクロサービス環境で、障害の原因を素早く特定するにはAPMが欠かせません。本記事では、分散トレーシングの仕組みとAPMをPHPアプリに導入する手順もあわせて解説します。
はじめに
APM（Application Performance Monitoring）は、アプリケーションのパフォーマンスを監視し、問題を早期に発見するための仕組みです。遅延の原因はインフラ側かアプリケーション側か、詳細な分析で原因の特定を行うことができます。この記事ではAPMの重要な機能の一つである分散トレーシングの仕組みとPHPアプリケーションの導入手順について解説します。
APMの概要
APMはアプリケーションの稼働状況をユーザー目線で可視化します。ユーザーに影響を与える可能性がある問題を特定したり、アプリケーションのパフォーマンスを改善する手助けになります。対応言語はGo, Java,.NET,Node.js,PHP,Python,Rubyをはじめとする主要な言語に対応しています。開発担当者が安心してリリースを継続でき、ユーザー影響を最小限に抑えながら市場の変化に迅速に対応するためには、APMが必要不可欠になってきています。
主に以下の機能を提供します。
- アプリのレスポンス、エラー率、スループットをリアルタイム監視
- トランザクション分析や分散トレーシングでボトルネックを特定
- データベースや外部サービスのパフォーマンスを可視化
- アラート設定やカスタムダッシュボードで運用を効率化
APMが必要とする背景
ユーザーに影響を与えている問題を検出して対策するには、ユーザー目線でアプリケーションを監視することが必要になってきます。検出できてもその問題の分析や特定といった処置が遅れてしまうとビジネス影響は拡大していきます。特定や解決に時間がかかると工数もかかり、機会損失にもつながります。APMは、ユーザー目線での監視を実施することで、アプリケーション内の構成要素や処理の流れを可視化し、特定から対処までの時間を短縮することができます。APMが重要視されている背景について2つの観点から紹介します。
1つ目はアーキテクチャの変化。クラウドやサーバｰレスの技術が普及することで、1つのユーザーリクエストが複数のサービスを経由して処理されるようになっています。いくつものコンポーネントを経由する構成では、どのサービスで遅延やエラーが発生しているかを特定するのが難しくなります。APMを導入することで、サービス間の依存関係の可視化、トランザクションの遅延やエラーの原因追及、構成変更の影響分析が可能になります。
2つ目は開発プロセスの変化。クラウドやAIなどの技術進化が速く、新しいサービスや機能が次々と登場しています。顧客は最新トレンドを取り入れたいというニーズが高まっており、従来のウォーターフォール型開発では市場の変化に対応できない状況です。そのため、CI/CDによる頻繁なリリースと、価値を早く提供することが求められていますが、システム変更には性能劣化や障害のリスクがあります。APMを導入することで、構成変更の影響や変更前後の性能を追跡し、安心してリリースを継続できます。
APMでできること
ページの表示速度、API応答時間、フロントエンドからバックエンドまでの経路などユーザーが操作する視点で確認することで、ユーザー満足度の低下やビジネス機会損失の影響を最小限に抑えます。APMを導入することで、以下のようなことが実現できます。
| できること | 説明 | 導入効果 |
| サービスレベルの可視化 | ユーザー視点での各サービスの可用性、レイテンシ、エラーレートなどのサービス単位の健康状態を表示 | 重要サービスの健全性を一目で把握
SLO逸脱の早期検知 |
| E2Eの可視化(New Relicブラウザモニタリングが有効の場合) | ユーザー操作からレスポンスまで、外部を含めた全経路を横断的に表示 | ユーザー影響の把握
依存関係の可視化 |
| トランザクションの可視化 | 1つの処理（購入、決済、検索等）の流れを時系列で可視化（ステップごとの時間・結果） | 遅延ステップの特定
リトライ・タイムアウトの検知 UX改善の根拠提示 |
| 分散トレーシング | 一連のトランザクションの処理を横断的に分析 | 遅延、エラーの原因箇所を迅速特定
MTTR短縮 |
| サーバーレスアプリ監視 | Lambda、Functions等の実行時間、失敗率、同時実行数 | 実行コストと性能の最適化
イベント連鎖の不具合検知 スケール時の安定性向上 |
| エラートラッキング | 頻度、ユーザー影響の継続的追跡 | 優先度付け（頻度・影響）
脱ログ中心の確認 |
| インフラ・フロントエンド監視統合 | サーバ、ネットワーク、コンテナとブラウザを同画面で表示 | インフラ・アプリ運用のコミュニケーション円滑化 |
| 構成変更の記録 | パラメータ、バージョン、リリースノート等のリリース前後の影響範囲 | いつ・誰が・何を変えたかを追跡し障害と変更の相関を即確認
変更管理の品質向上 |
| 脆弱性の検出と可視化 | サードパーティーライブラリの脆弱性をスキャンして可視化 | 重大脆弱性の早期発見・優先度付け
パッチ適用計画の支援 コンプライアンス強化 |
分散トレーシング
分散トレーシングは、複数のサービスで構成されたシステムで、1つのリクエストがどのように処理されているかを追跡する技術です。マイクロサービスが主流になり、1つのリクエストが複数のサービスを経由します。例えば、Web画面 → API → 在庫サービス → データベースという流れのとき、どこで遅延やエラーが起きているかを1つ1つログを確認して見つけるには時間がかかり、迅速な復旧が難しくなります。そのため分散トレーシングを使ってリクエストの流れを可視化し、問題箇所を特定します。
分散トレーシングを必要とする理由
分散トレーシングを導入することで、障害対応の迅速化により本番環境で発生した問題を素早く特定し、解決までの時間を短縮できます。また、遅延の原因となるボトルネックを明確にして対策することで、システム全体のパフォーマンスを最適化できます。チーム間のコミュニケーションにおいては、開発と運用の両チームが共通の画面で確認することで、コードの問題か、インフラの負荷が問題か、認識の齟齬が軽減され、問題がユーザー体験に与える影響を把握し、初動を早めることが可能になります。サービス間の依存関係を分析することでアーキテクチャを改善し、リソース計画やスケーリングの判断に役立つデータも得られます。
基本構造
New Relicの分散トレーシングはOpenTelemetryの標準をベースに、スパン単位で操作を記録し、トレース全体をツリー構造で管理しています。
Trace
複数のサービスを通過する単一のリクエストのE2E経路を表し、一意のトレースIDで識別されます。1つのユーザ操作やリクエスト全体を識別するためのIDで、トレースが終わるまで不変の値です。この値が変わってしまうと、処理の繋がりが追えなくなってしまうためです。
Span
サービス内の個々の操作や動作を表します。開始時間と終了時間、所要時間、関連するメタデータに関する情報を含みます。各スパンは、ステップがいつ始まり、いつ終わったか、そして何か問題があったかどうかを確認できます。SpanにもIDがついています。Span ID は各スパン固有のIDで、親子関係を示すために Parent ID とともに使われます。
Context metadata
トレースの連続性を維持するためにサービス間で伝播される情報を指します。トレースIDはトレースを一意に識別するものであり、親スパンIDのような他のコンテキスト情報も含まれます。トレースコンテキストは、各サービスが自らのスパンを正しいトレースにリンクし、全体のトレース構造を維持できるようにします。各区間を同じ経路に結びつける重要な情報が入っており、途中で何も失われないようにしています。
分散トレーシングのサンプリング
全リクエストを記録すると、システムのパフォーマンスに影響するだけでなく、データコストも増加します。そのため、New Relicではデフォルトでヘッドベースサンプリングを採用し、トレースの一部のみを選んでNew Relicに送信しています。テールベースサンプリングを利用する場合は、All Capabilitiesから「Infinite Tracing settings」を選択して有効化する必要があります。
| 項目 | ヘッドベースサンプリング | テールベースサンプリング |
| サンプリングのタイミング | リクエスト開始時に決定 | リクエスト完了後に決定 |
| メリット | – 導入が簡単 – 起動が速い – パフォーマンスへの影響ほぼなし – コストが低い |
– 完了したトレースを見て判断できる – エラーや遅延を含むトレースを優先的に保存 – 問題箇所を確実に把握 |
| デメリット | – エラーや遅延があるか事前にわからない | – データ送信・保存コストが高い – 管理が複雑 |
| 適した環境 | – トランザクション量が少ないアプリ – マイクロサービス混在環境 |
– エラー調査や異常検知を重視する環境 – 高精度なトレース分析が必要な場合 |
W3C Trace Context
トレースコンテキストは、分散トレーシングにおいてサービス間のリクエストを関連付けるため、複数のサービス間を流れるリクエストを一意に識別し、関連付けるメタデータです。New Relicでは、HTTPヘッダーに以下の表のデータを伝播させることで、E2Eのトレースを構築しています。分散トレーシングの標準仕様であるW3C Trace Contextに準拠することで、トレースIDやスパンIDのフォーマットが標準化し、異なるAPMツールやオープンソース（例：OpenTelemetry）においても統一的な分散トレーシングが可能になっています。
| 属性名 | 説明 |
| traceId | トレース全体を一意に識別するID。分散トレーシングで全サービス共通。 |
| guid / parentId | 現在のスパンID。次のサービスに渡すときは「親ID」として利用。 |
| parent.type | 親の種類（ブラウザ、モバイル、APMなど）。 |
| timestamp | ペイロード作成時のUNIXタイムスタンプ（ミリ秒）。 |
| transactionId | トランザクションイベントの一意識別子。 |
| priority | サンプリング優先度（ランダム値）。サンプリング制御に利用。 |
| sampled | true / false。このトレースを収集するかどうか。 |
| traceparent | W3C標準ヘッダー。トレースID、スパンID、サンプリング情報を含む。 |
| tracestate | ベンダー固有情報を追加するためのW3C標準ヘッダー。 |
ブラウザモニタリング
New Relicブラウザモニタリング機能を導入することで、APMはサーバー側、Browserはクライアント側としてエンドツーエンドの監視が可能になります。ユーザー操作からシステム内部の導線を一つのトレースで確認可能になることでボトルネックがフロントかバックエンドかを即座に判断できます。ブラウザモニタリングはAPM導入と同時に設定することができます。ブラウザモニタリングの機能については、別記事にて紹介します。
PHPエージェント導入前提条件
New Relic PHPエージェント導入にあたり、PHPバージョンの要件や動作条件があります。サポート外のPHPバージョンまたはプラットフォームを使用している場合は、パッケージ管理による自動更新によって互換性の問題が発生する可能性があります。PHPエージェントのパッケージ自動更新を無効化にすることが推奨されています。
サポートされているPHPバージョン情報は以下をご参照ください。
PHPバージョンを含め、New Relic PHPエージェントが動作するOS、アーキテクチャの情報は以下をご参照ください。
ファイアウォールやセキュリティポリシーで外部との通信制限がされている場合は、以下をご参照ください。New Relicエージェントがデータ送信できるようにドメインやエンドポイントを追加する必要があります。
エージェント導入前の注意事項
システム要件を確認したうえで、PHPエージェント導入にはいくつか注意点があります。既存システムへの影響がないことをテスト環境で十分に検証し、その後本番環境へ導入することを推奨します。以下は一例になります。
WEBサーバーの再起動
本番環境で導入する場合は、インストールのタイミング調整が必要です。エージェント導入後や設定の変更、PHPおよびPHPエージェントのアップデート後はApacheやPHP-FPM、NginxなどのWEBサーバーを再起動する必要があります。WEBサーバーが起動して PHP を読み込むと、PHP エージェントも読み込まれます。
拡張モジュールの競合
競合製品がすでに導入されていないかを確認する必要があります。Xdebug、Blackfire、DrupalなどPHPのデバックやパフォーマンス監視、他APM製品が導入されている場合、競合により動作不具合やオーバーヘッドが増加する可能性があります。
長時間実行される処理がある
本番環境へ導入する前に、テスト環境にてエージェント導入後、リソースが高騰していないかを確認する必要があります。処理が数分から数時間続く場合、New Relicへのデータ送信が遅れ、メモリ使用量が増える可能性があります。エージェントはトランザクションデータをメモリに保持します。長時間タスクでは保持時間が長くなるため、メモリ使用量が増加し、オーバーヘッドが大きくなります。
セキュア情報が含まれるログの扱い
ログに個人情報や認証に関わるデータが出力されていないかを確認する必要があります。New Relicのプラットフォームはデータ転送は暗号化され、データ保存はセキュアな環境で管理されていますが、個人情報や機密データはNew Relicに送信しないよう対処する必要があります。
SQLクエリのリテラル値（文字列や数値）はNew Relicエージェント側で難読化処理したうえで、New Relicにデータを送信します。また、ユーザーがフォームに入力した値はデフォルトで収集対象外となっていますが、ログに出力される場合はマスキングや該当ログは転送除外設定が必要です。
データ転送量の増加
必要に応じて取得するデータ量の調整が必要となる場合があります。PHPエージェントに限らず、APMを導入すると、アプリケーションのトランザクション、エラー、SQLに加え、複数のサービスやシステムを経由するリクエストの流れを追跡する分散トレーシング機能が有効になります。そのため、New Relicへ送信されるデータ量は増加します。
PHPエージェント導入手順
PHPエージェントを導入すると、アプリケーションのレスポンス時間やデータベースのクエリの詳細を可視化でき、問題の特定や改善が容易になります。本手順では、Linux環境へエージェントのインストールから設定までの流れを説明します。
PHPエージェントのインストール方法(Linux)
PHPエージェントのインストール方法は以下が用意されています。
| 方法 | 説明 |
| On a host (CLI) |
New Relicが提供するインストールスクリプトをコマンドラインで実行して導入する方法。CLIで手動実行。
|
| On a host (tar archive) | 汎用的なインストール方法。tarファイルを展開して手動で設定する。パッケージ管理を使わない。 |
| On a host (package manager) | Linuxのパッケージ管理ツール（aptやyum）を使ってインストール。依存関係の自動解決やアップデートが容易。自動更新を有効にすると互換性リスクあり。 |
| Docker | Dockerコンテナ内でエージェントをインストール。コンテナ化されたアプリケーション向け。 |
| Kubernetes | Kubernetesクラスタにエージェントを導入。Podやノードの監視に対応。 |
| Ansible,Chef,Puppet | 構成管理ツールで自動化による導入。 |
PHPエージェントのインストール手順(Linux)
PHPエージェントのインストールをCLI形式で実行した場合は、Infrastructureエージェントのインストールも同時に行われます。PHPエージェントインストール後は、設定ファイルを編集する必要があるため、その反映にはWEBサーバーの再起動は再度必要になります。インストール作業は、WEBサーバへの既存の監視アラート（死活監視）の無効化や再起動によるサービス影響を確認した上で実施してください。
| 1.「Integrations & Agents」から、「Guided install」をクリックします。 | 2.APMのタブをクリックし、「PHP」を選択します。 |
 |
 |
| 3.この手順ではOn a host (CLI)で進めます。 | 4.User keyを入力し、「Continue」をクリックします。 |
 |
 |
| 5.「Copy to clipboard」をクリックします。 | 6.対象のサーバにログインし、コピーしたコマンドを実行します。途中、APMの名前を入力する箇所がありますので、任意の名前を入力します(後ほど名前変更可能です)。 |
 |
 |
| 7.WEBサーバの再起動の許可を選択する画面が表示されます。後から再起動する場合は、Nと入力します。本手順ではYで進めます。 | 8.PHPエージェントのインストール許可を選択する画面が表示されます。Yを入力します。 |
 |
 |
| 9.実行後、以下の赤枠でinstalledとなっていることを確認します。 | 10.項番5の画面で「Continue」をクリックします。New Relicと通信状態が表示されます。導入環境によって表示項目は異なります。Apacheへの導入は「Install Apache」をクリックします。 |
 |
 |
| 11.「Guided」をクリックします。 | 12.同様にUser keyを入力後に表示されるコマンドをコピーし、対象のサーバーで実行後、以下の赤枠が表示されていることを確認します。 |
 |
 |
| 13.New Relicとの通信確認でApacheがinstalledとなっていることを確認します。「See your data」をクリックします。本記事ではAWSとのインテグレーション設定はスキップします。 | 14.APMのサマリー画面が表示され、収集されたデータを確認することができます。 |
 |
 |
設定ファイルの編集
設定できる内容が多いので、基本設定やデータ削減に関係のある個所のみを主にピックアップして下記にデフォルト値を記載しています。設定ファイルを編集後はWEBサーバーの再起動が必須になります。PHPエージェント導入後、データ転送量が増大している場合は、必要に応じて設定値を調整する必要があります。
設定ファイル：/etc/php.d/newrelic.ini
| 機能カテゴリ | 設定項目 | 意味 |
| 基本設定 | newrelic.enabled = true | エージェントの有効化（falseで無効） |
| newrelic.license = “*********************NRAL” | New Relicライセンスキーの設定
環境変数で外出しが望ましい |
|
| newrelic.appname = “アプリケーションの名前” | APM上で表示するアプリケーション名 | |
| ログ設定 | newrelic.loglevel = “info” | PHPエージェントのログ出力レベル（info, debugなど） |
| newrelic.daemon.loglevel = “info” | デーモンのログ出力レベル | |
| エラー収集 | newrelic.error_collector.enabled = true | PHPエラーの収集を有効化 |
| ブラウザ監視 | newrelic.browser_monitoring.auto_instrument = true | HTMLにブラウザ監視スクリプトを自動挿入 |
| トランザクション詳細 | newrelic.transaction_tracer.enabled = true | トランザクション詳細トレースを有効化 |
| newrelic.transaction_tracer.threshold = “apdex_f” | トレース対象の閾値（例：apdex_f） | |
| newrelic.transaction_tracer.slow_sql = true | 遅いSQLクエリの収集を有効化 | |
| newrelic.transaction_tracer.stack_trace_threshold = 500 | スタックトレースを取得するSQLの閾値（ms） | |
| newrelic.transaction_tracer.explain_enabled = true | SQLのEXPLAINを有効化 | |
| newrelic.transaction_tracer.explain_threshold = true | EXPLAINを実行するSQLの閾値（ms） | |
| イベント設定 | newrelic.transaction_events.enabled = true | トランザクションイベントの有効化 |
| newrelic.custom_events.max_samples_stored = | カスタムイベントの最大保持件数 | |
| ログ収集 | newrelic.application_logging.enabled = true | アプリケーションログ収集を有効化 |
| newrelic.application_logging.forwarding.enabled = true | アプリケーションログをNew Relicへ転送を有効化 |
UIから設定できる項目もあります。UI上から設定した場合、エージェント設定ファイルと競合する箇所は上書きされ、UIの設定が優先となりますが、PHPの場合は例外とされています。
ユーザ体験の可視化指標：Apdex
アプリケーションのパフォーマンスに対するユーザー体験を数値化する指標としてApdexがあります。1.0に近いほど、ユーザー体験は問題ないとされています。以下についてはベンダーごとに評価基準は異なります。
| Apdex値の範囲 | 評価（Rating） |
| 0.94 ～ 1.00 | Excellent（非常に良い） |
| 0.85 ～ 0.93 | Good（良い） |
| 0.70 ～ 0.84 | Fair（普通） |
| 0.50 ～ 0.69 | Poor（悪い） |
| 0.00 ～ 0.49 | Unacceptable（許容外） |
Apdex(T) = (Satisfied count + (Tolerating count ÷ 2)) ÷ Total samples
- 満足（Satisfied） ：レスポンスタイム ≤ T
- 許容（Tolerating） ：T < レスポンスタイム ≤ 4T
- 不満足（Frustrated）：レスポンスタイム > 4T
満足（Satisfied） ： レスポンスタイム ≤ 3秒
許容（Tolerating） ：3秒 < レスポンスタイム ≤ 12秒
不満足（Frustrated）：レスポンスタイム > 12秒
参考: https://www.apdex.org/index.php/documents/
トラブルシューティング
New RelicのPHPエージェントは、バックグラウンドで動作するnewrelic-daemonプロセスにデータを渡します。このデーモンがデータを集約し、New Relicのプラットフォームへ送信する仕組みです。エージェント関連で問題が発生した場合は、状況に応じて以下のログを確認します。
| 状況・問題 | 確認するログ | ログで確認するポイント | 次のアクション |
| New Relicにデータが送信されない | newrelic-daemon.log | ・daemonが起動しているか ・サーバーへの接続エラー ・キューが溜まっていないか |
・daemonを再起動 ・ネットワーク疎通確認 ・Proxy設定確認 ・アクセス権の確認 |
| PHPアプリのメトリクスがNew Relicに表示されない | php_agent.log | ・エージェントが正しく読み込まれているか ・設定ファイル読み込みエラー |
・php.ini設定確認 ・PHP再起動 |
エージェントの再送処理
エージェントは、トランザクション、エラー、カスタムイベントなどのデータを即時送信せず、メモリに一時保持します。その保持したデータを定期的にNew Relicのコレクターへ送信するタイミングをハーベストサイクルと言います。この仕組みにより、アプリへの負荷を防ぎ、New Relicとの通信を効率化させています。いずれもメモリ上限やイベント種別ごとの制約により、すべて送信されるわけではありません。
| データ内容 | 再送 | 理由 |
| トランザクションイベント | 〇 | メモリに保持し、ハーベストサイクルで送信。 |
| エラーイベント | 〇 | メモリに保持し、再送可能。 |
| カスタムイベント | 〇 | 最大30,000件/分（newrelic.custom_events.max_samples_storedで調整可）。HTTPリクエストが1MBを超える場合は破棄。New Relicに送信できるイベント数は833件/5秒 のため、イベント数によってはすべて送信されずサンプリングとなる場合あり。 |
| スパンイベント（分散トレーシング） | 〇 | 再送可能。上限超過分は破棄。 |
| メトリクス（レスポンスタイム等） | 〇 |
集計値をメモリに保持し、再送可能（CPU,メモリなどのインフラメトリクスは再送不可）。
|
| ログ（ログフォワーディング） | × | リアルタイム送信のみ。通信切断時は保持されない。 |
PHPエージェントの更新
最新の技術を使うためにはエージェントの更新が必要となってきます。更新により、最新のセキュリティ対策やパフォーマンス改善が適用され、より正確な計測や新機能の利用が可能になります。古いバージョンを使い続けると、互換性の問題やサポート切れによるリスクが生じるため、定期的な更新が重要になります。
さいごに
この記事では、分散トレーシングの機能とPHP環境へのAPM導入手順、設定について解説しました。分散トレーシングは奥が深く、実際の障害対応や運用を通じて理解をさらに深め、設定をブラッシュアップしていくことが重要です。今回はPHP環境を紹介しましたが、今後はJavaなど他言語への導入方法ついても、より幅広い環境での可観測性向上の一助となる情報を目指していきます。
SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。
