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