はじめに
AWS ECS 上でデータベースのマイグレーションを実行する際、どの方法を選択するべきかを自分なりに解説します。
個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。
書こうと思ったきっかけ
ECS 上でのデータベースマイグレーションの実行方法には複数の選択肢があり、どの方法を採用するべきか迷うことが多いと感じました。
運用の手間や自動化の観点から、最適な方法を整理し、選択しやすい形でまとめることが重要だと考えました。
マイグレーションを実行する3つの方法（自分調べ）
方法 1: migrate_app をコンテナに追加（自分調べ）
概要
migrate.go をビルドして migrate_app というバイナリを作成し、コンテナに含める方法です。
メリット
- 手動実行も自動実行も可能
-
aws ecs execute-commandで簡単に実行できる - 継続的にマイグレーションが必要な場合に便利
デメリット
- コンテナサイズが少し増える（マイグレーション用のバイナリが含まれるため）
おすすめなケース
- ECS のコンテナを再起動するだけでマイグレーションを適用したい場合
- 本番運用を考慮し、手動・自動の両方の方法を取りたい場合
方法 2: aws ecs execute-command を使う（自分調べ）
概要
ECS Exec を使用し、実行中のコンテナに入って手動で migrate.go を実行する方法です。
メリット
- Dockerfile を変更せずにマイグレーションが可能
- 変更不要で試しやすい
- 一時的なマイグレーション作業に適している
デメリット
- 毎回手動で
aws ecs execute-commandを実行する必要がある - 自動化されないため、継続的な運用には向かない
おすすめなケース
- 短期間で数回だけマイグレーションを実行したい場合
- 現在のコンテナ環境を変更したくない場合
方法 3: ENTRYPOINT に migrate_app を追加（自分調べ）
概要
コンテナ起動時に自動で migrate_app を実行するように ENTRYPOINT を設定する方法です。
メリット
- マイグレーションが完全自動化される
-
migrate_appを実行し忘れる心配がない - CI/CD との統合がしやすい
デメリット
- マイグレーションに失敗するとアプリが起動しない
- アプリ起動前にマイグレーションが必要ない場合でも実行されてしまう
おすすめなケース
- 環境ごとにマイグレーションの状態を管理したくない場合
- CI/CD で自動化したい場合
どの方法を選ぶべきか？（自分調べ）
| 方法 | メリット | デメリット |
|---|---|---|
方法 1: migrate_app を追加 |
手動でも自動でも実行可能 | コンテナサイズが少し増える |
方法 2: aws ecs execute-command を使う |
変更不要で簡単に実行可能 | 毎回手動で実行する必要がある |
方法 3: ENTRYPOINT に migrate_app を追加 |
自動でマイグレーションされる | アプリ起動時にエラーがあるとコンテナが落ちる |
おすすめの選択肢
- 運用がシンプルな方法 1 (
migrate_appをビルドしてコンテナに含める) - 試しにすぐ実行するなら 方法 2 (手動で
migrate_appを実行) - 完全自動化したいなら 方法 3 (
ENTRYPOINTでマイグレーションを実行)
最もバランスの取れた方法
まずは 方法 1 (migrate_app をビルド・デプロイし、ECS Exec で手動実行) するのがベストです。
それで問題なければ、方法 3 に移行すると、マイグレーションの実行を完全に自動化できます。
まとめ（自分調べ）
ECS 上でのマイグレーション実行方法は、大きく3つのアプローチに分かれます。どの方法を選ぶかは、運用のしやすさや、どこまで自動化するかによって決まります。
-
方法 1 (
migrate_appを追加) が最もバランスが取れていて、手動と自動の両方に対応できる。 -
方法 2 (
aws ecs execute-command) は手軽に試せるが、継続的な運用には不向き。 -
方法 3 (
ENTRYPOINTにmigrate_appを追加) は完全自動化ができるが、エラー時の対応が難しくなる。
まずは 方法 1 を導入して様子を見つつ、最適な方法を選択する ことをおすすめします。