New Relicでパフォーマンス改善、ボトルネックの特定を効率的に。Agentのインストールで簡単に利用開始できる。

ツール導入前の課題

New Relicの導入以前は担当するサービスのリショップナビに関して、技術負債が貯まり重要ページのパフォーマンスが悪化していました。

そのため、悪化原因を素早く把握して改善する必要がありました。

1. パフォーマンス改善など定期的に実施しているが、エンジニアの経験によるチューニングでend to end（ブラウザ⇄システム）のボトルネックの可視化ができていない(調査工数の増大)
2. システム全体のパフォーマンス、状態に関する可視化ができていない
3. システムを構成しているサーバ、DBなどリソースごとはおえても、全体としての前後比較ができず、調査が難航するケースも多々あり
4. ユーザの体験の低下に関するシステム監視ができていない

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

1. システム全体でのパフォーマンス劣化の早期検知、早期改善
2. エラー検知、対応のフロー設定
3. フロントエンドのエラー検知
4. ユーザ体験トータルでの観測(core web vital)

• Datadog

• 利用料金が抑えられること
• 現在いるメンバーがキャッチアップしやすく、すぐに使えること

New Relicを別のサービスで活用していたメンバーがいたため。

また、ユーザ数とデータ量の課金なので、料金がよみやすいです。機能ごとの課金がなく、全ての機能が安心して試せるのは良かったです。(IAST機能などが実装され、現在は少し違ってきているかもしれないです)

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

• 開発者の勘や、ソースコードの調査によって解消していたボトルネックを早期に特定し対応することができた
• ソースコード初見の方でも、パフォーマンス改善のIssueをご対応いただくことが容易になった
• フロントエンドから、バックエンド、外部システムも含めてのパフォーマンスの可視化が容易になった

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

• 異常発生に素早く気づき、原因究明までの時間を削減することができるようになった
• Erros in boxを活用することで、ベトナムのチームでもエラー対応がスムーズに行えるようになった
• SRE、オブザーバビリティに関する理解がチーム内で促進され、改善活動に活かすことができるようになった

私たちの目的（バックエンドの）APMエージェントをインストールするだけですぐに使えるので、特に苦労したことはなかったです。

一方で、組織の中でSREというロールがなく、経験もあるメンバーもいなかったため、オブザーバービリティを理解しているメンバーがおらず、フル活用するという上でオブザーバービリティという概念をキャッチアップするために、New RelicのWebマニュアル、勉強会、書籍などでキャッチアップする必要はありました。

お試しであれば簡単に無料で試せるので、テスト環境で使用感を確認してみるといいと思います。
機能追加も活発に行われています。New Relicのユーザーグループのイベントでは定期的に新機能の紹介などもされているので、覗いてみるといいと思います。

現在、専任担当をつけられていないためつけて改善していきたいと考えています。

• ダッシュボードの充実化
• Observerbility as Codeの実践
• ビジネス部門の各部署を巻き込んでの改善活動(SLI、SLO運用)