Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Managing Database Migrations in Go Backend Systems
Search
Kazuhiko Yamashita
September 16, 2025
Programming
0
77
Managing Database Migrations in Go Backend Systems
https://pepabo.connpass.com/event/363869/
ペパボ & GO 〜 夏のGo祭り2025、あの夏〜でお話しました。
Kazuhiko Yamashita
September 16, 2025
Tweet
Share
More Decks by Kazuhiko Yamashita
See All by Kazuhiko Yamashita
新しい職場の CI が 20 分かかっていたらあなたならどうする?
pyama86
2
1.4k
事業を差別化する技術を生み出す技術
pyama86
4
1.8k
Re:Define 可用性を支える モニタリング、パフォーマンス最適化、そしてセキュリティ
pyama86
9
9k
AI時代におけるSRE、 あるいはエンジニアの生存戦略
pyama86
6
1.8k
Tuning GraphQL on Rails
pyama86
2
2.2k
ttlcacheのここがスゴい
pyama86
1
200
クラウドサービスの 利用コストを削減する技術 - 円安の真南風を感じて -
pyama86
3
660
実践ARMアーキテクチャ移行
pyama86
2
2.6k
リモートワーク時代の守護神 PHP開発者のためのセキュリティ強化術
pyama86
3
1.4k
Other Decks in Programming
See All in Programming
NetworkXとGNNで学ぶグラフデータ分析入門〜複雑な関係性を解き明かすPythonの力〜
mhrtech
3
960
After go func(): Goroutines Through a Beginner’s Eye
97vaibhav
0
220
ててべんす独演会〜Flowの全てを語ります〜
tbsten
1
220
CSC305 Lecture 03
javiergs
PRO
0
230
麻雀点数計算問題生成タスクから学ぶ Single Agentの限界と Agentic Workflowの底力
po3rin
5
2.1k
メモリ不足との戦い〜大量データを扱うアプリでの実践例〜
kwzr
1
760
大規模アプリのDIフレームワーク刷新戦略 ~過去最大規模の並行開発を止めずにアプリ全体に導入するまで~
mot_techtalk
0
360
ソフトウェア設計の実践的な考え方
masuda220
PRO
3
370
GraphQL×Railsアプリのデータベース負荷分散 - 月間3,000万人利用サービスを無停止で
koxya
1
1k
私はどうやって技術力を上げたのか
yusukebe
43
17k
私達はmodernize packageに夢を見るか feat. go/analysis, go/ast / Go Conference 2025
kaorumuta
2
460
Go Conference 2025: Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する
takehaya
7
1.5k
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
54
3k
The Pragmatic Product Professional
lauravandoore
36
6.9k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
For a Future-Friendly Web
brad_frost
180
9.9k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
51k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Gamification - CAS2011
davidbonilla
81
5.5k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
Become a Pro
speakerdeck
PRO
29
5.5k
Building an army of robots
kneath
306
46k
Raft: Consensus for Rubyists
vanstee
139
7.1k
Transcript
Managing Database Migrations in Go Backend Systems 2025.09.16 P山@GO株式会社
© GO Inc. 2 GO株式会社 山下 和彦 所属 開発本部 ソフトウェア開発統括部
バックエンド開発部 バックエンド1グループ @pyama86
© GO Inc. 3 旧来のバックエンドチームのDBマイグレーション 1. sqldefを利用しているリポジトリに変更内容をPR 2. レビュー後マージ 3.
開発環境は即時PR作成者が適用 4. 週に1回リリース担当のチームが変更を本番に適用
© 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)
© GO Inc. 5 十分に解決されていないこと 1. sqldefを利用しているリポジトリに変更内容をPR 2. レビュー後マージ 3.
開発環境は即時PR作成者が適用 4. 週に1回リリース担当のチームが変更を本番に適用
© GO Inc. 6 開発環境は即時PR作成者が適用 手順がそれなりにあり、トイルになっていた 1. bastionサーバにログイン(堅牢なログイン=手間) 2. 作業が重複しないように部全体に周知
3. 開発環境とQA環境へsqldefを実行
© GO Inc. 7 十分に解決されていないこと 1. sqldefを利用しているリポジトリに変更内容をPR 2. レビュー後マージ 3.
開発環境は即時PR作成者が適用 4. 週に1回リリース担当のチームが変更を本番に適用
© GO Inc. 8 週に1回リリース担当のチームが変更を本番に適用 変更を行いたい人と作業者が異なるのとMySQLの特性 1. MySQLのレプリケーションは ALTERで詰まる※ 2.
変更対象のテーブルの 件数が多い=ALTERが長期化する 3. 作業者がテーブルの行数を 確認する必要がある ※INSTANT DDLであれば高速に完了します
© 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によるレプリケーション遅延をコントロールして スキーマ・マイグレーションを行うソフトウェア
© GO Inc. 10 運用課題を解決するalterguard作った 1. sqldefのDryRunの結果を食わせると、テーブルの行数に 応じてALTER実行するか、pt-oscするか自動で決定して実行 2. DryRunやSlack通知を備えており、自動化に特化
3. テーブルのリネームやクリーンアップも対応 a. リネーム時に新旧のテーブル行数を精査 b. 成功時のクリーンアップだけじゃなく、失敗時の クリーンアップも対応 https://github.com/pyama86/alterguard/
© GO Inc. 11 alterguardの実行風景 Slack通知でオペレーション 内容がわかるし、 かかった時間や行数も 通知することで影響がわかる
© GO Inc. 12 現在のバックエンドチームのDBマイグレーション 1. sqldefを利用しているリポジトリに変更内容をPR 2. レビュー後マージ 3.
GitHub Actionsから開発環境、QA環境に自動適用 4. 週に1回リリース担当がGitHub Actionsをキック a. 本番はDryRunの後にActionsのApproveも必須
© GO Inc. 13 残っている課題 1. pt-oscは銀の弾丸ではなく、メタデータロックを 取るのと、コピー時にレコードをロックするため、 状況によってはオンライン処理のトランザクションが 失敗したりする
2. 交通インフラは高い可用性が求められるため、タクシーの 注文に重要なテーブルは深夜に適用している →運用枯れてきたら深夜に自動実行するかも?
© GO Inc. 14 最後に 1. トイルをなくすために、ソフトウェア作った 2. pt-osc便利だけど、それでも様々あるね 3.
GO、ベンチャーから会社の規模が大きくなるタイミングで 必要になる、仕組みで解決する仕事がたくさんある
© GO Inc. 日本のモビリティ、ほんとに良くしたいし、最近はそういう意識でデススト やってます 15 私たちと一緒に 未来を作っていきませんか?