[SRE NEXT] ARR150億円_エンジニア140名_27チーム_17プロダクトから始めるSLO.pdf

Transcript

1. ARR150億円、エンジニア 140 名、27チーム、17プロダクトから 始めるSLO 2025.07.12 Sat. SRE Next@TOC有明 佐藤 沢彦 SmartHR SRE
2. ❏ 佐藤沢彦 ❏ 経歴 ❏ 2020〜: SmartHR プロダクトエンジニア ❏ 2024〜: SmartHR SRE (1人目) ❏ 好きなエディタ ❏ neovim ❏ 好きなコマンド ❏ dstat ❏ X ❏ @SawshoS 自己紹介
3. ❏ SmartHRは創業当初からひたすら「とにかく顧客の要望を実現する 機能を作る」を続けていた ❏ 信頼性が課題となり SLOを導入しようとなったときには、 ARRは150 億円、140名のエンジニア、 27チーム、17のプロダクトの巨大な開 発組織 ❏ それに対して SREは1名 ❏ 巨大な開発組織に少人数で SLOを導入した際の工夫、失敗、成功 についてお話します 今日のお話
4. “求められる機能を、定められた条件の下で、定められた期間にわ たり、障害を起こすことなく実行する確率 [1] [1] Betsy Beyer、 Chris Jones Jennifer Petoff、 Niall Richard Murphy編／澤田武男、関根達夫、細川一茂、矢吹大輔監訳／ Sky株式会社 玉川竜司訳 『SRE サイトリライアビリティエンジニアリング Google の信頼性を支えるエンジニアリングチーム』株式会社オーム社、 2017年、p.xiv “信頼性”とは？ この発表では 信頼性 = レイテンシーとエラーレート とさせて下さい
5. SmartHRとは？
7. ※ARR（Annual Recurring Revenue）年間経常収益。顧客からの月間経常収益（MRR（Monthly Recurring Revenue））を12 ヶ月で乗じた もの。 現在のSmartHR: ARR200億、エンジニア170名、44チーム、22プロダクト
8. SmartHR 基本機能 基本機能と連携するアプリ 年末調整 文書配付 従業員サーベイ カスタム社員名簿 API連携 人事データベース • SmartHRは”基本機能”という人事データベースを 持つアプリとそれに連携するアプリでできている
9. SmartHRにSREができるまで
10. 2024年にSRE誕生 ❏ サービス開始後 9年目 ❏ ARR約150億円 “遅くない？ ”
11. “BtoB”
12. 一般的なtoCのWebサービス 検索サイト ECサイト ❏ 信頼性が収益に直結 ❏ 描画の遅れやエラーが収益の減少を招く ❏ 快適に動作しなければユーザーは離脱 ❏ 24/365で利用される
13. ❏ ユーザーは 仕事として 利用 ❏ ユーザーは快適な操作よりも機能性を重視 ❏ 100msの描画速度改善よりも 3hの業務を10s にする機能が望まれる ❏ メインのユーザーは 国内の労務担当者 ❏ 基本的に月 -金の9-17時にSmartHRを利用 SmartHR
14. 一般的なtoCのWebサービス SmartHR 24/365で利用される ほとんどが月-金の9-17時 信頼性が収益に直結 信頼性が収益に直結するわけではな い SREへのニーズが少なかった (過去形)
15. 新しいプロダクト次々とリリース
16. 高信頼性を求められるプロダクトが増加 IdP管理 お知らせ機能 メッセージ機能 勤怠 ❏ 24/365利用される ❏ 一般従業員も利用 ❏ 操作の快適さも重要
17. だいぶ遅くなったが SREが誕生 SRE誕生！
18. SLO導入の背景
19. SmartHRでは機能性の拡充が最優先 一般的なtoCのWebサービス SmartHR 24/365で利用される ほとんどが月-金の9-5時 信頼性が収益に直結 信頼性が収益に直結するわけではな い
20. ❏ 新しい機能を使いたい新規ユーザーが増える ❏ 既存ユーザーの満足度の向上 ❏ 既存ユーザーが新機能の使える上位のプランに 乗り換えてくれる SmartHRが機能性を拡充したいモチベーション
21. SmartHRの成長戦略 「ユーザーにとって便利な機能をたくさん 作る」
22. 「ユーザーにとって便利な機能をたく さん作る」 …が、長年、これだけを続けていると 無理が出てくる
23. バックグラウンドジョブが何時間待って も終わらない …… 画面遷移が遅くて仕事に支障が ……
24. ❏ 新機能をとにかく作る ❏ 信頼性に関する問題の対応 は、”問い合わせベース ” 当時のSmartHR の開発 新機能A開発 新機能B開発 新機能C開発
25. 「ユーザーにとって便利な 機能をたくさん作る」 信頼性 このバランスを取りたい SLOの導入
26. SLO導入
27. ARR150億円 エンジニア 140名 27チーム 17プロダクト 😊 😩 SRE1名 導入の課題 : 規模は大きいが SREは少ない
28. SLO導入の方針 ❏ SREはSLOのイネイブリング のみを行う ❏ SLOを徹底的にシンプル に
29. 方針: SREはSLOのイネイブリング ※のみを行う 27チーム、17プロダクトの SLOを1人で運用するのは無理。 SREはSLOのイネイブリ ングのみを行うことにし、実際の SLOの導入・運用は各プロダクトチームに任せた。 SREがやること プロダクトチームがやること ❏ SLOのイネイブリング ❏ SLO導入ガイドの用 ❏ SLO説明会 ❏ etc… ❏ SLOの定義 ❏ SLOの運用 ※他のチームが新しい技術やスキルを習得することを支援すること
30. SLOの定義や運用は各プロダクトチームにやって もらう SLOを140人、27チームに理解してもらう必要があ る → そんな時間はない 😭
31. 方針: SLOを徹底的にシンプル に SLOという複雑な概念を 27チーム、140名のエンジニアに完璧に理解しても らうのは困難。 約400ページ 約500ページ SLOを徹底的にシンプルにし、 2,3分で理解可能にした。
32. 徹底的にシンプル なSLOとは？ ❏ エラーバジェットを 管理しない ❏ バーンレートアラートを 設定しない ❏ リリースの コントロールをしない じゃあ、逆に何をするのか？？？？
33. 徹底的にシンプル なSLOでやること ❏ SLOは違反している or していないの 2値 ❏ エラーバジェットを説明しなくて良い ❏ 1スプリントに 1回SLO違反を確認し違反があれば、 SLOを緩め る or 次スプリントで対応する ❏ バーンレートアラートは不要 ❏ リリースのコントロールはなし、 SLOはスプリント計画の判断 材料
34. ❏ SREはSLOのイネイブリング のみを行う ❏ SLOを徹底的にシンプル に この2つの方針で SLOを導入していった
35. SmartHR 基本機能 基本機能と連携するアプリ 年末調整 文書配付 従業員サーベイ カスタム社員名簿 API連携 人事データベース まず、基本機能関連のチーム (5チーム)にSLOを導入 ❏ SmartHRで最大のトラフィック ❏ 他のアプリが依存 ❏ 5チームの有志のあつまる ”パフォーマンス会 ”が存在
36. 結果: あまりうまくいかな かった
37. できたこと ❏ SLOの意義はある程度理解が広がった ❏ SLOの定義 ❏ 定期的なSLO違反確認 ❏ SLO違反対処のチケット作成 しかし、SLO違反の対応チケットが切られても、改善 対応が進まない 󰷺
38. これ！！
39. 成長戦略 「ユーザーにとって便利な機能をたくさん作る」 最重 要 ❏ スプリントに入れることができるのは 機能開発のみ ❏ SLO違反の対応はスプリントに入らず、実施されない
40. ❏ SLOの理念 ❏ →わかる。いいね 👍 ❏ SLO違反の対応 ❏ →うーん🤔新機能開発に影響を出してまではでき ないよね SLOに対する反応 機能開発と信頼性のバランスをとることはできなかった
41. そんな状況下で大問題が発生してしまう … SmartHR大規模障害
42. SmartHR大規模障害
43. ❏ 2024/9頃からSmartHR全体の信頼性が許容不能なレベルまで 低下 ❏ レイテンシーが極端に悪化したり、レスポンスがエラーになる事象 がユーザーから多数報告される 当時のSLO
44. ❏ 9月だけで7回の”アクセス しづらい不具合 ”のお知ら せ ❏ 復旧を宣言しても、その後 アクセスしづらい事象が再 発
45. なにが起きていたか？ ❏ 相互に依存する問題が多数発生していた ❏ どれか1つへの対処を行っても信頼性が根本的に回復しなかっ た ❏ →このため何度も復旧宣言をしてしまった DBコネクション枯渇 スロークエリ 不適切なIndexの利用 DBのCPU不足 リクエストの滞留
46. 大規模障害対応専門チームが組成し対応 ❏ 十数名のエンジニアが約 1ヶ月対応に専念 ❏ 29件の改善を実施 ❏ スロークエリ改善、コネクションプーラー、サーキットブレーカー、 etc… 信頼性を許容されるレベルまで回復
47. 影響 ❏ 顧客からの信頼を損ねる深刻な影響 ❏ 顧客対応や障害対応のため現場は疲弊 ❏ ロードマップは見直しが必要に 再発防止が全社的な課題となる
48. SLOがうまく運用されてい れば防げたのでは？
49. SLOがあれば防げていた ? ❏ 以前からSLO違反が発生し、信頼性低下の兆候 は見えていた ❏ SLO違反が発生するたびに対処ができていれば、 許容不能なレベルまで信頼性が低下することは なかった
50. 大規模障害を防ぐための SLO
51. ❏ 再発防止のため新機能開発が最 優先されるスプリントを変えること が必要であると提案 新機能A開発 新機能B開発 新機能C開発 SLO違反対応 SLOで大規模障害を防ぐための提案
52. ❏ SLOがエンジニアだけでなく PMなど他のステークホルダー 含む共通認識に ❏ VPoEからの合意も得られ、 SLOの導入はプロダクト部門 の注力ポイント に SLOの必要性が広く受け入れられた 大規模障害の 苦い記憶 何とかしな きゃ！
53. ❏ SLO違反への対応が 機能開発同等のタスク としてス プリントに入るようになった ❏ プロダクトチーム側から ”SLOを導入したい ”と言われ るようになった 変わったこと
54. 現在の状況 ❏ 2024/1月までは0チームだったが、現在は 13チーム にSLOが導入された ❏ SLO違反→対応というサイクルを回すことができてい る SLO導入成功
55. 成功したこと 🎉
56. ❏ ビジネス上大きな影響を出してしまった問題なので再 発防止策の必要性が共通認識だった ❏ SLOが”やったほうがいいこと ”から”やらないといけな いこと”になった SLOを大規模障害の 再発防止策 として位置づけた
57. ❏ 導入のハードルが下がり、自主的に導入してくれる チームが出た SLOを徹底的にシンプル にしたこと
58. ❏ SREがプロダクトの開発プロセスを知らないこともあ り、多数のチームのイネイブリングには限界 ❏ 特に1プロダクト複数チームの場合は、どのチームが どのSLOのオーナーになるかなどが複雑 チームのSLO推進担当者 を出してもらったこと
59. 失敗したこと 😭
60. “SLO”は”機能開発”より優先すべきと言ったこと ❏ 高い基準の信頼性を達成するため、機能開発に割くこと のできる時間が減るという印象を与えた ❏ 今まで目指してきたものが変わると思われて反感が大 SLOは必要な信頼性が保てているかを計測するためのツー ルに過ぎないということを丁寧に説明すべきだった
61. まとめ
62. ❏ SREが1名の状態で大規模なチームへの SLO導入に挑戦 ❏ シンプルな SLOをイネイブリングしていくことで少人数で多 数のチームへの SLO導入を行った ❏ 大規模障害の再発防止策として SLOの導入を推し進めた ❏ 13チームにSLOが導入された
63. 今後やりたいこと
64. ❏ SLOを全チームに広げる ❏ SLO違反→対応というサイクルを徹底 ❏ シンプルな SLOを進化 ❏ エラーバジェット・バーンダウンアラートの導入
65. we’re hiring 2名しかいないよー
66. スペシャルサンクス
67. ご清聴ありがとうございました 🙇