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
200
クラウドネイティブと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
KTC_DBRE.pdf
_awache
1
410
_オープニング__GitLabに学ぶ_世界最先端のリモート組織のつくりかた_そーだいなる輪読会キックオフ.pdf
_awache
0
47
[Opening] DBRE Summit 2023
_awache
0
430
CUS-11_AWS-Summit-2023_DBRE_Practice.pdf
_awache
1
2.7k
DBRE 活動と information_schema
_awache
1
1.8k
実践:Cloud Center of Excellence を中心としたクラウド戦略/The Practice of Cloud Center of Excellence
_awache
0
4k
PostgreSQLUnconference#19
_awache
0
120
introduceDBREJP
_awache
0
460
mysql_casual_talks_13 Change Character Set
_awache
6
1.7k
Other Decks in Technology
See All in Technology
From here to resilience - a travel guide
ufried
1
140
令和版ソフトウェアエンジニアの情報収集術 PHPカンファレンス香川2024
ysknsid25
4
760
.NET Profiler in 2024.
kkamegawa
2
3.1k
20240509 CloudWatch でいろいろなものを監視してみよう
masaruogura
1
110
DevRelによる信頼構築とデータ駆動で変わるエンジニア採用 / DevRel Trust Building to Data Driven Engineering Hiring
bobtani
1
120
複雑なビジネスルールに挑む:正確性と効率性を両立するfp-tsのチーム活用術 / Strike a balance between correctness and efficiency with fp-ts
kakehashi
5
2.7k
Documentação de Produtos: Artefatos essenciais na prática
rigolon
1
240
Observabilityジャーニーを実現するためのAWSサービス:CloudWatch編
o11yfes2023
0
110
パスワードを保存しますか?
hanacchi
0
240
能動学習のいろは:書籍「Human-in-the-Loop機械学習」3〜5章
hiroyoshiito
0
250
Rustで「プリズモイダル法」を利用して「土量計算」をガチでやる
nokonoko1203
1
370
本当のガバクラ基礎
toru_kubota
0
280
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
74
8.3k
Reflections from 52 weeks, 52 projects
jeffersonlam
345
19k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
245
20k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
104
6.7k
Art, The Web, and Tiny UX
lynnandtonic
290
19k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
Why Our Code Smells
bkeepers
PRO
331
56k
A Philosophy of Restraint
colly
197
16k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.9k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
Documentation Writing (for coders)
carmenintech
60
4k
Making Projects Easy
brettharned
109
5.5k
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;