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 の技術セットは各社似通っていて "つぶしがきく" 職業になった、が、 深く潜った人にだけ見える景色がある