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
21
8.6k
インフラから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
490
Cookpad TechConf 2022 Keynote
mirakui
0
3.8k
ドライイーストを使わずにパンを焼けるか? 〜天然酵母のパン作りを支える技術〜
mirakui
0
3.4k
関東積みについて/How to build Kanto-stacking
mirakui
0
690
先折りGTRについて/How to build left-GTR transitions
mirakui
3
1.1k
サービス開発速度に着目したソフトウェアアーキテクチャ/Software architecture for effective service development at Cookpad
mirakui
5
7k
Beyond the Boundaries
mirakui
1
1.3k
Cookpad Under a Microscope
mirakui
6
8.6k
Technical Successes and Failures in the History of Cookpad Development
mirakui
45
37k
Other Decks in Technology
See All in Technology
白金鉱業Meetup_Vol.19_PoCはデモで語れ!顧客の本音とインサイトを引き出すソリューション構築
brainpadpr
2
460
~宇宙最速~2025年AWS Summit レポート
satodesu
1
860
VISITS_AIIoTビジネス共創ラボ登壇資料.pdf
iotcomjpadmin
0
140
VCpp Link and Library - C++ breaktime 2025 Summer
harukasao
0
220
新卒3年目の後悔〜機械学習モデルジョブの運用を頑張った話〜
kameitomohiro
0
370
20250623 Findy Lunch LT Brown
3150
0
720
Snowflake Summit 2025全体振り返り / Snowflake Summit 2025 Overall Review
mtpooh
2
170
ローカルLLMでファインチューニング
knishioka
0
120
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
4
1.3k
ひとり情シスなCTOがLLMと始めるオペレーション最適化 / CTO's LLM-Powered Ops
yamitzky
0
330
doda開発 生成AI元年宣言!自家製AIエージェントから始める生産性改革 / doda Development Declaration of the First Year of Generated AI! Productivity Reforms Starting with Home-grown AI Agents
techtekt
0
190
Agentic DevOps時代の生存戦略
kkamegawa
0
830
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
Designing for humans not robots
tammielis
253
25k
Documentation Writing (for coders)
carmenintech
71
4.9k
How GitHub (no longer) Works
holman
314
140k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Git: the NoSQL Database
bkeepers
PRO
430
65k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.7k
Typedesign – Prime Four
hannesfritz
42
2.7k
Side Projects
sachag
455
42k
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 の技術セットは各社似通っていて "つぶしがきく" 職業になった、が、 深く潜った人にだけ見える景色がある