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?

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 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

Slide 3

Slide 3 text

© 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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© 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

Slide 9

Slide 9 text

© 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向けの軽量なツールといった印象

Slide 10

Slide 10 text

© 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向けのツールといった印象

Slide 11

Slide 11 text

© NTT Communications Corporation All Rights Reserved. 11 検討したツール・方法の比較 • golang-migrate ＋ Atlasの組み合わせ • 特徴 • golang-migrateとAtlasの良さの良いとこ取りが可能 • マイグレ/ロールバックのやりやすさ（ golang-migrate ） • マイグレーションのためのSQL文の自動生成 & 宣言的方式による現在のDBの構造の把握のしやすさ（ Atlas ）総評 golang-migrateとAtlasの良いとこ取りが可能ただし１つだけでなく2つのツールの使い方を覚える必要があり、認知負荷は高い

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 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の構造がわかるのがメリット

Slide 14

Slide 14 text

© 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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© NTT Communications Corporation All Rights Reserved. 16 採用してみた結果（まさかのオチ） • DBマイグレーションに用いるツールの選定を行ったが、そもそもツール自体導入する必要はなかったのではないか？ • 1テーブルしかない小規模なDBのスキーマ変更でツールを導入するにはtoo match、手動でも良かった • 機能開発の目的・ユーザーに届けたいものを意識して、どこについて考えるべきか絞るべきだった • DBマイグレ方式考える際に、それを考える時間と費用対効果を考えるべきだったが、それを考慮してなかった • 「全体に抜け漏れなく、シンプルに、 etc. 」とずっと考えてると新機能リリースまでに時間がかかってしまう • ただしこれはDBマイグレーションツールを導入してから一ヶ月しか経過してない状態での振り返り…

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© NTT Communications Corporation All Rights Reserved. 18 真：採用してみた結果 DBマイグレーションツールを導入し数ヶ月経過後振り返ってみた結果 • 当時の機能開発以外でも他の様々なケースにも活用できているので、簡易なマイグレーションツール導入は有効だった • もし手動作業を採用していた場合、次の作業も「時間がないので手動」を選択した可能性がある • 一度手動で始めた作業を「変える」のは労力がいる • 最初から小さいツールで変更点をコードで管理したことでその選択肢をなくせたというのは効果があった • とはいえ最初は手動/スクリプトによる作業にしてからすこしずつ改善していく方法でもよかったのではないか • ツール選定に時間を使ってしまい、新機能リリースまでの時間が長くなってしまったのは事実

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© NTT Communications Corporation All Rights Reserved. 20 今回のケースを通じて感じた技術選定のポイント・まとめ • 技術選定やアーキテクチャ選定を行う際は、それを考える時間と費用対効果を考え、機能開発の目的・ユーザーに届けたいものを意識してどこについて考えるべきか絞るべき • 「全体に抜け漏れなく、シンプルに、 etc. 」とずっと考えてると新機能リリースまでに時間がかかってしまう • 自動化の類のツールの選定はすぐに効果を実感できないケースがあるのですぐに効果を実感できなくても一喜一憂しないようにすべし • golnag-migrateとAtlas以外にもツールの候補はあったはずなので、候補が複数ある場合は皆で協力して手分けして進めるべし