BASE株式会社におけるNew Relicの導入と活用

導入にあたっては以下の資料も合わせてご確認ください。

New Relicを全社導入するときに必要なこと / 20221213_NRUG_newrelic

• 〜2020年頃: SRE + 特定メンバーで先行利用
• 2021年2月: プロダクト開発組織 全体に対するオンボーディングを実施（New Relic 担当者とのインタラクティブな形式）

ツール導入前の課題

アプリケーション開発者は普段の業務でオブザーバビリティのデータに触れる機会が限られており、インフラ監視は Mackerel、エラー通知は Sentry、その他はアプリケーションログ、という目的別に分散した構成の中で、開発者が自分の機能の挙動を内部から観測する手段が薄い状況でした。

2020年ごろからのEC需要の増加により、サービスへのアクセスが急増。その結果、アクセスに耐えられないようなタイミングもありました。それらの対応時に「あの人なら原因がわかる」に依存して属人化し、調査経路が組織のナレッジとして残りにくい。改善の効果測定も「たぶん大丈夫」「なんとなくこの閾値」といった感覚値に近い判断にならざるを得ない、というような状況でした。

どのような状態を目指していたか

プロダクト開発エンジニア全員がオブザーバビリティのデータに日常的に触れる状態を目指しました。特定のチームやメンバーが状態を把握して責任を負うのではなく、自分たちが開発しているサービスの状況を全てのエンジニアが把握できている状態を目指しました。

検討対象として並べたのは下記です（カテゴリ別）。

• APM／統合オブザーバビリティ: New Relic、Datadog
• メトリクス／インフラ監視: Mackerel（既存）
• エラートラッキング: Sentry（既存）

「既存ツールの組み合わせ」も継続案として明確に置いたうえで比較しました。

トランザクション・データベース・外部 HTTP コールが自動計装されること、カスタム属性で業務ドメインの軸を足せること、ログとトレースが繋がることなどを重視しました。

APM・Infrastructure・Logs・アラート・SLI/SLO を1ツールで横断できる統合プラットフォーム性、チーム全員に広げて使える学習コストと表現力のバランス、サポート体制などが決め手になりました

改善したかった課題はどれくらい解決されたか

内部の挙動の把握については、New Relicで自動で計測されるデータを用いることで、かなり解像度は上がりました。

障害対応の属人化については、ダッシュボードなどを整備したことにより、ある程度属人性はなくなりましたが、調査が得意なメンバーとそうでないメンバーの差はまだある状況です。

どのような成果が得られたか

各種改善プロジェクトが発足。New Relicのデータやダッシュボードなどを活用することで、現状の課題と改善効果を可視化し改善を実施することができました。

• 購入完了メールの配信遅延を解消: APMでボトルネックを特定し改善策を検討・実施し、クーポン配布・TV影響タイミングでもユーザー体験を維持できるようになった
• 注文検索の最大レイテンシを 190秒 → 3秒以下 に短縮（MySQLからOpenSearchへの移行の要否判断・効果測定をNew Relicで実施）
• サービスレベル定点観測会の発足。月次でSLOサマリーを共有し、組織として「ユーザー体験の状態」を会話できる土台ができた

• 「入れただけ」になりやすい: APMエージェントを入れても、最初の数ヶ月は「ダッシュボードを開く人が決まった一部」という状況になりがちだった
  • → New Relic主催のワークショップや社内での勉強会などを通じて、習熟度が向上することにより解消していきました。
• 計装のカスタマイズ: アーキテクチャや実行環境の差で自動計装がうまくいかず、独自の実装などをしている箇所もある
• コスト: Full Platform ユーザー数の管理やCCUは継続的にチューニングが必要で、棚卸しサイクルを仕組み化するまでは負担に感じる場面があった

重要なのは導入をゴールにしないことだと思います。New Relicを入れるのは1日でできますが、本当の価値は SLI/SLO・標準ダッシュボード・アラート設計を組織の運用に組み込んでからです。そのために、最初に「何を守るか」の優先順位で定義しておくと、すべてを同じ熱量で監視しようとして破綻する事態を避けられると思います。

計装は機能と同時に設計することを原則とすることでオブザーバビリティの向上にもつながります。

活用状況でも記載しましたが、最近は運用へのAIの組み込みを進めています。内製のアラート分析ツール（Claude Agent SDK + MCP）でアラートトリアージの属人性を排除し、誰でもアラートの初期調査を実施できるようにしています。

また、New RelicのリソースのIaC（Terraform利用）も進めております。

中長期的には、 PAY ID / BASE などサービスをまたいだ可視化に活用してサブシステム間の影響範囲を一目で把握できる状態を目指したいと考えています。また、New Relic Lens で BigQuery / MySQL 等の外部データソースを横断分析する検証も進めて、ビジネスメトリクスと運用メトリクスを同じダッシュボードで扱える基盤を構築したいと考えています。