インフラからSREへ

Road to SRE NEXT@会津若松
2025/05/17

Transcript

1. インフラからSREへ Issei Naruta (mirakui) Principal Engineer / IVRy Inc. Road to SRE NEXT@会津若松 2025/05/17
2. Issei Naruta (mirakui) IVRy Inc. 2024/2- Principal Engineer SRE / Data Engineering Cookpad Inc. 2010-2023 Infra -> CTO (2016-2022) 趣味 パン作り ルービックキューブ 深夜アニメ
3. インフラからSREへ
4. Site Reliability Engineering
5. 自分の肩書きに "SRE" が含まれる人?
6. 自分(達)は Site Reliability Engineering を実践していると思っている人?
7. non-offensive (こわくないよ)
8. 歴史の話
9. 2016: SRE本の衝撃
11. 何が新しかったか インフラ領域にソフトウェアエンジニアリングや科学的方法論を導入し、インフラ固 有の組織課題、コミュニケーション課題にスポットライトが当て、共通言語をもたら したこと →コスト部門から欧米的経済合理性の世界へ SLI/SLO Error Budget Eliminating Toil On-call Postmortem Observability
12. 2000年代初頭くらいまでのインフラエンジニアの世 界観 「運用さん」 職人芸 手順書 各社異なる技術セット、ノウハウ
13. 近代 (2010年代前半) "DevOps" 一大ブーム CD Flickr "10 deploys per day" Infrastructure as Code Chef, Puppet, ... IaaS の台頭 AWS 東京リージョン開設(2011) インフラ技術の進化がめまぐるしい過渡期 →インフラ界隈のコミュニティが活性化
14. 近代 (2010年代後半) SRE book の発表 (2016) コモディティ化の時代へ コンテナ技術の台頭 Docker, Kubernetes, ECS, ... 各社だいたい同じような技術セットでインフラを運用している状態に →SRE職の流動性が向上・人気職業に
15. SREプラクティスと現実 次々と登場する目新しい技術とのギャップ、焦り Google / big tech スタイルの SRE プラクティスは自分たちに合うのか？ という問 題 US big tech の開発はジョブ型が主流 日本は境界を分けすぎない組織が人気 SREチームといいながらplatformなんでも屋になりがちなのはどう解釈するか？
16. 組織フェーズとSREの発展段階の例 黎明期 1. プロダクト開発のエンジニアが片手間にインフラの面倒を見る 2. 一人目の専業インフラエンジニアができる 成長期 3. 複数人のインフラエンジニアによるチームになり、事業やシステムごとに担当者 を割り振れるようになる 成熟期 4. self-service が発達して事業側にon-callを任せられるようになる 5. 中央集権型のSREチームは解散し、platform teamが中央に残る
17. 組織フェーズとSRE 黎明期〜成長期〜成熟期であるべき姿は異なる 教科書通りのSREチームになっていないことは全く気にしなくてよい が、SREたるマインドセットは持つべき(後述)
18. 閑話休題: SREの解散について 十分に成熟したSREは解散に向かう説 自動化、権限委譲による self-service 化が進み中央集権である必要がなくなる 基盤技術のメンテナンスは必要なので platform 部隊は必要
19. SREとマインドセット
20. 量への向き合い方 Site Reliability Engineering は定量指標を使って 経済合理性の着地点を設ける試みでもある
21. 量への向き合い方 例: 10,000ユーザ中の1ユーザに影響のある障害 0.01% のユーザにしか影響がなかった vs 1人のユーザに影響があった 「SLO / Error Budget の範囲内だから大丈夫」と考えるか？
22. 1人のユーザには何が起こったのか？ 何も起こらなかった 広告枠が表示されなかった 見たいレシピが表示できなかった 1時間かけて書いた記事が保存されず消えてしまった 推しのライブチケットが買えなかった 大事な電話の途中で切れてしまった 今月の売上が振り込まれなかった
23. ユーザ体験で捉える "1行のログの向こうに1人のユーザがいる"
24. ユーザ体験で捉える エラーログを見るだけではなく、サービスを触って確認してみる これをやらない人は意外と多い どういうエラー文言が出ているか？ 待たされているのか、誤動作しているのか、あるいは全く問題ないのか
25. 量への向き合い方 SLO / Error Budget はあくまで組織の行動を変えるための閾値として捉えるべき 体験を損ねている顧客がいるのなら、少なければ大丈夫という話じゃない 少数のエラーやパフォーマンス劣化でも目を通し、unknown-unknowns を減らす 意識を持つ
26. インフラ課題をインフラ技術だけで解かない
27. インフラ課題をインフラ技術だけで解かない 例: スロークエリが多発してDBの負荷が高い 原因は複雑な COUNT クエリだった
28. インフラ課題をインフラ技術だけで解かない ユーザ体験で捉える 原因は複雑な COUNT クエリだった クエリをチューニングしよう 何をしたときに発生するのか確認しよう
29. インフラ課題をインフラ技術だけで解かない 原因: 原因がページネーション用の合計数字を計算するクエリが遅かった インフラレイヤーでの解き方 クエリを改善する DBをチューニングしてクエリが速く計算できるようにする スケールアップする
30. インフラ課題をインフラ技術だけで解かない アプリケーションレイヤーでの解き方 数字を非同期で表示するようにする カウンタキャッシュを導入する →アプリケーションエンジニアとコミュニケーションする →SRE自らアプリケーションコードに手を入れる
31. インフラ課題をインフラ技術だけで解かない プロダクトレイヤーでの解き方 そもそもそのクエリが顧客にどういう価値をもたらしているか？ 数字を表示するのをやめる ページネーションをやめる →PdMやデザイナーとコミュニケーションする
32. インフラ課題をインフラ技術だけで解かない DB負荷などのインフラ課題が顧客に何をもたらしているのかをすぐに結びつけら れるか？ スロークエリの改善であっても事業/プロダクトのレベルで考えて解き方を決めら れるか？ 組織的越境のフットワークを軽く保つには？
33. Site Reliability Engineering
34. 信頼性工学 (Reliability Engineering) 機器が故障することなく動作し、意図された結果が得られる確率(信頼性)を上げること を目的としたシステム工学
35. Site Reliability Engineering の目的 顧客にとって信頼できるサービスを追求しつつ経済合理性の着地点を見つけること (...と解釈してもいいのではないか)
36. まとめ: インフラからSREへ 技術が進化し、組織論が整理されてもあるべきマインドセットは変わっていない 最新のSREの要素技術に取り組めていないことを気にしすぎる必要は全くない あるべき姿に後付けで名付けられたものにすぎない 顧客、事業、プロダクトにどれだけ deep dive できているかが最も重要 組織的越境の視座を持つこと SRE の技術セットは各社似通っていて "つぶしがきく" 職業になった、が、 深く潜った人にだけ見える景色がある