Slide 1

Slide 1 text

Atlas をプロジェクトに導入してみた話 golang.tokyo #36 2024.08.08

Slide 2

Slide 2 text

自己紹介 Sugar Sato (@satoIsSugar) ● 2023年 BuySell Technologies入社 ● 基盤チーム所属(Portal/Account/Approval) PjM ○ アソシエイトマネージャー ● Go / Angular / Serverless ○ Go歴: 4年くらい ● 熱帯植物 ○ ビカクシダ ● 猫 ○ Lambda (♀ 2才)

Slide 3

Slide 3 text

プロダクト群「バイセルリユースプラットフォーム Cosmos」の開発が進行中 リユースに必要なすべての機能を提供する 「リユースプラットフォーム Cosmos」の開発が進行中です。 Cosmosを活用して、バイセルグループ全体での業務効率改善やデータドリブン経営の深化を目指しています。 リユースプラットフォーム Cosmos 自社開発のリユース特化業務基幹システムでありサービス群の集合体 買取申込 買取・査定 在庫管理 販売 多様なチャネルで収益最大化 CRM -顧客対応- 買取種別に応じた最適なシステム構築 Visit -訪問買取 - Store -店舗買取 - Promas -商材マスタ - Appraisal -専門査定 - Stock -在庫管理 - EXS -販売管理 - Core -会員管理- Portal -データ利用- Pocket -データ基盤- 買取 専門チームによる真贋・査定と連携 査定 申込 効率的な顧客対応 在庫 在庫管理の最適・効率化 販売 データ 各事業プロセスにある データを一元管理 :基幹システム

Slide 4

Slide 4 text

どんなマイグレーションツール使っていますか?

Slide 5

Slide 5 text

golang-migrate? goose? Go Prisma?

Slide 6

Slide 6 text

いろんな選択肢がありますよね〜 今回は Atlas について話します

Slide 7

Slide 7 text

アジェンダ Atlas 導入背景 01 Atlas とは 02 まとめ 04 導入してみてどうだった ?? 03

Slide 8

Slide 8 text

Atlas 導入背景

Slide 9

Slide 9 text

● BST FY24 1day サマーインターンシップ ○ 学生がコードを書くことに集中させるために特定の技術に依存し た課題をさけたかった ■ そのため golang-migrate * (sqlboiler | ent) みたいな選 択肢はなかった ● ORM は実装がシンプルな GORM を選定した ○ Model をスキーマとして扱い開発を容易にしたかっ たから 導入背景

Slide 10

Slide 10 text

● BST FY24 1day サマーインターンシップ ○ 課題作成期限が2週間弱しかないので開発速度が求められる ■ とりあえず大体の開発は終わった ■ さぁマイグレーションをどうしようか... 導入背景

Slide 11

Slide 11 text

そこで最初の問題に戻ります

Slide 12

Slide 12 text

golang-migrate? goose? Go Prisma?

Slide 13

Slide 13 text

● 不採用 ○ Prisma エコシステムの一部 ○ そもそもインターン課題では ORM として Prisma をつかってない ○ Prisma 自体が CHECK 制約がスキーマ操作から自動生成をサ ポートしていない等 ■ 反対に制約を外す際に SQL を実行しなければならずマイグ レーションで完結できない 技術選定 (Go Prisma)

Slide 14

Slide 14 text

技術選定 (goose / golang-migrate) ● 不採用 ○ 一般的な up / down の概念があって使いやすい ○ ただスキーマの変更と model の変更を両方行わなきゃならな い ■ もっと楽したいなぁ...

Slide 15

Slide 15 text

他にないかな〜というときに Atlas を使っている記事発見! PoC してみた

Slide 16

Slide 16 text

Atlas とは

Slide 17

Slide 17 text

● > manage your database schema as code ○ hcl でスキーマや設定ファイルが記述ができる ■ Terraform で使い慣れているので記述が楽 ● ファイル ○ 設定: atlas.hcl ○ スキーマ定義: schema.hcl Atlas

Slide 18

Slide 18 text

● 使い方 ○ コマンド実行 ■ $ atlas schema apply ■ $ atlas migrate (apply | down | new | hash | diff) ● down の考え方が違い down ファイルは存在しない ○ ❌ “pre-planned” ○ ⭕ “computes a migration plan based on the current state of the database” Atlas

Slide 19

Slide 19 text

atlas.hcl (設定ファイル )

Slide 20

Slide 20 text

● atlas schema inspect ○ --format オプションをつけて SQL に変換できる スキーマ取り込み

Slide 21

Slide 21 text

● メリット ○ データベーススキーマを管理できる ○ プロジェクト間でのファイルの共有と再利用 ができる schema.hcl

Slide 22

Slide 22 text

マイグレーション実行

Slide 23

Slide 23 text

● https://atlasgo.io/blog/2023/10/12/atlas-actions-v1 ● “一部制約” があるものの公式アクションで CI/CD 可能 GitHub Actions Action Use Case ariga/setup-atlas Install Atlas from a GitHub Actions workflow ariga/atlas-action/migrate/lint CI for schema changes ariga/atlas-action/migrate/push Push your migration directory to Atlas Cloud (atlasgo.cloud) ariga/atlas-action/migrate/apply Deploy versioned migrations from GitHub Actions

Slide 24

Slide 24 text

プロジェクトに導入してみてどうだった?

Slide 25

Slide 25 text

結論、よかった!

Slide 26

Slide 26 text

● ORM との親和性が高い ○ 公式ドキュメント豊富 ■ Go 意外にも広く対応している ■ Atlas 内にリンクはないが ent も公 式ドキュメントがある ○ struct tags を使った開発が便利だった ■ e.g. GORM よかったこと

Slide 27

Slide 27 text

● Model の差分から自動生 成される ○ 好きな ORM でこれがし たかった!! ○ SQL 編集後は下記実行 ■ atlas migrate hash ■ atlas migrate apply よかったこと

Slide 28

Slide 28 text

一方で課題もありました

Slide 29

Slide 29 text

● 共通化した struct に gorm の primaryKey が含まれている ● 回避策 ○ スクリプトを作成すること ○ 共通化せず愚直に記述すること ■ ただ記述ミスなど発生する懸念があるが lint を使うことで回 避できる 不要なテーブルが生成される

Slide 30

Slide 30 text

不要なテーブルが生成される

Slide 31

Slide 31 text

--dev-url の記述 ● uuid-ossp などの module を使う場合には --dev-url は公式ドキュメ ント通りにいかない ○ --dev-url "docker://postgres/15/dev?search_path=public" ■ 当たり前だけど temporary database に module が含まれ ない ■ 向き先を実際に使用する DB に向ける必要がある

Slide 32

Slide 32 text

--dev-url の記述

Slide 33

Slide 33 text

● Atlas Cloud の契約が必要 ● 回避策 ○ cli で回避すること ■ > If for any reason you cannot use the free Atlas Cloud tier, you can always simply call `atlas migrate lint` from any normal GitHub Actions Workflow and get a similar result. ariga/atlas-action/migrate/lint の制約

Slide 34

Slide 34 text

個人的に、しっくりきた運用方法としては

Slide 35

Slide 35 text

● 前提: GORM ● tag (primaryKey) 付きの struct を書く ○ tag は敢えて細かく書かない ○ 生成されたマイグレーションファイルで整地していく ■ 理由 ● 他の ORM に変える可能性もあるので tag の習熟を極めても仕 方ないため ○ tag の学習コストを下げて他のことに時間を使う ● SQL(DDL) をレビューしたほうがレビュアーの負担が少なくなるた め 個人的に、しっくりきた運用方法

Slide 36

Slide 36 text

まとめ

Slide 37

Slide 37 text

まとめ ● Atlas を使ってみて ○ 公式のドキュメントが豊富でわかりやすい ○ さまざまな ORM に対応していて開発者体験がよかった ○ 一部課題はあったものの回避策を講じて、PoC からプロジェクト 導入まで漕ぎつけられた ■ e.g. サマーインターン課題 → 基盤プロダクトのリプレイス

Slide 38

Slide 38 text

Atlas は良いぞってことで

Slide 39

Slide 39 text

Thank you

Slide 40

Slide 40 text

● https://goprisma.org/ ● https://pkg.go.dev/github.com/golang-migrate/migrate/v4 ● https://pkg.go.dev/github.com/pressly/goose/v3 ● https://atlasgo.io/ ● https://atlasgo.io/blog/2023/10/12/atlas-actions-v1 ● https://github.com/prisma/prisma/issues/3388 ● https://atlasgo.io/getting-started/#inspecting-our-database ● https://entgo.io/ja/docs/versioned-migrations ● https://atlasgo.io/versioned/down ● https://github.com/ariga/atlas-action/issues/112#issuecomment-2040953705 引用