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

第34回 中国地方DB勉強会 in 広島にてお話させていただきました「Why DBRE?」の資料です。
イベントURL：https://dbstudychugoku.connpass.com/event/316403/

Transcript

1. Why DBRE? 第34回 中国地方DB勉強会 in 広島 @tomomo1015 2024/05/25
2. Agenda 00. Introduction 01. SREとは？ 02. DBREとは？ 03. DBRE+PM 04. PdM
3. Introduction 00
4. Why? なぜ？ 今日のテーマ
5. 名前：tomo(@tomomo1015) 職歴 • 新卒でSIerに1X年、PM＆DBAに従事 • 事業会社にてSRE＆DBREを3年 • 2024年2月から別事業会社でPdM見習い DB • まいえすきゅーえりたい • ぽすぐれしはじめた • おらくるってる すき • 家族とおでかけ、特に娘とデート • ポケモンのミミッキュ この資料を書いた人
6. Q：なんであかずきんなんですか？ A：初めて登壇したコミュニティイベントが赤帽社さん主催のAnsibleのイベントで 　 　　 赤い帽子で連想したキャラクターが「あかずきん」だったから。 　　帽子の赤い色はずっと、Ansibleのロゴの色です。 この資料を書いた人（余談）
7. URLはこちら！ https://t.co/VvwysB8C69 DBREJPというSlackやってます
8. Dev 今日お話させていただくこと SRE DBRE
9. Dev 今日お話させていただくこと SRE DBRE 今日の主題は DBRE！
10. SREとは？ 01 What is SRE?
11. Site Reliability Engineering Googleで培われた システム管理とサービス運用の方法論 ロールや職位 ではない
12. SREとは • SREが生まれた背景は？ ◦ SRE本には「運用チームと開発チームの対立」があった ▪ 好きなものを好きなタイミングでローンチしたい　→わかる ▪ 一旦動いたシステムは変更したくない　→わかる • チーム目標が対立しがち • SREとは？ ◦ 「ソフトウェアエンジニアに運用チームの設計を依頼したときにあがる もの」という記述 ▪ これが正解ではなく、あくまで「GoogleのSRE」でのお話
13. あなたの考えるSREとは？
14. あなたの考えるSREとは？ • 何故あなたは、SREをやる/やろうと思っているの？ ◦ SRE本に書いてあるのはあくまで「方法の一例である」という　　前提を念 頭においてほしい ▪ SRE本に書いてある様々な手法、組織論はあくまで　　　　　 「Google」という世界規模の企業事例である • 技術的なノウハウ本だと思うといい
15. Toilの撲滅 postmortem SLA/SLO observability リリース エンジニアリング よくあるSREの手法（一部）
16. Toilの撲滅 postmortem SLA/SLO observability リリース エンジニアリング これらをしていたら SREになれる？ よくあるSREの手法（一部）
17. Toilの撲滅 postmortem SLA/SLO observability リリース エンジニアリング 個人意見はNO あくまでこれらは手段 よくあるSREの手法（一部）
18. Toilの撲滅 postmortem SLA/SLO observability リリース エンジニアリング 何のために これらをするの？ よくあるSREの手法（一部）
19. 事業目標 実施施策 データの 密結合 マイクロ サービス サイト 不安定 SRE コストを 減らす クラウド移 行 考え方のステップ（例） 課題 手段
20. 事業目標 どうすれば 達成できる？ データの 密結合 マイクロ サービス サイト 不安定 SRE コストを 減らす クラウド移 行 考え方のステップ（例） 課題 手段 課題に対し 実施手段は様々 サイトが不安定な状態に対し 実施する施策は 設備増強かもしれない コスト削減は ソフトウェアの棚卸が 最善案かもしれない
21. 事業目標 実施施策 データの 密結合 マイクロ サービス サイト 不安定 SRE コストを 減らす クラウド移 行 考え方のステップ（例） 課題 手段 課題や手段は 事業目標と実施施策 に大きく依存する
22. あなたの考えるSREとは？ • SREという職位、部署がすること ◦ SREの技術を実施する組織にたいし、企業が実現したことは様々 ▪ だからSRE憲章を作るということが大事 • SRE本に書いてあることが100点できなくていい • 今の事業目標、実施施策に対し、SREという方法の中で　最も 実施すべき手段を定めて実施すればいい 他社と比較する必要は全くない ツールもモダンじゃなくていい 課題に対しSREの手法で何を成し得たかが 一番大事！！
23. SREは手段や 考え方が書かれた文化であって 目的ではない ※個人の意見です
24. DBREとは？ 02 What is DBRE?
25. Database Reliability Engineering 本書はデータベースのリライアビリティを実現するための考え方を 「データベースリライアビリティエンジニアリング」と定義して、その 具体的な手法を紹介します DBREも SREと同じ手法
26. DBAとDBREの違いは？
27. データ 死守 周囲を 巻き込む Toil撲滅 脱ペット 分業廃止 DBREの指針
28. データ 死守 周囲を 巻き込む Toil撲滅 脱ペット 分業廃止 DBREの指針 全てではないですが 多くの場合ここが DBAとDBREの違いに なるかなと思っています 全てではないですが 多くの場合ここが DBAとDBREの違いに なるかなと思っています 全てではないですが 多くの場合ここが DBAとDBREの違いに なるかなと思っています
29. DBAとDBREの違い • 「周囲を巻き込む」とは？ ◦ DBで起きた問題をDBエンジニアだ けで解決するのではなく、周囲を巻き 込んで解決すること ▪ 例えば「何故INDEXを沢山作っては いけないか？」を説明し理解してもら う ▪ 実際の障害の原因を開発者にも説明 し、責めるのではなく「どうすれば再発 しないようにできるか」を議論する 周囲を 巻き込む
30. DBAとDBREの違い • 「ペット」とは？ ◦ 餌をあげ、世話をし、病気になったら つきっきりで面倒をみる ◦ DBエンジニアが常時存在しないと開 発運用ができないDBのこと • 「脱ペット」とは？ ◦ 家畜化のこと ◦ 基本世話をしない、病気になったら隔 離すること 脱ペット
31. DBAとDBREの違い • 具体的な例 ◦ ペットになっている原因を探して解消 する ▪ 例えばメモリ逼迫が頻繁に発生するので あれば、その問題を解決する、予兆検知 できるようにする ◦ YugabyteDB等の技術的に可能に する ▪ ただし運用負荷など別課題が発生する可 能性もあるので、慎重な判断が必要 脱ペット
32. DBAとDBREの違い • 「分業廃止」とは？ ◦ DB以外の業務、技術分野も実施すること ▪ 実際DBREをやって一番大事だと　　 思ったことでありDBAとの違い ▪ DBREはSREが実施するソフトウェアエ ンジニアリング、リリースエンジニアリング も当然含まれる • DBだけやっているとどうしても視野や考え が狭くなる、対立してしまうので、他技術にも 触れることで苦労を理解し、同じ土俵に立っ て会話することが大事 分業廃止 同様にSREも DBREにDBを任せっぱなしは ダメ
33. DBREとSREの違いは？
34. Dev 開発とSREとDBRE SRE DBRE SREとDevもやるけど SREよりDevがちょっと多いのが DBRE
35. DBREとSRE • DBREとSREの責任分界点を明確にすること ◦ SRE/DBREが両方存在する会社が最初に定めること ◦ DBREはあくまでSREの中でDBに少し偏った業務をするエンジニアリン グであって、基本はSREと同等 ◦ DBのSREは全てDBREに任せていい訳ではなく、同様にDBREがSRE の業務をやらなくていい訳ではない ▪ 例として、RDSのTerraformは誰が作ってもいいが、DBREのレビュー無しで はmaster marge＆apply はNG、逆も同様等 ▪ DBばっかりやってると、視野も狭くなるし技術力つかないよ
36. DBREとDev • DBREの特権は「SREよりDevに近い」こと ◦ DBはそもそも、インフラと開発の中間に存在することが多く、両技術をあ る程度把握しないと業務が出来ないという点がある ▪ ソフトウェアインストールする際はOS/インフラ知識が必要 ▪ SQLやテーブル設計等は開発知識が必要 ◦ DBREはSREとDevの間に立って両サイドの間を取りつもつということが できる ▪ DBのスロークエリログからアプリケーションの課題を見つけ、SREにWEB サーバのメモリ拡張を提案する、等
37. DBREの必要スキルとは？
38. DBREに求められる技術スキル Dev Ops Infra DB ※個人の意見です
39. DBRE＋PM 03 Why DBRE＋PM?
40. DBREをやりたいと思った背景
41. SIer時代の悩み 開発側なんでこんなに DB分かってくれないの なんで設定変えた… インフラ冗談だよね 2日でDBインストールから セットアップ終わらせろと？！ 一回SQL流したら 通ったからって それ他のクエリ考慮 してないよー！ ストレージの設計 なんでレビュー参加させて くれないの 冗長構成要件満たしていないよ
42. SIer時代の悩み そっか 問題の原因もどんなに大変かも どんな設計してるのかも ちゃんと伝えきれてないんだ 巻き込み不足だ！ ！
43. SIer時代の悩み DBRE?! そうかみんなに教育すれば 今の悩み解決するかも？！ でもDBREやってるところ 少ないし まずはSREやってみる？ ♪ ♪
44. スキル不足という壁
45. 結論 自分の特異点を見つけて活かしてみて！
46. DBREに求められる技術スキル（再掲） Dev Ops Infra DB ※個人の意見です
47. その時点の私のスキル PM Infra DB DBチョットワカルPM Dev
48. 詰んだ と思ったけど…
49. その時点の私のスキル PM Infra DB DBチョットワカルPM 幸いこの程度スキルで 拾っていただきました！
50. その時点の私のスキル 要件定義 基本詳細 設計 構築 導入 移行 運用 Ops 自分で出来る ここの経験がなかったのと 対応できるDBエンジン数が 少なかった
51. その時点のメンバーのスキル 要件定義 基本詳細 設計 構築 導入 移行 運用 Ops チームメンバーの得意なこと ここが出来る人が少なかった PMが出来る人はSREには 存在しなかった
52. 自分の特異点を活かす
53. 私がやった特異点の活かし方 自身に 足りない 技術に 触る 特異点を 活かす所 を探す Just do it!!
54. 事業目標 実施施策 データの 密結合 マイクロ サービス サイト 不安定 SRE コストを 減らす クラウド移 行 管理職としてやったこと 課題 手段
55. SRE/DBREにおける管理職 • 事業目標に対し具体的な対応策/実施施策を策定し明文化する ◦ 実施施策の取捨選択をする ▪ 緊急度や重要度と要員数に応じて、年度単位で実施する施策を決める ◦ 完了条件やマイルストン、期限も明確化する ◦ 各メンバーと1on1を経てスキルや成長に合わせた施策にアサインす る ▪ Primary/Secondary制にするなど工夫する ◦ 各施策（プロジェクト）の進捗の確認や課題の吸い上げをし、必要に応 じて対処する
56. SRE/DBREにおけるPM • 基本は通常のPMと同じこと ◦ 目的/GOALを必ず明文化し、メンバーに浸透させる ◦ ただしSRE/DBREが実施することはスピード優先であることが多いこ とから、WFであることは少ない ▪ 目的とスケジュールに合わせて柔軟にプロジェクトの進め方を変える必要 はある ▪ アジャイル、半アジャイル等、手法をそれぞれを用いる ◦ フェーズによって重要ポイント、判断ポイントを変える ▪ 例えば性能改善プロジェクトの場合、原因調査をする場合は　　「分析」に 重きを置き、施策実施は「スピード」に重きを置く
57. PdM 04 Why PdM?
58. サービス信頼性の階層 引用元 ：https://sre.google/sre-book/part-III-practices /
59. サービス信頼性の階層 引用元 ：https://sre.google/sre-book/part-III-practices / 監視してる？
60. サービス信頼性の階層 引用元 ：https://sre.google/sre-book/part-III-practices / 障害対応してる？
61. サービス信頼性の階層 引用元 ：https://sre.google/sre-book/part-III-practices / 障害分析してる？
62. サービス信頼性の階層 引用元 ：https://sre.google/sre-book/part-III-practices / 障害原因の恒久対応 テストしてリリースした？
63. サービス信頼性の階層 引用元 ：https://sre.google/sre-book/part-III-practices / そもそも容量設計 足りてる？
64. サービス信頼性の階層 引用元 ：https://sre.google/sre-book/part-III-practices / プロダクト育てる為の 開発やってる？
65. サービス信頼性の階層 引用元 ：https://sre.google/sre-book/part-III-practices / プロダクトの信頼性 が成り立つ
66. サービス信頼性の階層 引用元 ：https://sre.google/sre-book/part-III-practices / from bottom to top
67. サービス信頼性の階層 引用元 ：https://sre.google/sre-book/part-III-practices / from top to bottom?
68. PdMから始めるSRE/DBRE • PdMから始める「サイト信頼性の向上」 ◦ サイト/サービスの信頼性をするのは、SRE/DBRE/DevOpsだけで なく、PdMも入るべきでは？ ◦ どんなに素晴らしいエンジニアが作っても利用されない、廃止されるシ ステムの原因でよくあること ▪ 要件設計 ▪ プロダクト設計 • ここにチャンレンジしてみることにしました！
69. 私のDBREへの道は まだ道半ばです
70. Thank you for your attention!! May your life always be rich and happy DBRE life!