New Relicで解決するNewsPicksの本番障害。厳選N選（N≧3？）

2025/02/26に行われた「そのオブザーバビリティツール、どう活かした？実践例と効果の全貌」の登壇資料です。

資料内のリンク
プロダクト開発エンジニア全員で取り組むオブザーバビリティ
HikariCPのinstrumentation
S3 バケットへの Java ヒープダンプファイルのエクスポート | AWS re:Post
https://github.com/newrelic/nri-ecs

Transcript

1. New Relicで解決する NewsPicksの本番障害 厳選N選（N≧3？） そのオブザーバビリティツール、どう活かした？実践例と効果の全貌 2025/02/26 株式会社ユーザベース / 飯野 卓見
2. 00
 自己紹介 ©Uzabase Inc. All Rights Reserved.
 飯野 卓見 株式会社ユーザベース NewsPicks事業部 SREチーム 2023年入社のSREチームのエンジニアです。 入社前はふつうのRailsエンジニアでした。 NewsPicksではSREとして頑張っています。 好きなこと：依存関係更新 入社前実績 Rails 3 → 5, 6 → 7 入社後実績 Java 8 → 11とSpring 4 → 5 @troter
3. 00
 ソーシャル経済メディア NewsPicksについて ©Uzabase Inc. All Rights Reserved.

4. 1. New Relicで解決する本番障害とは？ 2. NewsPicksのNew Relic導入状況 3. 本番障害。N選 4. まとめ 00
 本日のアジェンダ ©Uzabase Inc. All Rights Reserved.

5. ©Uzabase Inc. All Rights Reserved.
 01
 New Relicで解決する 本番障害とは？
6. 01
 New Relicで解決する本番障害とは？ ©Uzabase Inc. All Rights Reserved.
 ❌エラー追跡（Errors Inbox）に記録された例外からバグを特定する。 ⭕アプリケーションの不可解な動作や性能劣化の原因を特定し解決を行う。 さまざまな変更の結果少しずつ不安定になってしまった原因をNew Relic APM（アプリ ケーション性能監視）などで可視化したデータを元に特定し解決していく。 よくあるNewsPicksの本番障害としては次のようなものがある。 • ニュースをプッシュ通知したら先週と同じアクセス数が処理できない。 • 気づいたらリソース枯渇でサーバーが頻繁に停止する。 • SLOを確認したらいつからか遅くなっていた≒ユーザー体験が悪くなっていた。
7. 01
 開発の全体像がわからない状況で障害の原因を特定していく ©Uzabase Inc. All Rights Reserved.
 左は2025/01末のリリースカレンダー。この週は 50回リリース※があった。 さまざまな意図で複数の施策が並行してリリース されている。開発の全体像が把握できない状況で 本番障害を解決するのは難しい。 この困難にオブザーバビリティで立ち向かう。 ※iOS/AndroidアプリのリリースやA/Bテストの開始終了 は含まない。
8. ©Uzabase Inc. All Rights Reserved.
 02
 NewsPicksの New Relic導入状況
9. 02
 NewsPicksのNew Relic導入状況 ©Uzabase Inc. All Rights Reserved.
 2021年〜2022年 New Relicがさまざまなシステムに導入さる。 「プロダクト開発エンジニア全員で取り組むオブザーバビリティ」より抜粋
10. 02
 NewsPicksのNew Relic導入状況 ©Uzabase Inc. All Rights Reserved.
 2023年 SREを中心にSLOのモニタリングを開始する。 「プロダクト開発エンジニア全員で取り組むオブザーバビリティ」より抜粋
11. 02
 NewsPicksのNew Relic導入状況 ©Uzabase Inc. All Rights Reserved.
 2024年〜 プロダクト開発エンジニア全員でオブザーバビリティに取り組む。 「プロダクト開発エンジニア全員で取り組むオブザーバビリティ」より抜粋
12. ©Uzabase Inc. All Rights Reserved.
 03
 本番障害。N選
13. 03
 そのまえにNewsPicksのシステム構成を改めて ©Uzabase Inc. All Rights Reserved.
 「プロダクト開発エンジニア全員で取り組むオブザーバビリティ」より抜粋 スマホアプリ Web Web(Next.js) BFF(Apollo) 共通 バックエンド (Spring) 課金 広告配信 検索 推薦 New Relic APM Agent 今回紹介する本番障害は共通バックエンドで発生したものです。 

14. ©Uzabase Inc. All Rights Reserved.
 03
 本番障害 Case1. SLOアラート多発
15. 03
 本番障害Case1. SLOアラート多発 ©Uzabase Inc. All Rights Reserved.
 どんな障害だったか SLOアラートが連続して発生した。Webの検索を中心に全体の動作が遅くなった。
16. 03
 本番障害Case1. SLOアラート多発 ©Uzabase Inc. All Rights Reserved.
 New Relicでどうやって原因を特定した？ SLOアラートで通知されたTransactionをAPMで確認。 ChangeTrackingのすぐ後にN+1で遅くなっているのでリリース起因と判明。 ChangeTracking→

17. 03
 本番障害Case1. SLOアラート多発 ©Uzabase Inc. All Rights Reserved.
 解説その1 リリース時にChangeTrackingを作成するとAPMの各種画面に表示される。 リリース起因とすぐに特定できる。 ChatOpsでのリリース時にChangeTrackingを作成
18. 03
 本番障害Case1. SLOアラート多発 ©Uzabase Inc. All Rights Reserved.
 解説その2 APMのTransactionのBreakdown tableに1 Transactionあたりの呼び出し回数が表示 される。N+1の発生がすぐに確認できる。 N+1には色がつくのでわかりやすい
19. 03
 本番障害Case1. SLOアラート多発 ©Uzabase Inc. All Rights Reserved.
 対応 リリース起因なのでリリースを巻き戻す。最適化を行って再リリース。 以前のリリース内容の適用もChatOps
20. ©Uzabase Inc. All Rights Reserved.
 03
 本番障害 Case2. プッシュ通知時に遅い
21. 03
 本番障害Case2. プッシュ通知時に遅い ©Uzabase Inc. All Rights Reserved.
 どんな障害だったか 編成チームからプッシュ通知時のアプリの動作が遅いことが共有される。 先週は問題なかったアクセス数を満足に処理できなくなってしまった。 さらにはプッシュ通知のたびにWeb版NewsPicksが落ちる事態となった。 CEOから緊急の連絡。SREとしてこれでいいのだろうか、、、
22. 03
 本番障害Case2. プッシュ通知時に遅い ©Uzabase Inc. All Rights Reserved.
 New Relicでどうやって原因を特定した？ APMのDatabasesでプッシュ通知時に特定のテーブルに負荷が集中していることを確 認。あるタイミングから特定のAPIの処理傾向が変化していることがわかった。
23. 03
 本番障害Case2. プッシュ通知時に遅い ©Uzabase Inc. All Rights Reserved.
 解説 APMのDatabasesでデータベースごとの操作の割合を確認できる。操作を選択すると Transactionごとの割合が表示でき、そこから問題となるTransactionを特定できる。 データベースの操作から Transactionを特定できる

24. 03
 本番障害Case2. プッシュ通知時に遅い ©Uzabase Inc. All Rights Reserved.
 New Relicで得た情報を共有して判明した障害発生の背景 「Segmentの傾向が変化したタイミング」からアプリのホームタブの並び順が変更さ れていた。この影響でアプリ起動時のAPIの呼び出し傾向が変化し、APIサーバーに 負荷がかかり障害へと繋がってしまった。 タブの順序を 変えただけなのに、、
25. 03
 本番障害Case2. プッシュ通知時に遅い ©Uzabase Inc. All Rights Reserved.
 対応：APIサーバーとアプリ APIの高速化、アプリ起動時のAPI呼び出しの最適化を実施。 処理時間が1/3に！ Android/iOSも爆速で対応
26. 03
 本番障害Case2. プッシュ通知時に遅い ©Uzabase Inc. All Rights Reserved.
 対応：オブザーバビリティ 「スループット / 消費時間 = 処理効率」という性能の目安となるグラフを作成。 処理効率をモニタリングすることで変化に気づきやすくなった。 平時の処理効率と比較することでプッシュ通知時の性能の変化を可視化できる
27. ©Uzabase Inc. All Rights Reserved.
 03
 本番障害 Case3. コネクションプール枯渇
28. 03
 本番障害Case3. コネクションプール枯渇 ©Uzabase Inc. All Rights Reserved.
 何が起きたか 書き込みのJDBCコネクションプールが枯渇しアプリでエラー発生することがあった が、その回数が急激に増えた。この状態になるとほぼ全てのAPIでエラーが発生し、 最終的にはECSタスクが停止するのでELBで大量の50xが発生していた。
29. 03
 本番障害Case3. コネクションプール枯渇 ©Uzabase Inc. All Rights Reserved.
 New Relicでどうやって原因を特定した？ APMのTransactionをエラー追跡（Bugsnag）に記録されたホストで絞り込むこと で、異常な消費時間を記録いているAPIを発見した。
30. 03
 本番障害Case3. コネクションプール枯渇 ©Uzabase Inc. All Rights Reserved.
 解説 APMはホストごとに絞り込みが行える。 全体ではなく個別のホストを深掘りしていくと問題究明の役にたつ。 問題が発生するホストが分かっているならとても有用
31. 03
 本番障害Case3. コネクションプール枯渇 ©Uzabase Inc. All Rights Reserved.
 判明した障害発生の背景 社内業務で使う新設APIが非常に遅く、このAPIを短時間にプールサイズ回呼び出すと システム全体に影響が出ていた。実際のところでは、このAPIを呼び出す画面を使う たびにエラーが発生し最終的にはタスクが停止していた。 このAPIは「禁断のAPI」と名付けられた。 禁断のAPIにおののく開発者たち
32. 03
 本番障害Case3. コネクションプール枯渇 ©Uzabase Inc. All Rights Reserved.
 対応：API、インフラ 禁断のAPIの作り直し。 社内システムが利用するための専用ECSサービスを用意し負荷を分離。 想定以上の使われ方をしていたので作り直し 専用ECSサービスで負荷を分離 スマホアプリ
 Web
 Web
 BFF
 共通
 バックエンド
 共通
 バックエンド
 （社内用）
 社内システム
 社内

33. 03
 本番障害Case3. コネクションプール枯渇 ©Uzabase Inc. All Rights Reserved.
 対応：オブザーバビリティ ホストごとのJDBCコネクションプールの使用率のグラフを作成。 使用率をモニタリングすることで変化に気づきやすい体制を作った。 newrelic-java-agentに含まれるHikariCPのinstrumentationを利用して可視化
34. ©Uzabase Inc. All Rights Reserved.
 04
 まとめ
35. 04
 まとめ ©Uzabase Inc. All Rights Reserved.
 どの障害もオブザーバビリティに取り組んでいなければ原因の特定は困難だった。 • APMのTransactionsやDatabasesを確認するだけで原因が特定できる障害も多い。 APMは導入してすぐ使えるので即効性がある。 • ChangeTrackingやSLOアラート（ServiceLevelの定義や通知条件）など 情報や道具を揃えていくことで素早い判断や対応が行える。 • ダッシュボードを整備することでAPMに用意されていないメトリクスも可視化できる。 平時の負荷を知れば異常の発見も早くなる • システムへの理解が浅くても今回紹介した本番障害に立ち向かえる。 システムへの理解を深めるツールとしてもオブザーバビリティが使える。 • （発表者は）New Relic（オブザーバビリティ）なしで本番障害や性能改善に立ち向かう のは難しいと考えるほど頼っている。それくらい強力なツール。
36. ©Uzabase Inc. All Rights Reserved.
 01
 ご清聴ありがとうございました！
37. ©Uzabase Inc. All Rights Reserved.
 05
 おまけ：（現時点では） New Relicで解決できていない問題
38. 05
 （現時点では）New Relicで解決できていない問題 ©Uzabase Inc. All Rights Reserved.
 OutOfMemoryError java.lang.OutOfMemoryError JVMで発生するOutOfMemoryError。 New RelicにMemoryDump/ThreadDumpの機能があるが使いこなせていない。 発生時にJVMオプションでHeapDumpを取得するのが確実という印象がある。 • S3 バケットへの Java ヒープダンプファイルのエクスポート | AWS re:Post ECSタスクのOutOfMemoryError コンテナに割り当てたメモリより大きなメモリを確保すると発生。 発生時はAPMにメトリクスが送信される前にコンテナがkill -9されてしまう。 New Relic integration for Amazon ECSで調査しているが解決できていない。 • https://github.com/newrelic/nri-ecs