はじめに
こんにちは！千株式会社 システム開発部 横断開発課でSREをしている@youmjwwです。SEN Advent Calendar 2025の2日目になります！
昨日はおはぎ（@ohagi_dev）さんによる進捗報告の朝会からチーム全員で場をつくるデイリースクラムへをお届けしました。
AWS を中心にインフラ設計・構築・運用を担当する中で、監視ツールにNewRelicを新規導入する案件に携わりました。
導入の目的は明確でしたが、導入直後には予期せぬコスト超過や、Fargate環境でAPMエージェントが原因となりサービス自体がダウンするという重大なトラブルに直面しました。
本記事では、実際に私がNewRelicを導入する中で直面した具体的な5つの苦労点とその解決策、そして最終的にパフォーマンスを20倍改善できた経緯をまとめます。同じように導入を検討している方の実戦的なトラブルシューティングの参考になれば幸いです。
導入背景：なぜNewRelicが必要だったのか
既存の監視基盤は CloudWatch や Zabbix を中心に構成されていました。しかし、サービス改善サイクルを高速に回すため、以下の機能不足が課題となっていました。
- アプリケーション内部のトレース（APM) や、外形監視などの統合的な実施。
そこで、APM・インフラ監視・ログ管理・SLO 可視化をNewRelicで一元化し、オブザーバビリティ（可観測性）を高めるために導入を決定しました。
また、弊社では一部プロダクトへOpenTelemetry + Grafanaでオブザーバビリティ環境を構築しています。
参考記事
新たなプロダクトへオブザーバビリティ基盤を導入するにあたり、プロダクトチームや担当者が未経験分野で導入するため、今回はSaaSであるNewRelicを選択しました。
導入時に直面した5つの苦労と解決策
1. 環境ごとに異なる Agent 設定の複雑性
NewRelic APM やインフラエージェントは、言語やデプロイ環境によって設定項目が微妙に異なり、特にコンテナ環境（ECS/Fargate）やマルチアカウント構成では、設定ファイルの整合性を維持するのに苦労しました。
【教訓】
統一されたデプロイメントツールで設定をコード化し、環境変数を中心に管理することで、設定の属人化を防ぐことが重要です。
2. NRQLの壁：独自のクエリ言語による可視化の再構築
NewRelic は可視化機能が豊富な反面、柔軟なダッシュボードやアラートを実現するには、NRQL（New Relic Query Language） の習得が必須でした。
CloudWatch Dashboardでは簡単に作れていた SLO（Service Level Objective）可視化も、NewRelicのデータ構造を深く理解し、NRQLで一からクエリを再構築する必要があり、初期の立ち上げに時間を要しました。
3. Fargateでの落とし穴：同期通信によるサービスボトルネック
これが最も深刻な問題でした。
弊社の場合、ECS Fargate に NewRelic APM を導入した際、エージェントとデータ送信デーモンを同じコンテナ内で起動していました。これにより、アプリケーションがリクエストを処理する際に、NewRelicへのデータ送信を同期的に行ってしまう構成になっていました。
APM導入直後は問題無かったのですが、ピークの時間帯に同期通信のオーバーヘッドが顕在化し、ボトルネックとなってサービス応答が極端に遅延するという深刻な課題が発生しました。
【解決策】
データ送信デーモンを別コンテナ（サイドカー）として実行するように構成を変更しました。これにより、NewRelicへのデータ送信を非同期で行うことが可能となり、アプリケーションパフォーマンスへの影響を排除し、問題を解決しました。
4. ログフィルタリングの失敗：ストレージ圧迫とコスト増
オブザーバビリティ向上のため、APMからのログをNewRelicにすべて送る設定にしていました。しかし、すべてのログレベル（DEBUG, INFO, WARN, ERROR）のログを送信した結果、不必要にストレージを圧迫してしまいました。
【解決策】
ストレージコストを抑えるため、APMからのログは一旦 ERROR レベル以上のログのみを送信するようにフィルタリングし、ストレージ節約を図りました。
5. ストレージ使用量の爆発：全量送信設定によるストレージ契約の3倍超え
NewRelicを導入したのだからと、AWS側と行き来する手間を省くため、すべてのメトリクスやすべてのログをNewRelicへ転送する 「全量監視」 の設定にしました。
その結果、ストレージ使用量が契約の3倍にまで膨れ上がってしまうというコスト上の大失敗を経験しました。
【解決策】
想定していたコストを大幅に超過したため、以下の見直しを徹底的に行い、ストレージ容量の削減に務めました。
- NewRelicへ送信するAWSメトリクスの厳密な選定
- ログのフィルタリング（前述の通り）
- セッションリプレイのサンプリング率の調整
- 不必要なサービスで有効になっていた分散トレーシングの無効化
NewRelicを入れてみてどうだったか：パフォーマンス20倍改善の実現
多くの苦労を乗り越えましたが、NewRelicを導入した最大の成果は、サービスのボトルネックが「データ駆動」で可視化されたことです。
具体的には、プロダクトチームと協力しAPMのトレース機能でデータを確認し、特定のデータベースクエリの実行計画においてインデックスが適切に使われていないことが明らかになりました。
このインデックス不足を改善したところ、クエリ効率が劇的によくなり、アプリケーションのパフォーマンスが最終的に20倍良くなるという劇的な成果を達成しました。
この成功体験により、SREの活動として理想とされる
観測（NewRelic） → 実装（改善） → 効果測定（NewRelic） → 次回の改善計画
を高速で回せるようになり、「計測なくして改善なし」の原則を体現できました。
今後の展望：NewRelicを文化にするために
NewRelicのような運用ツールは、導入するだけでなく、文化として根付かせなければ「金をドブに捨てたようなもん」になりかねません。今後は、NewRelicの運用をプロダクトチームへ定着させるための活動に力を入れていきます。
- NewRelicなど運用ツールを早期に文化創生し、活用を進める
- 監視レビュー会の定着と、NRQL知見の共有
- NewRelicをチームのエンジニアへトレーニング
- アプリエラーの Slack 通知の整備とノイズ削減
- トラブルシュート手順書のテンプレ化とナレッジの蓄積
さいごに
ここまでお読みいただきありがとうございます。
本記事は導入編となりますが、具体的な改善の話はこちらをご参照ください。
新卒でもできた！New Relic の言う通りにしただけで39倍早くなったIndex改善
さて、SEN Advent Calendar 2025 3日目となる明日は kawata さん！ laravelアプリケーションで環境変数を管理する手法 実例
をお届けします。お楽しみに♪
千株式会社では共に幼保業界や写真業界のDXを進めていく仲間を募集しています！