長期運用プロジェクトでの MySQL から TiDB 移行の検証 私たちはなぜ NewSQL を使うのか TiDB 選定5社が語る選定理由と活用 LT

曽我 光瑛 ● 2018年新卒入社 ● 技術基盤本部 インフラストラクチャ部 第1グループ所属 ● ゲームインフラの横断的な負荷対策やコスト最適化を担当 2 自己紹介

アジェンダ 1. 長期運用プロジェクトの課題 2. TiDB 導入の背景 3. TiDB 導入の課題 4. まとめ 3

現状のコロプラの構成について ● VM 上に構築したシンプルな Source / Replica 構成の MySQL ● 水平 / 垂直分割による負荷分散 4 長期運用プロジェクトの課題

ディスクの削減が困難 ● 不要データ削除後のディスクの削減のために Source の切替が必要 構成の縮小 ● 水平/垂直分割した DB を一つの DB にまとめる ● インフラだけでなくアプリケーション面の対応も必要 セキュリティ対応 ● 分割数が多いため、 MySQL や OS のアップデートに追従するコストが重い ● オンラインで実施するためには Source の切替作業が必要 5 長期運用プロジェクトの課題

Source の切替について ● 新 Source/Replica の組み合わせを作成しメンテナンス無しで切替 ● Source の停止が必要な作業では実施しますが、準備に手間がかかります 6 長期運用プロジェクトの課題 Source Replica Source Replica Application Source Replica Source Replica Application

以下の理由で TiDB を選択 ● MySQL 互換 ● スケールアウト/スケールインが比較的容易に実施可能 ● メンテナンス無しでバージョンアップ可能 ● 分割した DB はそのままにエンドポイントを一つに集約可能 ● データ圧縮によるディスクの削減 7 TiDB 導入の背景

検証でうまくいった部分 ● データ圧縮は想定どおり 1/3 程度まで圧縮 ● レイテンシーの悪化は想定の範囲内 8 TiDB 導入の課題

TiKV Region1 データ量による負荷 ● 大量のデータにより TiKV 上でリージョンの分割が多く発生 ● リージョン間のやり取りのプロセスによりクエリの量以上に TiKV の負荷が上がる ● 適切な Primary Key (PK) やインデックスの追加で軽減可能 9 TiDB 導入の課題 Region3 ID (PK) USER_ID DATA 5 1 data5 6 3 data6 Region2 ID (PK) USER_ID DATA 3 1 data3 4 4 data4 ID (PK) USER_ID DATA 1 1 data1 2 2 data2 SELECT * FROM USER_ID = 1;

得意ではないデータやクエリが存在する ● 一部の DB で本番相当の負荷をかけた際に、クエリ量に対して負荷が高い状態となった トランザクション分離レベル ● MySQL と同じ REPEATABLE-READ だが実装が異なる ● 本番相当のクエリ量の試験で意図しない動作が発生した ○ リトライによる多重リクエストのようなクエリで MySQL と異なる結果 ■ 二重インサート防止のためのアプリケーションのロジックが InnoDB の挙動に依存して いたため、TiDB ではエラーが発生した 10 TiDB 導入の課題 [1] https://docs.pingcap.com/ja/tidb/stable/transaction-isolation-levels#difference-between-tidb-and-mysql-repeatable-read

今回の検証で判明したこと ● 小規模なデータ、低頻度のアクセスでは発見できない課題がある ○ 適切な規模で負荷試験を実施することで分散 DB 特有の問題を見つけることができる ● TiDB では適切なデータの配置になるようなインデックスや Primary Key の設定が必要 ● InnoDB エンジンに依存するロジックの改善が必要であること 11 まとめ