Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
インフラからSREへ
Search
Issei Naruta
May 17, 2025
Technology
23
9k
インフラからSREへ
Road to SRE NEXT@会津若松
2025/05/17
Issei Naruta
May 17, 2025
Tweet
Share
More Decks by Issei Naruta
See All by Issei Naruta
データパイプラインをなんとかした話 / Improving the Data Pipeline in IVRy
mirakui
1
550
Cookpad TechConf 2022 Keynote
mirakui
0
3.9k
ドライイーストを使わずにパンを焼けるか? 〜天然酵母のパン作りを支える技術〜
mirakui
0
3.5k
関東積みについて/How to build Kanto-stacking
mirakui
0
710
先折りGTRについて/How to build left-GTR transitions
mirakui
3
1.1k
サービス開発速度に着目したソフトウェアアーキテクチャ/Software architecture for effective service development at Cookpad
mirakui
5
7.1k
Beyond the Boundaries
mirakui
1
1.4k
Cookpad Under a Microscope
mirakui
6
8.7k
Technical Successes and Failures in the History of Cookpad Development
mirakui
45
37k
Other Decks in Technology
See All in Technology
入院医療費算定業務をAIで支援する:包括医療費支払い制度とDPCコーディング (公開版)
hagino3000
0
110
AIエージェントによる業務効率化への飽くなき挑戦-AWS上の実開発事例から学んだ効果、現実そしてギャップ-
nasuvitz
5
1.1k
20251027_findyさん_音声エージェントLT
almondo_event
2
410
What's new in OpenShift 4.20
redhatlivestreaming
0
230
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
13
82k
プレイドのユニークな技術とインターンのリアル
plaidtech
PRO
1
350
ストレージエンジニアの仕事と、近年の計算機について / 第58回 情報科学若手の会
pfn
PRO
3
820
OSSで50の競合と戦うためにやったこと
yamadashy
3
980
Building a cloud native business on open source
lizrice
0
180
AI時代の開発を加速する組織づくり - ブログでは書けなかったリアル
hiro8ma
1
310
ハノーファーメッセ2025で見た生成AI活用ユースケース.pdf
hamadakoji
1
460
Azure Well-Architected Framework入門
tomokusaba
1
120
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
238
140k
Code Review Best Practice
trishagee
72
19k
Raft: Consensus for Rubyists
vanstee
140
7.2k
Optimizing for Happiness
mojombo
379
70k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.7k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Agile that works and the tools we love
rasmusluckow
331
21k
Building Better People: How to give real-time feedback that sticks.
wjessup
369
20k
Embracing the Ebb and Flow
colly
88
4.9k
Optimising Largest Contentful Paint
csswizardry
37
3.5k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Scaling GitHub
holman
463
140k
Transcript
インフラからSREへ Issei Naruta (mirakui) Principal Engineer / IVRy Inc. Road
to SRE NEXT@会津若松 2025/05/17
Issei Naruta (mirakui) IVRy Inc. 2024/2- Principal Engineer SRE /
Data Engineering Cookpad Inc. 2010-2023 Infra -> CTO (2016-2022) 趣味 パン作り ルービックキューブ 深夜アニメ
インフラからSREへ
Site Reliability Engineering
自分の肩書きに "SRE" が含まれる人?
自分(達)は Site Reliability Engineering を実践していると思っている人?
non-offensive (こわくないよ)
歴史の話
2016: SRE本の衝撃
None
何が新しかったか インフラ領域にソフトウェアエンジニアリングや科学的方法論を導入し、インフラ固 有の組織課題、コミュニケーション課題にスポットライトが当て、共通言語をもたら したこと →コスト部門から欧米的経済合理性の世界へ SLI/SLO Error Budget Eliminating Toil
On-call Postmortem Observability
2000年代初頭くらいまでのインフラエンジニアの世 界観 「運用さん」 職人芸 手順書 各社異なる技術セット、ノウハウ
近代 (2010年代前半) "DevOps" 一大ブーム CD Flickr "10 deploys per day"
Infrastructure as Code Chef, Puppet, ... IaaS の台頭 AWS 東京リージョン開設(2011) インフラ技術の進化がめまぐるしい過渡期 →インフラ界隈のコミュニティが活性化
近代 (2010年代後半) SRE book の発表 (2016) コモディティ化の時代へ コンテナ技術の台頭 Docker, Kubernetes,
ECS, ... 各社だいたい同じような技術セットでインフラを運用している状態に →SRE職の流動性が向上・人気職業に
SREプラクティスと現実 次々と登場する目新しい技術とのギャップ、焦り Google / big tech スタイルの SRE プラクティスは自分たちに合うのか? という問
題 US big tech の開発はジョブ型が主流 日本は境界を分けすぎない組織が人気 SREチームといいながらplatformなんでも屋になりがちなのはどう解釈するか?
組織フェーズとSREの発展段階の例 黎明期 1. プロダクト開発のエンジニアが片手間にインフラの面倒を見る 2. 一人目の専業インフラエンジニアができる 成長期 3. 複数人のインフラエンジニアによるチームになり、事業やシステムごとに担当者 を割り振れるようになる
成熟期 4. self-service が発達して事業側にon-callを任せられるようになる 5. 中央集権型のSREチームは解散し、platform teamが中央に残る
組織フェーズとSRE 黎明期〜成長期〜成熟期であるべき姿は異なる 教科書通りのSREチームになっていないことは全く気にしなくてよい が、SREたるマインドセットは持つべき(後述)
閑話休題: SREの解散について 十分に成熟したSREは解散に向かう説 自動化、権限委譲による self-service 化が進み中央集権である必要がなくなる 基盤技術のメンテナンスは必要なので platform 部隊は必要
SREとマインドセット
量への向き合い方 Site Reliability Engineering は定量指標を使って 経済合理性の着地点を設ける試みでもある
量への向き合い方 例: 10,000ユーザ中の1ユーザに影響のある障害 0.01% のユーザにしか影響がなかった vs 1人のユーザに影響があった 「SLO / Error
Budget の範囲内だから大丈夫」と考えるか?
1人のユーザには何が起こったのか? 何も起こらなかった 広告枠が表示されなかった 見たいレシピが表示できなかった 1時間かけて書いた記事が保存されず消えてしまった 推しのライブチケットが買えなかった 大事な電話の途中で切れてしまった 今月の売上が振り込まれなかった
ユーザ体験で捉える "1行のログの向こうに1人のユーザがいる"
ユーザ体験で捉える エラーログを見るだけではなく、サービスを触って確認してみる これをやらない人は意外と多い どういうエラー文言が出ているか? 待たされているのか、誤動作しているのか、あるいは全く問題ないのか
量への向き合い方 SLO / Error Budget はあくまで組織の行動を変えるための閾値として捉えるべき 体験を損ねている顧客がいるのなら、少なければ大丈夫という話じゃない 少数のエラーやパフォーマンス劣化でも目を通し、unknown-unknowns を減らす 意識を持つ
インフラ課題をインフラ技術だけで解かない
インフラ課題をインフラ技術だけで解かない 例: スロークエリが多発してDBの負荷が高い 原因は複雑な COUNT クエリだった
インフラ課題をインフラ技術だけで解かない ユーザ体験で捉える 原因は複雑な COUNT クエリだった クエリをチューニングしよう 何をしたときに発生するのか確認しよう
インフラ課題をインフラ技術だけで解かない 原因: 原因がページネーション用の合計数字を計算するクエリが遅かった インフラレイヤーでの解き方 クエリを改善する DBをチューニングしてクエリが速く計算できるようにする スケールアップする
インフラ課題をインフラ技術だけで解かない アプリケーションレイヤーでの解き方 数字を非同期で表示するようにする カウンタキャッシュを導入する →アプリケーションエンジニアとコミュニケーションする →SRE自らアプリケーションコードに手を入れる
インフラ課題をインフラ技術だけで解かない プロダクトレイヤーでの解き方 そもそもそのクエリが顧客にどういう価値をもたらしているか? 数字を表示するのをやめる ページネーションをやめる →PdMやデザイナーとコミュニケーションする
インフラ課題をインフラ技術だけで解かない DB負荷などのインフラ課題が顧客に何をもたらしているのかをすぐに結びつけら れるか? スロークエリの改善であっても事業/プロダクトのレベルで考えて解き方を決めら れるか? 組織的越境のフットワークを軽く保つには?
Site Reliability Engineering
信頼性工学 (Reliability Engineering) 機器が故障することなく動作し、意図された結果が得られる確率(信頼性)を上げること を目的としたシステム工学
Site Reliability Engineering の目的 顧客にとって信頼できるサービスを追求しつつ経済合理性の着地点を見つけること (...と解釈してもいいのではないか)
まとめ: インフラからSREへ 技術が進化し、組織論が整理されてもあるべきマインドセットは変わっていない 最新のSREの要素技術に取り組めていないことを気にしすぎる必要は全くない あるべき姿に後付けで名付けられたものにすぎない 顧客、事業、プロダクトにどれだけ deep dive できているかが最も重要 組織的越境の視座を持つこと
SRE の技術セットは各社似通っていて "つぶしがきく" 職業になった、が、 深く潜った人にだけ見える景色がある