DMMプラットフォームにおけるTiDBの導入から運用まで

DMMプラットフォームにおける TiDBの導入から運用まで @pospome

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

目次 1. New SQLを採用した背景 2. Google Cloud Spanner vs TiDB/TiDB
Cloud 3. TiDB Cloudで本番アプリケーションを運用してみて実際どうか

DMMプラットフォームについて扱う領域：DMM会員、決済、DMMポイント、不正対策などエンジニア数：120名以上開発チーム数：16チームマイクロサービス数：約40サービスピーク時のリクエスト：19,000RPS

レガシーシステムのリプレイスプロジェクトインフラのクラウド化 & Goへのrewriteする必要がある。 • 認証チームオンプレ, MySQL, Java, Cassandra,
Couchbase • 認可チームオンプレ, MySQL, PHP, Redis

クラウドでもMySQLを使うのか? MySQLを利用することに対する懸念 1. マスターノードが単一障害点 a. 認証認可が止まるとDMMが止まる。 2. バージョンアップ時のダウンタイム a. DMMはメンテを入れるのが面倒。
3. Writeが水平スケールしない a. 各種サービスの都合でリクエストが増える。

NoSQLの検討現実的に厳しい。 • Writeが水平にスケールし、バージョンアップ時のダウンタイムもない。 • MySQLのデータ構造をNoSQL向けに変更する必要がある。 • コードの改修もまあまあ発生する。 •
NoSQLを使いこなすための学習コストがかかる。 ◦ 例：JOINがない、トランザクションがない、などなど・・・。

New SQLの採用を検討した

New SQLの特徴中長期的に要件を満たせるDBだと感じた。 • バージョンアップ時にダウンタイムがない。 • Writeがスケールする。 • 強整合性を持つ。 •
耐障害性が高い。

New SQLの特徴 • RDBに比べるとレイテンシは高くなる。 ◦ ノード間の通信が発生する。 ◦ データが複数のノードに分散する。 ◦ レプリカ間の整合性を取る処理が必要になる。
• 費用が高くなる傾向にある。 ◦ 同じリソース量の場合はRDBの方が高いパフォーマンスを出せる。 • MySQL, NoSQLの上位互換ではない。 ◦ 適材適所である。

Google Cloud Spanner を使おう

PingCAPの大エースから謎のDMが来た・・・このDMはノリなのでは? (´・ω・`)

TiDBの特徴 • Spannerの論文を参考に開発されたOSSのNewSQLである。 • MySQL互換 ◦ MySQLのSQLやテーブル定義がそのまま使える。 ◦ ここに価値を感じたので検討候補に入れた。認証チームも認可チームもMySQLを利用しており、
開発・運用作業やエコシステムをそのまま活かせる。

MySQL互換

MySQL互換 TiDB独自の仕様はコメント構文で定義することで、 MySQLで有効な構文として扱うことができる。 MySQL互換を徹底している。

TiDB Cloudについて • TiDBを開発しているPingCAPが提供するDBaaSである。 • AWS, Google Cloud に対応している。 •
WebUIの管理画面がある。クラスターのスケールアップや各種メトリクスが確認できる。

TiDB Cloudについて • DMMプラットフォームではTiDB Cloudを採用することになる。 ◦ DevOpsを実現するため。 ▪ オンプレのMySQLはインフラ部への作業依頼 &
待ちが発生した。 ▪ 認証チーム、認可チームでインフラ運用が完結するように。

Spanner vs TiDB/TiDB Cloud 1. システムアーキテクチャ 2. パフォーマンス 3. 既存DBとの互換性
4. OLAP（オンライン分析処理） 5. ローカル開発 6. クラウド費用 7. GCPとの連携

Spannerのざっくりシステムアーキテクチャ

補足：詳細バージョン

TiDBのシステムアーキテクチャ

双方のシステムアーキテクチャについて • TiDBはSpannerを参考に開発されただけあって似ている。 ◦ コンピューティングとストレージを分割している。 ◦ Placement Driverによってデータ配置を調整している。 • SpannerはGoogleのインフラレベルで設計されており、
グローバルスケールで高可用性を持つDBになっている。 ◦ Clossus（分散ストレージ） ◦ True Time API（GPS & 原子時計） • TiDBはあくまでソフトウェアである。

パフォーマンス（QPS & レイテンシ） • ノード上のデータ配置、実行するクエリなどに依存するのでなんとも言えない。 ◦ TiDBはオンプレにもホスティングできる。 • 強整合性を保証したSELECTのQPSはSpannerの方が高いと思う。
◦ レプリカの仕様に違いがあるため。

TiDBのレプリカ • TiDBはデータをレプリカとして TiKVノードに複製する。 • クエリはリーダーにのみ向けられる。 • フォロワーはあくまでも
バックアップである。

Spannerのレプリカ • SpannerはTiDBでいうフォロワーにもアクセスできる。 • フォロワーは自身が持つデータが最新かどうかをリーダーに問い合わせる必要がある。 •
リクエストをレプリカに分散できる。

パフォーマンス（QPS & レイテンシ） • 強整合性を保証したSELECTのQPSはSpannerの方が高いと思う。 ◦ Spannerはフォロワーに負荷分散できるため。 ◦ リーダーに問い合わせる処理が発生するので、レイテンシは高くなりそう。
◦ GPS, 原子時計を利用しているTrue Time APIによってノード間の時刻差を限りなく小さくできる点も貢献しているかもしれない。

パフォーマンス（JOIN） • Spannerはインターリーブという機能を備えている。 ◦ 親子関係にあるデータを物理的に同じ場所に配置することで複数のノードからデータをかき集めることがなくなる。 ◦ JOINに強くなる。 ◦ Spannerはグローバルスケールなので
こういった最適化が必要なのかもしれない。

既存DBとの互換性 • TiDBはMySQL互換である。 ◦ 前述した通り一部の機能は利用できない。 • SpannerはPostgreSQL互換を備えている。 ◦ MySQLを利用しているレガシーシステムを PostgreSQLに対応する改修をいれることで
Spannerを利用することができる。

PGAdapterを利用しなければいけない • SpannerをPostgreSQL互換で利用するにはPGAdapterというプロキシを利用しなければいけない。 • Cloud Runでホスティングしたり、サイドカーとして稼働させる。

Spanner & PGAdapterは見送った以下の理由で見送った。 • MySQLに依存したリソースをPostgreSQLに移行する工数がかかる。どの程度の工数がかかるか読めない。 • PGAdapterと付き合っていかなければいけない。 Spannerはフルマネージドなのにプロキシの運用が発生してしまう。
リプレイスの都合上、オンプレ環境で稼働させる必要がある。 • Spannerを利用するなら覚悟を決めてネイティブ対応した方がよさそう。

OLAP（オンライン分析処理） • New SQLはデータが複数のノードに散るので、各種分析に必要な集計処理（sum, average, etc）が苦手である。 ◦ RDBも得意というわけではない。 •
TiDBは分析処理をサポートしている（HTAP）。 TiFlash（列指向のストレージコンポーネント）を導入することによってOLAPが可能になる。

TiDBにおける分析処理の実現方法 • TiKVのデータをTiFlashにも保存する。 ◦ データを2重で持つことになるが、TiDBが同期してくれる。 • 集計クエリをTiFlashに投げる。 ◦ MySQL互換のクエリを利用することができる。 ▪
OLTP, OLAPを透過的に扱うことができる。 ◦ TiFlashに適したクエリは自動的にTiFlashに投げてくれるが、明示的に指定することもできる。

TiFlashのコスパについて • TiFlashノードを常時稼働させる必要があるのでコスパは微妙。 ◦ 推奨環境は CPU 48コア, Memory 128GB, 2ノード
である。 • 可用性を気にしないなら1ノードでも問題ない。 ◦ 分析用途なら1ノードでもよさそう。 ◦ TiDB Cloudの最小構成だと月額980ドルくらい。

補足：TiFlashの分散ストレージ & コンピューティング • TiDB 7.0 以降で利用できる TiFlashのアーキテクチャである。 • 以下のコンポーネントで構成される。
◦ Write Node ◦ Compute Node ◦ S3 • コスパ良くTiFlashを使える仕組み。

OLAP（オンライン分析処理） • TiDBはHTAPをサポートしている。 TiFlash（列指向のストレージコンポーネント）を導入することによってOLAPが可能になる。 • SpannerはHTAPをサポートしていない。 ◦ BigQueryと連携する必要がある。

SpannerとBigQueryの連携 • Change Streamsを利用してデータをBQに連携する。 ◦ Spannerから送られる更新情報を DataﬂowやストリーミングのAPIを利用してBQに連携する。 • BQのクエリ連携を利用する。 ◦
BQがSpannerのデータを直接クエリする（コピーしない）。 ◦ BQネイティブに比べるとパフォーマンスが劣る可能性がある。 ◦ BQがサポートしないデータ型は扱えない。別の型にキャストする必要がある。

SpannerのData Boost • SpannerのOLTPで利用されるノードとは別のノードを用意し、任意のクエリを実行できる。 • 既存のOLTPに影響を与えない。 •
クエリ実行にかかったリソースのみ課金される。

ローカル開発 • TiDBはtiupというCLIツールを利用すると、ローカルPCに軽量な形でTiDBを立ちあげることができる。 ◦ 本物のTiDBが立ち上がるので各種検証にも利用できる。 ◦ OSSならではのメリットである。 • Spannerは開発/テスト用途のエミュレーターを提供している。
◦ 本番相当のAPIを提供しているがあくまでエミュレーターである。 ◦ SpannerはクライアントとgRPCで通信するので、本物のSpannerを立ててローカルからアクセスすればいーのでは。

クラウド費用 • どちらが安いかは一概には言えない。 ◦ パフォーマンス（QPS, レイテンシ）次第になってしまう。 ◦ Enterprise Discount Program(EDP)のような割引も絡んでくる。

GCPとの連携 • SpannerはGCのサービスなので各種GCサービスとの連携がある。 ◦ IAMによるアカウント管理 ◦ Cloud Logging, Cloud Monitoring
◦ BigQueryとの連携 ◦ Lookerとの連携 ◦ Change Streamsによる更新内容のストリーミング

結論：Google Cloud Spanner vs TiDB • Spannerの方が完成度が高い。 • Googleの資金力や開発力に勝つのは難しい。 ◦
特にインフラも含めて最適化されている点はどうしようもない。 • クラウドサービスとしての品質もGoogle Cloudには敵わない。 ◦ 今まで積み上げてきた実績やエコシステムが存在する。

SpannerはTiDBの直接的な競合になるのか? 意外と棲み分けができているのでは? • TiDBはOSSなのでオンプレでのホスティングが可能である。 • MySQL互換 ◦ エコシステムをそのまま利用できる。 ◦ 既存コードに手を入れず、DBを移行することができる。
▪ レガシーシステムにとっては嬉しい。 ◦ エンジニアの学習コストを低く抑えることができる。 • AWS利用者はTiDB Cloudを利用できる。

DMMプラットフォームはTiDB Cloudを採用した • Spannerほどではないが十分実用に耐える品質になっている。 ◦ GAFAのようなビッグテックならまだしも、日本国内の企業であれば十分利用できる。 • レガシーシステムをリプレイスするDMMプラットフォームでは “MySQL互換”
が決め手となってTiDB Cloudを選択した。 ◦ 試しにMySQLからTiDBに向き先を変えてE2Eテストを実行したらそのまま通った。

移行作業を振り返って • エンジニアを2人ほど貼り付けて大体半年くらいかかった。 ◦ カナリアリリースやデータ同期チェック期間による待ちがあったので実際にかかった工数はもっと少ない。 • 移行に必要な実装はダブルライトくらい。 ◦ ダウンタイムが許されないので無停止で移行した。
◦ レガシーアプリケーションながらも既存の Insert, Update, Delete をコピペするだけなのでサクサク進めることができた。

移行後のレイテンシについて • 認証チームのアプリケーションのレイテンシは全体的に20~30msecほど上がった。 ◦ 許容できる範囲内なので問題なし。

目次 1. TiDB Cloudは安定して動くのか 2. コスパはどう? 3. バージョンアップ戦略 4. MySQL互換が嬉しい
5. 意外と便利なTTL機能 6. 監視 7. Redis廃止しようかな 8. オートスケーラー 9. マルチテナント型クラスター

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台

TiDB Cloudは安定して動くのか? • 過去にあったトラブルは以下である。 ◦ キャパプラをミスってレイテンシが悪化した。 ◦ TiKVのバグに遭遇した。バージョンアップで解消した。

TiDB Cloudは安定して動くのか? • TiDBノードのCPU利用率が80%になるとレイテンシが悪化する。 ◦ 80%未満 … 数ミリ〜数十ミリ秒のレイテンシ ◦ 80%以上
… 数百ミリ秒のレイテンシ • TiDBノードのCPU使用率が80%を超えないようにキャパプラしている。

TiDB Cloudは安定して動くのか? • リプレイスが完了すると約15,000QPSくらいになる想定である。 ◦ 今後の機能追加やRedisを廃止するとQPSはさらに増える。

TiDB Cloudは安定して動くのか? • Writeが水平スケールするので、 DMMの各サービスからのスケール依頼に怯えなくてよくなった。 ◦ 例「来月のイベントで5000RPSくらいリクエスト増えるんですけど、大丈夫ですか?」

コスパはどう? • 中長期的に要件を満たせるDBが手に入ったのは嬉しいが、コスパがいいわけではないと思う。 • RDBで済むならRDBにした方が良いと思う。

別チームではコスパが理由でTiDBの採用を見送った • AWS Auroraと同等のQPSを出そうとするとインフラ費用が2倍以上かかるので採用を見送った。レイテンシの悪化はアプリケーション全体で60msec程度だった。 ◦ シンプルに Aurora がすごい。
• 十分なリソースを用意することができれば、アプリケーション全体のレイテンシの悪化は 100msec以内に収まる感じがする。 • NewSQLはRDBの上位互換ではない。

バージョンアップ戦略 • TiDB Cloudにはロールバック機能がないので一発勝負である。 ◦ 保存したデータまでロールバックすることはできないので、 TiDBとしてロールバック機能をサポートするのは難しい。 • ロールバックするにはロールバック用のクラスタを立てて、アプリケーションの向き先を変える必要がある。
◦ データの整合性がどこまで保証されるか不明。

できるだけ安全にバージョンアップするために • リリースノートで下位互換性を確認する。 • tiupでバージョンアップ対象のTiDBを立ち上げて、 E2Eテストを流すことでクエリの動作を保証する。 • 最新バージョンの1つ前のマイナーバージョンを利用する。 ◦ 枯れた実装を選択することで動作を保証する。
• 開発用のクラスターで様子を見てから本番用のクラスターをバージョンアップする。 ◦ 本番相当の負荷は来ないので参考程度。

MySQL互換が嬉しい • 既存の開発作業、運用作業、エコシステムに影響なし。 • エンジニアが持つMySQLの知見をそのまま活用できる。 ◦ TiDB移行後に新機能実装が入ったが今まで通りこなせた。 ◦ MySQLの知識を持っているエンジニアは多いので、新しくチームに参加した人の学習コストが低い。

MySQL互換が嬉しい • GitOpsで任意のSQLを実行できる仕組み ◦ gooseというマイグレーションツールを利用している。 • テーブル構成図をGitHub上で確認できる仕組み ◦ tblというドキュメント生成ツールを利用している。

そんなに甘くないMySQL互換 • TiDBはMySQL互換だが、裏側はTiDB & TiKVで構成されている。モノとしてはMySQLとは別物である。 • TiDBを利用して開発・運用するための学習コストがかかる。 ◦ MySQLの知見が100%役に立つわけではない。
◦ TiDB, TiKVのキャパプラやトラブルシューティングは試行錯誤している。 ◦ エンタープライズサポートは契約した方がいい。 ▪ 月額費用の20%がサポート費用として上乗せされる。

意外と便利なTTL機能 • TiDBはテーブルにTTL属性を持たせることができる。 ◦ 認証認可領域はアクセストークンやログインセッションなどの有効期限を持つデータが多いので意外と利用する機会が多い。

監視 • TiDB CloudはDatadog, New Relicと連携することができる。 • Datadog, New Relic上のメトリクスが高く出てしまう。
◦ TiDB Cloudのインフラが原因らしい。 ◦ Datadog, New Relicの監視やダッシュボードが使い物にならない。 ▪ 特に監視は誤発火するので困る。 • TiDB Cloudの管理画面を利用するしかない。

TiDB Cloudの管理画面が使いづらい • 各種メトリクスが最大で1週間分しか表示できない。 ◦ 直近1ヶ月のメトリクスを確認しようとすると、 1週間分のメトリクスを4回確認しなければいけない。 • アラートがメールで通知されるのみ。 ◦
受信したメールをSlack通知する仕組みを作った。

Redisを廃止しようかな • 認証チーム、認可チームのレガシーシステムはRedisを利用している。 ◦ SET, GETが2msec未満くらい。 • Write/Readが水平にスケールするのでTiDBに寄せることが可能。 ◦ 単純なKey-Valueデータの操作は4~15ミリ秒で済む。
◦ キャッシュのパージ戦略を考慮しなくていい。 ◦ システムアーキテクチャがシンプルになる。 ◦ SQLによる高度なデータ操作が可能になる。 • 費用が高くなりそうなので要検討。

オートスケーラーが欲しい • QPSに応じてスケールイン・アウトして欲しい。 ◦ コスパ良くなる。 ◦ 想定外のスパイクに対応できるようになる。

マルチテナント型クラスター • TiDBはマルチテナントを想定して作られている。 ◦ 例：複数のアプリケーションのDBを1つのクラスターに載せる。 ◦ 例：各アプリケーションのテスト環境を　　単一のクラスターで実現する。 ◦ 例：Webアプリケーションとバッチアプリケーションが
　　同じDBにアクセスする。 • マルチテナント構成ではノイジーネイバーが問題になる。

リソース制御機能 • マルチテナントをサポートする機能としてリソース制御機能がある。 ◦ TiDBのユーザー、セッション、ステートメントごとに利用できるリソースを制御できる。 ◦ ノイジーネイバーを防ぐことができる。

リソース制御機能とバックアップの相性が悪い • TiDB Cloudのバックアップ機能がクラスター単位なので、バックアップをリストアすると全データが一緒に巻き戻ってしまう。 ◦ DB単位でバックアップできるようになって欲しい。 • いまいちマルチテナントしづらい。 ◦
DMMプラットフォームでもマルチテナント型クラスターを検討しているが困っている。

まとめ • プロダクトとしての完成度はSpannerの方が高い。 ◦ Googleによってインフラレベルで最適化されている。 • TiDBも良いプロダクトであり、Spannerとの棲み分けができてる。 ◦ 国内の企業であれば十分使える。 ◦
オンプレの会社やMySQL利用者に刺さる。 • TiDB Cloudは安定して動くが、管理画面が使いづらい。 ◦ なんだかんだ実用に耐える形になっているのでプロダクト設計上手いなと思った。

DMMプラットフォームにおけるTiDBの導入から運用まで

DMMプラットフォームにおけるTiDBの導入から運用まで

More Decks by pospome

Other Decks in Programming

Featured

Transcript