DMMプラットフォームが TiDB Cloudを採用した背景 @pospome

登壇者 名前：pospome（ぽすぽめ） 所属：DMMプラットフォーム Twitter:@pospome

概要 ● DMMプラットフォーム内の認証チームがTiDB Cloudを採用した。 ○ すでに本番環境で動いている。 ○ 別のチームも採用予定である。

認証チームが抱えるDB周りの課題 ● オンプレのMySQLをクラウド化したい。 ○ マネージドなDBを採用し、DevOpsを実現する。 ● Cassandra, Couchbaseを廃止し、DBを一本化したい。 ○ 歴史的経緯でNoSQLも利用していた。 ● 中長期的な要件に対応できるDBが欲しかった。 ○ 書き込みのスケール、強整合性、耐障害性などなど。 ● DB起因のダウンタイムを避けたい。 ○ マイクロサービス環境では調整コストが高い。

New SQLの検討 ● 書き込みがスケールする。 ● 強整合性を保証できる。 ● 耐障害性が高い。 ● ダウンタイムがない。 ● パフォーマンスはRDBに劣る。 ○ それほどパフォーマンスにシビアではない環境なので問題ない。 ○ TiDB移行後の実績値として APIのレイテンシは全体的に20~30ミリ秒ほど高くなった。

よし、Google Cloud Spanner 使おう (´・ω・`)

謎のDMが来た・・・ このDMはノリなのでは? (´・ω・`)

TiDBも検討候補に・・・ ● Spannerの論文を参考に開発されたOSSである。 ● MySQLプロトコル互換 ○ MySQLのSQLやテーブル定義をそのまま使える。 ○ ここに価値を感じたので検討候補に入れた。 ● マネージド環境としてTiDB Cloudがある。 ○ 認証チームでTiDBを採用する場合は TiDB Cloudを採用することになる。

検証結果 Spannerの方がDBとしては完成されている

Spannerのすごさ ● Googleの技術力と資金力によって開発されている。 ○ ハードウェアも含めてのSpannerである。 ● レプリカへの読み取り操作も強整合性を保証できる。 ○ TiDBよりもパフォーマンスが高くなる可能性が高い。 ● JOIN対象のテーブルを同一ノードに保存できる（インターリーブ）。 ○ JOINのパフォーマンスを最適化できる。 ● 課金体系が柔軟でスモールスタートしやすい。 ● Google Cloud との連携がある。

なぜTiDBを選択したのか?

TiDB Cloudを採用した理由 ● MySQLプロトコル互換 ○ レガシーアプリケーションのコード変更が不要。 ○ テーブル定義の変更が不要。 ○ 運用作業の変更が不要。 ○ MySQLエコシステムをそのまま活用できる。 ○ エンジニアの学習コストを低く抑えられる。 ● TiDBでも十分中長期的に使っていけると判断した。

TiDB Cloudを採用した後の話 ● 本番環境で稼働している ○ 特に問題なく動いている。 ○ TiDB CloudによってDevOpsを徹底できている。 ● MySQLプロトコル互換は嬉しい。 ○ 移行作業は想定以上にスムーズに進んだ。 ○ TiDBを採用する前と変わらず開発・運用できている。 ● MySQLは廃止済み & Cassandraの移行中

まとめ 以下の観点でTiDBがハマる可能性がある。 ● オンプレをメインで利用している。 ● 組織内にMySQLのノウハウやエコシステムが存在する。 ● MySQLを利用しているレガシーシステムが存在する。 地味にSpannerとの棲み分けができている。(´・ω・`)

おわり