こんにちは。クラウドの深淵を覗き込み、インフラをコードで統治するSREの世界へようこそ。
今日は、多くのエンジニアが「一度はやってみたいが、失敗が怖くて手が出せない」と語る、ECSとALBを用いた「ブルーグリーンデプロイメント」をTerraformで構築する方法を伝授します。
難しいことはありません。本質さえ押さえれば、デプロイは「祈る作業」から「確実な儀式」へと変わります。
—
1. なぜ「ブルーグリーン」なのか？
従来のデプロイ（インプレース更新）は、本番稼働中のサーバーを直接書き換えるため、失敗時のリスクが高く、ロールバックも困難でした。
ブルーグリーンデプロイメントは、全く同じ環境（グリーン）を新しく構築し、最後にALB（ロードバランサー）の向き先を切り替えることで、「ダウンタイムゼロ」かつ「一瞬で切り戻し可能」な安全地帯を実現します。
2. インフラの骨組みを理解する
Terraformでこれを実現するには、以下のパーツが必要です。
- ALBリスナールール: トラフィックの振り分け先を制御する門番。
- ターゲットグループ (TG): コンテナの受け皿。BlueとGreenで2つ用意します。
- ECSサービス: コンテナを動かすエンジン。
3. 実践コード：安全な切り替えを実現するTerraform構成
最も重要なのは、「Terraformがリソースを勝手に破壊しないように制御する」ことです。`lifecycle` ブロックがその鍵を握ります。
ターゲットグループの定義
まずは、BlueとGreenの2つの受け皿を作ります。
Blueターゲットグループ
resource “aws_lb_target_group” “blue” {
name = “app-blue”
port = 80
protocol = “HTTP”
vpc_id = var.vpc_id
lifecycle {
create_before_destroy = true # 破壊前に新しい環境を作る
}
}
Greenターゲットグループ
resource “aws_lb_target_group” “green” {
name = “app-green”
port = 80
protocol = “HTTP”
vpc_id = var.vpc_id
}
ECSサービスの管理
ここでポイントとなるのが `ignore_changes` です。デプロイのたびにTerraformが「現在の状態と違う！」とECSを再構築しようとするのを防ぎます。
resource “aws_ecs_service” “app” {
name = “my-app-service”
cluster = aws_ecs_cluster.main.id
task_definition = aws_ecs_task_definition.app.arn
desired_count = 2
load_balancer {
target_group_arn = var.target_group_arn # ここをデプロイ時に切り替える
container_name = “web”
container_port = 80
}
# デプロイ時にロードバランサー設定が書き換わっても、Terraformで上書きしない
lifecycle {
ignore_changes = [load_balancer]
}
}
—
4. 現場で震えるほど役立つ「デプロイ制御の極意」
Terraform単体でトラフィックを切り替える場合、`var.target_group_arn` を入れ替えて `terraform apply` を実行します。しかし、より高度な運用を目指すなら `null_resource` を活用しましょう。
賢いスイッチングの仕組み
`null_resource` を使うことで、Terraformの実行フローの中で「デプロイが終わった後にALBのルールを更新する」という順序を強制できます。
resource “null_resource” “switch_traffic” {
# ターゲットグループが変更されたら実行
triggers = {
tg_arn = aws_lb_target_group.green.arn
}
provisioner “local-exec” {
# AWS CLIでリスナールールの向き先をGreenへ変更
command = “aws elbv2 modify-listener –listener-arn ${var.listener_arn} –default-actions Type=forward,TargetGroupArn=${self.triggers.tg_arn}”
}
}
—
5. 初心者が陥りやすい罠と対策
1. 「create_before_destroy」の罠:
リソース名が固定されていると衝突します。常にユニークな名前（例: `app-blue-${timestamp()}`）を付与する工夫をしましょう。
2. ヘルスチェックの猶予:
切り替え直後にトラフィックを流すと、コンテナの起動が間に合わずエラーになります。`deregistration_delay` を長めに設定するのがSREの嗜みです。
最後に：あなたへのアドバイス
「完璧な自動化」を目指す必要はありません。まずは「手動で行っていた切り替え作業を、AWS CLIコマンド1つに集約し、それをTerraformで呼び出す」というステップから始めてください。
Terraformは単なる「設定ファイル作成ツール」ではありません。「理想の状態を定義し、それを維持し続けるための意志」そのものです。
このコードを動かせた瞬間、あなたはもう「サーバーをいじる人」ではなく、「インフラを設計するエンジニア」の仲間入りです。さあ、安全なデプロイの世界へようこそ。何か詰まったら、いつでもまた聞きに来てくださいね。