この記事をシェア
プロローグ：新人エンジニアの悲劇
田中（新人）「先輩！大変です！ECSでサービスを立ち上げたんですけど、『ローリングアップデート』っていうのを推奨されて、『Blue/Greenデプロイ』は推奨されなかったんです！でも、これってどっちが良いんですか？？」
佐藤先輩「おー、田中くん落ち着いて。コーヒーでも飲みながら説明するから座って座って。まずは深呼吸だよ。」
田中「はい...（ゴクゴク）でも本当にローリングアップデートだけで大丈夫なんでしょうか？」
佐藤先輩「まあまあ、その不安な気持ちも分かるよ。実際、僕も最初は『ローリング？青緑？何それ美味しいの？』って感じだったからね（笑）」
第1章：ローリングアップデートってなんぞや？
佐藤先輩「まずは基本から説明するね。ローリングアップデートっていうのは、既存のインスタンスを少しずつ新バージョンに置き換えていく方法なんだ。」
田中「少しずつ...ですか？」
佐藤先輩「そう！例えば、君のサービスに4つのタスクが動いてるとするよね。ローリングアップデートだと、こんな感じになる：」
【ローリングアップデートの流れ】
初期状態：古いバージョンのタスク4つ稼働 🟦🟦🟦🟦
↓
新バージョンのタスクを2つ追加 🟦🟦🟦🟦🟩🟩（計6タスク）
↓
ヘルスチェック成功確認 ✅
↓
古いバージョンのタスクを2つ削除 🟦🟦🟩🟩
↓
さらに新バージョンを2つ追加 🟦🟦🟩🟩🟩🟩
↓
最後に古いタスクを削除 🟩🟩🟩🟩（完了！）
田中「おお！なるほど、段階的に置き換えていくんですね！」
佐藤先輩「そういうこと！設定もシンプルでね、こんな感じで書けるよ：」
{
"deploymentConfiguration": {
"maximumPercent": 200,
"minimumHealthyPercent": 100
}
}
田中「この数字の意味がよく分からないです...」
佐藤先輩「あー、これね。maximumPercent: 200っていうのは、『最大で通常の2倍までタスクを起動していいよ』って意味。minimumHealthyPercent: 100は『健全なタスクは最低でも通常の100%は維持してね』って意味なんだ。」
田中「つまり、4タスクなら最大8タスクまで起動できて、最低でも4タスクは健全に動いてないとダメってことですか？」
佐藤先輩「正解！君、飲み込み早いじゃない！」
ローリングアップデートのメリット・デメリット
佐藤先輩「ローリングアップデートの良いところと悪いところをまとめるとこんな感じかな：」
【メリット】
- 💰 コストが安い（追加のインフラが不要）
- 🔄 自動でヘルスチェックしながら更新
- 📉 問題が発生しても影響範囲を限定できる
- ⚡ 設定が簡単
【デメリット】
- 🔄 完全なロールバックが難しい
- 🔀 デプロイ中は新旧バージョンが混在
- 🔗 後方互換性が必要
田中「後方互換性って何ですか？」
佐藤先輩「例えば、データベースのカラムを削除するような変更をしたとき、古いバージョンのアプリがまだ動いてると、そのカラムを参照しようとしてエラーになっちゃうでしょ？そういうのを避けるために、新旧両方で動くように作る必要があるってことだよ。」
田中「なるほど...それは確かに気をつけないといけませんね。」
第2章：Blue/Greenデプロイメントの謎
佐藤先輩「じゃあ次は、Blue/Greenデプロイメントについて説明するね。これは『青い環境』と『緑の環境』を用意する方法だよ。」
田中「青と緑...何だかカラフルですね！」
佐藤先輩「名前がカラフルなだけじゃなくて、考え方も全然違うんだ。Blue/Greenは、新環境（Green）を完全に構築してから一気に切り替える方法なんだよ。」
graph TD
A[Blue環境稼働中 🟦] -->|新環境構築| B[Green環境構築 🟩]
B -->|テスト実施| C[テスト完了 ✅]
C -->|トラフィック移行開始| D[段階的な移行 🔄]
D -->|完全移行| E[Green環境に完全移行 🟩]
E -->|問題なし| F[Blue環境削除 🗑️]
E -->|問題発生| G[Blue環境に即時ロールバック 🔙]
田中「わー、これだと環境が2つ必要になるんですね。」
佐藤先輩「そう！だからコストは倍かかっちゃうけど、その分安全性は高いんだ。設定例はこんな感じ：」
resource "aws_ecs_service" "main" {
deployment_controller {
type = "CODE_DEPLOY"
}
load_balancer {
target_group_arn = aws_lb_target_group.blue.arn
container_name = "app"
container_port = 80
}
}
Blue/Greenデプロイメントのメリット・デメリット
【メリット】
- ⚡ 迅速なロールバックが可能
- 🧪 テスト環境としても利用可能
- 🚫 バージョンの混在がない
- ⏰ ダウンタイムなしで切り替え可能
【デメリット】
- 💸 コストが高い（環境を2つ用意）
- 📊 リソース使用量が多い
- 🔄 切り替え時のセッション管理が必要
田中「うーん、どっちも一長一短ですね...」
佐藤先輩「そうなんだよ。だから状況に応じて使い分けることが大事なんだ。」
第3章：実際の運用での悲喜こもごも
佐藤先輩「実際の運用では、色々なドラマがあるんだよ。僕の経験談を話そうか。」
ケース1：ローリングアップデートでの大失敗
佐藤先輩「去年のことなんだけど、Webアプリのアップデートでローリングアップデートを使ったんだ。でも、新バージョンでAPIの仕様を変更しちゃってね...」
田中「え、それってまずくないですか？」
佐藤先輩「超まずかった！古いバージョンのフロントエンドが新しいAPIを呼び出そうとして、エラーが頻発したんだ。お客さんからのクレームの嵐で、その日は徹夜でロールバック作業をしたよ（涙）」
# 緊急ロールバックの様子
$ aws ecs update-service --service my-service --task-definition old-task-def
# 「頼む！戻ってくれ！」って祈りながら実行した
田中「それは大変でしたね...でも、良い勉強になりそうです。」
佐藤先輩「そうなんだ。それからは、後方互換性をきちんと考えるようになったよ。例えば、こんな風にヘルスチェックを強化したりね：」
# タスク定義でのヘルスチェック設定
healthCheck:
command: ["CMD-SHELL", "curl -f http://localhost/health || exit 1"]
interval: 30
timeout: 5
retries: 3
startPeriod: 60
ケース2：Blue/Greenデプロイメントでの成功体験
佐藤先輩「一方で、大規模なデータベースマイグレーションが必要なときは、Blue/Greenデプロイメントで救われたことがあるんだ。」
田中「どんな状況だったんですか？」
佐藤先輩「ユーザーテーブルの構造を大幅に変更する必要があってね。普通にローリングアップデートでやったら、確実に障害が起きる状況だった。」
-- こんな感じのマイグレーション
CREATE TABLE users_new (
id BIGINT PRIMARY KEY,
name VARCHAR(255),
email VARCHAR(255),
profile_data JSONB, -- 新しく追加
created_at TIMESTAMP
);
-- データ移行
INSERT INTO users_new
SELECT id, name, email, '{}', created_at FROM users;
佐藤先輩「Blue/Greenだと、Green環境で完全にテストしてから切り替えられるから、安心だったよ。切り替えも一瞬だったし。」
田中「なるほど！やっぱり状況に応じて使い分けが重要なんですね。」
第4章：判断基準をマスターしよう
佐藤先輩「じゃあ、実際にどっちを使うか迷ったときの判断基準を教えるね。」
ローリングアップデートを選ぶべき場面
佐藤先輩「こんなときはローリングアップデートがオススメだよ：」
- 🐛 小規模なバグフィックス
- 🔒 セキュリティパッチの適用
- 📦 コンテナイメージの更新
- ✨ 小さな機能追加
- 💰 コストを抑えたい場合
田中「具体的にはどんな感じですか？」
佐藤先輩「例えば、『ログ出力の形式をちょっと変更』とか『UIの色を変更』とか、そういう影響の少ない変更ならローリングアップデートで十分だね。」
Blue/Greenデプロイメントを選ぶべき場面
佐藤先輩「逆に、こんなときはBlue/Greenを選んだ方がいいよ：」
- 🏗️ 大規模なアーキテクチャ変更
- 🗄️ データベーススキーマの変更
- 📈 フレームワークのメジャーバージョンアップ
- 🧪 完全なテストが必要な機能追加
- 🚨 ミッションクリティカルなサービス
田中「ミッションクリティカルって？」
佐藤先輩「要するに、『これが止まったら会社が大変なことになる』っていうサービスのことだよ。決済システムとか、重要なAPIとかね。」
第5章：監視とトラブルシューティング
佐藤先輩「デプロイ戦略を選んだら、次は監視が重要だよ。どちらの方法でも、しっかりと監視設定をしておかないと、問題に気づくのが遅れちゃうからね。」
監視設定の例
# CloudWatch Alarms設定例
alarms:
- name: HighErrorRate
metric: ErrorRate
threshold: 1%
period: 60
evaluationPeriods: 2
action: "何かおかしいぞ！エラー率が上がってる！"
- name: HighLatency
metric: p95Latency
threshold: 500ms
period: 300
evaluationPeriods: 3
action: "レスポンスが遅くなってる！調査開始！"
田中「うわー、これだけ設定するのも大変そうですね...」
佐藤先輩「最初は大変だけど、一度設定しちゃえば後は楽だよ。特にエラー率とレスポンス時間は必須だね。これがあるかないかで、障害の発見時間が全然違うから。」
トラブルシューティングの実例
佐藤先輩「実際にトラブルが起きたときの対処法も教えておくね。」
ローリングアップデートでヘルスチェックが失敗した場合：
# まずはサービスの状態確認
$ aws ecs describe-services --service my-service
# タスクの詳細確認
$ aws ecs describe-tasks --tasks task-id
# ログ確認
$ aws logs get-log-events --log-group-name /ecs/my-service
佐藤先輩「大抵の場合、ログを見れば原因が分かるよ。『OutOfMemory』とか『Connection refused』とか、分かりやすいエラーが出てることが多いからね。」
Blue/Greenデプロイメントで切り替えに失敗した場合：
# 即座にロールバック
$ aws deploy stop-deployment --deployment-id deployment-123
$ aws deploy create-deployment --application-name my-app --deployment-group-name my-group --revision revisionType=S3,s3Location=bucket=my-bucket,key=old-version.zip
田中「ロールバックって、そんなに簡単にできるんですね！」
佐藤先輩「Blue/Greenの最大のメリットがそれなんだ。問題が起きても、『はい、元に戻しまーす』って感じで、数分で元の環境に戻せるからね。」
第6章：実践的なTips
佐藤先輩「最後に、実際に運用する上での実践的なTipsを教えるよ。」
ローリングアップデートのコツ
1. 段階的な設定変更
{
"deploymentConfiguration": {
"maximumPercent": 150, // 最初は控えめに
"minimumHealthyPercent": 75 // 段階的に調整
}
}
2. ヘルスチェックの工夫
# Dockerfileでのヘルスチェック
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
CMD curl -f http://localhost:8080/health || exit 1
Blue/Greenデプロイメントのコツ
1. セッション管理
# Nginxでのセッション維持設定
upstream backend {
ip_hash; # IPベースでセッション維持
server blue.example.com;
server green.example.com backup;
}
2. データベース接続の工夫
# アプリケーション側での接続切り替え
def get_db_connection():
if os.environ.get('DEPLOYMENT_COLOR') == 'green':
return connect_to_green_db()
else:
return connect_to_blue_db()
田中「なるほど！細かい工夫がいっぱいあるんですね。」
佐藤先輩「そうなんだ。最初は基本的な設定から始めて、徐々に細かいところを調整していけばいいよ。」
終章：田中くんの成長
田中「先輩、今日は本当にありがとうございました！おかげで、ローリングアップデートとBlue/Greenデプロイメントの違いがよく分かりました。」
佐藤先輩「どういたしまして！で、結局田中くんのサービスはどっちを使うことにしたの？」
田中「えーっと、僕のサービスは小規模なWebアプリで、大きなスキーマ変更もないので、ローリングアップデートで行こうと思います！」
佐藤先輩「いい判断だね！でも、将来的にサービスが大きくなったら、Blue/Greenも検討してみてよ。」
田中「はい！あと、監視設定もちゃんとやります。エラー率とレスポンス時間の監視は必須ですよね！」
佐藤先輩「完璧！君なら大丈夫だよ。何か困ったことがあったら、またいつでも聞いてね。」
田中「ありがとうございます！これで安心してデプロイできます！」
まとめ
ECSでのデプロイ戦略選択は、サービスの特性や要件によって決まります。重要なのは：
- ローリングアップデート: コスト効率重視、小規模変更に適している
- Blue/Greenデプロイメント: 安全性重視、大規模変更や重要なサービスに適している
どちらを選んでも、適切な監視設定とトラブルシューティングの準備が欠かせません。最初は基本的な設定から始めて、徐々に運用ノウハウを蓄積していきましょう！
この記事が、ECSでのデプロイ戦略選択に悩む全てのエンジニアの助けになれば幸いです。Happy Deploying! 🚀
