Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

Tech Leverages

February 17, 2025
Tweet

More Decks by Tech Leverages

Other Decks in Programming

Transcript

  1. | © 2024 Levtech Co., Ltd. 2 レバテックSRE 金澤 伸行 NOBUYUKI

    KANAZAWA 社内での経歴 • 2022年9月〜 社内業務システム開発 • 2023年3月〜 EmbeddedSREと兼任開始 • 2023年9月〜 レバテックSREチーム発足 サイクリングとドライブが好きです 下手だけどゴルフもやってます
  2. | © 2024 Levtech Co., Ltd. 3 • レバテックについて • 理想の状態

    • 移行前の課題 • TiDBで解決する課題 • 移行の辛い点 • まとめ • ちょっとだけ宣伝 目次 Index
  3. | © 2024 Levtech Co., Ltd. 5 事業ポートフォリオ レバテックについて エージェント プログラミング

    スクール コンテンツ メディア プラット フォーム ダイレクト リクルーティング ITエンジニア・クリエイターの フリーランス・転職・就職・教育の すべてを備える採用プラットフォーム エージェントを中心に、求人媒体、 プログラミング教育まで IT専門職のキャリアを厚くサポート。
  4. | © 2024 Levtech Co., Ltd. 7 開発チーム • 自分たちのシステムに関する部分にのみ注力できる ◦

    各テーブルの管理 ◦ クエリチューニング等のパフォーマンス管理 ◦ メトリクス • リアーキテクトや新規開発に注力できる状態 ◦ バージョンアップのためのメンテナンス等の運用負担を軽減 目指すべき姿 理想の状態
  5. | © 2024 Levtech Co., Ltd. 8 SRE • 全体のリソース管理 ◦

    コスト ◦ ユーザーと権限 ◦ メトリクス • 全体のリソース管理をスコープとし、DB以外の改善や施策に着手できるよ うたい 目指すべき姿 理想の状態
  6. | © 2024 Levtech Co., Ltd. 11 新しいシステムの開発と並行してレガシーシステムからの脱却のために • リアーキテクト •

    マイクロサービス化 が進んでおり管理するシステムの数が増加していた 前提 移行前の課題
  7. | © 2024 Levtech Co., Ltd. 13 クラスター数が増加することで • 用途に応じたインスタンスタイプの選定 ◦

    RI含む • メトリクス確認 • バージョンアップ対応 • コスト確認 などの管理コストが増加 管理コスト 移行前の課題
  8. | © 2024 Levtech Co., Ltd. 16 DBの運用にかかる工数を減らしたい • 開発チームとSRE間での確認/調整を減らす •

    分担が明確にできている状態 メンテナンスの回数は減らしたい、なくしたい • ユーザー影響を可能な限りなくしたい • 開発者体験の改善 解決したいこと 移行前の課題
  9. | © 2024 Levtech Co., Ltd. 17 課題解決のためにできることを考える・・・ • SRE以外で専任のDBを管理するチームを作る? •

    リアーキテクトの体制の見直し? ◦ 依存関係の複雑さを急いで解消する • DB自体の管理方法を見直す? どうやって解決するか? 移行前の課題
  10. | © 2024 Levtech Co., Ltd. 20 課題解決のためにできることを考える・・・ • SRE以外で専任のDBを管理するチームを作る? •

    リアーキテクトの体制の見直し? ◦ 依存関係の複雑さを急いで解消する • DB自体の管理方法を見直す? どうやって解決するか? 移行前の課題
  11. | © 2024 Levtech Co., Ltd. 23 選定理由①ゼロダウンタイムの実現 TiDBの選定理由と解決する課題 ①Leaderを切り替えながら1台ず つ入れ替わる

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

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

    どの程度のリソースを使えるか(RuPerSec) を管理する事が可能 この機能により、同一クラスター内にスキーマを集約しても特定のシステムによるリ ソースの食い潰しを回避できる 選定理由②クラスターの一元管理 TiDBの選定理由と解決する課題
  14. | © 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
  15. | © 2024 Levtech Co., Ltd. 27 ユーザーとResourceGroupのコード管理 • SRE ◦

    リソースの割当 ◦ 各ユーザーの権限管理 ◦ スキーマ管理 • 開発チーム ◦ マイグレーションによるテーブル管理等 選定理由②クラスターの一元管理 TiDBの選定理由と解決する課題
  16. | © 2024 Levtech Co., Ltd. 31 AWS DMSを採用 • クラスターを集約するにあたってスキーマの命名が衝突するケースが存在した

    • TiDBのDMSではスキーマ名の変更ができないためAWS DMSを採用 テーブル定義などは最低限しか連携されない • 事前にスキーマとテーブルは作成する必要がある • 各制約などは引き継がれない AWS DMSによるレプリケーション 移行の辛い点
  17. | © 2024 Levtech Co., Ltd. 32 LOBデータの取り込み時はImportのモードが変わる • 接続属性で外部キー制約の無効化しても設定が無視されてしまう •

    LOBデータのカラムにNOT NULL制約がついているとエラーになる Import可能な状態のDDLの作成、差分確認、差分を埋めるクエリの作成スクリプト を内製化して対応 AWS DMSによるレプリケーション 移行の辛い点
  18. | © 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
  19. | © 2024 Levtech Co., Ltd. 35 基本は • RUの設定値を大きめ、ないしはバースト可能にして移行 •

    その後実際に利用しているRUを確認して調整 の形で対応 現在はクラスター全体のメトリクスが安定しているので問題は発生していない RUの調整 移行の辛い点
  20. | © 2024 Levtech Co., Ltd. 36 AutoIncrementが連番ではなくなる • レガシーシステムの場合、PrimaryKeyで順番を制御していたり・・・ •

    パフォーマンス悪化を許容すればテーブル単位で連番発行可能 ロック、外部キー制約 • 排他ロックしかない • ※共有ロックは実装される予定とのこと 分散DBへの移行に伴う苦労 移行の辛い点
  21. | © 2024 Levtech Co., Ltd. 39 未来は明るい • 移行中にTiDBのバージョンアップをしたがゼロダウンタイムを実現できた •

    TiFlashの活用を進めて分析基盤としても利用できるようにしていきたい • DB管理以外の開発部の課題解決に注力する 移行は辛い • DDLの作成や差分チェックはスクリプト化して可能な限り移行作業を自動化 • メンテナンスのハードルはこれから楽になる未来を想像して乗り越える まとめ まとめ
  22. | © 2024 Levtech Co., Ltd. 41 技術広報 ちょっとだけ宣伝 カンファレンススポンサー や

    テックブログ に力を入れてます!  もフォローしてね! etc.