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

Slide 1

Slide 1 text

New Relicで解決する NewsPicksの本番障害厳選N選（N≧3？）そのオブザーバビリティツール、どう活かした？実践例と効果の全貌 2025/02/26 株式会社ユーザベース / 飯野卓見

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

01  New Relicで解決する本番障害とは？ ©Uzabase Inc. All Rights Reserved.  ❌エラー追跡（Errors Inbox）に記録された例外からバグを特定する。 ⭕アプリケーションの不可解な動作や性能劣化の原因を特定し解決を行う。さまざまな変更の結果少しずつ不安定になってしまった原因をNew Relic APM（アプリケーション性能監視）などで可視化したデータを元に特定し解決していく。よくあるNewsPicksの本番障害としては次のようなものがある。 ● ニュースをプッシュ通知したら先週と同じアクセス数が処理できない。 ● 気づいたらリソース枯渇でサーバーが頻繁に停止する。 ● SLOを確認したらいつからか遅くなっていた≒ユーザー体験が悪くなっていた。

Slide 7

Slide 7 text

01  開発の全体像がわからない状況で障害の原因を特定していく ©Uzabase Inc. All Rights Reserved.  左は2025/01末のリリースカレンダー。この週は 50回リリース※があった。さまざまな意図で複数の施策が並行してリリースされている。開発の全体像が把握できない状況で本番障害を解決するのは難しい。この困難にオブザーバビリティで立ち向かう。 ※iOS/AndroidアプリのリリースやA/Bテストの開始終了は含まない。

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

03  そのまえにNewsPicksのシステム構成を改めて ©Uzabase Inc. All Rights Reserved.  「プロダクト開発エンジニア全員で取り組むオブザーバビリティ」より抜粋スマホアプリ Web Web(Next.js) BFF(Apollo) 共通バックエンド (Spring) 課金広告配信検索推薦 New Relic APM Agent 今回紹介する本番障害は共通バックエンドで発生したものです。  

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

03  本番障害Case2. プッシュ通知時に遅い ©Uzabase Inc. All Rights Reserved.  どんな障害だったか編成チームからプッシュ通知時のアプリの動作が遅いことが共有される。先週は問題なかったアクセス数を満足に処理できなくなってしまった。さらにはプッシュ通知のたびにWeb版NewsPicksが落ちる事態となった。 CEOから緊急の連絡。SREとしてこれでいいのだろうか、、、

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

03  本番障害Case2. プッシュ通知時に遅い ©Uzabase Inc. All Rights Reserved.  New Relicで得た情報を共有して判明した障害発生の背景「Segmentの傾向が変化したタイミング」からアプリのホームタブの並び順が変更されていた。この影響でアプリ起動時のAPIの呼び出し傾向が変化し、APIサーバーに負荷がかかり障害へと繋がってしまった。タブの順序を変えただけなのに、、

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

03  本番障害Case3. コネクションプール枯渇 ©Uzabase Inc. All Rights Reserved.  判明した障害発生の背景社内業務で使う新設APIが非常に遅く、このAPIを短時間にプールサイズ回呼び出すとシステム全体に影響が出ていた。実際のところでは、このAPIを呼び出す画面を使うたびにエラーが発生し最終的にはタスクが停止していた。このAPIは「禁断のAPI」と名付けられた。禁断のAPIにおののく開発者たち

Slide 32

Slide 32 text

03  本番障害Case3. コネクションプール枯渇 ©Uzabase Inc. All Rights Reserved.  対応：API、インフラ禁断のAPIの作り直し。社内システムが利用するための専用ECSサービスを用意し負荷を分離。想定以上の使われ方をしていたので作り直し専用ECSサービスで負荷を分離スマホアプリ  Web  Web  BFF  共通  バックエンド  共通  バックエンド  （社内用）  社内システム  社内 

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

04  まとめ ©Uzabase Inc. All Rights Reserved.  どの障害もオブザーバビリティに取り組んでいなければ原因の特定は困難だった。 ● APMのTransactionsやDatabasesを確認するだけで原因が特定できる障害も多い。 APMは導入してすぐ使えるので即効性がある。 ● ChangeTrackingやSLOアラート（ServiceLevelの定義や通知条件）など情報や道具を揃えていくことで素早い判断や対応が行える。 ● ダッシュボードを整備することでAPMに用意されていないメトリクスも可視化できる。平時の負荷を知れば異常の発見も早くなる ● システムへの理解が浅くても今回紹介した本番障害に立ち向かえる。システムへの理解を深めるツールとしてもオブザーバビリティが使える。 ● （発表者は）New Relic（オブザーバビリティ）なしで本番障害や性能改善に立ち向かうのは難しいと考えるほど頼っている。それくらい強力なツール。

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

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