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.9k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
41
19k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
2k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
820
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.8k
(再アップロード)Microservices & APIs
pospome
0
190
(再アップロード)Datastore/Go のデータ設計と struct の振る舞いについて
pospome
0
200
Other Decks in Technology
See All in Technology
[SRE NEXT 2025] すみずみまで暖かく照らすあなたの太陽でありたい
carnappopper
2
740
毎晩の 負荷試験自動実行による効果
recruitengineers
PRO
5
200
DATA+AI SummitとSnowflake Summit: ユーザから見た共通点と相違点 / DATA+AI Summit and Snowflake Summit
nttcom
0
120
ゼロから始めるSREの事業貢献 - 生成AI時代のSRE成長戦略と実践 / Starting SRE from Day One
shinyorke
PRO
0
200
AWS 怖い話 WAF編 @fillz_noh #AWSStartup #AWSStartup_Kansai
fillznoh
0
140
【あのMCPって、どんな処理してるの?】 AWS CDKでの開発で便利なAWS MCP Servers特集
yoshimi0227
6
1.1k
How Do I Contact Jetblue Airlines® Reservation Number: Fast Support Guide
thejetblueairhelpsupport
0
220
「現場で活躍するAIエージェント」を実現するチームと開発プロセス
tkikuchi1002
5
860
安定した基盤システムのためのライブラリ選定
kakehashi
PRO
3
160
全部AI、全員Cursor、ドキュメント駆動開発 〜DevinやGeminiも添えて〜
rinchsan
11
5.5k
スプリントレビューを効果的にするために
miholovesq
5
1.1k
Microsoft Fabric ガバナンス設計の一歩目を考える
ryomaru0825
1
160
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Scaling GitHub
holman
460
140k
Making Projects Easy
brettharned
116
6.3k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
The World Runs on Bad Software
bkeepers
PRO
70
11k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
282
13k
Into the Great Unknown - MozCon
thekraken
40
1.9k
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を計画している。
• 分析のためのデータプラットフォームがある。