ニフティでSRE推進活動を始めて取り組んできたこと

SRE NEXT 2022の発表資料です。
https://sre-next.dev/2022/schedule#sp03

登壇者
ニフティ株式会社
N1! SRE 浅見 則彦(https://github.com/rubihiko)

Transcript

1. Copyright © NIFTY Corporation All Rights Reserved.
 ニフティでSRE推進活動を始めて 取り組んできたこと ニフティ株式会社 会員システムグループ 浅見 則彦 SRE NEXT 2022 Track C #srenext #srenextC
2. Copyright © NIFTY Corporation All Rights Reserved.
 自己紹介
 ニフティ株式会社 会員システムグループ SRE推進チーム N1! SRE 浅見 則彦 担当業務 • Webサービスの開発・運用 • SRE推進活動、SREsを増やす活動 • クラウドアーキテクト、IaC、モニタリング、Toil削減 • 新人育成、クラウド系勉強会 • 社内タスクフォース: システム安定化、採用ブランディング 2

3. Copyright © NIFTY Corporation All Rights Reserved.
 3
 ネットワークサービス WEBサービス インターネット回線 生活インフラを支える 生活を豊かにする メディア・コンテンツ 会員 オプションサービス 格安スマホ サービス紹介

4. Copyright © NIFTY Corporation All Rights Reserved.
 4
 目次 • ニフティにSREチームが生まれるまで
 • SLI/SLO設定
 • オンコール対応の改善
 • Toilの削減
 • まとめ

5. Copyright © NIFTY Corporation All Rights Reserved.
 5
 ニフティにSREチームが生まれるまで
6. Copyright © NIFTY Corporation All Rights Reserved.
 経緯・歴史
 6
 AWS PoC・移行〜 2022
 2018
 2019
 2020
 2021
 AWS移行中〜安定化 SRE推進〜 SRE横展開〜 SRE推進チームができるまで サービス毎のAWS移行が始まる PoC・サービス移行を全員で実施 1サービス単位で移行を進め、 1人大体3〜5サービスを担当する SREを全社的に横展開を進める SLI/SLOの設定、モニタリング、ポストモー テム、障害対応ロールプレイングなどを中 心に、SREアプローチの提案や、 SREsを 増やすための活動を行う 移行も大部分が完了 システム不安定な部分が気になり始める クラウドに適した構成や自動化が求められる 安定化PJを立ち上げシステム安定化を進める。 SRE推進チームの前身となる活動がこれ
7. Copyright © NIFTY Corporation All Rights Reserved.
 7
 ・・・
 チーム
 サービス・チーム構成
 インフラ (AWS) アプリケーション サービスE インフラ (AWS) アプリケーション サービスD インフラ (AWS) アプリケーション サービスA インフラ (AWS) アプリケーション サービスB インフラ (AWS) アプリケーション サービスC インフラ (AWS) アプリケーション サービスF
8. Copyright © NIFTY Corporation All Rights Reserved.
 それぞれのチームがアプリとインフラの責任を持つ
 8
 インフラ (AWS) アプリケーション サービス • 各チームがプロダクトに責任を持つ状態 • 開発者も運用をする • 運用者も開発をする • インフラも全員で • オンコール対応 • チームメンバー全員が全部できるように クラウドのメリットを十分に活かす素早い開発と効率的 な運用のため、メンバーの意識やスキルが変わろうと していた チームメンバーの役割も変化
9. Copyright © NIFTY Corporation All Rights Reserved.
 サービス課題
 9
 課題: AWS移行後にシステムが安定しない
 本来の目的である”ユーザーに価値を提供する” ことに集中できない。 ユーザー影響 手作業 障害/問い合せ
10. Copyright © NIFTY Corporation All Rights Reserved.
 課題解決に向けて 10
 信頼性の定義 全てを計測 Toil削減 自動化 未然に防ぐ 素早い復旧 • 素早く復旧するためには • 問い合せ対応を減らすには • サービス障害の判断基準 • サービス状態の把握 • 時間をかけずに済むには • 不確かな作業を無くすには ユーザー影響 手作業 障害/問い合せ 👉 SREのアプローチ
11. Copyright © NIFTY Corporation All Rights Reserved.
 SREのアプローチ 11
 信頼性を定義、全てを計測する 障害は未然に防ぐ、発生する場合は素早い復旧を Toil・手作業を減らす、自動化することで時間削減と品質向上が見込める • サービスの状態を把握して、正しい判断を行いたい • ユーザーに提供している価値である信頼性を可視化したい • 信頼性を起点として、 DevOpsのアクションに繋げたい • そのために全てを計測する • 防ぐための自動化 • 障害は発生するものとして備える • 訓練・練習 • Toilを洗い出す • 手作業は不安定で危険なもの、出来るだけ自動化を
12. Copyright © NIFTY Corporation All Rights Reserved.
 組織横断的な関わり
 12
 SRE推進チーム サービスチームA • あるサービスチームがSRE推進チームへと変化 • Embedded SRE ぽい感じで横展開していく • 各チームの持つ課題を一緒に解決していくスタイル ◦ システム不安定 ◦ SLI/SLO設計 ◦ モニタリング ◦ IaC ◦ Toil ◦ オンコール対応 • 各チーム、段階的に変化を進める サービスチーム群 基幹系 インフラ系 SRE実践
 変化
 横展開

13. Copyright © NIFTY Corporation All Rights Reserved.
 13
 SLI/SLO設定
14. Copyright © NIFTY Corporation All Rights Reserved.
 SLI/SLO設計ステップ
 14
 ユーザージャーニー 参考: https://cloud.google.com/blog/products/management-tools/practical-guide-to-setting-slos
 • ユーザージャーニーを洗い出す
 • 重要な順に並び替える
 SLIを決める 期間とSLOを決める • SLIを決める（どのようなメトリクスを採用するか） • 期間とSLOを決める
15. Copyright © NIFTY Corporation All Rights Reserved.
 SLI、メトリクス
 15
 サービス種別 SLI 測定方法 リクエスト主導型サービス 可用性 正常に処理された有効なリクエストの割合 レイテンシ しきい値よりも速く処理された有効なリクエストの割合 品質 サービスの中断なしに処理された有効なリクエストの割合 データ処理サービス 鮮度 しきい値よりも最近更新された有効なデータの割合 カバレッジ 正常に処理された有効なデータの割合 正確性 正しい出力を生成した有効なデータの割合 スループット データ処理率がしきい値よりも速い時間の割合 スケジュールされた実行サービス スキュー 予想開始時刻の許容時間内に開始される実行の割合 実行時間 許容時間内に完了した実行の割合 参考: https://cloud.google.com/architecture/adopting-slos

16. Copyright © NIFTY Corporation All Rights Reserved.
 SLOドキュメントを作る
 16
 参考: https://cloud.google.com/blog/products/management-tools/practical-guide-to-setting-slos
 ユーザージャーニー • 〇〇が検索できる • 〇〇を表示できる • 〇〇を購入できる SLI • 指標: 可用性 • メトリクス: 正常に処 理された有効なリクエ ストの割合 SLO • 目標: 99.9% • 期間: 30日 カテゴリ 機能 SLI SLO 可用性 〇〇ページの表示 30日間のリクエストの内、 503を 除く5xx以外のレスポンスを返す 割合 99.9% 成功 速度 〇〇ページの表示 30日間のリクエストの内、 50%は 200ms以内にレスポンスを返し、 90%は... リクエストの50% ≦ 200 ms リクエストの99% ≦ xxx ms … 👉ユーザーがサービスを使えて いますか？の観点で 

17. Copyright © NIFTY Corporation All Rights Reserved.
 SLI/SLOを可視化する
 17
 • SLOドキュメント・テンプレート • 各サービスのドキュメントを共有 SLOドキュメント メトリクスの収集、可視化 Amazon CloudWatch • Datadog • AWS CloudWatch • AWS CloudWatch Logs • サービス概要 • (クリティカル)ユーザージャーニー • SLI/SLO • 内部的なSLI/SLO ◦ HTTPサーバー ◦ アプリケーション・サーバー ◦ API ◦ データベース • 根拠 • エラーバジェット • 注意点
18. Copyright © NIFTY Corporation All Rights Reserved.
 SLO Dashboard
 18
 ※こちらはサンプルデータになります
19. Copyright © NIFTY Corporation All Rights Reserved.
 SLOを起点としたアクション
 19
 ユーザーは サービスを 使えている 機能開発を続ける ユーザーは サービスを 使えていない 開発は止めて信頼性回 復のための作業を行う SLOが下がる傾向が見 えたらアラート 自動修復アクション ※こちらはサンプルデータになります
20. Copyright © NIFTY Corporation All Rights Reserved.
 20
 オンコール対応の改善
21. Copyright © NIFTY Corporation All Rights Reserved.
 素早い復旧をするための準備
 21
 フローの確立 事前準備 • 障害時の連絡体制・フローをアップデート
 • 役割制を採用
 ◦ インシデントコマンダー、補佐、記録係、専門家、連絡係
 • ドキュメントの整備
 • 定期的な障害対応ロールプレイング・練習

22. Copyright © NIFTY Corporation All Rights Reserved.
 フロー整備
 22

23. Copyright © NIFTY Corporation All Rights Reserved.
 役割を決める
 23
 IC(インシデントコマンダー) インシデント時指揮を取る人 サービス責任者、PM 補佐 ICを補佐する人、技術的支援や提案など エンジニア 記録係 状況を整理してSlackなどのチャンネルに流す人 エンジニア 専門家 (通常は)インシデントを検知した人、1次対応者 調査・原因特定、復旧対応をする人 エンジニア ユーザー連絡係 エンドユーザーへ障害の告知をする人 CS、PM 内部連絡係 内部の関係者に連絡する人 CS、PM 参考: https://response.pagerduty.com/ 

24. Copyright © NIFTY Corporation All Rights Reserved.
 ロールプレイング
 24
 全員集合・開始 担当アサイン 調査・対応 実行 承認 関係者連絡 復旧 報告・記録
25. Copyright © NIFTY Corporation All Rights Reserved.
 振り返り文化
 25
 ポストモーテム共有会 パフォーマンス会議 • 振り返り • 事例の共有・相談 • 再発防止のアクション • MVPの表彰 • 定期的にサービスのパフォーマンスをみんなで見る ◦ SLI/SLO、モニタリング、エラー状況、Toil状況、相談 • コストも確認する ◦ 最適化を意識、コスト削減の施策共有 • ポストモーテム・ドキュメントの内容 ◦ インパクト ◦ 根本原因・発生原因 ◦ 対応・検出 ◦ アクションアイテム ◦ 教訓(うまくいったこと・いかなったこと、幸運 ) ◦ タイムライン ◦ 参考情報、特殊な用語など
26. Copyright © NIFTY Corporation All Rights Reserved.
 26
 Toil撲滅
27. Copyright © NIFTY Corporation All Rights Reserved.
 Toilとは
 サービスの成長や維持に関わる作業で、 手作業で繰り返し行われるという特徴がある作業のこと 代表的には(もし以下の作業が手作業で繰り返し行われていたらToilの可能性が高い ) - 証明書の更新作業 - 機能リリース作業 - 問い合わせの調査作業 - 障害対応 - トラフィック対策のサーバー増設作業 - …
28. Copyright © NIFTY Corporation All Rights Reserved.
 Toilチェックシート、Toil洗い出し
 1. 全作業をリストアップする 2. Toilかどうか、ポイントを付けてみる 3. 発生頻度・作業時間も判断ポイントに サービスにとって必要な作業の洗い出し、優先度を決めて削減・自 動化の作業に取り組めるため、非常に分かりやすい。 そして、自動化により品質の向上や時間削減に繋がりました。
29. Copyright © NIFTY Corporation All Rights Reserved.
 29
 まとめ
30. Copyright © NIFTY Corporation All Rights Reserved.
 まとめ
 30
 全社的に浸透できたこと • サービスチームから始まったSREを全社的に広めました • 横展開で広める際に注意したのは少しずつ変化させること ◦ 適用できるところから、解決できるところから柔軟に進める • 目に見えて分かる効果があると浸透させやすい ◦ かっこいいSLO Dashboardができた！モニタリングが充実した！ ◦ 障害時の体制が整ったので安心！アラート・連絡フローが明確になった！ ◦ システムの見える化、ドキュメントが充実した！ • ポストモーテム共有会、パフォーマンス会議を定例化 • ロールプレイング・練習の支援と開催 • 地道な活動 ◦ SRE本、ワークブックの輪読会を1年以上続けていた ◦ 新入社員研修やクラウド勉強会にもSRE回を取り入れ新人をそそのかす ◦ 社内LT大会などで、SRE、SLI/SLO、ポストモーテム、など発表
31. Copyright © NIFTY Corporation All Rights Reserved.
 まとめ
 31
 今後の展望 • 各チームにSREsを増やす ◦ 品質向上、自己完結できるチーム、DevOpsサイクル高速化のため ◦ チームに1人はSREを実践してくれる人がいる状態を目指す ◦ そのような人材を育てるための勉強会や研修を用意する • SLOの運用・エラーバジェット活用 ◦ 設定後の定期的な見直し・運用・アクションができるように ◦ エラーバジェットの活用 ◦ SLO設定がないサービスやシステムへの適用
32. Copyright © NIFTY Corporation All Rights Reserved.