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
クラウドネイティブとDBRE
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
_awache
June 16, 2022
Technology
0
300
クラウドネイティブとDBRE
Jagu'e'r Cloud Native #6 Cloud Day 振り返り & DeepDive
での LT 資料です
_awache
June 16, 2022
Tweet
Share
More Decks by _awache
See All by _awache
o11yで育てる、強い内製開発組織
_awache
4
670
20250710-dbtech-showcase-C7.pdf
_awache
0
76
Restarting_SRE_Road_to_SRENext_.pdf
_awache
1
580
SREKaigi.pdf
_awache
3
9.4k
Practical_Tips_for_Using_Confluence__Jira__and_Findy_Team__Right_Now.pdf
_awache
2
540
【関西DB勉強会】 ~ 全部見せます ~KINTO テクノロジーズの DBRE とは
_awache
2
3.7k
KTC_DBRE.pdf
_awache
1
700
_オープニング__GitLabに学ぶ_世界最先端のリモート組織のつくりかた_そーだいなる輪読会キックオフ.pdf
_awache
0
160
[Opening] DBRE Summit 2023
_awache
0
640
Other Decks in Technology
See All in Technology
非情報系研究者へ送る Transformer入門
rishiyama
9
6.7k
[JAWS DAYS 2026]私の AWS DevOps Agent 推しポイント
furuton
0
130
JAWS FESTA 2025でリリースしたほぼリアルタイム文字起こし/翻訳機能の構成について
naoki8408
1
210
AWS DevOps Agent vs SRE俺 / AWS DevOps Agent vs me, the SRE
sms_tech
3
510
SRE NEXT 2026 CfP レビュアーが語る聞きたくなるプロポーザルとは?
yutakawasaki0911
0
200
Kaggleの経験が実務にどう活きているか / kaggle_findy
sansan_randd
7
1.3k
20260305_【白金鉱業】分析者が地理情報を武器にするための軽量なアドホック分析環境
yucho147
2
220
Syncでつながるアジャイル 部署の壁を越えて進化し続けるチームづくり / Agile practices connecting and syncing beyond departmental boundaries
muit
0
110
20260311 技術SWG活動報告(デジタルアイデンティティ人材育成推進WG Ph2 活動報告会)
oidfj
0
150
8万デプロイ
iwamot
PRO
2
200
僕、S3 シンプルって名前だけど全然シンプルじゃありません よろしくお願いします
yama3133
1
150
ビズリーチにおける検索・推薦の取り組み / DEIM2026
visional_engineering_and_design
1
140
Featured
See All Featured
Color Theory Basics | Prateek | Gurzu
gurzu
0
240
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
330
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
240
Optimising Largest Contentful Paint
csswizardry
37
3.6k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
390
The Language of Interfaces
destraynor
162
26k
Building AI with AI
inesmontani
PRO
1
780
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
290
The Spectacular Lies of Maps
axbom
PRO
1
610
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
140
So, you think you're a good person
axbom
PRO
2
1.9k
Transcript
Google Confidential + proprietary Jagu'e'r Cloud Native #6 Cloud Day
振り返り & DeepDive クラウドネイティブと DBRE
自己紹介 mysql > SELECT * FROM me \G ********************* 1.
row ********************* name: 粟田 啓介 nickname: あわっち twitter: @_awache role: CCoE, DBRE Community: Jagu’e’r CCoE 研究分科会 SG, DBREJP 運営 1 rows in set (0.00 sec) mysql > SELECT * FROM readme; +-----------------------------------------------------------+ | readme | +-----------------------------------------------------------+ | この資料は @awache という個人の独断と偏見により作成されたものです。 | | 所属する組織等の意見を代表するものではありません。 | | 合法性や安全性、情報の正確性についても保証できません。 | +-----------------------------------------------------------+ 3 rows in set (0.00 sec)
Database Reliability Engineering(DBRE) とは ❖ 主な役割 ➢ SLO/SLI を測定し、それに合わせた開発組織へのアプローチ ➢
開発チームに対する教育 ➢ プラットフォームの構築 ➢ 自動化、自律化推進による生産性の向上 ➢ Database 運用のスペシャリスト ➢ 他分野のスペシャリストとの分野を超えたコラボレーション Database におけるモノゴトを Reliability Engineering によって解決 Database に対する専門知識と、Database Professional としての判断を用いて 再帰性のあるプロセスや戦略決定に落とし込むこと
Database スペシャリストの現状 ❖ 希望する割合が少ない ➢ 2022年3月発行職種別マーケットレポート ITエンジニアによるとインフラエンジニアへの希望割合は 全体の5% ▪ インフラエンジニアの中にもさらに種類は分類され、
Database スペシャリストは最もマイノリ ティな職種の一つになっている Database は専門スキル、希少性が高い
Database スペシャリストが希少な理由 ❖ Google Cloud をはじめとする Public Cloud の台頭により Database
に対するハードルが下 がった ➢ 難しい設定はクラウドベンダーが肩代わりしてくれる => Managed Service ➢ 誰でもある程度構築・運用ができるようになった Database スペシャリストがいなくてもアプリケーションは動くから 構築やバックアップ設定とかポチポチするだけでいい! モニタリング等便利な機能が次々提供される! ハードウェアは全部 Google Cloud がやってくれる!
Database スペシャリストが希少な理由 ❖ 膨大なレビューとチェック項目 ❖ 一つのオペレーションにかける工数 ❖ DB オペレーションの属人化によるリソース不足 ➢
結果として企業からも求められなくなり 市場からも相対的に減ってしまう状況になる DBA が門番として機能してしまうとアジリティを低下させてしまう DBA とコミュニケー ションするのめんどく さい
Database スペシャリストの重要性 ❖ Database を守るのではなく事業を守ることを第一に考える ➢ データを正しく守る ➢ 外的要因の変化に追従する ➢
障害復旧時間を短縮する ➢ サービスのレスポンスを正常に動作させる 事業を継続的に成長させるためには Database スペシャリストは重要
Database スペシャリストの重要性 ❖ Database を守るのではなく事業を守ることを第一に考える ➢ データを正しく守る ➢ 外的要因の変化に追従する ➢
障害復旧時間を短縮する ➢ サービスのレスポンスを正常に動作させる 事業を継続的に成長させるためには Database スペシャリストは重要
Database の価値 ❖ データは基本的に積み上げられる ➢ 価値が高まった Database は常に狙われる ➢ データ流出が発生した場合、実害だけでなく甚大なレピュテーションリスクを抱える
Database そのものの価値は時間に比例して高まる データ量 時間 価値
Database スペシャリストの重要性 ❖ Database を守るのではなく事業を守ることを第一に考える ➢ データを正しく守る ➢ 外的要因の変化に追従する ➢
障害復旧時間を短縮する ➢ サービスのレスポンスを正常に動作させる 事業を継続的に成長させるためには Database スペシャリストは重要
Database 運用の変化 ❖ 政治、世論、法律などの変化 ➢ 個人情報保護法は3年ごとに改定 ▪ 改定の度に罰則は厳しくなる傾向になる ➢ 2022-04
改正個人情報保護法 ▪ 1000件以上の個人情報漏洩は報告義務が発生し、重大なインシデントに位置付け ➢ GDPR, 戦争, etc. データはその重要性から外部要因の変化による影響も受けやすい
Database スペシャリストの重要性 ❖ Database を守るのではなく事業を守ることを第一に考える ➢ データを正しく守る ➢ 外的要因の変化に追従する ➢
障害復旧時間を短縮する ➢ サービスのレスポンスを正常に動作させる 事業を継続的に成長させるためには Database スペシャリストは重要
サービスのダウンタイム ❖ Database のダウンタイムはそのままサービスのダウンタイムにつながる ➢ サービスの復旧時間 > Database 復旧時間 サービスの正常な状態は
Database が正常に機能していることが前提 Frontend Platform Services Frontend Platform Services サービスA サービスB
サービスのダウンタイム ❖ Database のダウンタイムはそのままサービスのダウンタイムにつながる ➢ サービスの復旧時間 > Database 復旧時間 ➢
Database を共有している場合、ドミノ倒しのようにサービスが倒れていくリスクがある サービスの正常な状態は Database が正常に機能していることが前提 Frontend Platform Services Frontend Platform Services サービスA サービスB X : :
サービスのダウンタイム ❖ Database のダウンタイムはそのままサービスのダウンタイムにつながる ➢ サービスの復旧時間 > Database 復旧時間 ➢
Database を共有している場合、ドミノ倒しのようにサービスが倒れていくリスクがある サービスの正常な状態は Database が正常に機能していることが前提 Frontend Platform Services Frontend Platform Services サービスA サービスB X X X : : X
Database スペシャリストの重要性 ❖ Database を守るのではなく事業を守ることを第一に考える ➢ データを正しく守る ➢ 外的要因の変化に追従する ➢
障害復旧時間を短縮する ➢ サービスのレスポンスを正常に動作させる 事業を継続的に成長させるためには Database スペシャリストは重要
Database はボトルネックになりやすい ❖ アプリケーションレスポンスタイム悪化起因の最も多い要因は Database ➢ データ量増加に耐えられなくなりレスポンスが悪くなる ➢ データ量増加と共に返されるデータサイズが大きくなりアプリケーション処理時間が増える データ量増加に伴うサービスレベルの低下
Database スペシャリストの重要性 (再掲) ❖ Database を守るのではなく事業を守ることを第一に考える ➢ データを正しく守る ➢ 外的要因の変化に追従する
➢ 障害復旧時間を短縮する ➢ サービスのレスポンスを正常に動作させる 事業を成長させるためには Database を正しく扱うことが重要になる
僕の目指す DBRE の姿 ❖ 僕は横断組織に所属 ➢ 横断組織はそこにあるだけでは何に使われるか分からない税金と同じ ➢ ビジネスに対していい影響を与えることが重要 ▪
いい影響とは • サービスの失敗率を下げ、持続可能性を上げるための活動 • エンジニアの生産性向上への寄与 など アウトプットがビジネスに反映されることによって価値提供される
DBREという選択 ❖ ルールやレビューだけで対応できるほど事業のスピードは遅くない ➢ ルールで雁字搦めにするのではなく Platform の提供や現場のエンジニアとの協業によって課題を 解決し続ける ➢ Database
スキルを持つエンジニアはエンジニア全体から見たら希少 ▪ とはいえエンジニアは市場にたくさんいる ▪ (手の届く範囲の) エンジニアが誰でも同じように Database を扱える状態を作ることで中長期 成長を見据えたアプリケーション開発に寄与し続ける Database のさまざまな課題に対する解決を手助けする
DBRE だけで何かがやれるとは思えない やりたいことはたくさん生まれる もちろん全部できたら最強 けどスキルもリソースも限られている ビジネスの視点、プロダクトの視点で考えないと 価値が分からないことも多い なぜなら個人が持てるパラメータや装備は有限だから だったらどうする?!
周りの全ての力を借りる ❖ 自分の得意な分野を伸ばしていきつつ ❖ 周りの力を借りて、同時に周辺の知識を少しずつ蓄えていくことで ➢ 社内だけでなくコミュニティも ❖ 価値を提供し続けることを考え続ける ❖
それが今、クラウド時代を生きている僕にできる最大限のことだと思っています 足りないところを補っていただき、自分もそれを還元する
X X
SELECT questions FROM you;
SELECT ‘THANK YOU’ FROM me;