DB変更とECS API公開を安全に分離する
DBの変更、秘密情報、常駐するAPI、1回だけ走るmigration taskを混ぜずに管理する。構築順よりも、失敗したときにどこを確認するかを先に決める章。
TL;DR
- RDSの変更とパスワードは、stateに何が残るかまで含めて扱う。
- migrationはAPI serviceとは別の短命taskとして実行し、終了結果とログで確認する。
- APIはALB・Route 53経由で公開し、HTTP 200とECSログの両方を確認する。
01変更の責務を4つに分ける
RDS、Secrets Manager、ECS migration task、ECS API service は、同じアプリを動かしても実行の目的と確認方法が異なる。
1. RDSと秘密情報
RDSの構成変更は plan で影響を確認する。sensitive は表示を隠すだけで、通常の値はstateに残る。stateに残さない必要がある値は ephemeral と write-only 属性を使い、後から参照する正本は Secrets Manager に置く。
秘密の境界: Terraform state は秘密保管庫ではない。値を再利用するなら Secrets Manager、変更を追うなら write-only 属性の version を使う。
2. one-shot migration task
db-migrator はAPI serviceに混ぜず、RDSへ到達できるネットワークと必要最小限の権限で1回だけ起動する。完了は「起動した」ではなく、taskの終了状態・migrationログ・期待したschemaをまとめて確認する。
3. 常駐API service
Slack Metrics APIはECRのイメージ、タスク定義、target group、ALB、ECS serviceをつなぐ常駐コンポーネント。migrationと同じDB認証を使っても、再起動し続けるサービスと一度で終わる作業を同じ失敗境界にしない。
| 確認対象 | 完了の見方 |
|---|---|
| DB migration | task終了状態、CloudWatchログ、schema |
| API公開 | Route 53のURLへHTTPリクエストし、200応答 |
| APIの内部動作 | ECSログでDB・Slack・SQS・SES連携の記録 |
順序の要点: DB変更をAPIデプロイの副作用にしない。互換性が必要な変更は、schemaを広げてからmigrationし、アプリを切り替え、最後に古いschemaを片付ける。
この章で持ち帰ること
- 秘密値はstateへの残り方まで設計し、正本をSecrets Managerへ分ける。
- migration taskとAPI serviceを分けると、失敗調査と再実行の責務が明確になる。
- 公開確認はHTTP、処理確認はECSログで、それぞれ証拠を残す。