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.3k
マイクロサービス環境における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.5k
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
8
4.2k
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
10
5.8k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
41
19k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
2k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
800
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.7k
(再アップロード)Microservices & APIs
pospome
0
180
(再アップロード)Datastore/Go のデータ設計と struct の振る舞いについて
pospome
0
190
Other Decks in Technology
See All in Technology
活きてなかったデータを活かしてみた話 / Shirokane Kougyou vol 19
sansan_randd
1
380
Long journey of Continuous Delivery at Mercari
hisaharu
1
230
Model Mondays S2E01: Advanced Reasoning
nitya
0
420
Navigation3でViewModelにデータを渡す方法
mikanichinose
0
130
DB 醬,嗨!哪泥嘎斯基?
line_developers_tw
PRO
0
490
本部長の代わりに提案書レビュー! KDDI営業が毎日使うAIエージェント「A-BOSS」開発秘話
minorun365
PRO
14
2k
Nonaka Sensei
kawaguti
PRO
4
770
Perk アプリの技術選定とリリースから1年弱経ってのふりかえり
stomk
0
120
OCI Oracle Database Services新機能アップデート(2025/03-2025/05)
oracle4engineer
PRO
1
190
原則から考える保守しやすいComposable関数設計
moriatsushi
3
480
初めてのAzure FunctionsをClaude Codeで作ってみた / My first Azure Functions using Claude Code
hideakiaoyagi
1
120
CI/CDとタスク共有で加速するVibe Coding
tnbe21
0
220
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
16
930
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.7k
Code Review Best Practice
trishagee
68
18k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Producing Creativity
orderedlist
PRO
346
40k
Music & Morning Musume
bryan
46
6.6k
Practical Orchestrator
shlominoach
188
11k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
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を計画している。
• 分析のためのデータプラットフォームがある。