New Relic APM導入でデータ量が増大! データ取得の考え方

システム監視は、単なる「安定稼働」の維持を超え、「ブランドイメージと売上を守る」ための生命線です。

従来の監視体制の限界を感じ、E2Eの可視化を実現するNew Relic APMを導入しました。これで障害の予兆は掴める！と安堵したのも束の間、すぐに直面したのは予想外の壁でした。それは、リッチなデータ取得の代償としてのデータ送信量の爆発的な増加=利用コストの高騰です。

APMの費用対効果をどう最大化するのか？ 分散トレーシングはすべて取る必要があるのか？本記事では、ECサイトを事例に費用対効果を最大化する考え方を戒めとして残します。

1. はじめに：APM導入の目的と、まさかの「コスト増」という壁

ECサイトにおけるAPMの重要性（導入前の課題）

ECサイトの運用者なら誰もが知る通り、システム障害はブランドイメージと機会損失（売上低下）に直結する、絶対に避けたい事態です。

これまではサーバーの死活監視やログ収集ツールを主軸に運用していましたが、これらのツールでは、「サーバーは生きているが、特定の商品検索APIだけが異常に遅い」といった、ユーザー体験を損なう「遅い障害」を事前に察知することが困難でした。

そこで私たちは、E2Eの可視化による迅速な障害検知と原因特定を目指し、New Relic APM（Application Performance Monitoring）の導入を決断しました。

導入直後の誤算：予想以上に膨らんだデータ送信量

New Relic APMの導入自体は成功でした。アプリケーション内部のメソッド単位の処理時間や、外部サービスとの連携状況まで、すべてが手に取るように可視化され、ボトルネックの発見速度は劇的に向上しました。

しかし、このリッチなデータ取得には代償が伴いました。それは、New Relicへのデータ送信量の急増です。特にトラフィックの多いECサイトでは、トランザクション、エラー、そして強力な機能である分散トレーシングのデータ量が、当初の試算を大幅に超過しました。サービスの安定稼働（守り）と、コスト最適化（攻め）の両立という、新たな命題に取り組む必要に迫られたのです。

2. 課題の核心：分散トレーシングとサンプリングのジレンマ

New Relic APMの目玉機能の一つである「分散トレーシング」は、マイクロサービスアーキテクチャや複数のシステムをまたがるリクエストの「繋がり（スパン）」を可視化してくれる強力なツールです。複雑化するECシステムにおいて、この機能は障害原因特定時間を大幅に短縮してくれました。

しかし、これがデータ送信量増大の最大の要因でした。1つのリクエストが注文サービス、在庫サービス、決済サービスなど複数のサービスを通過するたびに、数多くのトレースデータが生成されます。トランザクション数が多いほど、データ量は雪だるま式に増加するのです。

ここで私たちは以下の問いに直面しました。

障害を特定するために、すべてのリクエストについて詳細な分散トレーシングのデータを取る必要はあるのか？

私たちの出した結論はすべてのデータを取る必要はないです。

ECサイトにおけるリクエストの大部分は、正常に、かつ迅速に処理されています。重要なのは、異常なトランザクション（エラーが発生したもの）や、パフォーマンスが悪いトランザクションに絞って詳細なデータを取得することです。サンプリングを賢く適用すれば、分析の質を落とさずにコストを大幅に削減できるはずです。APMの価値を維持しつつ、従来の予算内に収める目標に掲げました。

3.コスト削減を実現した具体的なチューニングと設定

APMを導入し、コスト最適化を達成したことで、私たちはコストの縛りから、サービス改善の提案へシフトさせることができました。
閾値を何秒にするかによってデータ削減が大きく変動しますが、障害が起きた時の代償も伴います。なかなか一筋縄ではいかないため、都度の見直しが求められます。

• インフラのプロセスデータの停止
  enable_process_metrics: false

• トランザクション・トレースを記録する処理時間の閾値（秒）を設定
  newrelic.transaction_tracer.threshold

• 個々のセグメント（メソッドやDBクエリなどの処理）の処理時間を設定
  newrelic.transaction_tracer.stack_trace_threshold

• スパンイベントの最大数を設定
  newrelic.span_events.max_samples_stored

参考URL
https://docs.newrelic.com/docs/apm/agents/php-agent/configuration/php-agent-configuration/

4. まとめ：APMは「可視化」だけでなく「コスト最適化」のツールでもある

New Relic APMの導入は、ECサイトの信頼性向上という当初の目標を達成する上で不可欠でした。

しかし、その導入効果を最大限に引き出すためには、コストとのバランスを取るチューニングが必須です。

「分散トレーシングですべてのデータを取る必要はない」という教訓のもと、パラメタを適切に設定しました。ただ、この手段は、どうしても予算を追加できない場合の最終手段と考えています。データ取得を制限することで、本当にビジネス価値を最大化できるのか、なかなかビジネス層を説得することは難しいと思います。ですので、オブザーバビリティを導入することで、運用工数や開発者の調査工数をどれだけ軽減できるのか、生産性向上の観点で説得すべきです。

オブザーバビリティへの投資をコストで終わらせてはいけません。私たちは、New Relicの導入効果をデータ取得量ではなく、工数削減と開発生産性の向上という観点で評価するのがよいのではないでしょうか。

具体的には、

• 運用チームの障害調査工数を月間3割削減

• 開発者がログ分析にかけるムダな時間を排除し、コア開発への集中率を30%向上

これにより、New Relicのライセンスコスト以上の効果を実現します。オブザーバビリティは、システムを安定させる保険ではなく、組織全体の生産性を向上させるための投資なのです。

今後も、このAPMデータを元にした恒常的なパフォーマンス改善サイクルを回し続け、より速く、より安定したECサイトを目指していきます。キャプチャがなく経験談をつらつら記載した寂しい記事になってしまいましたが、APM導入を検討されている、または導入後のコストに悩んでいる皆様の参考になれば幸いです。