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.1k
マイクロサービス環境における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
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
8
3.9k
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
10
5.7k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
42
17k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
1.9k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
740
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.6k
(再アップロード)Microservices & APIs
pospome
0
150
(再アップロード)Datastore/Go のデータ設計と struct の振る舞いについて
pospome
0
160
マイクロサービス環境におけるToilを削減するTerraformの活用 in DMMプラットフォーム
pospome
3
1.6k
Other Decks in Technology
See All in Technology
PHPカンファレンス名古屋-テックリードの経験から学んだ設計の教訓
hayatokudou
2
300
抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization
soudai
16
6.6k
ビジネスモデリング道場 目的と背景
masuda220
PRO
9
520
Classmethod AI Talks(CATs) #16 司会進行スライド(2025.02.12) / classmethod-ai-talks-aka-cats_moderator-slides_vol16_2025-02-12
shinyaa31
0
110
Goで作って学ぶWebSocket
ryuichi1208
0
800
なぜ私は自分が使わないサービスを作るのか? / Why would I create a service that I would not use?
aiandrox
0
740
7日間でハッキングをはじめる本をはじめてみませんか?_ITエンジニア本大賞2025
nomizone
2
1.8k
一度 Expo の採用を断念したけど、 再度 Expo の導入を検討している話
ichiki1023
1
170
データの品質が低いと何が困るのか
kzykmyzw
6
1.1k
Oracle Cloud Infrastructure:2025年2月度サービス・アップデート
oracle4engineer
PRO
1
210
データ資産をシームレスに伝達するためのイベント駆動型アーキテクチャ
kakehashi
PRO
2
540
表現を育てる
kiyou77
1
210
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
960
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
The Language of Interfaces
destraynor
156
24k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
174
51k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
How to train your dragon (web standard)
notwaldorf
91
5.8k
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を計画している。
• 分析のためのデータプラットフォームがある。