Slide 1
Slide 1 text
マイクロサービス環境におけるDB戦略
in DMMプラットフォーム
@pospome
Slide 2
Slide 2 text
登壇者
名前：pospome（ぽすぽめ）
所属：DMMプラットフォーム
Twitter:@pospome
Slide 3
Slide 3 text
今回の発表内容について
DMMプラットフォーム
x
マイクロサービス
x
DB戦略
Slide 4
Slide 4 text
DMMプラットフォームについて
扱う領域：DMM会員、決済、DMMポイント、不正対策など
エンジニア数：120名以上
開発チーム数：16チーム
マイクロサービス数：約40サービス
ピーク時のリクエスト：19,000RPS
Slide 5
Slide 5 text
DMMプラットフォームで利用されているDB
オンプレ
● MySQL
● Cassandra
● Couchbase
GCP
● Firestore
● Spanner
● Cloud SQL
AWS
● RDS Aurora(MySQL)
● Dynamo DB
その他
● TiDB Cloud
Slide 6
Slide 6 text
なんか多くない?(´・ω・`)
Slide 7
Slide 7 text
DMMプラットフォームのDB戦略
● 各チームで適切にDB選定・運用してもらう方針に倒している。
○ アプリケーション特性に左右される。
■ 組織としてのデファクト・スタンダードは定義していない。
○ クラウド環境ではマネージドなDBが多い。
Slide 8
Slide 8 text
DMMプラットフォームとDevOps
● DBに限らずDevOpsを徹底している。
○ コミュニケーションコストの削減
○ 独立性が高く、スピード感のある開発を実現
● オンプレのDBはインフラ部が運用している。
○ コミュニケーションコストが高く、上手くDevOpsできていない。
○ クラウド化を進めている。
Slide 9
Slide 9 text
マイクロサービスのデータ管理
1. DBメンテナンスに伴うダウンタイムとの付き合い方
2. 既存方針における開発効率の悪さ
3. DMMにおけるデータ分析
Slide 10
Slide 10 text
マイクロサービスのデータ管理
1. DBメンテナンスに伴うダウンタイムとの付き合い方
2. 既存方針における開発効率の悪さ
3. DMMにおけるデータ分析
Slide 11
Slide 11 text
マイクロサービスのダウンタイムは面倒
● マイクロサービスはダウンタイムを伴う変更がめんどくさい。
○ 例：メンテナンス作業など
● 面倒な理由
○ どこに影響があるか分からない。
○ どの程度影響があるか分からない。
○ 関係各所への連絡が必要になる。
■ どの程度のダウンタイムであれば許容できるか。
○ ダウンタイムなしで頑張るのもそれなりの工数がかかる。
Slide 12
Slide 12 text
DMMプラットフォームにおけるダウンタイムとの付き合い方
● DMMプラットフォームは各サービスが共通利用する機能を提供する。
○ ダウンタイムが結構クリティカル。
○ 例：認証基盤がダウンするとほぼ全サービスが止まる。
● DMMは60以上のサービスを展開している。
○ ダウンタイムを伴う作業がとても大変。
○ 調整コストが高い。
Slide 13
Slide 13 text
調整コストの高さ
● 各サービスの責任者に承認を得なければいけない。
○ 60サービスあるけど・・・。
○ 「その日はキャンペーンやっているので避けてほしい」とかある。
■ 影響の度合いが読みづらい・・・。
Slide 14
Slide 14 text
調整コストの高さ
● 各サービスに特殊な?要件がある。
○ DMM TV「生配信があるので、その日は避けて欲しい」
○ DMM英会話「メンテナンスの曜日を固定にしないで欲しい」
Slide 15
Slide 15 text
調整に失敗したこともある
● ダウンタイムを伴うメンテを企画したが、
スケジュール調整が難航して、一度リスケになったことがある。
○ 多くの人の工数を消費する一大イベントになってしまう。
Slide 16
Slide 16 text
DBのダウンタイムは極力避けたい・・・
● ダウンタイムを伴うDBのメンテナンスは極力避けたい。
○ 分散DBだとダウンタイムがない傾向にあるので嬉しい。
● MySQLはダウンタイムを伴いがちだったが、最近はそうでもない。
○ オンラインDDL
○ AuroraのBlue/Greenデプロイ機能
■ 切り戻しにはダウンタイムを伴ってしまう・・・。
■ 切り戻しを考慮して関係各所とやりとりするか・・・?
Slide 17
Slide 17 text
認証基盤ではTiDBを採用
● TiDB
○ New SQL
■ Writeがスケールする
■ 強整合性
○ MySQLプロトコル互換
○ 分散DBなのでメンテナンスによるダウンタイムがない。
■ 瞬断するのでリトライは必須
● 中長期的に非機能要件を満たせる。
Slide 18
Slide 18 text
TiDB採用に関する登壇資料
フルマネージドNewSQLであるTiDB Cloudの可能性
Slide 19
Slide 19 text
マイクロサービスのデータ管理
1. DBメンテナンスに伴うダウンタイムとの付き合い方
2. 既存方針における開発効率の悪さ
3. DMMにおけるデータ分析
Slide 20
Slide 20 text
既存方針における開発効率の悪さ
● “各チームで適切なDBを選定し、運用する” のは効率が悪い面がある。
○ 各チームのエンジニアリングスキルに大きく依存してしまう。
○ チームによって利用するDBが異なるので、知見共有が難しく、
エコシステムも作りづらい。
Slide 21
Slide 21 text
DMMプラットフォームのDBをTiDBに寄せれば、
これらの問題が解決するのでは・・・?
(´・ω・`)
Slide 22
Slide 22 text
TiDBに寄せたイメージ
Slide 23
Slide 23 text
TiDBに寄せたイメージ
Slide 24
Slide 24 text
TiDBに寄せたイメージ
Slide 25
Slide 25 text
TiDBに寄せたイメージ
Slide 26
Slide 26 text
TiDBに寄せた際のメリット
● 知見共有できるようになる。
● プラットフォームチームがエコシステムを構築できるようになる。
● プラットフォームチームがクラスター運用を担当する。
○ 各チームの運用工数削減
Slide 27
Slide 27 text
TiDBに寄せれるか?
● MySQLプロトコル互換
○ エンジニアの学習コストが低い。
○ 既存のMySQLエコシステムが使える。
● 強整合性を持っている。
○ トランザクション処理が可能。
● Writeがスケールする。
○ Dynamo DBのようなKVSも寄せれそう。
Slide 28
Slide 28 text
TiDBに寄せれるか?
● HTAPもサポートしている。
○ HBaseのような列指向NoSQLとしても利用できる。
● マルチテナントによるリソース最適化
リソース制御機能があり、
DBごとに消費リソースを制限することができる。
Slide 29
Slide 29 text
なんか良さそう！
(´・ω・`)
Slide 30
Slide 30 text
多くのハードル・・・
● TiDBはゆーてNewSQLである。
○ RDB, NoSQLが実現できる要件を満たせるとは限らない。
○ 特にレイテンシの悪化は避けられない。
■ MySQLからTiDBへの移行によってアプリケーションの
p99のレイテンシが数十msec高くなった実績がある。
● マルチテナントを運用する難易度
○ リソース制御機能があったとしても、キャパプラ難易度が高い。
Slide 31
Slide 31 text
多くのハードル・・・
● クラスターレベルのチューニングが難しい
○ すべてのアプリケーションにハマるチューニングできなさそう。
● TiDBのバージョンアップで足並みを揃える必要がある。
○ 各チームのスケジュール調整できるかな・・・?
Slide 32
Slide 32 text
なんか無理そうだけど、現在計画中・・・
Slide 33
Slide 33 text
マイクロサービスのデータ管理
1. DBメンテナンスに伴うダウンタイムとの付き合い方
2. 既存方針における開発効率の悪さ
3. DMMにおけるデータ分析
Slide 34
Slide 34 text
DMMにおけるデータ分析
● 各部署が持つデータを突き合わせて分析する必要がある。
○ 電子書籍の書籍データとDMMプラットフォームの会員データとか
● DMMにはこれを実現するデータプラットフォームがある。
○ DMMプラットフォームとは別の部署である。
○ ビジネス要件みたいなものまでヒアリングしてくれる。
Slide 35
Slide 35 text
データプラットフォームの仕組み
Slide 36
Slide 36 text
データプラットフォームの仕組み
Slide 37
Slide 37 text
データプラットフォームの仕組み
Slide 38
Slide 38 text
まとめ
● DMMプラットフォームはDevOpsの思想に基づいて、
各チームにDBに対するオーナーシップを持たせている。
● マイクロサービスにおいてダウンタイムを伴う変更は大変。
○ DBもダウンタイムがないものが理想である。
● TiDBを中心としたDBaaSを計画している。
● 分析のためのデータプラットフォームがある。