みんなで育てるNewsPicksのSLO

2025/03/19に行われた「僕のSLOとNew Relic by NRUG Vol.13」の登壇資料です。

資料内のリンク
プロダクト開発エンジニア全員で取り組むオブザーバビリティ
New Relicで解決するNewsPicksの本番障害。厳選N選（N≧3？）

Transcript

1. みんなで育てる NewsPicksのSLO 僕のSLOとNew Relic by NRUG Vol.13 2025/03/19 株式会社ユーザベース NewsPicks事業部 / 飯野 卓見
2. 00
 自己紹介 ©Uzabase Inc. All Rights Reserved.
 飯野 卓見 株式会社ユーザベース NewsPicks事業部 SREチーム 2023年入社。2025年3月から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. ©Uzabase Inc. All Rights Reserved.
 00
 NewsPicksのSREチーム を取り巻く状況
5. 00
 突然ですがここでクイズです ©Uzabase Inc. All Rights Reserved.
 この数字の変化は何の変化でしょうか？みなさん予想してみてください。 2023/01 2025/03 6 3 →
6. 00
 この数字の変化は。。。 ©Uzabase Inc. All Rights Reserved.
 SREチームのチームメンバー数です。 2023/01 2025/03 6 3 → （SREチームだけでSLOを運用していく体力がないんだよなぁ。。）
7. 00
 備えるための時間はあった ©Uzabase Inc. All Rights Reserved.
 人数が減ることは2024年の後半には予想されていました。 大変ですが前向きに「強制的にSREのフェーズを進めるきっかけになった」と捉えています。 前SREリーダーのCTO就任
 火消し→門番（今）→支持者（次）→触媒 実は以前からSREは少ない人数で運用していくための整理や仕組みづくりを進めていました。 その一つが（今以上に）「みんなでSLOを育てていくこと」です。
8. 1. NewsPicksのSLO運用 2. 運用上の工夫 3. まとめ 00
 本日のアジェンダ ©Uzabase Inc. All Rights Reserved.

9. ©Uzabase Inc. All Rights Reserved.
 01
 NewsPicksのSLO運用
10. 01
 担当チームがユーザー体験（CUJ）のSLOを運用する ©Uzabase Inc. All Rights Reserved.
 CUJ/SLOの運用のルールにしたがって担当チームが運用しています。 （開発チームは8〜10チームあり、それぞれがメンテナンスを行っている）
11. 01
 APMのエンドポイントごとの監視に特化 ©Uzabase Inc. All Rights Reserved.
 スマホアプリ Web Web(Next.js) BFF(Apollo) 共通 バックエンド (Spring) 課金 広告配信 検索 推薦 New Relic APM Agent 「プロダクト開発エンジニア全員で取り組むオブザーバビリティ」より抜粋 ユーザー体験の悪化を検知できなかった反省から、主要なエンドポイントごとの監視に 特化してSLOを構築しています。（外形監視としてSynthetic Monitorも併用）
12. 01
 SLOをセルフサービスで設定できる仕組みを提供 ©Uzabase Inc. All Rights Reserved.
 エンドポイントごとのSLOモニタリングの仕組み リポジトリ (GitHub) Export&PR CDK for Terraform New Relic アラート チームチャンネル に通知 ダッシュボード 確認 反映 Slack 開発チーム 設定 cdktf deploy • Service Levels • Dashboard • AlertPolicy • AlertConfition • Workflow SLO DB (Notion)
13. 01
 SLOをセルフサービスで設定できる仕組みを提供 ©Uzabase Inc. All Rights Reserved.
 SLO、ダッシュボード、通知設定まで一括作成 Dashboard ServiceLevel 可用性/レイテンシー ServiceLevel 可用性/レイテンシー APM Entity単位のSLO Transaction（エンドポイント）単位のSLO AlertCondition (バーンレートアラート) AlertCondition (バーンレートアラート) Workflow Issue （SLO違反） Alert Policy Destination Channel （通知先のチャンネル） Destination （通知先） NRQLで参照 SLO準拠？ SLO準拠？ SLO違反検知 作成 通知対象？ SLO違反通知 通知設定 Issue作成 ポリシー SLOダッシュボード 枠で囲ったリソースを 作成しています。
14. 01
 実際に作成しているダッシュボード ©Uzabase Inc. All Rights Reserved.
 チームごとのタブ 可用性SLO 準拠率 レイテンシーSLO 準拠率 Transactionの Segment brakedown エンドポイントの説明 ServiceLevelのリンク チームのタブを見ることで 担当のエンドポイントの モニタリングを行っています。
15. 01
 SLOによって発生するコミュニケーション ©Uzabase Inc. All Rights Reserved.
 担当しているチームが性能劣化原因を調査＆変更したチームに共有。 SREを介さず当事者同士で解決する動きが習慣化しています。
16. ©Uzabase Inc. All Rights Reserved.
 02
 運用上の工夫
17. 02
 SLOアラートは別チャンネルで調整のち本番に通知する ©Uzabase Inc. All Rights Reserved.
 背景： 運用初期の頃。プッシュ通知時などのアクセス急増時に必要以上に通知があり、他の重 要な通知が埋もれてしまった。これでは運用当番（オンコール担当）が困ってしまう。 この状況が続くとSLOへの不信感が出てきてしまう。 閾値が厳しすぎるSLOの通知で溢れると運用当番が疲弊してしまう
18. 02
 SLOアラートは別チャンネルで調整のち本番に通知する ©Uzabase Inc. All Rights Reserved.
 対応： デバッグ用通知先で調整。（実際に通知すると頻度がわかりやすい） 調整が終わったSLOから本番の通知先を追加する。（検索が便利なのでデバッグ用も並行稼働） Alert Conditionに通知先のタグを設定します。 （Alert ConditionのタグはIssueへ反映されます） WorkflowのIssue Filterでタグを絞り込むことで複数の通知先に通知します。
19. 02
 夜間のレイテンシーアラートは通知しない ©Uzabase Inc. All Rights Reserved.
 背景： 深夜は利用者が少ないのでスケジュールでサーバーの台数を減らしている。このため、日中 よりも応答速度が遅くなりがちである。 深夜2時から朝方5時ごろにレイテンシーアラートが頻発した時に運用当番はどんな行動を取 るべきでしょうか？ 午前3時から午前4時はレイテンシーアラートのゴールデンタイム！
20. 02
 夜間のレイテンシーアラートは通知しない ©Uzabase Inc. All Rights Reserved.
 そもそもレイテンシーアラートの通知は必要でしょうか？ NewsPicksでの運用では性能劣化の影響範囲をレイテンシーアラートで知ることが何度も ありました。なので、日中の通知は必要という考えを持っています。 （N+1の追加などを素早く検知できる。可用性は他の通知手段で検知が可能。） 右のスライドで紹介している本番障害は最初は可用性の アラートで検知しました。その後、N+1が追加された エンドポイント以外のレイテンシーアラートがきたことで 問題がさまざまな場所に影響していることがわかりました。 影響範囲を知れたので障害撲滅委員会（ポストモーテム）で 助かりました。 「New Relicで解決するNewsPicksの本番障害。厳選N選（N≧3？）」より抜粋
21. 02
 夜間のレイテンシーアラートは通知しない ©Uzabase Inc. All Rights Reserved.
 対応： 夜間に多少遅くなるのは許容しているため、対応の必要はありません。 対応しないアラートの通知は不要なのでMutingRuleを作成しアラート通知を停止しました。 Alert Conditionにmute対象のタグを設定します。 （Alert ConditionのタグはIssueへ反映されます） MutingRuleのFilterでタグを絞り込むことで通知を抑制します。
22. 02
 編集UIをNotionにしてみる（試行錯誤中） ©Uzabase Inc. All Rights Reserved.
 背景： 仕組みを作って、SLOを運用してもらって1年。 エンドポイント数は190個、設定ファイルは2000行 を超えて、整理が困難になってきた。 それに加え、組織変更により特定のチームにSLOが 集中してしまった。 IaC管理を行うと組織変更による担当変更の反映は簡単です。 でも、物量は解決できません。 8タブあるチームが登場
23. 02
 編集UIをNotionにしてみる（試行錯誤中） ©Uzabase Inc. All Rights Reserved.
 対策： 一覧性が悪いコードでの管理からNotion管理へ。Notion DBをエクスポートしたCSVをコ ミットする方式に変更。絶賛整理中です。
24. 02
 工夫：仕組みの改善にもみんなの力を借りる ©Uzabase Inc. All Rights Reserved.
 どんな組織でも波はあります 背景： 冒頭で話した通りSREは大ピンチ！
25. 02
 工夫：仕組みの改善にもみんなの力を借りる ©Uzabase Inc. All Rights Reserved.
 チームで解決できない時は他のチームの協力を仰ぎましょう。 。Notionを編集UIにする対応も委員会の成果です。これから試行錯誤していくぞ！ 対応： 性能に関する感度の高いPlatform Enginneringチームの協力の元、SLOの仕組み改善を 委員会として取り組んでいます。
26. ©Uzabase Inc. All Rights Reserved.
 03
 まとめ
27. 03
 まとめ ©Uzabase Inc. All Rights Reserved.
 NewsPicksではみんなでSLOを育てる仕組みづくりをしています。 • SLOの運用は開発チームが自ら行っています。 • 仕組み自体の改善についてもみんなの力を借りています。 ◦ SREの発展的解消（SREのゴールの一つ）に向けて進んでいる？ 課題もあるし、やりたいこともたくさんあります。 • SLO（ダッシュボード）が太りすぎたのでダイエットしたい。 • APM以外のSLOを管理する仕組みづくりもしていきたい。 ◦ データの鮮度（検索結果、分析に使うデータ）、など 今後の展開にご期待ください！！
28. ©Uzabase Inc. All Rights Reserved.
 01
 ご清聴ありがとうございました！