AuroraからTiDBへ！！安定運用タイトルで挑んだTiDB移行とNewSQLの可能性

2025年12月11日（木）に開催された「NewSQLデータベースでどう変わる？」（運営：PingCAP）で登壇した際の資料です。

運用6年目を迎えた安定稼働中のゲームタイトルにおいて、AuroraからTiDBへの移行事例について発表しました。
「なぜ安定しているタイトルを移行する必要があったのか？」という背景から、TiDBを採用した理由や移行時の工夫、実際の移行プロセスについて紹介しています。
また、移行直後に発生したトラブル対応や、TiDB Cloud APIを活用した運用自動化についても触れています。

本イベントのテーマである「NewSQL」にも触れながら、スケーラビリティや高可用性といったTiDBならではの特徴、実運用を通じて得られた知見についてお話ししました！！

下記にアーカイブ動画や資料もありますのでぜひ！！
「PingCAP Japanの公式YouTube」です。
https://www.youtube.com/watch?v=XqrecqI2I7s&t=2s

他のTiDB関連の動画を見たい場合は「Videos & Replays」から見ることができます。
https://pingcap.co.jp/videos/

Transcript

1. 株式会社オルトプラス　浦谷 和茂 NewSQLデータベースでどう変わる？ 12/11 14:10-
2. 今回お話しする内容は、 運用6年目のとある音ゲープロジェクトを AuroraからTiDBへ移行した事例についてです はじめに
3. 移行事例で登壇したセッションは2本あるので 今回はテイストを変えてお伝えします！！
4. © 2025 AltPlus Inc. 4 本日のアジェンダ • TiDB導入の背景 • NewSQLの水平スケールを支える仕組み • なぜTiDBなのか • TiDB Cloud選定の決め手 • TiDB Cloudへの移行 • 移行後について
5. © 2025 AltPlus Inc. 自己紹介 5 株式会社オルトプラス 技術部/エンジニアマネージャー kazushige uratani 浦谷 和茂 2023年6月にオルトプラスに入社 プロジェクトを横断的に見ていますー！！ SRE見ていますー！！ 入社してからずっと「 TiDBの推し活」をしてました（笑） TiDBのユーザーコミュニティー「 TiUG」も盛り上げ Ti！！
6. オルトプラスについて
8. オルトプラスの主なタイトル Everybody Shogi （えぶりばでぃ将棋） 忘却前夜 戦国小町苦労譚 語絵巻 - カタリエマキ - 新感覚カジュアル将棋 パズルゲーム 戦略的なバトルが特徴 のスマホ向けカードRPG フルボイス化＆平沢下戸先生 の魅力溢れるヴィジュアルで 再構築したノベルアプリ
9. TiDB導入の背景
10. © 2025 AltPlus Inc. TiDB導入の背景 10 運用6年目を迎えた音ゲープロジェクトでは、 Auroraクラスターで安定運用していました。 それではなぜ 安定運用中のタイトルを TiDBに刷新したのでしょうか？
11. © 2025 AltPlus Inc. TiDB導入の背景：移行前構成図 11
12. © 2025 AltPlus Inc. TiDB導入の背景：移行前構成図 12 　Auroraクラスター3台（Provisioned）で運用
13. © 2025 AltPlus Inc. TiDB導入の背景：Auroraの課題 13 Auroraは1クラスターで完結する前提の設計だが、 ゲームの成長にあわせてクラスターを横に増やして対応 リリース時 運用中盤 新規流入 クラスター増加に伴ってベースコストが増加 Range Sharding
14. © 2025 AltPlus Inc. TiDB導入の背景：問題点と理想 14 スケールはクラスター単位 • AuroraはWriterを増やせない → Range Sharding構成で運用 • イベント時など高負荷時 → 各クラスターでリソース調整が必要 Writerがスケールし、かつシャーディング不要で 運用できるデータベースがあれば・・・ 問題点 理想
15. NewSQLの水平スケールを支える仕組み
16. © 2025 AltPlus Inc. データベースの種類と特徴 16 データベース 特徴 RDB 強い整合性・複雑なJOIN・トランザクションが得意 スケールアップ中心で、スケールアウトは苦手 NoSQL 高いスケーラビリティ・柔軟なスキーマ SQL/トランザクション前提の設計には不向き NewSQL RDBのトランザクション／SQL互換性 NoSQL並みのスケールアウト性能 水平方向にスケール可能なアーキテクチャで、 従来のRDBが苦手とする書き込み負荷にも対応できる
17. © 2025 AltPlus Inc. NewSQLの水平スケールを支える仕組み：水平スケールの理由 17 NewSQLが水平方向にスケールできるのは、 データをKey-Value形式に分割して 分散管理できる設計になっているためです！！ 一意なキーをもとにデータを分割できるため、 各ノードが独立して読み書きが可能！！
18. © 2025 AltPlus Inc. NewSQLの水平スケールを支える仕組み：Key-Valueに変換「KV Encoder」 18 TiDBも同様SQLを内部でKey-Valueに変換して保存 することで、1台のWriterではなく「クラスタ全体 で書き込み処理ができる」構造になっています。 TiDBでは「SQL Core Layer」の 「Executor」内でKey-Valueに変換
19. © 2025 AltPlus Inc. NewSQLの水平スケールを支える仕組み：SQLレイヤーのデータフロー（全体像） 19 Client Protocol Layer SQL Core Layer Mem Buffer Two-phase Committer Packet SQL Data Data Packet Packet Command Data Execute SQL Core Layer内の ExecutorでKVに変換
20. © 2025 AltPlus Inc. NewSQLの水平スケールを支える仕組み：SQL Core Layerのデータフロー 20 SQL Core Layer Session Context SQL Parser SQL Validator AST Type Infer AST AST Logical Optimizer Logical Plan Physical Optimizer Physical Plan Distributed Coprocessor TiDB Executor SQL-to- Key-Value変換 Physical Planに基づ いてKey-Valueに変換 （tablecodec） Execute（DistSQL） tablecodec.go（EncodeRowKey＋EncodeRow）
21. © 2025 AltPlus Inc. NewSQLの水平スケールを支える仕組み：RowからKey-Valueへの変換イメージ 21 [ROW] 　　1, "TiDB", "SQL Layer", 10 　　2, "TiKV", "KV Engine", 20 　　3, "PD", "Manager", 30 [Key-Value] 　　t10_r1 --> ["TiDB", "SQL Layer", 10] 　　t10_r2 --> ["TiKV", "KV Engine", 20] 　　t10_r3 --> ["PD", " Manager", 30] tablecodec
22. © 2025 AltPlus Inc. [補足]TiDBコンピューティングについての資料 22 ドキュメントを参照するとより理解が深まります！！ https://docs.pingcap.com/ja/tidbcloud/tidb-computing/ #architecture-of-sql-layer [SQLレイヤーのアーキテクチャ] https://docs.pingcap.com/ja/tidbcloud/tidb-computing/ #example-of-key-value-mapping-relationship [キーと値のマッピング関係の例]
23. なぜTiDBなのか
24. © 2025 AltPlus Inc. なぜTiDBなのか 24 Auroraは高い安定性とマネージド運用を実現し、 長年その恩恵を受けてきました。 一方で、より柔軟なスケールや分散構成を求めて、 NewSQLであるTiDBを選択しました！！
25. © 2025 AltPlus Inc. なぜTiDBなのか 25 https://docs.pingcap.com/tidb/stable/tidb-architecture クラスター全般の 管理を行う頭脳 SQLを解析・ 最適化して実行 Key-Valueと 列指向の構造で データを永続化 TiDBは3つのコンポーネントに分かれているため、 より柔軟なスケールや分散構成が可能です
26. © 2025 AltPlus Inc. なぜTiDBなのか 26 Writerのスケール シャーディング不要 TiDBのStorage cluster「TiKV」のスケールで Writerのスケールが可能に！！ TiDBの分散機能によりデータと負荷が 自動分散されシャーディングが不要に！！
27. © 2025 AltPlus Inc. なぜTiDBなのか 27 NewSQLの中で、 TiDBを選んだ理由は何故か？
28. © 2025 AltPlus Inc. なぜTiDBなのか：①シャーディング不要で柔軟なスケール 28 ①シャーディング不要で柔軟なスケール • TiDBは自動でデータが分散される ◦ シャーディング構成が不要 • 必要なリソースに合わせたスケール ◦ 書き込み性能もノード追加で拡張可能
29. © 2025 AltPlus Inc. ①シャーディング不要で柔軟なスケール：自動シャーディングの仕組み 29 TiKV Region TiKV Region Region Increase Split Decrease Merge 96MiB以上で分割して20MiB以下でマージする （上記サイズはデフォルトで変更可能） v8.4.0以降では、Regionのデフォルトサイズが96MiBから256MiBに変更
30. © 2025 AltPlus Inc. ①シャーディング不要で柔軟なスケール：自動シャーディングの仕組み 30 https://docs.pingcap.com/ja/tidb/stable/tidb-storage#region [Key1, Key4) 範囲ベースの シャーディング戦略 [Key4, Key7) 【左閉右開区間】 [StartKey, EndKey)で表現可能
31. © 2025 AltPlus Inc. 31 コンピューティング ストレージ [短期的] QPSやコネクション数を元に増減 [短・中・長期的] QPS・IOPS・ストレージを元に増減 ①シャーディング不要で柔軟なスケール：コンポーネント単位でのスケール
32. © 2025 AltPlus Inc. なぜTiDBなのか：②MySQLとの互換性の高さ 32 ②MySQLとの互換性の高さ • MySQL5.7＋8.0（v7.5LTS） ◦ 従来のMySQLとほぼ同じ感じで使える 但し、FULLTEXT INDEX、ストアドプロシージャ、 トリガー等サポートしていない機能も一部あります
33. © 2025 AltPlus Inc. 33 将来的に全文検索の サポート計画はありますか？ はい、そうします。 https://docs.pingcap.com/tidbcloud/vector-search-full-text-search-sql/ 　現時点では特定のAWSリージョンのTiDB Cloud StarterとEssentialのみ対応 　　AWS: Frankfurt (eu-central-1) and Singapore (ap-southeast-1) ②MySQLとの互換性の高さ：FULLTEXT INDEXについて
34. © 2025 AltPlus Inc. 34 MySQL MySQL Client mysql -uxxx -p -hxxx –port=3306 mysql -uxxx -p -hxxx –port=4000 ホストとportを変更 するだけで接続先が変わる port:3306 MySQLクライアント データベース port:4000 ②MySQLとの互換性の高さ：各データベースへの接続イメージ
35. © 2025 AltPlus Inc. なぜTiDBなのか 35 自分は音ゲーの運用について日頃から考えて いたことがありました。 • Auroraクラスター3つの運用はコストがかかるのでは？ • シャーディングによるリソース調整が難しいのでは？ TiDBが向いているのではないか？
36. © 2025 AltPlus Inc. 弊社CTOと毎週話す機会があり提案 なぜTiDBなのか 36 まずは音ゲーに入れたらどうだろう？
37. © 2025 AltPlus Inc. なぜTiDBなのか 37 やっちまおうぜ！ 弊社CTOの有馬さんはこんな感じ（笑）
38. TiDB Cloud選定の決め手
39. © 2025 AltPlus Inc. TiDB Cloud選定の決め手 39 TiDBはセルフマネージドと フルマネージドを選べるが、 それではなぜ、 TiDB Cloudを選定したのか？ セルフ Cloud
40. © 2025 AltPlus Inc. TiDB Cloud選定の決め手 40 ①マネージドサービス • クラウド上でフルマネージド提供 ◦ インフラ構築や運用管理の負担を削減できる ◦ サポートによる対応の恩恵を受けやすい • スケーリングやバックアップも自動化 ◦ チームの運用コストや導入のハードルも低い
41. © 2025 AltPlus Inc. ①マネージドサービス：セルフマネージドはどうなの？ 41 セルフマネージドのTiDB環境を構築して移行検証をしていた時もありました TiUPコマンドを使用した運用も自動化できるので使いやすかったです！！ セルフマネージドの TiDBへデータ移行 Auroraのスナップ ショットを取得して
42. © 2025 AltPlus Inc. ①マネージドサービス：マネージド・セルフマネージド比較 42 観点 マネージド （TiDB Cloud） セルフマネージド （ソフトウェア） 導入ハードル 学習コストが低く導入が容易 専門知識と初期構築が必要 運用負荷 クラウド上でフルマネージド提供 （インフラ構築や運用管理の負担削減） 構築や保守などは自社で実施 （初期構築や運用ノウハウの負担がある） バックアップ 自動バックアップ機能を提供 設定や保守は自社で対応 アップデート 自動的に最新バージョンへ反映 バージョン管理や検証を自社で実施 サポート チケットベースの公式サポート （Jiraのチケット対応で迅速） 社内リソース依存で負担が大きい （ただしテクニカルサポートは可能）
43. © 2025 AltPlus Inc. TiDB Cloud選定の決め手 43 ②シンプルで直感的なUI • TiDB CloudのUIは操作がわかりやすい ◦ 学習コストが低い ◦ 画面から直感的にわかる • チームメンバーに説明する時間が減り、 導入初期のハードルが低い
44. © 2025 AltPlus Inc. 44 ①Organizationや Projectを選択 ②ナビゲーション ペインから項目を選択 ③選択内容が 表示される （左）のナビゲーションペインで選択した内容が、（右）のメインに表示 されるUI構成のため、シンプルで直感的に操作できると感じています。 ②シンプルで直感的なUI：UIがシンプルで直感的だと感じる理由
45. TiDB Cloudへの移行
46. ①移行手順と工夫
47. © 2025 AltPlus Inc. 47 TiDB Cloudへの移行：①移行手順と工夫 ドキュメントを確認しながら移行の方法を検討
48. © 2025 AltPlus Inc. 48 TiDB Cloudへの移行：①移行手順と工夫 ツール 説明 Dumpling （エクスポート） テーブル定義やバックアップを取得する際に使用 出力ファイルは「SQL、CSV」、出力先は「ローカル、S3」、 分割サイズは256MiBが推奨 sync-diff-inspector （整合性チェック） 移行データを比較する用途で使用（チェックサム） テーブル定義或いはデータ不一致の場合は修正用のQUERYを出力 ※動いている環境で実行すると差分がでてしまうので注意 検討した結果下記ツールを採用（セルフマネージド） https://docs.pingcap.com/tidb/stable/migration-tools/
49. © 2025 AltPlus Inc. 49 TiDB Cloudへの移行：①移行手順と工夫 ツール 説明 TiDB Cloud コンソール （インポート） TiDBクラスターへの初期データインポートで使用 Dumplingでエクスポートしたファイルを、 TiDB Cloudのインポート機能を使用してClusterに取り込む Physicalモードで、TiKVに直接データ（KVペア）を登録 インポート処理のみTiDB Cloudのマネージド機能を使用 https://docs.pingcap.com/tidbcloud/import-sample-data/
50. © 2025 AltPlus Inc. 50 TiDB Cloudへの移行：①移行手順と工夫 prod-altplus（987654321000） 移行のイメージ（全体像） tiup db_admin db_user_01 db_user_02 db_user_03 dumpling TiDB Cloud コンソール ：Import tidb cloudd db_admin db_user sync_diff_inspector
51. © 2025 AltPlus Inc. TiDB Cloudへの移行：①移行手順と工夫 [準備]TiDBクラスター作成 TiDB CloudのOrganizationを作成 tidb cloudd TiDB Clusterを作成 Organization作成後に「TiDB Cluster」の作成が可能になります 51
52. © 2025 AltPlus Inc. TiDB Cloudへの移行：①移行手順と工夫 prod-altplus（987654321000） [準備]プライベートエンドポイント接続設定 tidb cloudd AWS PrivateLink TiDB Cloudでは、PrivateLinkを使用したプライベートエンドポイント は必須ではありませんが推奨されています 52
53. © 2025 AltPlus Inc. TiDB Cloudへの移行：①移行手順と工夫 通信がパブリックインターネットを経由しない パブリックエンドポイントは簡易ですが、 セキュリティ要件が高い環境ではPrivateLinkの利用が望ましいです！！ AWSネットワーク内 で完結できる 53
54. © 2025 AltPlus Inc. TiDB Cloudへの移行：①移行手順と工夫 VPC Peeringも似た接続方法なのですが・・・ VPC PeeringはTiDB Cloud Starter非対応 のためPrivateLink一択になりました！！ 54
55. © 2025 AltPlus Inc. TiDB Cloudへの移行：①移行手順と工夫 prod-altplus（987654321000） [準備]TiDBテーブル定義変更対応 db_user_01 db_user_02 db_user_03 tidb-nodata.dmp 書き換え （例：AUTO_INCREMENT の削除など） db_admin tidb cloudd db_admin db_user シャーディングされたテーブル定義は「01」のみを取得し、 TiDB向けにdmpファイルを書き換えてリストアを実施する シャーディング統合 55
56. © 2025 AltPlus Inc. TiDB Cloudへの移行：①移行手順と工夫 prod-altplus（987654321000） TiDB Cloud コンソール ：Import tidb cloudd [準備]TiDBツール データチェックツール インストール インポートツール （TiDB Cluster作成後 に使用可能） sync_diff_inspector tiup dumpling エクスポートツール インストール 56
57. © 2025 AltPlus Inc. TiDB Cloudへの移行：①移行手順と工夫 prod-altplus（987654321000） [準備]S3バケット tiup dumpling tidb cloudd AWS Identity and Access Management (IAM) IAMポリシー IAMロール アタッチ エクスポート・インポート時に S3へのアクセス許可が必要！！ S3へのアクセス許可 TiDB Cloud コンソール ：Import エクスポート インポート 57
58. © 2025 AltPlus Inc. TiDB Cloudへの移行：①移行手順と工夫 prod-altplus（987654321000） [実行]Dumplingを使用したエクスポート tiup db_admin db_user_01 db_user_02 db_user_03 dumpling シャーディングと 非シャーディングのデータを 各DB単位でS3にエクスポート 非シャーディング用 パラメータで取得 シャーディング対象の各 DBを個別にパラメータを 指定して取得 エクスポート 58
59. © 2025 AltPlus Inc. TiDB Cloudへの移行：①移行手順と工夫 prod-altplus（987654321000） [実行]TiDB Cloudコンソールを使用したインポート TiDB Cloud コンソール ：Import tidb cloudd db_admin db_user TiDB Cloudコンソールを使用して 直感的なインポートを実行できます インポート実施前に 「S3URL」や「ロールのARN」を 控えておく必要があります インポート　 59
60. © 2025 AltPlus Inc. [補足]TiDB Cloudでのインポート：TiDB Cloudコンソール 60 Schemaはあるので「No」 ファイルタイプ ：SQL オルトプラスの例 S3URLを設定 ロールのARNを設定 上記全て入力すると「Connect」が活性化 ボタン押下時にOKであればインポートの画面へ
61. © 2025 AltPlus Inc. [補足]エクスポート→インポート（シャーディング統合）イメージ 61 db_admin db_user db_admin.admin_table-0000000000000.sql db_admin db_user_01 db_user_02 db_user_03 シャーディング統合 非シャーディング 同一テーブルがS3にアップロードされる際、 重複しないようにシャーディング番号を入れる db_user.user_table_1_0000000000000.sql db_user.user_table_2_0000000000000.sql db_user.user_table_3_0000000000000.sql
62. © 2025 AltPlus Inc. TiDB Cloudへの移行：①移行手順と工夫 62 prod-altplus（987654321000） [実行]sync_diff_inspectorを使用したデータ整合性チェック db_user_01 db_user_02 db_user_03 tidb cloudd インポート前後のデータを比較し、差分を検出 （非シャーディングとシャーディングで分けて実行する必要があります） 差分を検出 db_admin db_user db_admin sync_diff_inspector 非シャーディング シャーディング
63. ②本番移行
64. © 2025 AltPlus Inc. TiDB移行に必要なタスクについて 64 • tidb-manager環境構築 ◦ dumpling ▪ パラメータ設定 ◦ sync_diff_inspector ▪ TOML設定 • TiDB Cloud Dedicated作成 ◦ テーブル作成 ◦ ユーザー作成 • PrivateLink作成 • TiDB CloudのS3アクセス設定 • mysql_config_editor設定 • データ整合性チェック ◦ sync_diff_inspector • エクスポート実行 ◦ Dumpling • インポート実行 ◦ TiDB Cloudコンソール 青：本番移行前に実施可能、赤：本番移行時
65. © 2025 AltPlus Inc. TiDB Cloudへの移行：②本番移行 65 prod-altplus（987654321000） 本番移行前に実施可能な環境を構築 tiup dumpling TiDB Cloud コンソール ：Import tidb cloudd db_admin db_user sync_diff_inspector env テーブル定義
66. © 2025 AltPlus Inc. TiDB Cloudへの移行：②本番移行 66 prod-altplus（987654321000） snapshotから復元してリハーサル環境を構築 tiup dumpling TiDB Cloud コンソール ：Import tidb cloudd db_admin db_user sync_diff_inspector db_admin db_user_01 db_user_02 db_user_03 snapshotから復元
67. © 2025 AltPlus Inc. TiDB Cloudへの移行：②本番移行 67 特にsync_diff_inspectorはカラム単位での 比較となるため処理に時間がかかる 事前実施でメンテナンス時間を短縮 メンテナンス直前の比較で問題なければ本番も問題なしと判断可能
68. © 2025 AltPlus Inc. TiDB Cloudへの移行：②本番移行 68 移行PJ始動 リハーサル 環境構築 DEV環境 の手順を確立 QA環境 の手順を確立 STG環境 の手順を確立 REV環境 の手順を確立 本番を想定したリハーサルを行うためにも、 各環境での手順を先に固めてからリハーサルに臨みました！！
69. © 2025 AltPlus Inc. TiDB Cloudへの移行：②本番移行 69 リハーサル 環境構築 本番移行 本番環境 の手順を確立 時間計測 時間計測＋ 問題ないこと 時間計測＋ 問題ないこと リハーサルで処理時間を計測し、問題が発生しないことを確認 「再現性のあるリハーサル」を実施したおかげで、 本番移行も無事問題なく完了することができました！！
70. 移行後について
71. ①移行直後のドタバタ劇
72. © 2025 AltPlus Inc. 移行後について：①移行後のドタバタ劇 72 リリース後に負荷高騰でユーザー からの問い合わせが殺到！！ 移行直後に発生したトラブル — スパイクアクセス
73. © 2025 AltPlus Inc. ①移行後のドタバタ劇：移行直後に発生したトラブル — スパイクアクセス 73 リリース10分後、 プレゼント機能へのアクセスが一気に集中。 結果的にはEBSのIOPS上限に張り付き、 応答が一時的に悪化しました。
74. © 2025 AltPlus Inc. ①移行後のドタバタ劇：移行直後に発生したトラブル — スパイクアクセス 74 原因 一次対応 プレゼント機能のレンジスキャン 二次対応 TiKVのスケールアウトで対応 書き込みのスケールは「NewSQLの強み」 必要な件数（200件）のみを対象に スキャンするよう最適化
75. © 2025 AltPlus Inc. ①移行後のドタバタ劇：移行直後に発生したトラブル — スパイクアクセス 75 リリース直後の負荷もTiKVの スケールアウトで回避！！ その後はユーザー影響なく、 安定運用継続！！
76. © 2025 AltPlus Inc. 移行後について：①移行後のドタバタ劇 76 移行翌日のトラブル — スケール戦略の誤判断 予定外のスケールインの調整も、 ユーザー流入直前で停止！！
77. © 2025 AltPlus Inc. ①移行後のドタバタ劇：移行翌日のトラブル — スケール戦略の誤判断 77 少しでもコストカットができればと考えて 前日増やしたTiKVをスケールインしました。 結果的にはユーザー流入前にPingCAPさんに スケールインを一時停止いただきました💦
78. © 2025 AltPlus Inc. ①移行後のドタバタ劇：移行翌日のトラブル — スケール戦略の誤判断 78 時間 このあたりで スケールイン開始 このあたりで スケールイン完了（予測） このあたりで スケールアウト開始 ユーザーの流入前にスケールインが完了するので 流入前のタイミングでスケールアウトしよう！！ 当初の予定 このあたりから徐々に ユーザーが流入
79. © 2025 AltPlus Inc. ①移行後のドタバタ劇：移行翌日のトラブル — スケール戦略の誤判断 79 時間 このペースだとユーザーの流入前に スケールインが終わらなそうだ。。。 このあたりで スケールイン開始 スケールインの終了が予想と違うかもと焦りが・・・ 現実① このあたりで スケールイン完了しそう このあたりから徐々に ユーザーが流入
80. © 2025 AltPlus Inc. ①移行後のドタバタ劇：移行翌日のトラブル — スケール戦略の誤判断 80 時間 現実② このあたりで スケールイン開始 PingCAPさんに助けを求めました😭 その結果スケールインが止まりました！！ PingCAPさんにヘルプ要請！！ スケールイン停止 祈りタイム このあたりから徐々に ユーザーが流入
81. © 2025 AltPlus Inc. 81 ①移行後のドタバタ劇：移行翌日のトラブル — スケール戦略の誤判断 Regionの移動を途中で停止する LeaderのRegionが均等に分散されない状態 リソース使用に偏りが発生する
82. © 2025 AltPlus Inc. 82 ①移行後のドタバタ劇：移行翌日のトラブル — スケール戦略の誤判断 Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region Region tikv-0 tikv-1 tikv-2 tikv-3 tikv-4 tikv-5 tikv0-2に負荷が集中する 移動を停止中 tikv3-5はサポートのみ
83. © 2025 AltPlus Inc. ①移行後のドタバタ劇：移行翌日のトラブル — スケール戦略の誤判断 83 原因 一次対応 コストカットを意識し過ぎて予定外の スケールインを実施 二次対応 PingCAPさんがスケールイン停止の対応 ユーザー影響なしで回避 ピークタイムが過ぎた深夜0時過ぎに スケールインを再開（PingCAPさん）
84. © 2025 AltPlus Inc. 移行後について：①移行後のドタバタ劇 84 PingCAPさんのサポートのおかげで ユーザー影響なしで回避！！ サポートのありがたみを 改めて実感しました！！
85. ②TiDB Cloud APIでの自動化
86. © 2025 AltPlus Inc. 移行後について：②TiDB Cloud APIでの自動化 86 TiDB Cloud API（β版）を使用した 自動化を行いました！！ TiDB Cloud Dedicatedの操作をコンソールを 介さず実行できるためとても便利です！！
87. © 2025 AltPlus Inc. 移行後について：②TiDB Cloud APIでの自動化 87 • REST形式で提供されるAPI ◦ コンソールの主要操作をコードで実行可能 • 主要な操作 ◦ クラスターの作成・削除 ◦ スケーリング ◦ バックアップおよびリストア ◦ インポート（Physical） TiDB Cloud APIの特徴
88. © 2025 AltPlus Inc. 移行後について：②TiDB Cloud APIでの自動化 88 • API Key ◦ TiDB Cloudコンソールから作成 ▪ キーの管理はParameter Storeなど • スクリプトの準備 ◦ ドキュメントを確認して実装する ▪ パラメータはJSON 準備するもの https://docs.pingcap.com/ja/tidbcloud/api-overview/
89. © 2025 AltPlus Inc. 移行後について：②TiDB Cloud APIでの自動化 89 tidb cloud　 スケールアウトの例 db_admin db_user prod-altplus（987654321000） Amazon EventBridge Scheduler Lambda function AWS Lambda AWS Systems Manager Parameter Store cluster-modify.py アクティブユーザーの 流入に合わせて起動 APIキー取得 API実行 スケールアウト TiDB=5 TiKV=9
90. © 2025 AltPlus Inc. 移行後について：②TiDB Cloud APIでの自動化 90 • スケールアウトはアクティブな時間帯の直前で実行 • スケールインはバックアップ後に実行（念の為） 時間 アクティブな時間帯 　　非アクティブな時間帯 非アクティブな時間帯 バ ッ ク ア ッ プ Modifying Active Modifying Active スケールインAPI実行 スケールアウトAPI実行 リバランス オルトプラスでの運用例（毎日実行：TiKV） ピークタイム
91. ③自動化がメンテナンスと干渉しないために
92. © 2025 AltPlus Inc. 移行後について：③自動化がメンテナンスと干渉しないために 92 TiDB Cloudはメンテナンスウィンドウがあり、 自動化の設定によっては「意図しない接続断」 につながるケースがあります。 そのため、APIなどで自動化する場合は メンテナンスとの干渉を避ける工夫が必要です。
93. © 2025 AltPlus Inc. 移行後について：③自動化がメンテナンスと干渉しないために 93 • クラスター操作（変更/一時停止/再開） • セキュリティ設定の変更 • PrivateLink/VPC Peeringの作成 • インポート/移行ジョブ/Changefeedの作成 • 移行ジョブ/Changefeedのスケール変更 メンテナンス期間中に許可されない操作 https://docs.pingcap.com/ja/tidbcloud/configure-maintenance-window/
94. © 2025 AltPlus Inc. 移行後について：③自動化がメンテナンスと干渉しないために 94 時間 アクティブな時間帯 　　非アクティブな時間帯 スケールアウト スケールイン 例えば、スケールイン時にメンテナンス実施すると、 スケールイン後にメンテナンスが実施される ブロック メンテナンス実施 メンテナンスウィンドウのスケジュール 影響は最小限でも一時的な接続中断は発生する可能性がある ユーザー影響が あるかもしれない
95. © 2025 AltPlus Inc. 移行後について：③自動化がメンテナンスと干渉しないために 95 • メンテナンス期間の開始2週間前 ◦ 緊急メンテナンスタスクを除く • メンテナンスウィンドウが開始する72時間前 • メンテナンスウィンドウが開始される時間 • メンテナンスウィンドウが完了した時間 メンテナンスウィンドウの通知をメールで確認する メールだけでは気づきにくいためSlackやPagerDutyでの可視化を推奨
96. © 2025 AltPlus Inc. 移行後について：③自動化がメンテナンスと干渉しないために 96 時間 アクティブな時間帯 　　非アクティブな時間帯 スケールアウト スケールイン メンテナンス実施後にスケールインを実施することで、 ユーザー影響がない運用が可能となる メンテナンス実施 メンテナンスウィンドウのスケジュール スケジュールを メンテナンス後に変更 「メンテナンス後に実行する」工夫で安定運用につながります！！
97. © 2025 AltPlus Inc. まとめ 97 • NewSQLの観点からTiDB Cloud刷新の意義を整理 • 移行の手順と移行に使用したツールを紹介 • 移行後のトラブル対応と運用改善について共有
101. もっとTiDBを活用して、 NewSQLの力で楽をしましょうーー！！ ご清聴ありがとうございました