苦しいTiDBへの移行を乗り越えて快適な運用を目指す

Slide 1

Slide 1 text

苦しいTiDBへの移行を乗り越えて快適な運用を目指す金澤伸行

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

レバテックについて

Slide 5

Slide 5 text

Slide 6

Slide 6 text

理想の状態

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

移行前の課題

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

TiDBの選定理由と解決する課題

Slide 22

Slide 22 text

Slide 23

Slide 23 text

|　© 2024 Levtech Co., Ltd. 23 選定理由①ゼロダウンタイムの実現 TiDBの選定理由と解決する課題 ①Leaderを切り替えながら1台ずつ入れ替わる ②Leaderを切り替えながら1台ずつ入れ替わる・処理中のリクエストが完了するのを待機・処理が中断された場合もTiDBでリトライするためクライアントに影響はない ③TiDBが1台ずつLBターゲットから外れてアップデート引用：https://docs.pingcap.com/ja/tidb/stable/tidb-architecture

Slide 24

Slide 24 text

|　© 2024 Levtech Co., Ltd. 24 選定理由①ゼロダウンタイムの実現 TiDBの選定理由と解決する課題 ①Leaderを切り替えながら1台ずつ入れ替わる ②Leaderを切り替えながら1台ずつ入れ替わる・処理中のリクエストが完了するのを待機・処理が中断された場合もTiDBでリトライするためクライアントに影響はない ③TiDBが1台ずつLBターゲットから外れてアップデート引用：https://docs.pingcap.com/ja/tidb/stable/tidb-architecture ※デフォルト設定の場合瞬断の可能性がある ※詳しくはTiProxyを参照

Slide 25

Slide 25 text

Slide 26

Slide 26 text

|　© 2024 Levtech Co., Ltd. 26 選定理由②クラスターの一元管理 TiDBの選定理由と解決する課題 RuPerSec ● 10000 対象ユーザー ● systemA_admin ○ systemA_db ■ ALL PRIVILEGES ● systemA_writer ○ systemA_db ■ INSERT ■ SELECT ■ UPDATE ■ DELETE ● systemA_reader ○ systemA_db ■ SELECT SystemA_Group RuPerSec ● 30000 対象ユーザー ● systemB_admin ○ systemB_db ■ ALL PRIVILEGES ● systemB_writer ○ systemB_db ■ INSERT ■ SELECT ■ UPDATE ■ DELETE ● systemB_reader ○ systemB_db ■ SELECT SystemB_Group TiDB Cluster

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

移行の辛い点

Slide 31

Slide 31 text

|　© 2024 Levtech Co., Ltd. 31 AWS DMSを採用 ● クラスターを集約するにあたってスキーマの命名が衝突するケースが存在した ● TiDBのDMSではスキーマ名の変更ができないためAWS DMSを採用テーブル定義などは最低限しか連携されない ● 事前にスキーマとテーブルは作成する必要がある ● 各制約などは引き継がれない AWS DMSによるレプリケーション移行の辛い点

Slide 32

Slide 32 text

|　© 2024 Levtech Co., Ltd. 32 LOBデータの取り込み時はImportのモードが変わる ● 接続属性で外部キー制約の無効化しても設定が無視されてしまう ● LOBデータのカラムにNOT NULL制約がついているとエラーになる Import可能な状態のDDLの作成、差分確認、差分を埋めるクエリの作成スクリプトを内製化して対応 AWS DMSによるレプリケーション移行の辛い点

Slide 33

Slide 33 text

|　© 2024 Levtech Co., Ltd. 33 リソースタイプ RU消費量読む 2 つのstorage読み取りバッチは 1 RU を消費します 8 つのstorage読み取り要求は 1 RU を消費します 64 KiBの読み取り要求ペイロードは 1RUを消費します書く 1 回のstorage書き込みバッチで 1 RU が消費される 1 回のstorage書き込み要求で 1 RU が消費される 1 KiBの書き込み要求ペイロードは 1 RUを消費します CPU 3 ミリ秒で 1 RU を消費 RUの調整移行の辛い点引用：https://docs.pingcap.com/ja/tidb/stable/tidb-resource-control

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

まとめ

Slide 39

Slide 39 text

|　© 2024 Levtech Co., Ltd. 39 未来は明るい ● 移行中にTiDBのバージョンアップをしたがゼロダウンタイムを実現できた ● TiFlashの活用を進めて分析基盤としても利用できるようにしていきたい ● DB管理以外の開発部の課題解決に注力する移行は辛い ● DDLの作成や差分チェックはスクリプト化して可能な限り移行作業を自動化 ● メンテナンスのハードルはこれから楽になる未来を想像して乗り越えるまとめまとめ