AWS DB MIGRATION 解説

この課題で
何をしようとしていたのか

DBを丸ごとstgへコピーしたのではありません。ローカルで安全に試した「構造変更の設計図」を、ECRとECSを経由してstg RDSへ一度だけ適用する課題です。

TL;DR

  1. dump.sqlはローカル練習環境の再現用。stgの上書きには使わない。
  2. ECRへpushしたのはDBデータではなく、db-migratorとmigration SQLを含むDockerイメージ。
  3. ECS単発タスクがRDSへ接続し、既存データを残してdescriptionカラムだけ追加した。
✕ 今までのイメージ

ローカルで適当なデータを作り、ECR経由でstgを正規データに上書きする。

→
○ 実際にやったこと

ローカルで変更SQLを検証し、ECSからstgへ「カラム追加の差分」だけ適用する。

01まず全体像 — ローカルは予行演習、stgは差分の適用先

同じDBをコピーする流れではなく、検証済みの変更命令を運ぶ流れ。

ローカル検証からECS経由でstg RDSへmigrationを適用する全体図
運ばれたのはDBの中身ではなく、検証済みの変更命令です。

今回のゴール：stgのworkspacesテーブルへdescriptionカラムを1本追加すること。データベース全体を入れ替えることではありません。

場所役割今回したこと
ローカルPostgres安全な予行演習場restore、migration実行、TablePlus確認、dump
ECR実行物の倉庫db-migrator-stg:22b3bf3を保存
ECS一回限りの実行場所イメージを起動してmigrationを実行
stg RDS実際の変更対象descriptionカラムを追加

02混同しやすい2つ — dump.sqlとmigration SQL

どちらもSQLだが、目的と使われる場所が違う。

dump.sqlとmigration SQLの用途を比較した図
dumpは再現、migrationは差分。stgでdb-migratorが読むのはmigrationです。
dump.sqlmigration SQL
正体DB全体のスナップショット変更差分の命令書
主なコマンドmake restore / make dumpmake up / ECS run-task
今回の対象ローカルPostgresローカルPostgresとstg RDS
stg既存データ今回restoreしない残したままカラムだけ追加
 
-- stgで実際に適用された差分
ALTER TABLE workspaces
  ADD COLUMN description TEXT;

別操作に注意：TablePlusでstgへ追加したmigration-test行は、dumpやECRから投入されたseedではありません。確認のためstgへ直接INSERTしたデータです。

03ECR・タスク定義・ECS — なぜ3つ登場するのか

保管・指定・実行を分けることで、どの変更をどこで動かすかを固定する。

ECR、ECSタスク定義、ECS単発タスクの役割分担図
ECRは置く場所、タスク定義は選ぶ設定、ECSタスクは実際に動くプロセスです。
  1. make release-image：コミット22b3bf3の内容をDockerイメージ化してECRへpush。
  2. タスク定義リビジョン3：イメージ22b3bf3、Secrets、ネットワーク、ARM64を固定。
  3. make run-remote：aws ecs run-taskで単発タスクを1つ起動。
  4. コンテナ内の./main：RDSへ接続し、db/slack_metrics/migrationsをm.Up()で適用して終了。
ECSサービスが不要なのは、APIのように待ち受け続ける仕事ではなく、migrationを終えたら停止してよい仕事だから。

04RDSで実際に起きたこと — 上書きではなく増築

既存行を残したまま、テーブル構造とmigration履歴だけが進んだ。

workspacesへdescription列を追加しmigration履歴へ記録する図
既存データはそのまま。構造の差分と適用済み履歴が残ります。
確認場所確認できたこと意味
CloudWatchfinish to apply migrationsECS上のdb-migratorがエラーなく完了
schema_migrations20260603225644 / dirty=falseそのversionまで正常適用済み
TablePlus Structuredescription / text / nullable課題どおりのカラム構造
TablePlus Datadescription testを保存stgへの読み書きも確認。ただしmigrationとは別操作

重複防止：同じイメージを再実行しても、schema_migrationsが適用済みversionを管理するため、同じADD COLUMNを繰り返さずNo Changeとして終了します。

結論

  1. ローカルでしていたのは、本物のstgを壊さずに変更命令を検証する予行演習。
  2. ECRへ送ったのはDBデータではなく、db-migratorとmigration SQLを含む実行可能な箱。
  3. ECS単発タスクがstg RDSへ差分だけ適用し、CloudWatchとTablePlusで結果を確認した。