長期運用プロジェクトでのMySQLからTiDB移行の検証

Transcript

1. 長期運用プロジェクトでの MySQL から TiDB 移行の検証 私たちはなぜ NewSQL を使うのか TiDB 選定5社が語る選定理由と活用 LT
2. 曽我 光瑛 • 2018年新卒入社 • 技術基盤本部 インフラストラクチャ部 第1グループ所属 • ゲームインフラの横断的な負荷対策やコスト最適化を担当 2 自己紹介
3. アジェンダ 1. 長期運用プロジェクトの課題 2. TiDB 導入の背景 3. TiDB 導入の課題 4. まとめ 3
4. 現状のコロプラの構成について • VM 上に構築したシンプルな Source / Replica 構成の MySQL • 水平 / 垂直分割による負荷分散 4 長期運用プロジェクトの課題
5. ディスクの削減が困難 • 不要データ削除後のディスクの削減のために Source の切替が必要 構成の縮小 • 水平/垂直分割した DB を一つの DB にまとめる • インフラだけでなくアプリケーション面の対応も必要 セキュリティ対応 • 分割数が多いため、 MySQL や OS のアップデートに追従するコストが重い • オンラインで実施するためには Source の切替作業が必要 5 長期運用プロジェクトの課題
6. Source の切替について • 新 Source/Replica の組み合わせを作成しメンテナンス無しで切替 • Source の停止が必要な作業では実施しますが、準備に手間がかかります 6 長期運用プロジェクトの課題 Source Replica Source Replica Application Source Replica Source Replica Application
7. 以下の理由で TiDB を選択 • MySQL 互換 • スケールアウト/スケールインが比較的容易に実施可能 • メンテナンス無しでバージョンアップ可能 • 分割した DB はそのままにエンドポイントを一つに集約可能 • データ圧縮によるディスクの削減 7 TiDB 導入の背景
8. 検証でうまくいった部分 • データ圧縮は想定どおり 1/3 程度まで圧縮 • レイテンシーの悪化は想定の範囲内 8 TiDB 導入の課題
9. 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;
10. 得意ではないデータやクエリが存在する • 一部の 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
11. 今回の検証で判明したこと • 小規模なデータ、低頻度のアクセスでは発見できない課題がある ◦ 適切な規模で負荷試験を実施することで分散 DB 特有の問題を見つけることができる • TiDB では適切なデータの配置になるようなインデックスや Primary Key の設定が必要 • InnoDB エンジンに依存するロジックの改善が必要であること 11 まとめ