SREチームで始めたSLOモニタリングを プロダクト開発組織に拡大している話

14.5K Views

August 23, 23

#SRE #SLOモニタリング #NewsPicks #株式会社ユーザベース #信頼性

スライド概要

みんなで考えるシステムの安定運用Night〜信頼性から紐解くこれからの開発〜 の発表資料です
https://findy.connpass.com/event/292034/

profile-image
スライド一覧

経済ニュースアプリのSREの仕事をしています。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

ダウンロード(pdf - 3.15MB)

関連スライド

slide-thumbnail

3年間運用したCDKの失敗から学ぶCDK開発のプラクティス
user-img Yuki Ando 123.9K
slide-thumbnail

意外とマネージドなECS on EC2の運用
user-img Yuki Ando 112.1K
slide-thumbnail

SREチームがNew Relicを使って AWSコスト最適化に貢献した話
user-img Yuki Ando 70.5K
slide-thumbnail

AWSコストを全体で43.75%削減するためのコストモニタリング技術
user-img Yuki Ando 64.2K
slide-thumbnail

プロダクト開発エンジニア全員で取り組むオブザーバビリティ
user-img Yuki Ando 50.4K
slide-thumbnail

最高の開発者体験を目指してAWS CDKでCI/CDパイプラインを改善し続けている話
user-img Yuki Ando 46.6K
各ページのテキスト
1.

SREチームで始めたSLOモニタリングを プロダクト開発組織に拡大している話 株式会社ユーザベース 安藤裕紀 2023.8.23 みんなで考えるシステムの安定運用Night〜信頼性から紐解くこれからの開発〜 LT

2.

00 自己紹介 安藤 裕紀 / Yuki Ando NewsPicks SREチームリーダー 大手SIerで10年半エンジニア/アーキテクトとしてアプリケーション 開発、インフラ構築、クラウド活用コンサルティングなど大企業の 技術支援を行った後、2021年10月よりニューズピックス入社。 現在の仕事はSREチームのリードとエンジニア採用の推進。 ©Uzabase, Inc. All Rights Reserved.

3.

01 NewsPicksとプロダクト開発組織 ©Uzabase, Inc. All Rights Reserved.

4.

01 ソーシャル経済メディア NewsPicksについて タイトルタイトルタイトルタイトルタイトルタイトルタイト ルタイトルタイトルタイトル テキストテキストテキストテキストテキストテキストテ キストテキストテキストテキストテキストテキストテキ ストテキストテキストテキストテキストテキストテキスト テキストテキストテキストテキストテキストテキストテ キストテキストテキストテキストテキストテキストテキ ストテキストテキストテキストテキストテキストテキスト テキストテキストテキストテキストテキストテキストテ キストテキスト ©Uzabase, Inc. All Rights Reserved.

5.

01 NewsPicksはユーザベースのtoCサービス事業です ユーザベースは「経済情報の力で、誰もがビジネスを楽しめる世界をつくる」をパーパスに掲げ、経済情報に特化 した複数のサービスを運営しています。お互いの事業間での情報交換・人材交流なども活発に行われています。 ©Uzabase, Inc. All Rights Reserved.

6.

01 NewsPicksのプロダクト開発組織、エンジニア体制 ユーザベースグループ内にNewsPicks独自のプロダクト開発組織があり、70名ほどのエンジニアが在籍しています ユーザベースグループ(約1,200名※業務委託含む) NewsPicks Product Division (15Unit 約100名) プロダクト マネージャー NewsPicksエンジニア (11Unit 約70名) App Reader Experience Unit Creator Experience Unit Base Reader Experience Unit Marketing Product Unit BizPremium Product Unit Topics Experience Unit BrandDesign Unit Web Experience Unit デザイナー カスタマーサポート ©Uzabase, Inc. All Rights Reserved. Mobile App Unit Data/Algorithm Unit SRE Unit (6名) このチームから SLOモニタリン グ始めてます

7.

02 SLOモニタリングどうやって始めたか ©Uzabase, Inc. All Rights Reserved.

8.

02 サービスレベル目標(SLO) 顧客体験(CUJ)からSLIを決め、SLOを設定してサイトの信頼性を定量評価していくもの ©Uzabase, Inc. All Rights Reserved.

9.

02 SREチームはクリティカルユーザージャーニーを補足できていなかった CUJの補足 「アプリが開けない と困るだろう」 「ニュース記事は早 く読みたいよね」 くらいの浅い理解 ©Uzabase, Inc. All Rights Reserved. SLIの計測 サーバーへのリクエ ストは全てアクセス ログにあるので、 status 5XX以外の割 合と処理時間の平均 SLOの策定 サーバーへの全リク エストを対象に 現状のSLIから可用性 ・レイテンシーの SLOを策定

10.

02 当初、SLIの計測はアクセスログをRedshiftに入れてBIツールで可視化 事業KPIを集計・分析するためのログ収集・データ基盤があったので、そこに相乗り ©Uzabase, Inc. All Rights Reserved.

11.

02 SLIをBIツールで可視化して、Slackに通知していた 日別のSLO達成状況やエラーの兆候をSREチームのスプリント計画や朝会で確認 Slackに Dailyで 送信 ©Uzabase, Inc. All Rights Reserved.

12.

02 一旦、バックエンドへの全てのリクエストを対象にSLOを設定した ひとまずSLIの現状をもとに教科書的なSLOを設定 (サイトリライアビリティワークブックを参考) SLIの種類 SLI ユーザーのタイプ SLO 可用性 リクエスト成功率 モバイルアプリ 99.9%以上 Web 99.8%以上 モバイルアプリ 90%以上 Web 80%以上 モバイルアプリ 99%以上 Web 95%以上 レイテンシー 100ms以内のレスポンス 1000ms以内のレスポンス ©Uzabase, Inc. All Rights Reserved.

13.

02 SLOの準拠／違反の状況を週次でモニタリングしていくと… Webのレイテンシーが問題ということしかわからない。この状態からどうする？ SLIの種類 SLI ユーザーのタイプ SLO 可用性 リクエスト成功率 モバイルアプリ 99.9%以上 Web 99.8%以上 モバイルアプリ 90%以上 Web 80%以上 モバイルアプリ 99%以上 Web 95%以上 レイテンシー 100ms以内のレスポンス 1000ms以内のレスポンス ©Uzabase, Inc. All Rights Reserved.

14.

02 SLO違反の原因の特定にも、エスカレーションにも時間がかかった BIツールでDWHのアクセスログを集計する場合… リアルタイム性が低い(クエリ待ち時間) ©Uzabase, Inc. All Rights Reserved. エンドポイントの特定にSQLを書く必要がある

15.

02 モニタリングのためのSaaSを導入し、SLIを計測するようにした New Relic APMを導入し、SLIを計測しSlackへのアラートを設定 ©Uzabase, Inc. All Rights Reserved.

16.

01 SLO違反からエスカレーションまでの調査がかなり楽になった 主にNew Relicを利用して、SLO違反から特定エンドポイントの更新に辿り着く SLO違反タイミングの特定 デプロイの特定(Deployment Marker) デプロイしたユーザーとrevisionを特定し、 開発チームにリリース内容の影響を確認 ©Uzabase, Inc. All Rights Reserved.

17.

02 CUJわからないなりにエスカレーション100本ノックをしました 担当チームのSlackチャンネルにお伺いする ©Uzabase, Inc. All Rights Reserved.

18.

02 SRE実施のフェーズ 「SREの探求 22章 成功の文化としてのSRE」より ● フェーズ1 : 消火活動/事後対応 「システムを何とか動かし続ける」と同時に、自動化を通じて新たなアプローチを構築 ● フェーズ2 : 門番 プロダクションシステムに対する変更は必ず承認を受けて通過しなければならない唯一の関門として機能する ● フェーズ3 : 支持者/パートナー 合意したターゲットをパートナーが達成し、その後も引き続き満足していけるように支援する ● フェーズ4 : 触媒 あらゆるサービスの構想から廃止までに関与して、適切なツールを提供できるように支援する ©Uzabase, Inc. All Rights Reserved.

19.

02 SRE実施のフェーズ 「SREの探求 22章 成功の文化としてのSRE」より ● フェーズ1 : 消火活動/事後対応 「システムを何とか動かし続ける」と同時に、自動化を通じて新たなアプローチを構築 ● フェーズ2 : 門番 プロダクションシステムに対する変更は必ず承認を受けて通過しなければならない唯一の関門として機能する ● フェーズ3 : 支持者/パートナー 門番フェーズを超えて 支持者/パートナーを目指す 合意したターゲットをパートナーが達成し、その後も引き続き満足していけるように支援する ● フェーズ4 : 触媒 あらゆるサービスの構想から廃止までに関与して、適切なツールを提供できるように支援する ©Uzabase, Inc. All Rights Reserved.

20.

02 「門番」から「支持者/パートナー」へ Google CloudのBlogにも同様のことが書いてあります https://cloud.google.com/blog/ja/products/gcp/consequences-of-slo-violati ons-cre-life-lessons SLO の規定内でサービスが稼働していたとしても、積極的に信頼性を向上させることは、 障害の将来的なリスクを抑え、効率性を改善し、そしてコスト削減につながります。 一方、SLO を満たしていないからといって、すぐに内部での機能開発を完全にやめてしま う組織はほとんどありません。 (中略) 関連する開発チームにも知らせましょう。このプロセスは手動でもかまいません。 SRE チームは違反をフィルターにかけて集約し、意味のあるコンテキストを提供するなど 価値を付け加えることも可能です。 ©Uzabase, Inc. All Rights Reserved.

21.

02 このような支援を提供したい 開発チームがSLOのモニタリングと改善を自走できるまで、サポートをする ©Uzabase, Inc. All Rights Reserved.

22.

02 ここからSite Reliability Engineeringをやっていく ソフトウェアによる信頼性の確保とトイルの削減 これを自動化・セルフサービス化する ©Uzabase, Inc. All Rights Reserved.

23.

03 SLOモニタリングをプロダクト開発組織に拡大 ©Uzabase, Inc. All Rights Reserved.

24.

03 クリティカルユーザージャーニーに立ち返る SREチームがCUJを補足するのは難しいので、各開発チームに見てもらう ©Uzabase, Inc. All Rights Reserved.

25.

03 開発チームにヒアリングを絶賛実施中 チームのミッション クリティカルユーザージャーニー エンドポイント 読者の体験改善 ニュース記事の閲覧 ● 外部記事閲覧 ● オリジナル記事閲覧 ニュースフィード閲覧 ● ニュースフィードトップ ● カテゴリタブ ニュースのPICK・コメント ● PICK・コメント ● コメント削除 フォローリスト表示 ● フォローフィード取得 新規登録 ● ● ● ● ● ● 投稿者の体験改善 新規ユーザー獲得 ©Uzabase, Inc. All Rights Reserved. Appleサインアップ・ログイン Facebookサインアップ・ログイン Googleサインアップ・ログイン Twitterサインアップ・ログイン Linkedinサインアップ・ログイン メールアドレスのサインアップ・ログイン

26.

03 できあがったSLOモニタリングの仕組み エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 CDK for Terraform 反映 設定(PR) cdktf deploy ダッシュボード 確認 チームチャンネル に通知 Slack アラート ©Uzabase, Inc. All Rights Reserved. New Relic ● ● ● ● ● Service Levels Dashboard AlertPolicy AlertConfition Workflow

27.

03 開発チームはエンドポイントとSLOを設定してPR出すだけ エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 設定(PR) CDK for Terraform 反映 cdktf deploy ダッシュボード 確認 チームチャンネル に通知 New Relic Slack アラート ● APIエンドポイント ● SLOターゲット ● ターゲットレイテンシー目標 ● 担当チーム ©Uzabase, Inc. All Rights Reserved. ● ● ● ● ● Service Levels Dashboard AlertPolicy AlertConfition Workflow

28.

03 cdktf deployでNew Relicのリソース一式が反映される エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 CDK for Terraform 反映 設定(PR) cdktf deploy ダッシュボード 確認 チームチャンネル に通知 Slack アラート ©Uzabase, Inc. All Rights Reserved. New Relic ● ● ● ● ● Service Levels Dashboard AlertPolicy AlertConfition Workflow

29.

03 SLO・バーンレートからアラート閾値の自動計算、Slack通知 これはCDK for Terraform + TypeScriptのかなり大きな利点 エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 CDK for Terraform 反映 設定(PR) cdktf deploy ダッシュボード 確認 チームチャンネル に通知 Slack アラート ©Uzabase, Inc. All Rights Reserved. New Relic ● ● ● ● ● Service Levels Dashboard AlertPolicy AlertConfition Workflow

30.

03 アラートを受けてダッシュボードを見れば、SLO違反の 原因となったエンドポイント・デプロイの特定まで可能 エンドポイントごとのSLOモニタリング ダッシュボードにチーム別のタブがあり チームの担当エンドポイントを確認できる リポジトリ (GitHub) 開発者 CDK for Terraform 反映 設定(PR) cdktf deploy ダッシュボード 確認 チームチャンネル に通知 Slack アラート New Relic ● ● ● ● ● Service Levels Dashboard SLO準拠状況タイムライン AlertPolicy AlertConfition Workflow Transaction / DeploymentMarker ©Uzabase, Inc. All Rights Reserved.

31.

03 ● SLOをプロダクト開発組織に拡大する効果と今後の展望 効果 ○ 担当チーム以外理解の浅かったクリティカルユーザージャーニーをNotionにドキュメント化し IaCでダッシュボード・アラートを設定できるようになったことで、プロダクト開発組織全体 でチーム別の関心事・オーナーシップ範囲が可視化されつつある。 ○ ● ユーザーの理想に応えるサイト信頼性について開発チームが意識するきっかけになった 今後の展望 ○ 開発チームに絶賛ヒアリングして、ダッシュボードを作って、 チームで定期的に確認したりアラートを確認してSLOを見直す運用を開始している ○ 今年中には全てのチームが自律的にSLOの策定・見直しを実施し、 ユーザーにとって望ましい信頼性と機能開発のバランスをとれるようにする ©Uzabase, Inc. All Rights Reserved.

32.

ご清聴ありがとうございました！ NewsPicksではエンジニアを積極採用中です！ https://tech.newspicks.com ©Uzabase, Inc. All Rights Reserved.