Slide 1

Slide 1 text

Managing Database Migrations in Go Backend Systems 2025.09.16 P山@GO株式会社

Slide 2

Slide 2 text

© GO Inc. 2 GO株式会社 山下 和彦 所属 開発本部 ソフトウェア開発統括部  バックエンド開発部   バックエンド1グループ @pyama86

Slide 3

Slide 3 text

© GO Inc. 3 旧来のバックエンドチームのDBマイグレーション 1. sqldefを利用しているリポジトリに変更内容をPR 2. レビュー後マージ 3. 開発環境は即時PR作成者が適用 4. 週に1回リリース担当のチームが変更を本番に適用

Slide 4

Slide 4 text

© GO Inc. 4 sqldef k0kubunさんが開発したSQLで冪等にDBスキーマ管理が できるソフトウェア CREATE TABLE offices ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL, address VARCHAR(255), city VARCHAR(100), phone VARCHAR(50), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); ALTER TABLE `offices` ADD COLUMN `city` VARCHAR(100)

Slide 5

Slide 5 text

© GO Inc. 5 十分に解決されていないこと 1. sqldefを利用しているリポジトリに変更内容をPR 2. レビュー後マージ 3. 開発環境は即時PR作成者が適用 4. 週に1回リリース担当のチームが変更を本番に適用

Slide 6

Slide 6 text

© GO Inc. 6 開発環境は即時PR作成者が適用 手順がそれなりにあり、トイルになっていた 1. bastionサーバにログイン(堅牢なログイン=手間) 2. 作業が重複しないように部全体に周知 3. 開発環境とQA環境へsqldefを実行

Slide 7

Slide 7 text

© GO Inc. 7 十分に解決されていないこと 1. sqldefを利用しているリポジトリに変更内容をPR 2. レビュー後マージ 3. 開発環境は即時PR作成者が適用 4. 週に1回リリース担当のチームが変更を本番に適用

Slide 8

Slide 8 text

© GO Inc. 8 週に1回リリース担当のチームが変更を本番に適用 変更を行いたい人と作業者が異なるのとMySQLの特性 1. MySQLのレプリケーションは ALTERで詰まる※ 2. 変更対象のテーブルの 件数が多い=ALTERが長期化する 3. 作業者がテーブルの行数を 確認する必要がある ※INSTANT DDLであれば高速に完了します

Slide 9

Slide 9 text

© GO Inc. 9 pt-online-schema-change(pt-osc) https://martin-son.github.io/Martin-IT-Blog/mysql/3rd%20party%20tool/pt-osc/2022/08/20/pt-osc-%EC%84%A4%EC%B9%98- %EB%B0%8F-%EC%82%AC%EC%9A%A9%EB%B2%95.htmlより引用 ALTERによるレプリケーション遅延をコントロールして スキーマ・マイグレーションを行うソフトウェア

Slide 10

Slide 10 text

© GO Inc. 10 運用課題を解決するalterguard作った 1. sqldefのDryRunの結果を食わせると、テーブルの行数に 応じてALTER実行するか、pt-oscするか自動で決定して実行 2. DryRunやSlack通知を備えており、自動化に特化 3. テーブルのリネームやクリーンアップも対応 a. リネーム時に新旧のテーブル行数を精査 b. 成功時のクリーンアップだけじゃなく、失敗時の クリーンアップも対応 https://github.com/pyama86/alterguard/

Slide 11

Slide 11 text

© GO Inc. 11 alterguardの実行風景 Slack通知でオペレーション 内容がわかるし、 かかった時間や行数も 通知することで影響がわかる

Slide 12

Slide 12 text

© GO Inc. 12 現在のバックエンドチームのDBマイグレーション 1. sqldefを利用しているリポジトリに変更内容をPR 2. レビュー後マージ 3. GitHub Actionsから開発環境、QA環境に自動適用 4. 週に1回リリース担当がGitHub Actionsをキック a. 本番はDryRunの後にActionsのApproveも必須

Slide 13

Slide 13 text

© GO Inc. 13 残っている課題 1. pt-oscは銀の弾丸ではなく、メタデータロックを 取るのと、コピー時にレコードをロックするため、 状況によってはオンライン処理のトランザクションが 失敗したりする 2. 交通インフラは高い可用性が求められるため、タクシーの 注文に重要なテーブルは深夜に適用している →運用枯れてきたら深夜に自動実行するかも?

Slide 14

Slide 14 text

© GO Inc. 14 最後に 1. トイルをなくすために、ソフトウェア作った 2. pt-osc便利だけど、それでも様々あるね 3. GO、ベンチャーから会社の規模が大きくなるタイミングで 必要になる、仕組みで解決する仕事がたくさんある

Slide 15

Slide 15 text

© GO Inc. 日本のモビリティ、ほんとに良くしたいし、最近はそういう意識でデススト やってます 15 私たちと一緒に 未来を作っていきませんか?