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

次世代DB戦略を支えるNewSQL 〜導入企業が語る導入背景と今後の展望〜の登壇資料です
https://findy-tools.connpass.com/event/343774/

19:35〜「苦しいTiDBへの移行を乗り越えて快適な運用を目指す」レバテック株式会社　金澤伸行

Transcript

1. 苦しいTiDBへの移行を乗り越 えて快適な運用を目指す 金澤 伸行
2. |　© 2024 Levtech Co., Ltd. 2 レバテックSRE 金澤 伸行 NOBUYUKI KANAZAWA 社内での経歴 • 2022年9月〜　社内業務システム開発 • 2023年3月〜　EmbeddedSREと兼任開始 • 2023年9月〜　レバテックSREチーム発足 サイクリングとドライブが好きです 下手だけどゴルフもやってます
3. |　© 2024 Levtech Co., Ltd. 3 • レバテックについて • 理想の状態 • 移行前の課題 • TiDBで解決する課題 • 移行の辛い点 • まとめ • ちょっとだけ宣伝 目次 Index
4. レバテックについて
5. |　© 2024 Levtech Co., Ltd. 5 事業ポートフォリオ レバテックについて エージェント プログラミング スクール コンテンツ メディア プラット フォーム ダイレクト リクルーティング ITエンジニア・クリエイターの フリーランス・転職・就職・教育の すべてを備える採用プラットフォーム エージェントを中心に、求人媒体、 プログラミング教育まで IT専門職のキャリアを厚くサポート。
6. 理想の状態
7. |　© 2024 Levtech Co., Ltd. 7 開発チーム • 自分たちのシステムに関する部分にのみ注力できる ◦ 各テーブルの管理 ◦ クエリチューニング等のパフォーマンス管理 ◦ メトリクス • リアーキテクトや新規開発に注力できる状態 ◦ バージョンアップのためのメンテナンス等の運用負担を軽減 目指すべき姿 理想の状態
8. |　© 2024 Levtech Co., Ltd. 8 SRE • 全体のリソース管理 ◦ コスト ◦ ユーザーと権限 ◦ メトリクス • 全体のリソース管理をスコープとし、DB以外の改善や施策に着手できるよ うたい 目指すべき姿 理想の状態
9. |　© 2024 Levtech Co., Ltd. 9 共通 • DB専任チームがなくてもそれぞれの責任範囲の中で対応できる状態 目指すべき姿 理想の状態
10. 移行前の課題
11. |　© 2024 Levtech Co., Ltd. 11 新しいシステムの開発と並行してレガシーシステムからの脱却のために • リアーキテクト • マイクロサービス化 が進んでおり管理するシステムの数が増加していた 前提 移行前の課題
12. |　© 2024 Levtech Co., Ltd. 12 そしてシステムの数だけAuroraのクラスターが作成されていった 前提 移行前の課題
13. |　© 2024 Levtech Co., Ltd. 13 クラスター数が増加することで • 用途に応じたインスタンスタイプの選定 ◦ RI含む • メトリクス確認 • バージョンアップ対応 • コスト確認 などの管理コストが増加 管理コスト 移行前の課題
14. |　© 2024 Levtech Co., Ltd. 14 リアーキテクトの目処が経つまで、システム間の依存関係の複雑さが解 消できない メンテナンスの調整コスト 移行前の課題
15. |　© 2024 Levtech Co., Ltd. 15 ひとつのDBのバージョンアップをするのに複数のシステムをメンテナン ス状態にしないといけないケースが多い • 対象が多くまとめて同日に対応が難しい • 各サービスの施策との調整も必要 • 日程調整のハードルが高い メンテナンスの調整コスト 移行前の課題
16. |　© 2024 Levtech Co., Ltd. 16 DBの運用にかかる工数を減らしたい • 開発チームとSRE間での確認/調整を減らす • 分担が明確にできている状態 メンテナンスの回数は減らしたい、なくしたい • ユーザー影響を可能な限りなくしたい • 開発者体験の改善 解決したいこと 移行前の課題
17. |　© 2024 Levtech Co., Ltd. 17 課題解決のためにできることを考える・・・ • SRE以外で専任のDBを管理するチームを作る？ • リアーキテクトの体制の見直し？ ◦ 依存関係の複雑さを急いで解消する • DB自体の管理方法を見直す？ どうやって解決するか？ 移行前の課題
18. |　© 2024 Levtech Co., Ltd. 18 Aurora MySQL 2から３へのバージョンアップを検討していたが、メンテ ナンスコストが高いことを言い訳に、進められていなかった Aurora MySQLのバージョンアップどうする 移行前の課題
19. |　© 2024 Levtech Co., Ltd. 19 新たにRIを買えば、基本的に次の期限までAuroraのまま運用することに なる RIも期限が切れる 移行前の課題
20. |　© 2024 Levtech Co., Ltd. 20 課題解決のためにできることを考える・・・ • SRE以外で専任のDBを管理するチームを作る？ • リアーキテクトの体制の見直し？ ◦ 依存関係の複雑さを急いで解消する • DB自体の管理方法を見直す？ どうやって解決するか？ 移行前の課題
21. TiDBの選定理由と解決する課題
22. |　© 2024 Levtech Co., Ltd. 22 選定理由①ゼロダウンタイムの実現 TiDBの選定理由と解決する課題 引用：https://docs.pingcap.com/ja/tidb/stable/tidb-architecture
23. |　© 2024 Levtech Co., Ltd. 23 選定理由①ゼロダウンタイムの実現 TiDBの選定理由と解決する課題 ①Leaderを切り替えながら1台ず つ入れ替わる ②Leaderを切り替えながら1台ずつ入れ替わる ・処理中のリクエストが完了するのを待機 ・処理が中断された場合もTiDBでリトライするため クライアントに影響はない ③TiDBが1台ずつLBターゲット から外れてアップデート 引用：https://docs.pingcap.com/ja/tidb/stable/tidb-architecture
24. |　© 2024 Levtech Co., Ltd. 24 選定理由①ゼロダウンタイムの実現 TiDBの選定理由と解決する課題 ①Leaderを切り替えながら1台ず つ入れ替わる ②Leaderを切り替えながら1台ずつ入れ替わる ・処理中のリクエストが完了するのを待機 ・処理が中断された場合もTiDBでリトライするため クライアントに影響はない ③TiDBが1台ずつLBターゲット から外れてアップデート 引用：https://docs.pingcap.com/ja/tidb/stable/tidb-architecture ※デフォルト設定の場合瞬断の可能性がある ※詳しくはTiProxyを参照
25. |　© 2024 Levtech Co., Ltd. 25 ResourceGroupという単位で • 選択されたユーザーが • どの程度のリソースを使えるか（RuPerSec） を管理する事が可能 この機能により、同一クラスター内にスキーマを集約しても特定のシステムによるリ ソースの食い潰しを回避できる 選定理由②クラスターの一元管理 TiDBの選定理由と解決する課題
26. |　© 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
27. |　© 2024 Levtech Co., Ltd. 27 ユーザーとResourceGroupのコード管理 • SRE ◦ リソースの割当 ◦ 各ユーザーの権限管理 ◦ スキーマ管理 • 開発チーム ◦ マイグレーションによるテーブル管理等 選定理由②クラスターの一元管理 TiDBの選定理由と解決する課題
28. |　© 2024 Levtech Co., Ltd. 28 SpannerなどPostgreSQL互換が多い印象 しかしレバテックでは移行のハードルを上げたくなかったためMySQL互換である ことが求められた 選定理由③MySQL互換 TiDBの選定理由と解決する課題
29. |　© 2024 Levtech Co., Ltd. 29 • バージョンアップやリソースの追加、スペックの変更が容易に実施可能に • SREと開発チームの責任範囲の明確になる 解決できること TiDBの選定理由と解決する課題
30. 移行の辛い点
31. |　© 2024 Levtech Co., Ltd. 31 AWS DMSを採用 • クラスターを集約するにあたってスキーマの命名が衝突するケースが存在した • TiDBのDMSではスキーマ名の変更ができないためAWS DMSを採用 テーブル定義などは最低限しか連携されない • 事前にスキーマとテーブルは作成する必要がある • 各制約などは引き継がれない AWS DMSによるレプリケーション 移行の辛い点
32. |　© 2024 Levtech Co., Ltd. 32 LOBデータの取り込み時はImportのモードが変わる • 接続属性で外部キー制約の無効化しても設定が無視されてしまう • LOBデータのカラムにNOT NULL制約がついているとエラーになる Import可能な状態のDDLの作成、差分確認、差分を埋めるクエリの作成スクリプト を内製化して対応 AWS DMSによるレプリケーション 移行の辛い点
33. |　© 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
34. |　© 2024 Levtech Co., Ltd. 34 RUの調整 移行の辛い点 全然予測できない
35. |　© 2024 Levtech Co., Ltd. 35 基本は • RUの設定値を大きめ、ないしはバースト可能にして移行 • その後実際に利用しているRUを確認して調整 の形で対応 現在はクラスター全体のメトリクスが安定しているので問題は発生していない RUの調整 移行の辛い点
36. |　© 2024 Levtech Co., Ltd. 36 AutoIncrementが連番ではなくなる • レガシーシステムの場合、PrimaryKeyで順番を制御していたり・・・ • パフォーマンス悪化を許容すればテーブル単位で連番発行可能 ロック、外部キー制約 • 排他ロックしかない • ※共有ロックは実装される予定とのこと 分散DBへの移行に伴う苦労 移行の辛い点
37. |　© 2024 Levtech Co., Ltd. 37 今後DB関連でメンテナンスが不要になるなら頑張れる・・・！！ 移行のためにはメンテナンスが必要 移行の辛い点
38. まとめ
39. |　© 2024 Levtech Co., Ltd. 39 未来は明るい • 移行中にTiDBのバージョンアップをしたがゼロダウンタイムを実現できた • TiFlashの活用を進めて分析基盤としても利用できるようにしていきたい • DB管理以外の開発部の課題解決に注力する 移行は辛い • DDLの作成や差分チェックはスクリプト化して可能な限り移行作業を自動化 • メンテナンスのハードルはこれから楽になる未来を想像して乗り越える まとめ まとめ
40. ちょっとだけ宣伝
41. |　© 2024 Levtech Co., Ltd. 41 技術広報 ちょっとだけ宣伝 カンファレンススポンサー や テックブログ に力を入れてます！ 　もフォローしてね！ etc.
42. |　© 2024 Levtech Co., Ltd. 42 テックブログに力を入れています！※ 平均15本/月の記事を公開中 ちょっとだけ宣伝 テックブログURL