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
_awache
June 16, 2022
Technology
0
220
クラウドネイティブと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
SREKaigi.pdf
_awache
0
23
Practical_Tips_for_Using_Confluence__Jira__and_Findy_Team__Right_Now.pdf
_awache
1
310
【関西DB勉強会】 ~ 全部見せます ~KINTO テクノロジーズの DBRE とは
_awache
2
2.5k
KTC_DBRE.pdf
_awache
1
570
_オープニング__GitLabに学ぶ_世界最先端のリモート組織のつくりかた_そーだいなる輪読会キックオフ.pdf
_awache
0
87
[Opening] DBRE Summit 2023
_awache
0
510
CUS-11_AWS-Summit-2023_DBRE_Practice.pdf
_awache
1
2.9k
DBRE 活動と information_schema
_awache
1
2.1k
実践:Cloud Center of Excellence を中心としたクラウド戦略/The Practice of Cloud Center of Excellence
_awache
0
5.2k
Other Decks in Technology
See All in Technology
なぜfreeeはハブ・アンド・スポーク型の データメッシュアーキテクチャにチャレンジするのか?
shinichiro_joya
2
490
Godot Engineについて調べてみた
unsoluble_sugar
0
410
Building Scalable Backend Services with Firebase
wisdommatt
0
110
今年一年で頑張ること / What I will do my best this year
pauli
1
220
Bring Your Own Container: When Containers Turn the Key to EDR Bypass/byoc-avtokyo2024
tkmru
0
860
コロプラのオンボーディングを採用から語りたい
colopl
5
1.3k
Git scrapingで始める継続的なデータ追跡 / Git Scraping
ohbarye
5
500
AWS re:Invent 2024 re:Cap Taipei (for Developer): New Launches that facilitate Developer Workflow and Continuous Innovation
dwchiang
0
170
AWS re:Invent 2024 recap in 20min / JAWSUG 千葉 2025.1.14
shimy
1
100
月間60万ユーザーを抱える 個人開発サービス「Walica」の 技術スタック変遷
miyachin
1
140
メンバーがオーナーシップを発揮しやすいチームづくり
ham0215
2
140
デジタルアイデンティティ技術 認可・ID連携・認証 応用 / 20250114-OIDF-J-EduWG-TechSWG
oidfj
2
680
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
3
180
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.6k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
173
51k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.3k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
19
2.3k
The Cost Of JavaScript in 2023
addyosmani
46
7.2k
Code Reviewing Like a Champion
maltzj
521
39k
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;