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
3.4k
マイクロサービス環境における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 Cloudを採用した背景
pospome
9
4.1k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
29
11k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
1.4k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
420
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.2k
(再アップロード)Microservices & APIs
pospome
0
72
(再アップロード)Datastore/Go のデータ設計と struct の振る舞いについて
pospome
0
66
マイクロサービス環境におけるToilを削減するTerraformの活用 in DMMプラットフォーム
pospome
3
1.3k
組織のコード品質を向上させる “レビューシステム”の取り組み
pospome
11
7.3k
Other Decks in Technology
See All in Technology
リテール金融(キャッシュレス・ネット銀行・ネット証券)の競争環境と経済圏
8maki
0
1.3k
TechFeed Experts Night#27 〜 フロントエンドフレームワーク最前線 (Svelte)
baseballyama
1
540
Além do else! Categorizando Pokemóns com Pattern Matching no JavaScript
wmsbill
0
640
プロンプトエンジニアリングでがんばらない-Agentic Workflow へ-近藤憲児
kenjikondobai
3
970
アクセシビリティを考慮したUI/CSSフレームワーク・ライブラリ選定
yajihum
2
1k
開発パフォーマンスを最大化するための開発体制
ham0215
2
450
FrontDoorとWebAppsを組み合わせた際のリダイレクト処理の注意点
kenichirokimura
1
530
反実仮想機械学習とは何か
usaito
PRO
12
4.7k
Building a RAG-poweredAI chat appwith Python and VS Code
pamelafox
0
110
Grafana x PagerDuty Better Together
jacopen
0
110
競技としてのKaggle、役に立つKaggle
yu4u
4
1.9k
本当のAWS基礎
toru_kubota
0
530
Featured
See All Featured
Designing for humans not robots
tammielis
248
25k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
The Cost Of JavaScript in 2023
addyosmani
16
3.9k
Scaling GitHub
holman
457
140k
Facilitating Awesome Meetings
lara
42
5.6k
Web development in the modern age
philhawksworth
202
10k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
6
1.5k
Web Components: a chance to create the future
zenorocha
305
41k
BBQ
matthewcrist
80
8.8k
How to name files
jennybc
65
93k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
227
16k
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を計画している。
• 分析のためのデータプラットフォームがある。