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.7k
インフラから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
510
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
7.1k
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
CDK Toolkit Libraryにおけるテストの考え方
smt7174
1
540
大量配信システムにおけるSLOの実践:「見えない」信頼性をSLOで可視化
plaidtech
PRO
0
360
How Do I Contact Jetblue Airlines® Reservation Number: Fast Support Guide
thejetblueairhelpsupport
0
110
Autify Company Deck
autifyhq
2
44k
ポストコロナ時代の SaaS におけるコスト削減の意義
izzii
1
450
スタックチャン家庭用アシスタントへの道
kanekoh
0
120
Talk to Someone At Delta Airlines™️ USA Contact Numbers
travelcarecenter
0
160
An introduction to Claude Code SDK
choplin
1
140
サイバーエージェントグループのSRE10年の歩みとAI時代の生存戦略
shotatsuge
4
990
Amplify Gen2から知るAWS CDK Toolkit Libraryの使い方/How to use the AWS CDK Toolkit Library as known from Amplify Gen2
fossamagna
1
330
TROCCO と Stripeを使ったら Tenant-aware Telemetryを有効活用できそう! / Using TROCCO and Stripe, it seems possible to effectively utilize tenant-aware telemetry!
oztick139
0
110
LIXIL基幹システム刷新に立ち向かう技術的アプローチについて
tsukuha
1
270
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Embracing the Ebb and Flow
colly
86
4.8k
The Cost Of JavaScript in 2023
addyosmani
51
8.6k
Automating Front-end Workflow
addyosmani
1370
200k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Become a Pro
speakerdeck
PRO
29
5.4k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Being A Developer After 40
akosma
90
590k
A designer walks into a library…
pauljervisheath
207
24k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
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 の技術セットは各社似通っていて "つぶしがきく" 職業になった、が、 深く潜った人にだけ見える景色がある