Rubyでのシステム刷新と MySQL近代化

「Rubyでのシステム刷新と
MySQL近代化」
Omotesando.rb #127 でのLT資料です
https://omotesandorb.connpass.com/event/409933/

Transcript

1. Rubyでのシステム刷新と MySQL 近代化 by @Lni_T / ルニ Omotesando.rb #127
2. 自己紹介 Twitter(X) ID: @Lni_T (ルニ) JavaをRubyに移行したり PHPをRubyに移行したり といった サーバ引っ越し業で生計を立てている
3. 2024~2026年のおしごと
5. MedPeer Career 医師の転職をサポート
6. PHP製
7. さらに！ 2007年産まれのサービス！
8. 事情により PHPメンテナが不在に…
9. リニューアル！ 「Rubyにしろ！」
10. つらい
11. つらい Example • レスポンスに最大8秒かかるらしいAPI • 常に売上を0円でINSERTするSQL • 1日数十〜百件流れるSlow Query通知チャンネル
12. ということで本日は
13. 新鮮な苦労話 を、お届け！
14. 今日のおはなし • レガシーシステム刷新におけるデータ移行とDB改善 • これまでの苦労話 • 改善の取り組み • みんな大好き他人の苦労話！
15. システム刷新における データ移行の作戦
16. よくあるデータ移行のケース • 業務データがバラバラ！ → データを再編成しよう！
17. 今回のデータ移行のケース • 1箇所のDBに対してAppやSaaS、外部システムが大集結！ • それぞれの影響範囲は誰も知らない
18. 今回のデータ移行のケース • データ互換性を維持しつつ徐々に改善した方が傷が浅いか…… • 今のDBを立て直そう！
19. データ移行を進める
20. まず何をすべきか…
21. AGENTS.md HUMAN.md
22. 防波堤をつくろう
23. 防波堤をつくろう • とあるテーブル構造の抜粋 bigintじゃない 4バイト入らない 2038年問題
24. 防波堤をつくろう • 人間はコピペでコードを書くのが得意 • AIは現状の設計を維持するのが得意
25. 油断すると レガシーが増殖！
26. 防波堤をつくろう • 人間はコピペでコードを書くのが得意 • AIは現状の設計を維持するのが得意 • 問題が分かり次第、設計ルールを明文化！ • 初歩的な問題は増やさないようにしよう！
27. 防波堤をつくろう • 新規テーブルの追加指針を .claude/rules/ に定義 • 文字コードは utf8mb4 指定 • 主キーはbigint • タイムスタンプ列はdatetime型で • Rails開発ではあまり意識しないせいか、人間も見落としがち。
28. 防波堤をつくろう • 問題が分かっているなら、一括マイグレーションすれば良い？ • 現在稼働中のサービスからの書き込みクエリがある という理由もあるが……
29. 巨大ログテーブル
30. 巨大ログテーブル • どういうテーブルか？ • 特定イベントごとにINSERTされ続けるテーブル • 問題は？
31. DBマイグレーションが 全く終わらない
32. 巨大ログテーブル • どういうテーブルか？ • 特定イベントごとにINSERTされ続けるテーブル • 問題は？ • 長時間マイグレーション • 長いトランザクションに巻き込まれるとMetadata Lock
33. ログテーブルやめよう！
34. 打倒ログテーブル • アプリからログ分析・活用の役割を分離 • 適切なBIツール/CXツールに移行 • • KARTE • DBに溜める場合は蓄積と破棄をセットで実装
35. ところで PARTITION は？
36. DBのパーティショニング • 同一テーブル内で条件を指定して保存領域を分割管理できる • 大きなテーブルでも読み書き削除が高速！ logs 202601 DROP 202602 202603 202604
37. DBのパーティショニング • 残念ながらパーティションが効かない削除SQLが発行されていた • 通常よりも遅い logs 202601 202602 202603 DELETE 202604
38. そして【削除】と言えば…
39. とりあえず削除フラグ
40. 消したことにする
41. fl delete_ ag deleted_at
42. とりあえず削除フラグ • 削除フラグが立っている場合は消えていることにする • WHEREの条件、JOINの条件などで除外 • クエリ・インデックスが複雑化していく……
43. 対策
44. ひとまずscopeで対処 • 生きてるレコードのみ取得するscope • Scoped Associationも便利 • 論理削除済みレコードをJOIN時に除外できたりして便利
45. 物理削除に置き換えていく • Agent「このテーブルには削除フラグがありま • ぼく「いいからDELETEだ！」
46. 不要レコードは Maintenance Task で削除 • https://github.com/Shopify/maintenance_tasks • データのマイグレーションをサポートするツール
47. 他にも苦しみが 盛りだくさん！
48. 使いづらいDB構造… • 今は使われていないカラム • 全て空文字や0で運用 • 逆に情報が足りないテーブル • 登録時の値が欲しいのに正規化されてて引けない
49. 使いづらいDB構造… • ダブルライト（Double Write）で徐々に移行！ • テーブルを新規作成 • 新旧テーブル両方にデータを書き込み • 読み込み側を新テーブルに移行
50. つらかった...
51. Ruby化完了🎉
52. 目立った成果 • トップページのレスポンスが10倍速に • 2s -> 0.2s • Slow Query(5秒over)も 100件/日 → 1件/週に削減
53. 取り組み • レガシーの増殖を防ぐルール定義 • やめよう！ログテーブル • 削除フラグも消せ！ • システムの役割を整理 • ダブルライト(Double Write) でスキーマ整備 & 移行
54. 地味！
55. 地道な努力が大事なのかも…