[SRE NEXT] ARR150億円_エンジニア140名_27チーム_17プロダクトから始めるSLO.pdf

by sato-s

Slide 1

Slide 1 text

ARR150億円、エンジニア 140 名、27チーム、17プロダクトから始めるSLO 2025.07.12 Sat. SRE Next@TOC有明佐藤沢彦 SmartHR SRE

Slide 2

Slide 2 text

❏ 佐藤沢彦 ❏ 経歴 ❏ 2020〜: SmartHR プロダクトエンジニア ❏ 2024〜: SmartHR SRE (1人目) ❏ 好きなエディタ ❏ neovim ❏ 好きなコマンド ❏ dstat ❏ X ❏ @SawshoS 自己紹介

Slide 3

Slide 3 text

❏ SmartHRは創業当初からひたすら「とにかく顧客の要望を実現する機能を作る」を続けていた ❏ 信頼性が課題となり SLOを導入しようとなったときには、 ARRは150 億円、140名のエンジニア、 27チーム、17のプロダクトの巨大な開発組織 ❏ それに対して SREは1名 ❏ 巨大な開発組織に少人数で SLOを導入した際の工夫、失敗、成功についてお話します今日のお話

Slide 4

Slide 4 text

“求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率 [1] [1] Betsy Beyer、 Chris Jones Jennifer Petoff、 Niall Richard Murphy編／澤田武男、関根達夫、細川一茂、矢吹大輔監訳／ Sky株式会社玉川竜司訳『SRE サイトリライアビリティエンジニアリング Google の信頼性を支えるエンジニアリングチーム』株式会社オーム社、 2017年、p.xiv “信頼性”とは？この発表では信頼性 = レイテンシーとエラーレートとさせて下さい

Slide 5

Slide 5 text

SmartHRとは？

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

※ARR（Annual Recurring Revenue）年間経常収益。顧客からの月間経常収益（MRR（Monthly Recurring Revenue））を12 ヶ月で乗じたもの。現在のSmartHR: ARR200億、エンジニア170名、44チーム、22プロダクト

Slide 8

Slide 8 text

SmartHR 基本機能基本機能と連携するアプリ年末調整文書配付従業員サーベイカスタム社員名簿 API連携人事データベース ● SmartHRは”基本機能”という人事データベースを持つアプリとそれに連携するアプリでできている

Slide 9

Slide 9 text

SmartHRにSREができるまで

Slide 10

Slide 10 text

2024年にSRE誕生 ❏ サービス開始後 9年目 ❏ ARR約150億円 “遅くない？ ”

Slide 11

Slide 11 text

“BtoB”

Slide 12

Slide 12 text

一般的なtoCのWebサービス検索サイト ECサイト ❏ 信頼性が収益に直結 ❏ 描画の遅れやエラーが収益の減少を招く ❏ 快適に動作しなければユーザーは離脱 ❏ 24/365で利用される

Slide 13

Slide 13 text

❏ ユーザーは仕事として利用 ❏ ユーザーは快適な操作よりも機能性を重視 ❏ 100msの描画速度改善よりも 3hの業務を10s にする機能が望まれる ❏ メインのユーザーは国内の労務担当者 ❏ 基本的に月 -金の9-17時にSmartHRを利用 SmartHR

Slide 14

Slide 14 text

一般的なtoCのWebサービス SmartHR 24/365で利用されるほとんどが月-金の9-17時信頼性が収益に直結信頼性が収益に直結するわけではない SREへのニーズが少なかった (過去形)

Slide 15

Slide 15 text

新しいプロダクト次々とリリース

Slide 16

Slide 16 text

高信頼性を求められるプロダクトが増加 IdP管理お知らせ機能メッセージ機能勤怠 ❏ 24/365利用される ❏ 一般従業員も利用 ❏ 操作の快適さも重要

Slide 17

Slide 17 text

だいぶ遅くなったが SREが誕生 SRE誕生！

Slide 18

Slide 18 text

SLO導入の背景

Slide 19

Slide 19 text

SmartHRでは機能性の拡充が最優先一般的なtoCのWebサービス SmartHR 24/365で利用されるほとんどが月-金の9-5時信頼性が収益に直結信頼性が収益に直結するわけではない

Slide 20

Slide 20 text

❏ 新しい機能を使いたい新規ユーザーが増える ❏ 既存ユーザーの満足度の向上 ❏ 既存ユーザーが新機能の使える上位のプランに乗り換えてくれる SmartHRが機能性を拡充したいモチベーション

Slide 21

Slide 21 text

SmartHRの成長戦略「ユーザーにとって便利な機能をたくさん作る」

Slide 22

Slide 22 text

「ユーザーにとって便利な機能をたくさん作る」 …が、長年、これだけを続けていると無理が出てくる

Slide 23

Slide 23 text

バックグラウンドジョブが何時間待っても終わらない …… 画面遷移が遅くて仕事に支障が ……

Slide 24

Slide 24 text

❏ 新機能をとにかく作る ❏ 信頼性に関する問題の対応は、”問い合わせベース ” 当時のSmartHR の開発新機能A開発新機能B開発新機能C開発

Slide 25

Slide 25 text

「ユーザーにとって便利な機能をたくさん作る」信頼性このバランスを取りたい SLOの導入

Slide 26

Slide 26 text

SLO導入

Slide 27

Slide 27 text

ARR150億円エンジニア 140名 27チーム 17プロダクト 😊 😩 SRE1名導入の課題 : 規模は大きいが SREは少ない

Slide 28

Slide 28 text

SLO導入の方針 ❏ SREはSLOのイネイブリングのみを行う ❏ SLOを徹底的にシンプルに

Slide 29

Slide 29 text

方針: SREはSLOのイネイブリング ※のみを行う 27チーム、17プロダクトの SLOを1人で運用するのは無理。 SREはSLOのイネイブリングのみを行うことにし、実際の SLOの導入・運用は各プロダクトチームに任せた。 SREがやることプロダクトチームがやること ❏ SLOのイネイブリング ❏ SLO導入ガイドの用 ❏ SLO説明会 ❏ etc… ❏ SLOの定義 ❏ SLOの運用 ※他のチームが新しい技術やスキルを習得することを支援すること

Slide 30

Slide 30 text

SLOの定義や運用は各プロダクトチームにやってもらう SLOを140人、27チームに理解してもらう必要がある → そんな時間はない 😭

Slide 31

Slide 31 text

方針: SLOを徹底的にシンプルに SLOという複雑な概念を 27チーム、140名のエンジニアに完璧に理解してもらうのは困難。約400ページ約500ページ SLOを徹底的にシンプルにし、 2,3分で理解可能にした。

Slide 32

Slide 32 text

徹底的にシンプルなSLOとは？ ❏ エラーバジェットを管理しない ❏ バーンレートアラートを設定しない ❏ リリースのコントロールをしないじゃあ、逆に何をするのか？？？？

Slide 33

Slide 33 text

徹底的にシンプルなSLOでやること ❏ SLOは違反している or していないの 2値 ❏ エラーバジェットを説明しなくて良い ❏ 1スプリントに 1回SLO違反を確認し違反があれば、 SLOを緩める or 次スプリントで対応する ❏ バーンレートアラートは不要 ❏ リリースのコントロールはなし、 SLOはスプリント計画の判断材料

Slide 34

Slide 34 text

❏ SREはSLOのイネイブリングのみを行う ❏ SLOを徹底的にシンプルにこの2つの方針で SLOを導入していった

Slide 35

Slide 35 text

SmartHR 基本機能基本機能と連携するアプリ年末調整文書配付従業員サーベイカスタム社員名簿 API連携人事データベースまず、基本機能関連のチーム (5チーム)にSLOを導入 ❏ SmartHRで最大のトラフィック ❏ 他のアプリが依存 ❏ 5チームの有志のあつまる ”パフォーマンス会 ”が存在

Slide 36

Slide 36 text

結果: あまりうまくいかなかった

Slide 37

Slide 37 text

できたこと ❏ SLOの意義はある程度理解が広がった ❏ SLOの定義 ❏ 定期的なSLO違反確認 ❏ SLO違反対処のチケット作成しかし、SLO違反の対応チケットが切られても、改善対応が進まない 󰷺

Slide 38

Slide 38 text

これ！！

Slide 39

Slide 39 text

成長戦略「ユーザーにとって便利な機能をたくさん作る」最重要 ❏ スプリントに入れることができるのは機能開発のみ ❏ SLO違反の対応はスプリントに入らず、実施されない

Slide 40

Slide 40 text

❏ SLOの理念 ❏ →わかる。いいね 👍 ❏ SLO違反の対応 ❏ →うーん🤔新機能開発に影響を出してまではできないよね SLOに対する反応機能開発と信頼性のバランスをとることはできなかった

Slide 41

Slide 41 text

そんな状況下で大問題が発生してしまう … SmartHR大規模障害

Slide 42

Slide 42 text

SmartHR大規模障害

Slide 43

Slide 43 text

❏ 2024/9頃からSmartHR全体の信頼性が許容不能なレベルまで低下 ❏ レイテンシーが極端に悪化したり、レスポンスがエラーになる事象がユーザーから多数報告される当時のSLO

Slide 44

Slide 44 text

❏ 9月だけで7回の”アクセスしづらい不具合 ”のお知らせ ❏ 復旧を宣言しても、その後アクセスしづらい事象が再発

Slide 45

Slide 45 text

なにが起きていたか？ ❏ 相互に依存する問題が多数発生していた ❏ どれか1つへの対処を行っても信頼性が根本的に回復しなかった ❏ →このため何度も復旧宣言をしてしまった DBコネクション枯渇スロークエリ不適切なIndexの利用 DBのCPU不足リクエストの滞留

Slide 46

Slide 46 text

大規模障害対応専門チームが組成し対応 ❏ 十数名のエンジニアが約 1ヶ月対応に専念 ❏ 29件の改善を実施 ❏ スロークエリ改善、コネクションプーラー、サーキットブレーカー、 etc… 信頼性を許容されるレベルまで回復

Slide 47

Slide 47 text

影響 ❏ 顧客からの信頼を損ねる深刻な影響 ❏ 顧客対応や障害対応のため現場は疲弊 ❏ ロードマップは見直しが必要に再発防止が全社的な課題となる

Slide 48

Slide 48 text

SLOがうまく運用されていれば防げたのでは？

Slide 49

Slide 49 text

SLOがあれば防げていた ? ❏ 以前からSLO違反が発生し、信頼性低下の兆候は見えていた ❏ SLO違反が発生するたびに対処ができていれば、許容不能なレベルまで信頼性が低下することはなかった

Slide 50

Slide 50 text

大規模障害を防ぐための SLO

Slide 51

Slide 51 text

❏ 再発防止のため新機能開発が最優先されるスプリントを変えることが必要であると提案新機能A開発新機能B開発新機能C開発 SLO違反対応 SLOで大規模障害を防ぐための提案

Slide 52

Slide 52 text

❏ SLOがエンジニアだけでなく PMなど他のステークホルダー含む共通認識に ❏ VPoEからの合意も得られ、 SLOの導入はプロダクト部門の注力ポイントに SLOの必要性が広く受け入れられた大規模障害の苦い記憶何とかしなきゃ！

Slide 53

Slide 53 text

❏ SLO違反への対応が機能開発同等のタスクとしてスプリントに入るようになった ❏ プロダクトチーム側から ”SLOを導入したい ”と言われるようになった変わったこと

Slide 54

Slide 54 text

現在の状況 ❏ 2024/1月までは0チームだったが、現在は 13チームにSLOが導入された ❏ SLO違反→対応というサイクルを回すことができている SLO導入成功

Slide 55

Slide 55 text

成功したこと 🎉

Slide 56

Slide 56 text

❏ ビジネス上大きな影響を出してしまった問題なので再発防止策の必要性が共通認識だった ❏ SLOが”やったほうがいいこと ”から”やらないといけないこと”になった SLOを大規模障害の再発防止策として位置づけた

Slide 57

Slide 57 text

❏ 導入のハードルが下がり、自主的に導入してくれるチームが出た SLOを徹底的にシンプルにしたこと

Slide 58

Slide 58 text

❏ SREがプロダクトの開発プロセスを知らないこともあり、多数のチームのイネイブリングには限界 ❏ 特に1プロダクト複数チームの場合は、どのチームがどのSLOのオーナーになるかなどが複雑チームのSLO推進担当者を出してもらったこと

Slide 59

Slide 59 text

失敗したこと 😭

Slide 60

Slide 60 text

“SLO”は”機能開発”より優先すべきと言ったこと ❏ 高い基準の信頼性を達成するため、機能開発に割くことのできる時間が減るという印象を与えた ❏ 今まで目指してきたものが変わると思われて反感が大 SLOは必要な信頼性が保てているかを計測するためのツールに過ぎないということを丁寧に説明すべきだった

Slide 61

Slide 61 text

まとめ

Slide 62

Slide 62 text

❏ SREが1名の状態で大規模なチームへの SLO導入に挑戦 ❏ シンプルな SLOをイネイブリングしていくことで少人数で多数のチームへの SLO導入を行った ❏ 大規模障害の再発防止策として SLOの導入を推し進めた ❏ 13チームにSLOが導入された

Slide 63

Slide 63 text

今後やりたいこと

Slide 64

Slide 64 text

❏ SLOを全チームに広げる ❏ SLO違反→対応というサイクルを徹底 ❏ シンプルな SLOを進化 ❏ エラーバジェット・バーンダウンアラートの導入