はじめに
AWSのEC2からECSへの移行を検討している方向けに、実際の運用作業がどのように変わるのか、どこが変わらないのかを詳しくまとめました。
Railsアプリケーションの移行を想定していますが、他のアプリケーションでも参考になる内容です。
移行による作業変化の全体像
| 項目 | 現状（EC2） | ECS移行後 | 備考 |
|---|---|---|---|
| デプロイ | Capistrano | CodeBuild → ECRプッシュ → ECSサービス更新 | ビルド時間は増加するが自動化レベル向上 |
| ロールバック | currentリンク変更（数秒） | 前タスク定義でサービス更新（1-3分） | Circuit Breakerで自動ロールバック可能 |
| コンテナ内作業 | SSH直接アクセス | aws ecs execute-command |
ECS Exec有効化が必要 |
| マイグレート/Rake | SSH → 直接実行 | aws ecs execute-command |
ECS Exec有効化が必要 |
| コンソール実行 | SSH → rails console
|
ECS Exec → rails console
|
アクセス方法のみ変更 |
| 新ツール導入 | サーバーに直接インストール | Dockerfile修正 → ビルド | 全環境で確実に同じ構成 |
| 台数変更 | AutoScaling Group画面 | ECS Service画面 | より簡単で即効性あり |
| AutoScaling | CloudWatch CPU → ASG | CloudWatch CPU → ECS Service | 同様の仕組み、スケール速度は向上 |
| メインテナンス | ALB weight調整 | ー | ー |
| DB接続 | bastion経由SSH | ー | ー |
| ログ監視 | 直接ファイルアクセス | CloudWatch Logs + fluentd | ログ集約が向上 |
| NewRelic | エージェント直接インストール | コンテナ内またはサイドカー | 設定方法が変わるが機能は同等 |
| 環境変数 | 環境ファイル直接編集 | タスク定義 or Parameter Store | より安全な管理が可能 |
| Rubyバージョンアップ | rbenv install → global設定 | Dockerfileのベースイメージ変更 | 方法は変わるが工数は同等 |
| Railsバージョンアップ | Gemfile修正 → bundle update | Gemfile修正 → コンテナビルド | bundleがビルド時に移行 |
| Gemアップデート | bundle update → 再起動 | Gemfile修正 → コンテナビルド | bundleがビルド時に移行 |
| 接続監視 | auditd → audit.log確認 | CloudTrailでECS Exec監視 | CloudTrailでAPI実行監視 |
| ファイル差分検証 | auditd → 改ざん検知 | サイドカーコンテナの利用 | セキュリティツールのサイドカー実装 |
詳細解説
デプロイとロールバック
EC2時代のCapistranoによるデプロイは、リリースディレクトリを作成してcurrentシンボリックリンクを切り替える方式でした。ロールバックも瞬時に完了します。
# EC2でのロールバック（数秒）
cap production deploy:rollback
ECS移行後は、CodeBuildでコンテナイメージをビルドし、ECSサービスを更新する方式に変わります。
# ECSでのロールバック（1-3分）
aws ecs update-service --service myapp --task-definition myapp:123
Circuit Breakerを有効にすることで、デプロイ失敗時の自動ロールバックが可能です。
deploymentConfiguration:
deploymentCircuitBreaker:
enable: true
rollback: true
コンテナ内での作業
SSH接続から ECS Exec への変更が最も大きな違いです。
# EC2時代
ssh user@server
rails console
# ECS移行後
aws ecs execute-command \
--cluster cluster-name \
--task task-id \
--container container-name \
--command "/bin/bash" \
--interactive
# コンテナ内で
rails console
マイグレートやRakeタスクも同様にECS Exec経由で実行します。
AutoScaling
CloudWatchメトリクスを使用したスケーリングは同様に利用可能ですが、より高速になります。
# ECS Service Auto Scaling設定例
aws application-autoscaling put-scaling-policy \
--policy-name cpu-scaling \
--service-namespace ecs \
--scalable-dimension ecs:service:DesiredCount \
--resource-id service/cluster-name/service-name \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration '{
"TargetValue": 70.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ECSServiceAverageCPUUtilization"
}
}'
バージョンアップ作業
Rubyバージョンアップは、rbenvでの管理からDockerfileのベースイメージ変更になります。
# 変更前
FROM ruby:3.1
# 変更後
FROM ruby:3.2
Rails/Gemのアップデートは基本的に同じ手順ですが、bundle処理がビルド時に実行されます。
セキュリティ監視
システムauditの考え方が大きく変わります。
- SSH接続監視: auditdログ確認 → CloudTrailでECS Exec監視
- ファイル改ざん検知: auditdによる監視 → サイドカーコンテナでのセキュリティツール実装
イミュータブルなコンテナでは、実行時のファイル改ざんリスクが大幅に削減されます。
変わらないもの
データベース接続
SequelProなどのDBクライアントツールは、bastionサーバー経由のSSH接続設定をそのまま利用できます。
SequelPro → bastion(SSH) → RDS
メインテナンスモード
ALBのweight調整による段階的なメンテナンスは、ECSでも同様に実行できます。
複数ログ出力
Railsアプリケーションが出力する複数のログファイルは、CloudWatch Logs + fluentdサイドカーで問題なく処理できます。
移行のメリット
1. 運用の自動化
- 一貫したビルドプロセス: CodeBuildによる標準化
- 自動ロールバック: Circuit Breakerによる障害時の自動復旧
2. 環境の一貫性
- 開発・本番環境の統一: Dockerコンテナによる環境差分の排除
- 予期しない変更の防止: イミュータブルインフラによる安定性向上
3. スケーラビリティの向上
- 高速なスケール: コンテナ起動によるEC2インスタンス起動より高速な処理
- きめ細かな制御: CPU・メモリ使用率に基づく柔軟なスケーリング
4. 監視の向上
- ログ集約: CloudWatch Logsによる一元管理
- API監視: CloudTrailによるECS操作の追跡
移行時の注意点
1. デプロイ時間
コンテナイメージのビルド時間により、デプロイ時間が増加する可能性があります。
2. 学習コスト
ECS ExecやCodeBuildなど、新しいツールセットへの習熟が必要です。
3. ミドルウェアのバージョン管理
Dockerfileでのバージョン固定が重要です。
# ❌ 危険
FROM ubuntu:latest
# ✅ 推奨
FROM ubuntu:20.04
RUN apt-get install postgresql-client=12.9-0ubuntu0.20.04.1
まとめ
EC2からECSへの移行は、運用作業の本質は変わらず、自動化とインフラの安定性が大幅に向上します。
特に重要なポイント：
- デプロイ・ロールバックは時間が増加するが、信頼性が向上
- SSH接続からECS Execへの変更は必要だが、作業内容は同等
- セキュリティ監視はより簡素で効果的になる
- データベース接続や基本的な運用手順は変更不要
移行を検討されている方の参考になれば幸いです。