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
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
Search
pospome
March 19, 2024
Technology
12
4.2k
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
Database Engineering Meetup #2 の登壇資料です。
https://scalar.connpass.com/event/310641/
pospome
March 19, 2024
Tweet
Share
More Decks by pospome
See All by pospome
技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの
pospome
5
1.3k
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
8
4k
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
10
5.7k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
41
18k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
1.9k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
760
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.7k
(再アップロード)Microservices & APIs
pospome
0
160
(再アップロード)Datastore/Go のデータ設計と struct の振る舞いについて
pospome
0
180
Other Decks in Technology
See All in Technology
Restarting_SRE_Road_to_SRENext_.pdf
_awache
0
160
20250328_OpenAI製DeepResearchは既に一種のAGIだと思う話
doradora09
PRO
0
150
LINE Notify互換のボットを作った話
kenichirokimura
0
180
caching_sha2_passwordのはなし
boro1234
0
220
大規模サービスにおける カスケード障害
takumiogawa
1
210
ルートユーザーの活用と管理を徹底的に深掘る
yuobayashi
6
730
コンソールで学ぶ!AWS CodePipelineの機能とオプション
umekou
2
110
モンテカルロ木探索のパフォーマンスを予測する Kaggleコンペ解説 〜生成AIによる未知のゲーム生成〜
rist
4
1.1k
パスキーでのログインを 実装してみよう!
hibiki_cube
0
670
Redefine_Possible
upsider_tech
0
260
職種に名前が付く、ということ/The fact that a job title has a name
bitkey
1
240
技術好きなエンジニアが _リーダーへの進化_ によって得たものと失ったもの / The Gains and Losses of a Tech-Enthusiast Engineer’s “Evolution into Leadership”
kaminashi
0
200
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
137
6.8k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
7
620
Unsuck your backbone
ammeep
670
57k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
30k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Mobile First: as difficult as doing things right
swwweet
223
9.5k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
The Cult of Friendly URLs
andyhume
78
6.3k
Music & Morning Musume
bryan
46
6.4k
Transcript
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム @pospome
登壇者 名前:pospome(ぽすぽめ) 所属:DMMプラットフォーム Twitter:@pospome
今回の発表内容について DMMプラットフォーム x マイクロサービス x DB戦略
DMMプラットフォームについて 扱う領域:DMM会員、決済、DMMポイント、不正対策など エンジニア数:120名以上 開発チーム数:16チーム マイクロサービス数:約40サービス ピーク時のリクエスト:19,000RPS
DMMプラットフォームで利用されているDB オンプレ • MySQL • Cassandra • Couchbase GCP •
Firestore • Spanner • Cloud SQL AWS • RDS Aurora(MySQL) • Dynamo DB その他 • TiDB Cloud
なんか多くない?(´・ω・`)
DMMプラットフォームのDB戦略 • 各チームで適切にDB選定・運用してもらう方針に倒している。 ◦ アプリケーション特性に左右される。 ▪ 組織としてのデファクト・スタンダードは定義していない。 ◦ クラウド環境ではマネージドなDBが多い。
DMMプラットフォームとDevOps • DBに限らずDevOpsを徹底している。 ◦ コミュニケーションコストの削減 ◦ 独立性が高く、スピード感のある開発を実現 • オンプレのDBはインフラ部が運用している。 ◦
コミュニケーションコストが高く、上手くDevOpsできていない。 ◦ クラウド化を進めている。
マイクロサービスのデータ管理 1. DBメンテナンスに伴うダウンタイムとの付き合い方 2. 既存方針における開発効率の悪さ 3. DMMにおけるデータ分析
マイクロサービスのデータ管理 1. DBメンテナンスに伴うダウンタイムとの付き合い方 2. 既存方針における開発効率の悪さ 3. DMMにおけるデータ分析
マイクロサービスのダウンタイムは面倒 • マイクロサービスはダウンタイムを伴う変更がめんどくさい。 ◦ 例:メンテナンス作業など • 面倒な理由 ◦ どこに影響があるか分からない。 ◦
どの程度影響があるか分からない。 ◦ 関係各所への連絡が必要になる。 ▪ どの程度のダウンタイムであれば許容できるか。 ◦ ダウンタイムなしで頑張るのもそれなりの工数がかかる。
DMMプラットフォームにおけるダウンタイムとの付き合い方 • DMMプラットフォームは各サービスが共通利用する機能を提供する。 ◦ ダウンタイムが結構クリティカル。 ◦ 例:認証基盤がダウンするとほぼ全サービスが止まる。 • DMMは60以上のサービスを展開している。 ◦
ダウンタイムを伴う作業がとても大変。 ◦ 調整コストが高い。
調整コストの高さ • 各サービスの責任者に承認を得なければいけない。 ◦ 60サービスあるけど・・・。 ◦ 「その日はキャンペーンやっているので避けてほしい」とかある。 ▪ 影響の度合いが読みづらい・・・。
調整コストの高さ • 各サービスに特殊な?要件がある。 ◦ DMM TV「生配信があるので、その日は避けて欲しい」 ◦ DMM英会話「メンテナンスの曜日を固定にしないで欲しい」
調整に失敗したこともある • ダウンタイムを伴うメンテを企画したが、 スケジュール調整が難航して、一度リスケになったことがある。 ◦ 多くの人の工数を消費する一大イベントになってしまう。
DBのダウンタイムは極力避けたい・・・ • ダウンタイムを伴うDBのメンテナンスは極力避けたい。 ◦ 分散DBだとダウンタイムがない傾向にあるので嬉しい。 • MySQLはダウンタイムを伴いがちだったが、最近はそうでもない。 ◦ オンラインDDL ◦
AuroraのBlue/Greenデプロイ機能 ▪ 切り戻しにはダウンタイムを伴ってしまう・・・。 ▪ 切り戻しを考慮して関係各所とやりとりするか・・・?
認証基盤ではTiDBを採用 • TiDB ◦ New SQL ▪ Writeがスケールする ▪ 強整合性
◦ MySQLプロトコル互換 ◦ 分散DBなのでメンテナンスによるダウンタイムがない。 ▪ 瞬断するのでリトライは必須 • 中長期的に非機能要件を満たせる。
TiDB採用に関する登壇資料 フルマネージドNewSQLであるTiDB Cloudの可能性
マイクロサービスのデータ管理 1. DBメンテナンスに伴うダウンタイムとの付き合い方 2. 既存方針における開発効率の悪さ 3. DMMにおけるデータ分析
既存方針における開発効率の悪さ • “各チームで適切なDBを選定し、運用する” のは効率が悪い面がある。 ◦ 各チームのエンジニアリングスキルに大きく依存してしまう。 ◦ チームによって利用するDBが異なるので、知見共有が難しく、 エコシステムも作りづらい。
DMMプラットフォームのDBをTiDBに寄せれば、 これらの問題が解決するのでは・・・? (´・ω・`)
TiDBに寄せたイメージ
TiDBに寄せたイメージ
TiDBに寄せたイメージ
TiDBに寄せたイメージ
TiDBに寄せた際のメリット • 知見共有できるようになる。 • プラットフォームチームがエコシステムを構築できるようになる。 • プラットフォームチームがクラスター運用を担当する。 ◦ 各チームの運用工数削減
TiDBに寄せれるか? • MySQLプロトコル互換 ◦ エンジニアの学習コストが低い。 ◦ 既存のMySQLエコシステムが使える。 • 強整合性を持っている。 ◦
トランザクション処理が可能。 • Writeがスケールする。 ◦ Dynamo DBのようなKVSも寄せれそう。
TiDBに寄せれるか? • HTAPもサポートしている。 ◦ HBaseのような列指向NoSQLとしても利用できる。 • マルチテナントによるリソース最適化 リソース制御機能があり、 DBごとに消費リソースを制限することができる。
なんか良さそう! (´・ω・`)
多くのハードル・・・ • TiDBはゆーてNewSQLである。 ◦ RDB, NoSQLが実現できる要件を満たせるとは限らない。 ◦ 特にレイテンシの悪化は避けられない。 ▪ MySQLからTiDBへの移行によってアプリケーションの
p99のレイテンシが数十msec高くなった実績がある。 • マルチテナントを運用する難易度 ◦ リソース制御機能があったとしても、キャパプラ難易度が高い。
多くのハードル・・・ • クラスターレベルのチューニングが難しい ◦ すべてのアプリケーションにハマるチューニングできなさそう。 • TiDBのバージョンアップで足並みを揃える必要がある。 ◦ 各チームのスケジュール調整できるかな・・・?
なんか無理そうだけど、現在計画中・・・
マイクロサービスのデータ管理 1. DBメンテナンスに伴うダウンタイムとの付き合い方 2. 既存方針における開発効率の悪さ 3. DMMにおけるデータ分析
DMMにおけるデータ分析 • 各部署が持つデータを突き合わせて分析する必要がある。 ◦ 電子書籍の書籍データとDMMプラットフォームの会員データとか • DMMにはこれを実現するデータプラットフォームがある。 ◦ DMMプラットフォームとは別の部署である。 ◦
ビジネス要件みたいなものまでヒアリングしてくれる。
データプラットフォームの仕組み
データプラットフォームの仕組み
データプラットフォームの仕組み
まとめ • DMMプラットフォームはDevOpsの思想に基づいて、 各チームにDBに対するオーナーシップを持たせている。 • マイクロサービスにおいてダウンタイムを伴う変更は大変。 ◦ DBもダウンタイムがないものが理想である。 • TiDBを中心としたDBaaSを計画している。
• 分析のためのデータプラットフォームがある。