New RelicでNewsPicksのユーザー体験の変化をモニタリングし継続的に改善する

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

株式会社ユーザベース / Takumi Iino

メンバー / SRE / 従業員規模: 1,001〜5,000名

最終更新日2025/01/15投稿日2025/01/14

利用プラン

利用機能

ツールの利用規模

ツールの利用開始時期

事業形態

Pro

APM, Browser, Infrastructure, Dashboards

11名〜50名

2020年11月

B to B

B to C

利用プラン	Pro
利用機能	APM, Browser, Infrastructure, Dashboards
ツールの利用規模	11名〜50名
ツールの利用開始時期	2020年11月
事業形態	B to B B to C

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャの意図・工夫

デプロイフローでChange Trackingを作成

Change Trackingを作成すると、APMの各画面、ServiceLevel詳細、およびAPMメトリクスのダッシュボードにChange Trackingが表示されます。これにより、性能劣化やエラーがどのデプロイから発生したのかが一目で分かります。

CDK for TerraformによるSLOのIaC管理

SLOモニタリングには、ServiceLevelsの作成が必要です。SLO違反の検出にはAlertConditionとAlertPolicyが、通知にはWorkflowの作成が必要となります。ServiceLevelの対象となるTransactionのSegment breakdownを確認できるダッシュボードがあるとさらに便利です。

これらを管理するためにCDK for Terraform（とTerraform NewRelic Provider)を利用しています。手動での作成では、サービスの変更に伴うSLOの増減や組織変更による通知先の変更に多大なコストがかかります。一方IaC管理では、コード上でSLOや通知先を変更し適用するだけで New Relic のリソースを更新できます。開発チームが直接SLOの変更と適用を行えるため、SLO運用の民主化を実現できました。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

NewsPicksにNew Relicを導入する以前は、以下の監視体制を採用していました。

リソース監視（CloudWatch）
エラー監視（Bugsnag）
外形監視（自前実装）

これらの監視システムはシステム全体の状態を把握することはできましたが、プッシュ通知時のユーザー体験の悪化や、個別APIの監視、性能の経時的な変化を可視化することができませんでした。

この課題を解決するため、NewRelic（APM, Alerts）を導入し、主要APIのレスポンスタイムとエラー率の監視を実施することにしました。

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

個別のAPIに対する監視を強化し、ユーザー体験の悪化を検知することが主な目的です。

ユーザー体験の悪化につながる個別のAPIに対する監視の強化
- 時系列での性能変化の可視化
- 性能劣化原因の調査の簡易化
- エラー率の可視化
分散トレーシング機能によるweb/bff/apiの通信の可視化と串刺しでのパフォーマンス計測
SLOの管理とエラーバジェットによるSLOアラートの通知の実現

導入の成果

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

APMのTransactionによりAPI単位での時系列の性能変化が可視化され、性能劣化原因の調査も容易になりました。
分散トレーシングによりシステムを跨いだパフォーマンス調査が可能となりました。
ServiceLevelとAlertsによりユーザー体験悪化につながるAPIのエラーバジェットによるアラート通知が実現できました。

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

継続的な性能改善や安定性改善のための情報が得られました。
クリティカルユーザージャーニーと定めたユーザー体験の悪化を検知しエラーバジェットに応じてSlackへの通知を行う仕組みが構築できました。
- 担当チーム外の変更による副作用としての性能劣化、ABテストによる性能劣化を早期に検知し、必要以上にユーザー体験が悪化する状況を回避できました。
開発チームが担当SLOのAPIをモニタリングする文化が醸成されました。
- リリース後のパフォーマンス監視と改善が自発的に行われるようになりました。

導入に向けた社内への説明

上長・チームへの説明

2020年当初はSREやチームリーダーを対象に小さく導入していたようです。

2024年の契約更新時に開発者全員が使えるよう変更しました。主に次の二つの実績をもとに予算を確保しました。

New Relicによる改善実績（APMを使った性能改善や安定性改善）の蓄積
New Relicにかかる費用の数倍以上の大きなAWSコスト削減

活用方法

週次

チームが担当する機能に応じてSLOを割り当ており、週次でSLOモニタリングを行っています。

日次

チームや個人で性能改善を扱っている場合は毎日のようにAPMを開いて状況確認や性能改善のヒントを得ています。クライアントアプリ変更によってAPIの呼び出し傾向が変化したり、A/Bテスト開始前後で性能が変化したりすることがよくあります。平時のスループットや性能を認識しておくことが重要だと考えています。

不定期

ユーザー体験に影響があることがわかっている変更をリリースした場合に利用しています。

プッシュ通知時にスループットが増えるAPIなどを、性能変化の影響が大きいAPIを修正した後に想定外のユーザー体験悪化がないかを確認します。
- 特にクリティカルユーザージャーニーとして定めたユーザー体験については継続的に確認しています。
性能改善を行った後に本番のデータでも期待する性能が出ているかを確認します。

トラブル発生時に発生原因特定のヒントを得るために利用しています。

発生原因を探るためにAPMのTransactionやErrorsを確認します。
運用で利用しているダッシュボード（サーバーごとの消費時間、スループット、コネクションプール使用率など）を確認します。
リリース起因の場合、ChangeTrackingによって原因が一目でわかるので重宝しています。

よく使う機能

APM
- Transactions
- Databases
- Threads
- JVM
- Errors
- Metric Explorer
ダッシュボード
NRQL
Alerts
Manage Your Data

ツールの良い点

APMに十分な項目があり、WebUIを操作するだけですぐに性能改善のヒントが得られること。
NRQLによって柔軟な分析が行えること。
ほぼ全てのグラフからNRQLが取得できること。
- 既存のグラフのカスタマイズが簡単に行える。
- 段階的にダッシュボードの改善が行える。
Metric ExplorerやNerdGraph API Explorerといったデータ閲覧用ツールが用意されていること。
- WebUIで探索的にデータの閲覧が行える。
- 結果をすぐにダッシュボードに反映できる。
newrelic-agent-javaに組み込まれているinstrumentationが豊富なこと。
- 新しいinstrumentationのサポートも頻繁に追加されている。
- Experimentalなinstrumentationも提供されている。

ツールの課題点

契約容量と分散トレーシングの兼ね合い。
- サーバー数（ECSタスク数）に比例してMetrics, APM Events, Tracingのデータ量は増える。
- 契約容量に合わせてサンプリングを調整しているが、減らしすぎると分散トレーシングが機能しなくなる。
SLOの数が多い場合はツールの補助が必要なこと。
- 手動管理はすぐ属人化してしまう。
- 変更のコストが大きい。