みんなで育てるNewsPicksのSLO

Slide 1

Slide 1 text

みんなで育てる NewsPicksのSLO 僕のSLOとNew Relic by NRUG Vol.13 2025/03/19 株式会社ユーザベース NewsPicks事業部 / 飯野卓見

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

00  備えるための時間はあった ©Uzabase Inc. All Rights Reserved.  人数が減ることは2024年の後半には予想されていました。大変ですが前向きに「強制的にSREのフェーズを進めるきっかけになった」と捉えています。前SREリーダーのCTO就任  火消し→門番（今）→支持者（次）→触媒実は以前からSREは少ない人数で運用していくための整理や仕組みづくりを進めていました。その一つが（今以上に）「みんなでSLOを育てていくこと」です。

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

01  APMのエンドポイントごとの監視に特化 ©Uzabase Inc. All Rights Reserved.  スマホアプリ Web Web(Next.js) BFF(Apollo) 共通バックエンド (Spring) 課金広告配信検索推薦 New Relic APM Agent 「プロダクト開発エンジニア全員で取り組むオブザーバビリティ」より抜粋ユーザー体験の悪化を検知できなかった反省から、主要なエンドポイントごとの監視に特化してSLOを構築しています。（外形監視としてSynthetic Monitorも併用）

Slide 12

Slide 12 text

01  SLOをセルフサービスで設定できる仕組みを提供 ©Uzabase Inc. All Rights Reserved.  エンドポイントごとのSLOモニタリングの仕組みリポジトリ (GitHub) Export&PR CDK for Terraform New Relic アラートチームチャンネルに通知ダッシュボード確認反映 Slack 開発チーム設定 cdktf deploy ● Service Levels ● Dashboard ● AlertPolicy ● AlertConﬁtion ● Workﬂow SLO DB (Notion)

Slide 13

Slide 13 text

01  SLOをセルフサービスで設定できる仕組みを提供 ©Uzabase Inc. All Rights Reserved.  SLO、ダッシュボード、通知設定まで一括作成 Dashboard ServiceLevel 可用性/レイテンシー ServiceLevel 可用性/レイテンシー APM Entity単位のSLO Transaction（エンドポイント）単位のSLO AlertCondition (バーンレートアラート) AlertCondition (バーンレートアラート) Workﬂow Issue （SLO違反） Alert Policy Destination Channel （通知先のチャンネル） Destination （通知先） NRQLで参照 SLO準拠？ SLO準拠？ SLO違反検知作成通知対象？ SLO違反通知通知設定 Issue作成ポリシー SLOダッシュボード枠で囲ったリソースを作成しています。

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

02  SLOアラートは別チャンネルで調整のち本番に通知する ©Uzabase Inc. All Rights Reserved.  背景：運用初期の頃。プッシュ通知時などのアクセス急増時に必要以上に通知があり、他の重要な通知が埋もれてしまった。これでは運用当番（オンコール担当）が困ってしまう。この状況が続くとSLOへの不信感が出てきてしまう。閾値が厳しすぎるSLOの通知で溢れると運用当番が疲弊してしまう

Slide 18

Slide 18 text

02  SLOアラートは別チャンネルで調整のち本番に通知する ©Uzabase Inc. All Rights Reserved.  対応：デバッグ用通知先で調整。（実際に通知すると頻度がわかりやすい）調整が終わったSLOから本番の通知先を追加する。（検索が便利なのでデバッグ用も並行稼働） Alert Conditionに通知先のタグを設定します。（Alert ConditionのタグはIssueへ反映されます） WorkﬂowのIssue Filterでタグを絞り込むことで複数の通知先に通知します。

Slide 19

Slide 19 text

02  夜間のレイテンシーアラートは通知しない ©Uzabase Inc. All Rights Reserved.  背景：深夜は利用者が少ないのでスケジュールでサーバーの台数を減らしている。このため、日中よりも応答速度が遅くなりがちである。深夜2時から朝方5時ごろにレイテンシーアラートが頻発した時に運用当番はどんな行動を取るべきでしょうか？午前3時から午前4時はレイテンシーアラートのゴールデンタイム！

Slide 20

Slide 20 text

02  夜間のレイテンシーアラートは通知しない ©Uzabase Inc. All Rights Reserved.  そもそもレイテンシーアラートの通知は必要でしょうか？ NewsPicksでの運用では性能劣化の影響範囲をレイテンシーアラートで知ることが何度もありました。なので、日中の通知は必要という考えを持っています。（N+1の追加などを素早く検知できる。可用性は他の通知手段で検知が可能。）右のスライドで紹介している本番障害は最初は可用性のアラートで検知しました。その後、N+1が追加されたエンドポイント以外のレイテンシーアラートがきたことで問題がさまざまな場所に影響していることがわかりました。影響範囲を知れたので障害撲滅委員会（ポストモーテム）で助かりました。「New Relicで解決するNewsPicksの本番障害。厳選N選（N≧3？）」より抜粋

Slide 21

Slide 21 text

02  夜間のレイテンシーアラートは通知しない ©Uzabase Inc. All Rights Reserved.  対応：夜間に多少遅くなるのは許容しているため、対応の必要はありません。対応しないアラートの通知は不要なのでMutingRuleを作成しアラート通知を停止しました。 Alert Conditionにmute対象のタグを設定します。（Alert ConditionのタグはIssueへ反映されます） MutingRuleのFilterでタグを絞り込むことで通知を抑制します。

Slide 22

Slide 22 text

02  編集UIをNotionにしてみる（試行錯誤中） ©Uzabase Inc. All Rights Reserved.  背景：仕組みを作って、SLOを運用してもらって1年。エンドポイント数は190個、設定ファイルは2000行を超えて、整理が困難になってきた。それに加え、組織変更により特定のチームにSLOが集中してしまった。 IaC管理を行うと組織変更による担当変更の反映は簡単です。でも、物量は解決できません。 8タブあるチームが登場

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

03  まとめ ©Uzabase Inc. All Rights Reserved.  NewsPicksではみんなでSLOを育てる仕組みづくりをしています。 ● SLOの運用は開発チームが自ら行っています。 ● 仕組み自体の改善についてもみんなの力を借りています。 ○ SREの発展的解消（SREのゴールの一つ）に向けて進んでいる？課題もあるし、やりたいこともたくさんあります。 ● SLO（ダッシュボード）が太りすぎたのでダイエットしたい。 ● APM以外のSLOを管理する仕組みづくりもしていきたい。 ○ データの鮮度（検索結果、分析に使うデータ）、など今後の展開にご期待ください！！

Slide 28

Slide 28 text