golang-migrate VS Atlas !? 技術選定のポイントと学び ~DBマイグレーションツール選定の実例を通して~ / golang-migrate vs Atlas ! What is the point of technology selection and what you can learn from the examples of DB migration tool selection?

2025年5月14日の 【技術選定を突き詰める】Online Conference 2025 で発表した「golang-migrate VS Atlas !? 技術選定のポイントと学び ~DBマイグレーションツール選定の実例を通して~」の講演資料です。講演詳細についてはこちらを御覧ください（ https://findy.connpass.com/event/349580/ ）

Transcript

1. © NTT Communications Corporation All Rights Reserved. golang-migrate VS Atlas!? 技術選定のポイントと学び ~DBマイグレーションツール選定の実例を通して~ 2025年05月14日 【技術選定を突き詰める】Online Conferenc​​e 2025 NTTコミュニケーションズ株式会社 松永和也
2. © NTT Communications Corporation All Rights Reserved. 2 自己紹介 Name：松永和也 NTTコミュニケーションズ株式会社でソフトウェアエンジニアやってます 主な仕事： （2022/04~2024/12） 内製CI/CDプラットフォーム Qmonus Value Streamの開発運用・利用導入支援 （2025/01~） ネットワークサービス docomo business RINKの開発運用・CI/CD改善 https://www.ntt.com/business/services/rink.html X： @_mk_net_ mixi2: @mk_net
3. © NTT Communications Corporation All Rights Reserved. 3 今回話すこと 話すこと • 技術選定を実際に行う上で必要な実践的なポイントやマインドの部分 • 上記をDBマイグレーションツール選定の実例を通して話ます 話さないこと • golang-migrateやAtlasなどの技術やツールの詳細の話 • ここら辺の話はまた別の機会に… * 技術選定のより基礎的なマインドの部分に関しては別のイベントで話しているので、興味があればこちらも合わせてご覧ください 実際の業務で行った技術選定を通じて感じた 「君たちはどう技術選定をすべきか」 - 2024年12⽉19⽇ エンジニアの成⻑を応援する忘年LT⼤会2024 https://speakerdeck.com/nttcom/how-you-should-approach-technology-selection-insights-gained-from-actual-technology- selection-in-practice
4. © NTT Communications Corporation All Rights Reserved. 4 Index 1. DBマイグレーションツール選定を行うに至った背景 2. 検討したツール・方法の比較 3. 検討結果 4. 採用してみた結果（まさかのオチ） 5. ？？？ 6. 今回のケースを通じて感じた技術選定のポイント・まとめ
5. © NTT Communications Corporation All Rights Reserved. 5 Index 1. DBマイグレーションツール選定を行うに至った背景 2. 検討したツール・方法の比較 3. 検討結果 4. 採用してみた結果（まさかのオチ） 5. ？？？ 6. 今回のケースを通じて感じた技術選定のポイント・まとめ
6. © NTT Communications Corporation All Rights Reserved. 6 DBマイグレーションツール選定を行うに至った背景 • Qmonus Value Streamのとある新機能を開発していた • そこで新規導入したマイクロサービスのDBのスキーマを変更する最初の機会があった • そこでDBマイグレーションに用いるツールの選定を行った
7. © NTT Communications Corporation All Rights Reserved. 7 Index 1. DBマイグレーションツール選定を行うに至った背景 2. 検討したツール・方法の比較 3. 検討結果 4. 採用してみた結果（まさかのオチ） 5. ？？？ 6. 今回のケースを通じて感じた技術選定のポイント・まとめ
8. © NTT Communications Corporation All Rights Reserved. 8 検討したツール・方法の比較 • 検討したツール・マイグレ方法 • 今回はsqlcの公式ドキュメントで推奨されているマイグレーションツールの一部の中から比較・検討を行いました • （開発にsqlcを用いているため） • 手動 or スクリプトによるマイグレ • golang-migrate • Atlas • golang-migrate ＋ Atlasの組み合わせ * sqlc 公式ドキュメント sqlc Documentation - Modifying the database schema https://docs.sqlc.dev/en/latest/howto/ddl.html
9. © NTT Communications Corporation All Rights Reserved. 9 検討したツール・方法の比較 • golang-migrate（ https://github.com/golang-migrate/migrate ） • 特徴 • Githubのスター数は、sqlcの公式ドキュメントで紹介されているマイグレーションツールの中でも最も多い （2024/11/15時点で15.5K） • 日本語の記事も充実している • マイグレーション/ロールバックの方法について、up/down方式を採用していて、マイグレの手順が簡易的でやりやすい • CLI実行によって、 up/downの２種類の形式のファイルが生成され、それぞれマイグレーション実行用（up）とロールバック用（down） である • マイグレーション/ロールバックの実行は、これらのファイルを以下のコマンド（一部省略）で実行するだけで行うことができる • migrate up 1 --path db/migrations （マイグレーション） • migrate down 1 --path db/migrations（ロールバック） • マイグレーションのためのSQL文は自力で記述する必要がある • 後述のAtlasと比較して、dry-run機能など便利な機能はない • 現在のDBの構造を把握するためには、マイグレーション用のファイルを全て確認する必要がある 総評 あくまでマイグレーションツールとしての最低限の機能のみ実装されている 小規模なDB向けの軽量なツールといった印象
10. © NTT Communications Corporation All Rights Reserved. 10 検討したツール・方法の比較 • Atlas（ https://github.com/ariga/atlas ） • 特徴 • Githubのスター数は、golang-migrateと比較して少ない（2024/11/15時点で6K） • というかそもそもメジャーバージョンが出ていない（2024/11/15時点での最新版は v0.28.2-fcddac3-canary ） • 他の様々なDBマイグレツールと組み合わせて使用することもできる（ent , golang-migrate , goose , etc. ） • 従来までのバージョンによるマイグレーション管理だけでなくDBの理想状態を宣言的に記述することでもスキーマを反映する ことができ、宣言ファイルを見るだけで現在のDBの構造をある程度把握できる • マイグレーションのためのSQL文も自動で生成してくれる • マイグレ実行の機能だけでなく、マイグレーションファイルを検証して破壊的な変更やデータ依存の変更がないか検査してくれ るlint機能などの便利な機能も提供されている • https://atlasgo.io/lint/analyzers • 色々な機能が提供されているが、 Atlas CloudというSaaSにProプラン以上の契約をしないと使えない機能（Test機能など）も存在し、 すべて無料で使えるというわけではない • https://atlasgo.io/features#feature-availability • ツールの特性のせいかロールバック手順が複雑 総評 マイグレーションツールとしての機能だけでなく、その他便利な機能が実装されている 複雑で大規模なDB向けのツールといった印象
11. © NTT Communications Corporation All Rights Reserved. 11 検討したツール・方法の比較 • golang-migrate ＋ Atlasの組み合わせ • 特徴 • golang-migrateとAtlasの良さの良いとこ取りが可能 • マイグレ/ロールバックのやりやすさ（ golang-migrate ） • マイグレーションのためのSQL文の自動生成 & 宣言的方式による現在のDBの構造の把握のしやすさ（ Atlas ） 総評 golang-migrateとAtlasの良いとこ取りが可能 ただし１つだけでなく2つのツールの使い方を覚える必要があり、認知負荷は高い
12. © NTT Communications Corporation All Rights Reserved. 12 Index 1. DBマイグレーションツール選定を行うに至った背景 2. 検討したツール・方法の比較 3. 検討結果 4. 採用してみた結果（まさかのオチ） 5. ？？？ 6. 今回のケースを通じて感じた技術選定のポイント・まとめ
13. © NTT Communications Corporation All Rights Reserved. 13 検討結果 今回のDBマイグレーションの要件 • DBマイグレーション作業の際にマイグレーション/ロールバックの方法がわかりやすいか • 複雑な手順を踏む必要がないか、認知負荷が低い方法で実行可能か • マイグレーション/ロールバックの履歴を後から追いたい • どこまで適用したか、どこから適用したか管理したい • 既存のsqlcを使った開発体験を損なわないか • 「既存のsqlcを使った開発体験」とは？ • そもそもsqlcとは？ • 自分で用意したSQLファイルから構造体やDBへの操作をする関数のコードを自動生成してくれるGoのライブラリ • 最終状態のDBのスキーマ（schema.sql）とDBへの操作のSQL文を定義したquery.sqlからコードを自動生成でき、 schema.sqlを見れば現在のDBの構造がわかるのがメリット
14. © NTT Communications Corporation All Rights Reserved. 14 検討結果 結論 • 今回は「golang-migrate」を採用 • 採用理由 • マイグレーション・ロールバック実行のやり方が簡易的でやりやすい • 手動 or スクリプトによる方法よりもツールによる方法は再現性がある • 利用するツールは一つだけで、認知負荷も低い • バージョン管理方式なので、マイグレーション・ロールバックの履歴は後から追える • 利用するマイグレーションツールに関わらず、現在のDBの構造を確認したいだけなら、pg_dumpコマンドを実行するだけでOK • テーブルが１個しかない今回のDBでは現時点では自分でSQL文を書くのはそこまで負荷ではない • 後でAtlasに乗り換えたい、となった際でもAtlas公式がgolang-migrateをすでに導入している状態からAtlasを導入するやり方 を公式ドキュンメントで案内している • https://atlasgo.io/guides/migration-tools/golang-migrate
15. © NTT Communications Corporation All Rights Reserved. 15 Index 1. DBマイグレーションツール選定を行うに至った背景 2. 検討したツール・方法の比較 3. 検討結果 4. 採用してみた結果（まさかのオチ） 5. ？？？ 6. 今回のケースを通じて感じた技術選定のポイント・まとめ
16. © NTT Communications Corporation All Rights Reserved. 16 採用してみた結果（まさかのオチ） • DBマイグレーションに用いるツールの選定を行ったが、そもそもツール自体導入する必要はなかったの ではないか？ • 1テーブルしかない小規模なDBのスキーマ変更でツールを導入するにはtoo match、手動でも良かった • 機能開発の目的・ユーザーに届けたいものを意識して、どこについて考えるべきか絞るべきだった • DBマイグレ方式考える際に、それを考える時間と費用対効果を考えるべきだったが、それを考慮してなかった • 「全体に抜け漏れなく、シンプルに、 etc. 」とずっと考えてると新機能リリースまでに時間がかかってしまう • ただしこれはDBマイグレーションツールを導入してから一ヶ月しか経過してない状態での振り返り…
17. © NTT Communications Corporation All Rights Reserved. 17 Index 1. DBマイグレーションツール選定を行うに至った背景 2. 検討したツール・方法の比較 3. 検討結果 4. 採用してみた結果（まさかのオチ） 5. ？？？ 真：採用してみた結果 6. 今回のケースを通じて感じた技術選定のポイント・まとめ
18. © NTT Communications Corporation All Rights Reserved. 18 真：採用してみた結果 DBマイグレーションツールを導入し数ヶ月経過後振り返ってみた結果 • 当時の機能開発以外でも他の様々なケースにも活用できているので、簡易なマイグレーションツール導入 は有効だった • もし手動作業を採用していた場合、次の作業も「時間がないので手動」を選択した可能性がある • 一度手動で始めた作業を「変える」のは労力がいる • 最初から小さいツールで変更点をコードで管理したことでその選択肢をなくせたというのは効果があった • とはいえ最初は手動/スクリプトによる作業にしてからすこしずつ改善していく方法でもよかったのでは ないか • ツール選定に時間を使ってしまい、新機能リリースまでの時間が長くなってしまったのは事実
19. © NTT Communications Corporation All Rights Reserved. 19 Index 1. DBマイグレーションツール選定を行うに至った背景 2. 検討したツール・方法の比較 3. 検討結果 4. 採用してみた結果（まさかのオチ） 5. 真：採用してみた結果 6. 今回のケースを通じて感じた技術選定のポイント・まとめ
20. © NTT Communications Corporation All Rights Reserved. 20 今回のケースを通じて感じた技術選定のポイント・まとめ • 技術選定やアーキテクチャ選定を行う際は、それを考える時間と費用対効果を考え、機能開発の目的・ ユーザーに届けたいものを意識してどこについて考えるべきか絞るべき • 「全体に抜け漏れなく、シンプルに、 etc. 」とずっと考えてると新機能リリースまでに時間がかかってしまう • 自動化の類のツールの選定はすぐに効果を実感できないケースがあるのですぐに効果を実感できなくても 一喜一憂しないようにすべし • golnag-migrateとAtlas以外にもツールの候補はあったはずなので、候補が複数ある場合は皆で協力し て手分けして進めるべし
21. © NTT Communications Corporation All Rights Reserved. 21 © NTT Communications Corporation All Rights Reserved. FIN 21 © NTT Communications Corporation All Rights Reserved.