太りすぎコアモデルのダイエット作戦（減量編） / railstokyo-03-lmi

リンクアンドモチベーション登壇資料（2026/02/19）

#railstokyo_meetup #リンモチ

===========================================
【イベント情報】
■イベントページ
https://railstokyo.connpass.com/event/378921/
【株式会社リンクアンドモチベーション】
■お問合せ先
　engineer_pr@lmi.ne.jp
■テックブログ
　https://link-and-motivation.hatenablog.com/
■開発組織の公式X
　https://x.com/LinkandM_dev
=============================================

Transcript

1. 太りすぎコアモデルの ダイエット作戦（減量編） 中﨑 健太 — Rails Tokyo #3 コアテーブルを無停止で垂直分割した実践 © Link and Motivation Group
2. 自己紹介 中﨑 健太 株式会社リンクアンドモチベーション プロダクトデザイン室　エンゲージメントプロダクトユニット バックエンドエンジニア © Link and Motivation Group 2
3. 会社紹介 創業年月日 ｜ 2000年4月7日 上場市場 ｜ 東京証券取引所 プライム市場 従業員数 ｜ 約1,500名（グループ全体） 売上 ｜ 374億（グループ全体）※2024年12月期 事業内容 ｜ 組織改善クラウドの開発・提供 © Link and Motivation Group 3
4. ゴール: テーブルの垂直分割 Before App read / write results 集計軸 + 結果 After App 結果 集計軸 results (結果) segments (集計軸) 前回「決意編」でコアテーブル分割を決意 results (集計軸+結果) → results (結果) + segments (集計軸) に分離したい © Link and Motivation Group 4
5. テーブル分割の一般的な手順の例 直列でやるとこうなる: 1. 新テーブルを作成 2. 計画停止（メンテナンスモード） 3. 既存データを新テーブルへ一括コピー 4. アプリコードの参照先・書き込み先を一括変更してデプロイ 5. メンテナンス解除 6. 旧テーブルから移行済みカラムを削除 → すべて直列。前のステップが終わらないと次に進めない。 © Link and Motivation Group 5
6. 直列移行の課題 計画停止が必要 一括データコピー中の不整合を防ぐため、書き込みを止める必要がある データ移行がクリティカルパスになる コピー完了まで、コード変更に着手できない ビッグバンリリースになる 参照先・書き込み先の変更を一度にデプロイする必要がある 切り戻しが困難 データ移動済み + コード変更済みの状態から戻すのは大変 © Link and Motivation Group 6
7. 我々のPJTで重視したこと 安全に進められること 切り戻しができる （不可逆なデータ・スキーマ変更はなるべく 避けたい） 変更差分を小さく、段階的にデプロイしたい （障害リスクを抑えるため） 並行しながら進められること データ移行がクリティカルパスにならないこ と （参照先の変更だけで100ファイル以上。 最も時間がかかる作業を早く始めたかった） © Link and Motivation Group 7
8. 解決策: 論理VIEWを挟む VIEW = 仮想テーブル（元テーブルへのSELECTに名前をつけたもの） データ移動なしで新テーブル名を使い始められる 計画停止 → 不要（全工程を無停止で実施） クリティカルパス → 解消（VIEW作成後すぐコード変更開始） ビッグバン → 回避（PR単位で段階リリース可能） 切り戻し → 簡単（RENAME TABLEで入替/戻し） © Link and Motivation Group 8
9. VIEWを使った移行の全体像 1. 論理VIEW segments を作成 ・分割元の results から集計軸に関わるカラムに絞ったVIEWを作成 2. データの参照先を segments （VIEW）に変更 3. データの移行（ tmp_segments テーブルを作成） a. 新規データを tmp_segments にも反映（frontfill） b. 既存データの移行（backfill） 4. データ監視 — tmp_segments と results の集計軸カラムの完全一致を確認 5. テーブルSWAP — RENAME TABLE で VIEW TABLE を入替 6. お掃除 — 旧VIEW削除 / 旧カラム削除 / sync解除 → 2と3を並行して複数人で進められる © Link and Motivation Group 9
10. SWAP前後のデータフロー Before SWAP App read (集計軸) segments (VIEW) 参照 results App write results sync tmp_segments (TABLE) RENAME TABLE で⼊れ替え segments (VIEW) ↔ tmp_segments (TABLE) After SWAP App read (集計軸) segments (TABLE に昇格) App write results sync アプリコードの変更なし © Link and Motivation Group 10
11. ぶつかった壁・注意点 VIEWの書き込み制約 複雑なVIEW（JOINやサブクエリ）は書き込み不可。単一テーブルのマッピングならOK 2テーブル間のID一致が前提 results.id == tmp_segments.id の対応をSWAPまで維持する必要があった Rails固有の注意点 primary_key 指定が必要 / schema.rb にVIEW非記載（許容） © Link and Motivation Group 11
12. VIEWで実現①: 安全に進められた Readが常に正しい VIEWは元テーブルを直接参照 → データの齟齬が原理的に発生しない 段階リリースできた 安心してPR単位で参照先を変更できる。ビッグバンにならない 切り戻しが簡単 最終切替は RENAME TABLE （metadata操作のみ、アトミックに入替） © Link and Motivation Group 12
13. VIEWで実現②: 並行で進められた VIEWがあるから、参照変更とデータ移行を並行して進められた 時間 データ参照先の変更 複数⼈ + AI で並⾏実施 書き込み先の変更（frontfill） 1⼈で実装 既存データの移⾏（backfill） 別の1⼈が担当 並 ⾏ データ移行がクリティカルパスから外れた © Link and Motivation Group 13
14. まとめ — VIEWを挟むことで 安全に進められた 段階リリース + アトミックな切り戻し 並行して進められた データ移行がクリティカルパスから外れた © Link and Motivation Group 14
15. まとめ — VIEWを挟むことで 安全に進められた 段階リリース + アトミックな切り戻し 並行して進められた データ移行がクリティカルパスから外れた © Link and Motivation Group 15 テーブルの垂直分割は、論理VIEWから始めてみませんか？
16. 来週、レガシーコードのイベントで登壇します！ © Link and Motivation Group 16
17. 初めてRubyKaigiのスポンサーをします！ © Link and Motivation Group 17
18. Thank you! ご質問はお気軽にどうぞ © Link and Motivation Group 18