第34回中国地方DB勉強会 in 広島_Why DBRE?

Slide 1

Slide 1 text

Why DBRE? 第34回中国地方DB勉強会 in 広島 @tomomo1015 2024/05/25

Slide 2

Slide 2 text

Agenda 00. Introduction 01. SREとは？ 02. DBREとは？ 03. DBRE+PM 04. PdM

Slide 3

Slide 3 text

Introduction 00

Slide 4

Slide 4 text

Why? なぜ？今日のテーマ

Slide 5

Slide 5 text

名前：tomo(@tomomo1015) 職歴 ● 新卒でSIerに1X年、PM＆DBAに従事 ● 事業会社にてSRE＆DBREを3年 ● 2024年2月から別事業会社でPdM見習い DB ● まいえすきゅーえりたい ● ぽすぐれしはじめた ● おらくるってるすき ● 家族とおでかけ、特に娘とデート ● ポケモンのミミッキュこの資料を書いた人

Slide 6

Slide 6 text

Q：なんであかずきんなんですか？ A：初めて登壇したコミュニティイベントが赤帽社さん主催のAnsibleのイベントで　　　赤い帽子で連想したキャラクターが「あかずきん」だったから。　　帽子の赤い色はずっと、Ansibleのロゴの色です。この資料を書いた人（余談）

Slide 7

Slide 7 text

URLはこちら！ https://t.co/VvwysB8C69 DBREJPというSlackやってます

Slide 8

Slide 8 text

Dev 今日お話させていただくこと SRE DBRE

Slide 9

Slide 9 text

Dev 今日お話させていただくこと SRE DBRE 今日の主題は DBRE！

Slide 10

Slide 10 text

SREとは？ 01 What is SRE?

Slide 11

Slide 11 text

Site Reliability Engineering Googleで培われたシステム管理とサービス運用の方法論ロールや職位ではない

Slide 12

Slide 12 text

SREとは ● SREが生まれた背景は？ ○ SRE本には「運用チームと開発チームの対立」があった ■ 好きなものを好きなタイミングでローンチしたい　→わかる ■ 一旦動いたシステムは変更したくない　→わかる ● チーム目標が対立しがち ● SREとは？ ○ 「ソフトウェアエンジニアに運用チームの設計を依頼したときにあがるもの」という記述 ■ これが正解ではなく、あくまで「GoogleのSRE」でのお話

Slide 13

Slide 13 text

あなたの考えるSREとは？

Slide 14

Slide 14 text

あなたの考えるSREとは？ ● 何故あなたは、SREをやる/やろうと思っているの？ ○ SRE本に書いてあるのはあくまで「方法の一例である」という　　前提を念頭においてほしい ■ SRE本に書いてある様々な手法、組織論はあくまで　　　　　「Google」という世界規模の企業事例である ● 技術的なノウハウ本だと思うといい

Slide 15

Slide 15 text

Toilの撲滅 postmortem SLA/SLO observability リリースエンジニアリングよくあるSREの手法（一部）

Slide 16

Slide 16 text

Toilの撲滅 postmortem SLA/SLO observability リリースエンジニアリングこれらをしていたら SREになれる？よくあるSREの手法（一部）

Slide 17

Slide 17 text

Toilの撲滅 postmortem SLA/SLO observability リリースエンジニアリング個人意見はNO あくまでこれらは手段よくあるSREの手法（一部）

Slide 18

Slide 18 text

Toilの撲滅 postmortem SLA/SLO observability リリースエンジニアリング何のためにこれらをするの？よくあるSREの手法（一部）

Slide 19

Slide 19 text

事業目標実施施策データの密結合マイクロサービスサイト不安定 SRE コストを減らすクラウド移行考え方のステップ（例）課題手段

Slide 20

Slide 20 text

事業目標どうすれば達成できる？データの密結合マイクロサービスサイト不安定 SRE コストを減らすクラウド移行考え方のステップ（例）課題手段課題に対し実施手段は様々サイトが不安定な状態に対し実施する施策は設備増強かもしれないコスト削減はソフトウェアの棚卸が最善案かもしれない

Slide 21

Slide 21 text

事業目標実施施策データの密結合マイクロサービスサイト不安定 SRE コストを減らすクラウド移行考え方のステップ（例）課題手段課題や手段は事業目標と実施施策に大きく依存する

Slide 22

Slide 22 text

あなたの考えるSREとは？ ● SREという職位、部署がすること ○ SREの技術を実施する組織にたいし、企業が実現したことは様々 ■ だからSRE憲章を作るということが大事 ● SRE本に書いてあることが100点できなくていい ● 今の事業目標、実施施策に対し、SREという方法の中で　最も実施すべき手段を定めて実施すればいい他社と比較する必要は全くないツールもモダンじゃなくていい課題に対しSREの手法で何を成し得たかが一番大事！！

Slide 23

Slide 23 text

SREは手段や考え方が書かれた文化であって目的ではない ※個人の意見です

Slide 24

Slide 24 text

DBREとは？ 02 What is DBRE?

Slide 25

Slide 25 text

Database Reliability Engineering 本書はデータベースのリライアビリティを実現するための考え方を「データベースリライアビリティエンジニアリング」と定義して、その具体的な手法を紹介します DBREも SREと同じ手法

Slide 26

Slide 26 text

DBAとDBREの違いは？

Slide 27

Slide 27 text

データ死守周囲を巻き込む Toil撲滅脱ペット分業廃止 DBREの指針

Slide 28

Slide 28 text

データ死守周囲を巻き込む Toil撲滅脱ペット分業廃止 DBREの指針全てではないですが多くの場合ここが DBAとDBREの違いになるかなと思っています全てではないですが多くの場合ここが DBAとDBREの違いになるかなと思っています全てではないですが多くの場合ここが DBAとDBREの違いになるかなと思っています

Slide 29

Slide 29 text

DBAとDBREの違い ● 「周囲を巻き込む」とは？ ○ DBで起きた問題をDBエンジニアだけで解決するのではなく、周囲を巻き込んで解決すること ■ 例えば「何故INDEXを沢山作ってはいけないか？」を説明し理解してもらう ■ 実際の障害の原因を開発者にも説明し、責めるのではなく「どうすれば再発しないようにできるか」を議論する周囲を巻き込む

Slide 30

Slide 30 text

DBAとDBREの違い ● 「ペット」とは？ ○ 餌をあげ、世話をし、病気になったらつきっきりで面倒をみる ○ DBエンジニアが常時存在しないと開発運用ができないDBのこと ● 「脱ペット」とは？ ○ 家畜化のこと ○ 基本世話をしない、病気になったら隔離すること脱ペット

Slide 31

Slide 31 text

DBAとDBREの違い ● 具体的な例 ○ ペットになっている原因を探して解消する ■ 例えばメモリ逼迫が頻繁に発生するのであれば、その問題を解決する、予兆検知できるようにする ○ YugabyteDB等の技術的に可能にする ■ ただし運用負荷など別課題が発生する可能性もあるので、慎重な判断が必要脱ペット

Slide 32

Slide 32 text

DBAとDBREの違い ● 「分業廃止」とは？ ○ DB以外の業務、技術分野も実施すること ■ 実際DBREをやって一番大事だと　　思ったことでありDBAとの違い ■ DBREはSREが実施するソフトウェアエンジニアリング、リリースエンジニアリングも当然含まれる ● DBだけやっているとどうしても視野や考えが狭くなる、対立してしまうので、他技術にも触れることで苦労を理解し、同じ土俵に立って会話することが大事分業廃止同様にSREも DBREにDBを任せっぱなしはダメ

Slide 33

Slide 33 text

DBREとSREの違いは？

Slide 34

Slide 34 text

Dev 開発とSREとDBRE SRE DBRE SREとDevもやるけど SREよりDevがちょっと多いのが DBRE

Slide 35

Slide 35 text

DBREとSRE ● DBREとSREの責任分界点を明確にすること ○ SRE/DBREが両方存在する会社が最初に定めること ○ DBREはあくまでSREの中でDBに少し偏った業務をするエンジニアリングであって、基本はSREと同等 ○ DBのSREは全てDBREに任せていい訳ではなく、同様にDBREがSRE の業務をやらなくていい訳ではない ■ 例として、RDSのTerraformは誰が作ってもいいが、DBREのレビュー無しではmaster marge＆apply はNG、逆も同様等 ■ DBばっかりやってると、視野も狭くなるし技術力つかないよ

Slide 36

Slide 36 text

DBREとDev ● DBREの特権は「SREよりDevに近い」こと ○ DBはそもそも、インフラと開発の中間に存在することが多く、両技術をある程度把握しないと業務が出来ないという点がある ■ ソフトウェアインストールする際はOS/インフラ知識が必要 ■ SQLやテーブル設計等は開発知識が必要 ○ DBREはSREとDevの間に立って両サイドの間を取りつもつということができる ■ DBのスロークエリログからアプリケーションの課題を見つけ、SREにWEB サーバのメモリ拡張を提案する、等

Slide 37

Slide 37 text

DBREの必要スキルとは？

Slide 38

Slide 38 text

DBREに求められる技術スキル Dev Ops Infra DB ※個人の意見です

Slide 39

Slide 39 text

DBRE＋PM 03 Why DBRE＋PM?

Slide 40

Slide 40 text

DBREをやりたいと思った背景

Slide 41

Slide 41 text

SIer時代の悩み開発側なんでこんなに DB分かってくれないのなんで設定変えた… インフラ冗談だよね 2日でDBインストールからセットアップ終わらせろと？！一回SQL流したら通ったからってそれ他のクエリ考慮してないよー！ストレージの設計なんでレビュー参加させてくれないの冗長構成要件満たしていないよ

Slide 42

Slide 42 text

SIer時代の悩みそっか問題の原因もどんなに大変かもどんな設計してるのかもちゃんと伝えきれてないんだ巻き込み不足だ！！

Slide 43

Slide 43 text

SIer時代の悩み DBRE?! そうかみんなに教育すれば今の悩み解決するかも？！でもDBREやってるところ少ないしまずはSREやってみる？ ♪ ♪

Slide 44

Slide 44 text

スキル不足という壁

Slide 45

Slide 45 text

結論自分の特異点を見つけて活かしてみて！

Slide 46

Slide 46 text

DBREに求められる技術スキル（再掲） Dev Ops Infra DB ※個人の意見です

Slide 47

Slide 47 text

その時点の私のスキル PM Infra DB DBチョットワカルPM Dev

Slide 48

Slide 48 text

詰んだと思ったけど…

Slide 49

Slide 49 text

その時点の私のスキル PM Infra DB DBチョットワカルPM 幸いこの程度スキルで拾っていただきました！

Slide 50

Slide 50 text

その時点の私のスキル要件定義基本詳細設計構築導入移行運用 Ops 自分で出来るここの経験がなかったのと対応できるDBエンジン数が少なかった

Slide 51

Slide 51 text

その時点のメンバーのスキル要件定義基本詳細設計構築導入移行運用 Ops チームメンバーの得意なことここが出来る人が少なかった PMが出来る人はSREには存在しなかった

Slide 52

Slide 52 text

自分の特異点を活かす

Slide 53

Slide 53 text

私がやった特異点の活かし方自身に足りない技術に触る特異点を活かす所を探す Just do it!!

Slide 54

Slide 54 text

事業目標実施施策データの密結合マイクロサービスサイト不安定 SRE コストを減らすクラウド移行管理職としてやったこと課題手段

Slide 55

Slide 55 text

SRE/DBREにおける管理職 ● 事業目標に対し具体的な対応策/実施施策を策定し明文化する ○ 実施施策の取捨選択をする ■ 緊急度や重要度と要員数に応じて、年度単位で実施する施策を決める ○ 完了条件やマイルストン、期限も明確化する ○ 各メンバーと1on1を経てスキルや成長に合わせた施策にアサインする ■ Primary/Secondary制にするなど工夫する ○ 各施策（プロジェクト）の進捗の確認や課題の吸い上げをし、必要に応じて対処する

Slide 56

Slide 56 text

SRE/DBREにおけるPM ● 基本は通常のPMと同じこと ○ 目的/GOALを必ず明文化し、メンバーに浸透させる ○ ただしSRE/DBREが実施することはスピード優先であることが多いことから、WFであることは少ない ■ 目的とスケジュールに合わせて柔軟にプロジェクトの進め方を変える必要はある ■ アジャイル、半アジャイル等、手法をそれぞれを用いる ○ フェーズによって重要ポイント、判断ポイントを変える ■ 例えば性能改善プロジェクトの場合、原因調査をする場合は　　「分析」に重きを置き、施策実施は「スピード」に重きを置く

Slide 57

Slide 57 text

PdM 04 Why PdM?

Slide 58

Slide 58 text

サービス信頼性の階層引用元：https://sre.google/sre-book/part-III-practices /

Slide 59

Slide 59 text

サービス信頼性の階層引用元：https://sre.google/sre-book/part-III-practices / 監視してる？

Slide 60

Slide 60 text

サービス信頼性の階層引用元：https://sre.google/sre-book/part-III-practices / 障害対応してる？

Slide 61

Slide 61 text

サービス信頼性の階層引用元：https://sre.google/sre-book/part-III-practices / 障害分析してる？

Slide 62

Slide 62 text

サービス信頼性の階層引用元：https://sre.google/sre-book/part-III-practices / 障害原因の恒久対応テストしてリリースした？

Slide 63

Slide 63 text

サービス信頼性の階層引用元：https://sre.google/sre-book/part-III-practices / そもそも容量設計足りてる？

Slide 64

Slide 64 text

サービス信頼性の階層引用元：https://sre.google/sre-book/part-III-practices / プロダクト育てる為の開発やってる？

Slide 65

Slide 65 text

サービス信頼性の階層引用元：https://sre.google/sre-book/part-III-practices / プロダクトの信頼性が成り立つ

Slide 66

Slide 66 text

サービス信頼性の階層引用元：https://sre.google/sre-book/part-III-practices / from bottom to top

Slide 67

Slide 67 text

サービス信頼性の階層引用元：https://sre.google/sre-book/part-III-practices / from top to bottom?

Slide 68

Slide 68 text

PdMから始めるSRE/DBRE ● PdMから始める「サイト信頼性の向上」 ○ サイト/サービスの信頼性をするのは、SRE/DBRE/DevOpsだけでなく、PdMも入るべきでは？ ○ どんなに素晴らしいエンジニアが作っても利用されない、廃止されるシステムの原因でよくあること ■ 要件設計 ■ プロダクト設計 ● ここにチャンレンジしてみることにしました！

Slide 69

Slide 69 text

私のDBREへの道はまだ道半ばです

Slide 70

Slide 70 text

Thank you for your attention!! May your life always be rich and happy DBRE life!