Slide 1
Slide 1 text
DMMプラットフォームにおける
TiDBの導入から運用まで
@pospome
Slide 2
Slide 2 text
登壇者
名前：pospome（ぽすぽめ）
所属：DMMプラットフォーム
Twitter:@pospome
Slide 3
Slide 3 text
目次
1. New SQLを採用した背景
2. Google Cloud Spanner vs TiDB/TiDB Cloud
3. TiDB Cloudで本番アプリケーションを運用してみて実際どうか
Slide 4
Slide 4 text
目次
1. New SQLを採用した背景
2. Google Cloud Spanner vs TiDB/TiDB Cloud
3. TiDB Cloudで本番アプリケーションを運用してみて実際どうか
Slide 5
Slide 5 text
DMMプラットフォームについて
扱う領域：DMM会員、決済、DMMポイント、不正対策など
エンジニア数：120名以上
開発チーム数：16チーム
マイクロサービス数：約40サービス
ピーク時のリクエスト：19,000RPS
Slide 6
Slide 6 text
レガシーシステムのリプレイスプロジェクト
インフラのクラウド化 & Goへのrewriteする必要がある。
● 認証チーム
オンプレ, MySQL, Java, Cassandra, Couchbase
● 認可チーム
オンプレ, MySQL, PHP, Redis
Slide 7
Slide 7 text
クラウドでもMySQLを使うのか?
MySQLを利用することに対する懸念
1. マスターノードが単一障害点
a. 認証認可が止まるとDMMが止まる。
2. バージョンアップ時のダウンタイム
a. DMMはメンテを入れるのが面倒。
3. Writeが水平スケールしない
a. 各種サービスの都合でリクエストが増える。
Slide 8
Slide 8 text
NoSQLの検討
現実的に厳しい。
● Writeが水平にスケールし、
バージョンアップ時のダウンタイムもない。
● MySQLのデータ構造をNoSQL向けに変更する必要がある。
● コードの改修もまあまあ発生する。
● NoSQLを使いこなすための学習コストがかかる。
○ 例：JOINがない、トランザクションがない、などなど・・・。
Slide 9
Slide 9 text
New SQLの採用を検討した
Slide 10
Slide 10 text
New SQLの特徴
中長期的に要件を満たせるDBだと感じた。
● バージョンアップ時にダウンタイムがない。
● Writeがスケールする。
● 強整合性を持つ。
● 耐障害性が高い。
Slide 11
Slide 11 text
New SQLの特徴
● RDBに比べるとレイテンシは高くなる。
○ ノード間の通信が発生する。
○ データが複数のノードに分散する。
○ レプリカ間の整合性を取る処理が必要になる。
● 費用が高くなる傾向にある。
○ 同じリソース量の場合はRDBの方が高いパフォーマンスを出せる。
● MySQL, NoSQLの上位互換ではない。
○ 適材適所である。
Slide 12
Slide 12 text
Google Cloud Spanner を使おう
Slide 13
Slide 13 text
PingCAPの大エースから謎のDMが来た・・・
このDMはノリなのでは? (´・ω・`)
Slide 14
Slide 14 text
TiDBの特徴
● Spannerの論文を参考に開発されたOSSのNewSQLである。
● MySQL互換
○ MySQLのSQLやテーブル定義がそのまま使える。
○ ここに価値を感じたので検討候補に入れた。
認証チームも認可チームもMySQLを利用しており、
開発・運用作業やエコシステムをそのまま活かせる。
Slide 15
Slide 15 text
MySQL互換
Slide 16
Slide 16 text
MySQL互換
TiDB独自の仕様は
コメント構文で定義することで、
MySQLで有効な構文として
扱うことができる。
MySQL互換を徹底している。
Slide 17
Slide 17 text
TiDB Cloudについて
● TiDBを開発しているPingCAPが提供するDBaaSである。
● AWS, Google Cloud に対応している。
● WebUIの管理画面がある。
クラスターのスケールアップや各種メトリクスが確認できる。
Slide 18
Slide 18 text
No content
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
TiDB Cloudについて
● DMMプラットフォームではTiDB Cloudを採用することになる。
○ DevOpsを実現するため。
■ オンプレのMySQLはインフラ部への作業依頼 & 待ちが発生した。
■ 認証チーム、認可チームでインフラ運用が完結するように。
Slide 21
Slide 21 text
目次
1. New SQLを採用した背景
2. Google Cloud Spanner vs TiDB/TiDB Cloud
3. TiDB Cloudで本番アプリケーションを運用してみて実際どうか
Slide 22
Slide 22 text
Spanner vs TiDB/TiDB Cloud
1. システムアーキテクチャ
2. パフォーマンス
3. 既存DBとの互換性
4. OLAP（オンライン分析処理）
5. ローカル開発
6. クラウド費用
7. GCPとの連携
Slide 23
Slide 23 text
Spanner vs TiDB/TiDB Cloud
1. システムアーキテクチャ
2. パフォーマンス
3. 既存DBとの互換性
4. OLAP（オンライン分析処理）
5. ローカル開発
6. クラウド費用
7. GCPとの連携
Slide 24
Slide 24 text
Spannerのざっくりシステムアーキテクチャ
Slide 25
Slide 25 text
補足：詳細バージョン
Slide 26
Slide 26 text
TiDBのシステムアーキテクチャ
Slide 27
Slide 27 text
双方のシステムアーキテクチャについて
● TiDBはSpannerを参考に開発されただけあって似ている。
○ コンピューティングとストレージを分割している。
○ Placement Driverによってデータ配置を調整している。
● SpannerはGoogleのインフラレベルで設計されており、
グローバルスケールで高可用性を持つDBになっている。
○ Clossus（分散ストレージ）
○ True Time API（GPS & 原子時計）
● TiDBはあくまでソフトウェアである。
Slide 28
Slide 28 text
Spanner vs TiDB/TiDB Cloud
1. システムアーキテクチャ
2. パフォーマンス
3. 既存DBとの互換性
4. OLAP（オンライン分析処理）
5. ローカル開発
6. クラウド費用
7. GCPとの連携
Slide 29
Slide 29 text
パフォーマンス（QPS & レイテンシ）
● ノード上のデータ配置、実行するクエリなどに依存するので
なんとも言えない。
○ TiDBはオンプレにもホスティングできる。
● 強整合性を保証したSELECTのQPSはSpannerの方が高いと思う。
○ レプリカの仕様に違いがあるため。
Slide 30
Slide 30 text
TiDBのレプリカ
● TiDBはデータをレプリカとして
TiKVノードに複製する。
● クエリはリーダーにのみ
向けられる。
● フォロワーは
あくまでも
バックアップである。
Slide 31
Slide 31 text
Spannerのレプリカ
● SpannerはTiDBでいうフォロワーにもアクセスできる。
● フォロワーは
自身が持つデータが
最新かどうかを
リーダーに問い合わせる
必要がある。
● リクエストを
レプリカに分散できる。
Slide 32
Slide 32 text
パフォーマンス（QPS & レイテンシ）
● 強整合性を保証したSELECTのQPSはSpannerの方が高いと思う。
○ Spannerはフォロワーに負荷分散できるため。
○ リーダーに問い合わせる処理が発生するので、
レイテンシは高くなりそう。
○ GPS, 原子時計を利用しているTrue Time APIによって
ノード間の時刻差を限りなく小さくできる点も
貢献しているかもしれない。
Slide 33
Slide 33 text
パフォーマンス（JOIN）
● Spannerはインターリーブという機能を備えている。
○ 親子関係にあるデータを物理的に同じ場所に配置することで
複数のノードからデータをかき集めることがなくなる。
○ JOINに強くなる。
○ Spannerはグローバルスケールなので
こういった最適化が必要なのかもしれない。
Slide 34
Slide 34 text
Spanner vs TiDB/TiDB Cloud
1. システムアーキテクチャ
2. パフォーマンス
3. 既存DBとの互換性
4. OLAP（オンライン分析処理）
5. ローカル開発
6. クラウド費用
7. GCPとの連携
Slide 35
Slide 35 text
既存DBとの互換性
● TiDBはMySQL互換である。
○ 前述した通り一部の機能は利用できない。
● SpannerはPostgreSQL互換を備えている。
○ MySQLを利用しているレガシーシステムを
PostgreSQLに対応する改修をいれることで
Spannerを利用することができる。
Slide 36
Slide 36 text
PGAdapterを利用しなければいけない
● SpannerをPostgreSQL互換で
利用するにはPGAdapterという
プロキシを利用しなければいけない。
● Cloud Runでホスティングしたり、
サイドカーとして稼働させる。
Slide 37
Slide 37 text
Spanner & PGAdapterは見送った
以下の理由で見送った。
● MySQLに依存したリソースをPostgreSQLに移行する工数がかかる。
どの程度の工数がかかるか読めない。
● PGAdapterと付き合っていかなければいけない。
Spannerはフルマネージドなのにプロキシの運用が発生してしまう。
リプレイスの都合上、オンプレ環境で稼働させる必要がある。
● Spannerを利用するなら覚悟を決めてネイティブ対応した方がよさそう。
Slide 38
Slide 38 text
Spanner vs TiDB/TiDB Cloud
1. システムアーキテクチャ
2. パフォーマンス
3. 既存DBとの互換性
4. OLAP（オンライン分析処理）
5. ローカル開発
6. クラウド費用
7. GCPとの連携
Slide 39
Slide 39 text
OLAP（オンライン分析処理）
● New SQLはデータが複数のノードに散るので、
各種分析に必要な集計処理（sum, average, etc）が苦手である。
○ RDBも得意というわけではない。
● TiDBは分析処理をサポートしている（HTAP）。
TiFlash（列指向のストレージコンポーネント）を
導入することによってOLAPが可能になる。
Slide 40
Slide 40 text
No content
Slide 41
Slide 41 text
TiDBにおける分析処理の実現方法
● TiKVのデータをTiFlashにも保存する。
○ データを2重で持つことになるが、TiDBが同期してくれる。
● 集計クエリをTiFlashに投げる。
○ MySQL互換のクエリを利用することができる。
■ OLTP, OLAPを透過的に扱うことができる。
○ TiFlashに適したクエリは自動的にTiFlashに投げてくれるが、
明示的に指定することもできる。
Slide 42
Slide 42 text
TiFlashのコスパについて
● TiFlashノードを常時稼働させる必要があるのでコスパは微妙。
○ 推奨環境は CPU 48コア, Memory 128GB, 2ノード である。
● 可用性を気にしないなら1ノードでも問題ない。
○ 分析用途なら1ノードでもよさそう。
○ TiDB Cloudの最小構成だと月額980ドルくらい。
Slide 43
Slide 43 text
補足：TiFlashの分散ストレージ & コンピューティング
● TiDB 7.0 以降で利用できる
TiFlashのアーキテクチャである。
● 以下のコンポーネントで構成される。
○ Write Node
○ Compute Node
○ S3
● コスパ良くTiFlashを使える仕組み。
Slide 44
Slide 44 text
OLAP（オンライン分析処理）
● TiDBはHTAPをサポートしている。
TiFlash（列指向のストレージコンポーネント）を
導入することによってOLAPが可能になる。
● SpannerはHTAPをサポートしていない。
○ BigQueryと連携する必要がある。
Slide 45
Slide 45 text
SpannerとBigQueryの連携
● Change Streamsを利用してデータをBQに連携する。
○ Spannerから送られる更新情報を
DataflowやストリーミングのAPIを利用してBQに連携する。
● BQのクエリ連携を利用する。
○ BQがSpannerのデータを直接クエリする（コピーしない）。
○ BQネイティブに比べるとパフォーマンスが劣る可能性がある。
○ BQがサポートしないデータ型は扱えない。
別の型にキャストする必要がある。
Slide 46
Slide 46 text
SpannerのData Boost
● SpannerのOLTPで
利用されるノードとは
別のノードを用意し、
任意のクエリを実行できる。
● 既存のOLTPに影響を与えない。
● クエリ実行にかかった
リソースのみ課金される。
Slide 47
Slide 47 text
Spanner vs TiDB/TiDB Cloud
1. システムアーキテクチャ
2. パフォーマンス
3. 既存DBとの互換性
4. OLAP（オンライン分析処理）
5. ローカル開発
6. クラウド費用
7. GCPとの連携
Slide 48
Slide 48 text
ローカル開発
● TiDBはtiupというCLIツールを利用すると、
ローカルPCに軽量な形でTiDBを立ちあげることができる。
○ 本物のTiDBが立ち上がるので各種検証にも利用できる。
○ OSSならではのメリットである。
● Spannerは開発/テスト用途のエミュレーターを提供している。
○ 本番相当のAPIを提供しているがあくまでエミュレーターである。
○ SpannerはクライアントとgRPCで通信するので、
本物のSpannerを立ててローカルからアクセスすればいーのでは。
Slide 49
Slide 49 text
Spanner vs TiDB/TiDB Cloud
1. システムアーキテクチャ
2. パフォーマンス
3. 既存DBとの互換性
4. OLAP（オンライン分析処理）
5. ローカル開発
6. クラウド費用
7. GCPとの連携
Slide 50
Slide 50 text
クラウド費用
● どちらが安いかは一概には言えない。
○ パフォーマンス（QPS, レイテンシ）次第になってしまう。
○ Enterprise Discount Program(EDP)のような割引も絡んでくる。
Slide 51
Slide 51 text
Spanner vs TiDB/TiDB Cloud
1. システムアーキテクチャ
2. パフォーマンス
3. 既存DBとの互換性
4. OLAP（オンライン分析処理）
5. ローカル開発
6. クラウド費用
7. GCPとの連携
Slide 52
Slide 52 text
GCPとの連携
● SpannerはGCのサービスなので各種GCサービスとの連携がある。
○ IAMによるアカウント管理
○ Cloud Logging, Cloud Monitoring
○ BigQueryとの連携
○ Lookerとの連携
○ Change Streamsによる更新内容のストリーミング
Slide 53
Slide 53 text
結論：Google Cloud Spanner vs TiDB
● Spannerの方が完成度が高い。
● Googleの資金力や開発力に勝つのは難しい。
○ 特にインフラも含めて最適化されている点はどうしようもない。
● クラウドサービスとしての品質もGoogle Cloudには敵わない。
○ 今まで積み上げてきた実績やエコシステムが存在する。
Slide 54
Slide 54 text
SpannerはTiDBの直接的な競合になるのか?
意外と棲み分けができているのでは?
● TiDBはOSSなのでオンプレでのホスティングが可能である。
● MySQL互換
○ エコシステムをそのまま利用できる。
○ 既存コードに手を入れず、DBを移行することができる。
■ レガシーシステムにとっては嬉しい。
○ エンジニアの学習コストを低く抑えることができる。
● AWS利用者はTiDB Cloudを利用できる。
Slide 55
Slide 55 text
DMMプラットフォームはTiDB Cloudを採用した
● Spannerほどではないが十分実用に耐える品質になっている。
○ GAFAのようなビッグテックならまだしも、
日本国内の企業であれば十分利用できる。
● レガシーシステムをリプレイスするDMMプラットフォームでは
“MySQL互換” が決め手となってTiDB Cloudを選択した。
○ 試しにMySQLからTiDBに向き先を変えてE2Eテストを実行したら
そのまま通った。
Slide 56
Slide 56 text
移行作業を振り返って
● エンジニアを2人ほど貼り付けて大体半年くらいかかった。
○ カナリアリリースやデータ同期チェック期間による待ちが
あったので実際にかかった工数はもっと少ない。
● 移行に必要な実装はダブルライトくらい。
○ ダウンタイムが許されないので無停止で移行した。
○ レガシーアプリケーションながらも
既存の Insert, Update, Delete をコピペするだけなので
サクサク進めることができた。
Slide 57
Slide 57 text
移行後のレイテンシについて
● 認証チームのアプリケーションのレイテンシは
全体的に20~30msecほど上がった。
○ 許容できる範囲内なので問題なし。
Slide 58
Slide 58 text
目次
1. New SQLを採用した背景
2. Google Cloud Spanner vs TiDB/TiDB Cloud
3. TiDB Cloudで本番アプリケーションを運用してみて実際どうか
Slide 59
Slide 59 text
目次
1. TiDB Cloudは安定して動くのか
2. コスパはどう?
3. バージョンアップ戦略
4. MySQL互換が嬉しい
5. 意外と便利なTTL機能
6. 監視
7. Redis廃止しようかな
8. オートスケーラー
9. マルチテナント型クラスター
Slide 60
Slide 60 text
目次
1. TiDB Cloudは安定して動くのか
2. コスパはどう?
3. バージョンアップ戦略
4. MySQL互換が嬉しい
5. 意外と便利なTTL機能
6. 監視
7. Redis廃止しようかな
8. オートスケーラー
9. マルチテナント型クラスター
Slide 61
Slide 61 text
TiDB Cloudは安定して動くのか?
● DMMプラットフォームはAWS上で半年ほどTiDB Cloudを
利用しているが今のところ安定して動いている。
● 現状のQPSはSELECT, INSERT, UPDATE, DELETE の合計で
約 4,500 QPSくらい。
○ TiDB(CPU 8コア, Memory 16GB) * 3台
○ TiKV(CPU 8コア, Memory 32GB) * 3台
Slide 62
Slide 62 text
TiDB Cloudは安定して動くのか?
● 過去にあったトラブルは以下である。
○ キャパプラをミスってレイテンシが悪化した。
○ TiKVのバグに遭遇した。
バージョンアップで解消した。
Slide 63
Slide 63 text
TiDB Cloudは安定して動くのか?
● TiDBノードのCPU利用率が80%になるとレイテンシが悪化する。
○ 80%未満 … 数ミリ〜数十ミリ秒のレイテンシ
○ 80%以上 … 数百ミリ秒のレイテンシ
● TiDBノードのCPU使用率が80%を超えないように
キャパプラしている。
Slide 64
Slide 64 text
TiDB Cloudは安定して動くのか?
● リプレイスが完了すると約15,000QPSくらいになる想定である。
○ 今後の機能追加やRedisを廃止するとQPSはさらに増える。
Slide 65
Slide 65 text
TiDB Cloudは安定して動くのか?
● Writeが水平スケールするので、
DMMの各サービスからのスケール依頼に怯えなくてよくなった。
○ 例「来月のイベントで5000RPSくらいリクエスト増えるんですけど、大丈夫
ですか?」
Slide 66
Slide 66 text
目次
1. TiDB Cloudは安定して動くのか
2. コスパはどう?
3. バージョンアップ戦略
4. MySQL互換が嬉しい
5. 意外と便利なTTL機能
6. 監視
7. Redis廃止しようかな
8. オートスケーラー
9. マルチテナント型クラスター
Slide 67
Slide 67 text
コスパはどう?
● 中長期的に要件を満たせるDBが手に入ったのは嬉しいが、
コスパがいいわけではないと思う。
● RDBで済むならRDBにした方が良いと思う。
Slide 68
Slide 68 text
別チームではコスパが理由でTiDBの採用を見送った
● AWS Auroraと同等のQPSを出そうとすると
インフラ費用が2倍以上かかるので採用を見送った。
レイテンシの悪化はアプリケーション全体で60msec程度だった。
○ シンプルに Aurora がすごい。
● 十分なリソースを用意することができれば、
アプリケーション全体のレイテンシの悪化は
100msec以内に収まる感じがする。
● NewSQLはRDBの上位互換ではない。
Slide 69
Slide 69 text
目次
1. TiDB Cloudは安定して動くのか
2. コスパはどう?
3. バージョンアップ戦略
4. MySQL互換が嬉しい
5. 意外と便利なTTL機能
6. 監視
7. Redis廃止しようかな
8. オートスケーラー
9. マルチテナント型クラスター
Slide 70
Slide 70 text
バージョンアップ戦略
● TiDB Cloudにはロールバック機能がないので一発勝負である。
○ 保存したデータまでロールバックすることはできないので、
TiDBとしてロールバック機能をサポートするのは難しい。
● ロールバックするにはロールバック用のクラスタを立てて、
アプリケーションの向き先を変える必要がある。
○ データの整合性がどこまで保証されるか不明。
Slide 71
Slide 71 text
できるだけ安全にバージョンアップするために
● リリースノートで下位互換性を確認する。
● tiupでバージョンアップ対象のTiDBを立ち上げて、
E2Eテストを流すことでクエリの動作を保証する。
● 最新バージョンの1つ前のマイナーバージョンを利用する。
○ 枯れた実装を選択することで動作を保証する。
● 開発用のクラスターで様子を見てから本番用のクラスターを
バージョンアップする。
○ 本番相当の負荷は来ないので参考程度。
Slide 72
Slide 72 text
目次
1. TiDB Cloudは安定して動くのか
2. コスパはどう?
3. バージョンアップ戦略
4. MySQL互換が嬉しい
5. 意外と便利なTTL機能
6. 監視
7. Redis廃止しようかな
8. オートスケーラー
9. マルチテナント型クラスター
Slide 73
Slide 73 text
MySQL互換が嬉しい
● 既存の開発作業、運用作業、エコシステムに影響なし。
● エンジニアが持つMySQLの知見をそのまま活用できる。
○ TiDB移行後に新機能実装が入ったが今まで通りこなせた。
○ MySQLの知識を持っているエンジニアは多いので、
新しくチームに参加した人の学習コストが低い。
Slide 74
Slide 74 text
MySQL互換が嬉しい
● GitOpsで任意のSQLを実行できる仕組み
○ gooseというマイグレーションツールを利用している。
● テーブル構成図をGitHub上で確認できる仕組み
○ tblというドキュメント生成ツールを利用している。
Slide 75
Slide 75 text
そんなに甘くないMySQL互換
● TiDBはMySQL互換だが、裏側はTiDB & TiKVで構成されている。
モノとしてはMySQLとは別物である。
● TiDBを利用して開発・運用するための学習コストがかかる。
○ MySQLの知見が100%役に立つわけではない。
○ TiDB, TiKVのキャパプラやトラブルシューティングは
試行錯誤している。
○ エンタープライズサポートは契約した方がいい。
■ 月額費用の20%がサポート費用として上乗せされる。
Slide 76
Slide 76 text
目次
1. TiDB Cloudは安定して動くのか
2. コスパはどう?
3. バージョンアップ戦略
4. MySQL互換が嬉しい
5. 意外と便利なTTL機能
6. 監視
7. Redis廃止しようかな
8. オートスケーラー
9. マルチテナント型クラスター
Slide 77
Slide 77 text
意外と便利なTTL機能
● TiDBはテーブルにTTL属性を持たせることができる。
○ 認証認可領域はアクセストークンやログインセッションなどの
有効期限を持つデータが多いので意外と利用する機会が多い。
Slide 78
Slide 78 text
目次
1. TiDB Cloudは安定して動くのか
2. コスパはどう?
3. バージョンアップ戦略
4. MySQL互換が嬉しい
5. 意外と便利なTTL機能
6. 監視
7. Redis廃止しようかな
8. オートスケーラー
9. マルチテナント型クラスター
Slide 79
Slide 79 text
監視
● TiDB CloudはDatadog, New Relicと連携することができる。
● Datadog, New Relic上のメトリクスが高く出てしまう。
○ TiDB Cloudのインフラが原因らしい。
○ Datadog, New Relicの監視やダッシュボードが使い物にならない。
■ 特に監視は誤発火するので困る。
● TiDB Cloudの管理画面を利用するしかない。
Slide 80
Slide 80 text
TiDB Cloudの管理画面が使いづらい
● 各種メトリクスが最大で1週間分しか表示できない。
○ 直近1ヶ月のメトリクスを確認しようとすると、
1週間分のメトリクスを4回確認しなければいけない。
● アラートがメールで通知されるのみ。
○ 受信したメールをSlack通知する仕組みを作った。
Slide 81
Slide 81 text
目次
1. TiDB Cloudは安定して動くのか
2. コスパはどう?
3. バージョンアップ戦略
4. MySQL互換が嬉しい
5. 意外と便利なTTL機能
6. 監視
7. Redis廃止しようかな
8. オートスケーラー
9. マルチテナント型クラスター
Slide 82
Slide 82 text
Redisを廃止しようかな
● 認証チーム、認可チームのレガシーシステムはRedisを利用している。
○ SET, GETが2msec未満くらい。
● Write/Readが水平にスケールするのでTiDBに寄せることが可能。
○ 単純なKey-Valueデータの操作は4~15ミリ秒で済む。
○ キャッシュのパージ戦略を考慮しなくていい。
○ システムアーキテクチャがシンプルになる。
○ SQLによる高度なデータ操作が可能になる。
● 費用が高くなりそうなので要検討。
Slide 83
Slide 83 text
目次
1. TiDB Cloudは安定して動くのか
2. コスパはどう?
3. バージョンアップ戦略
4. MySQL互換が嬉しい
5. 意外と便利なTTL機能
6. 監視
7. Redis廃止しようかな
8. オートスケーラー
9. マルチテナント型クラスター
Slide 84
Slide 84 text
オートスケーラーが欲しい
● QPSに応じてスケールイン・アウトして欲しい。
○ コスパ良くなる。
○ 想定外のスパイクに対応できるようになる。
Slide 85
Slide 85 text
目次
1. TiDB Cloudは安定して動くのか
2. コスパはどう?
3. バージョンアップ戦略
4. MySQL互換が嬉しい
5. 意外と便利なTTL機能
6. 監視
7. Redis廃止しようかな
8. オートスケーラー
9. マルチテナント型クラスター
Slide 86
Slide 86 text
マルチテナント型クラスター
● TiDBはマルチテナントを想定して作られている。
○ 例：複数のアプリケーションのDBを1つのクラスターに載せる。
○ 例：各アプリケーションのテスト環境を
単一のクラスターで実現する。
○ 例：Webアプリケーションとバッチアプリケーションが
同じDBにアクセスする。
● マルチテナント構成ではノイジーネイバーが問題になる。
Slide 87
Slide 87 text
リソース制御機能
● マルチテナントをサポートする機能としてリソース制御機能がある。
○ TiDBのユーザー、セッション、ステートメントごとに
利用できるリソースを制御できる。
○ ノイジーネイバーを防ぐことができる。
Slide 88
Slide 88 text
リソース制御機能とバックアップの相性が悪い
● TiDB Cloudのバックアップ機能がクラスター単位なので、
バックアップをリストアすると全データが一緒に巻き戻ってしまう。
○ DB単位でバックアップできるようになって欲しい。
● いまいちマルチテナントしづらい。
○ DMMプラットフォームでもマルチテナント型クラスターを
検討しているが困っている。
Slide 89
Slide 89 text
まとめ
● プロダクトとしての完成度はSpannerの方が高い。
○ Googleによってインフラレベルで最適化されている。
● TiDBも良いプロダクトであり、Spannerとの棲み分けができてる。
○ 国内の企業であれば十分使える。
○ オンプレの会社やMySQL利用者に刺さる。
● TiDB Cloudは安定して動くが、管理画面が使いづらい。
○ なんだかんだ実用に耐える形になっているので
プロダクト設計上手いなと思った。