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!