96장. 배포 전략 — Blue-Green · Canary

이 장에서 말하고자 하는 것

49장에서 ECS의 배포 전략을 다뤘다.

이 장은 그 위에서
전체 시스템 차원의 배포 전략 을 정리한다.

• 새 버전이 깨져도 사용자 영향을 최소화하기
• 점진적으로 트래픽을 옮기기
• 자동으로 문제를 감지하고 되돌리기

1. 세 가지 표준 전략

각각 49장에서 본 ECS 단의 동작이 시스템 전체로 확장된다.

2. Blue-Green 의 진가

[Listener]
 └─ TG-blue (v1, 100%)

신버전 배포:
  TG-green 에 v2 띄움 → 헬스 통과 → Listener forward 전환
  ↓
[Listener]
 └─ TG-green (v2, 100%)

• 전환이 한순간
• 롤백도 한순간 (forward 되돌림)
• DB 스키마 호환 부담이 줄어듦

3. Canary — 안전한 점진 전환

Step 1: 5%  → green
        ↓ 5분 관찰 (자동 메트릭)
Step 2: 25% → green
        ↓ 10분 관찰
Step 3: 50% → green
Step 4: 100% → green

각 단계에서 메트릭 (5xx · 지연 · 비즈니스 지표) 이 임계를 넘으면 자동으로 롤백.

정말 위험한 변경(결제 로직 · DB 호환성) 에 어울린다

4. Feature Flag — 코드는 배포, 기능은 별도 토글

배포 전략과 함께 자주 등장한다.

새 기능 코드를 배포
  ↓ 기본은 OFF
  ↓ 일부 사용자에게만 ON (회사 내부, 베타 그룹)
  ↓ 점진 확대 → 모든 사용자

• “배포 ≠ 출시” 가 가능해진다
• 기능을 즉시 끌 수 있다
• AWS AppConfig · LaunchDarkly · 자체 구현 등

코드 롤백보다 Feature Flag OFF 가 더 빠른 비상 정지

5. CloudFront / API Gateway 가중치

CloudFront · API Gateway · Route 53 에서도 가중치 라우팅을 줄 수 있다.

api.example.com
  ├─ 90% → 기존 ALB (v1)
  └─ 10% → 새 ALB (v2)

전체 스택을 두 개 유지하는 큰 변경(예: 클라우드 마이그레이션) 에서도 같은 사고방식.

6. 자동 롤백 트리거

배포 후 어떤 신호로 롤백할까.

• ALB 5xx 비율 > 1%
• 응답 지연 p99 > 임계
• CloudWatch Alarm 발동
• 비즈니스 지표 (주문 수 · 결제 성공률) 급감

“신호” 가 명확해야 자동 롤백이 동작한다 — 모호한 임계는 잡음만 만든다

7. 인프라 변경의 배포 전략

코드뿐 아니라 인프라 변경에도 전략이 필요하다.

안전한 인프라 변경

• 추가 (생성) → 거의 항상 안전
• 변경 (수정) → 다운타임 가능 — 신중
• 삭제 (제거) → 가장 위험 — 충분한 검토

Terraform lifecycle.create_before_destroy = true 가 핵심:

lifecycle {
  create_before_destroy = true
}

새 자원을 먼저 만들고, 트래픽 전환 후, 옛 자원 삭제.

8. DB 스키마 변경의 단계

배포 전략의 가장 큰 함정.

v1: column a 사용
v2: column a 삭제, b 사용

만약 v1 · v2 가 동시에 살아 있는 시간에 b 컬럼을 추가/삭제하면 한쪽이 깨진다

해결 — 항상 세 단계로 분리:

Phase 1: b 컬럼 추가 (DB만 변경, v1 그대로 동작)
Phase 2: 새 코드 v2 배포 (b를 함께 쓰면서 a도 유지)
Phase 3: a 컬럼 제거 (다음 배포에서)

이러면 어떤 시점에도 두 버전이 호환된다.

9. 우리 서비스에서

서비스별 전략:
  orders / users   → ECS Rolling + Circuit Breaker
  payments         → CodeDeploy Blue-Green
  catalog          → Rolling + Feature Flag

자동 롤백:
  ALB 5xx > 1% for 2 minutes
  ALB p99 > 1.5s for 5 minutes

DB 변경:
  3-Phase migration (추가 → 코드 → 삭제)
  Flyway / Liquibase

10. 직접 확인해보기 — CLI

Canary 비율 변경 (CodeDeploy)

aws deploy create-deployment-config \
  --deployment-config-name CanaryEcs10Then50 \
  --compute-platform ECS \
  --traffic-routing-config '{
    "type": "TimeBasedCanary",
    "timeBasedCanary": {
      "canaryPercentage": 10,
      "canaryInterval": 5
    }
  }'

자동 롤백 알람 연결

CodeDeploy Deployment Group에 CloudWatch Alarm을 묶어두면
배포 중 알람이 울리면 자동 롤백.

11. 코드로는 이렇게 생겼다 — Terraform (CodeDeploy + Alarms)

resource "aws_codedeploy_app" "payments" {
  compute_platform = "ECS"
  name             = "payments"
}

resource "aws_codedeploy_deployment_group" "payments" {
  app_name              = aws_codedeploy_app.payments.name
  deployment_group_name = "payments-dg"
  service_role_arn      = aws_iam_role.codedeploy.arn

  deployment_style {
    deployment_type   = "BLUE_GREEN"
    deployment_option = "WITH_TRAFFIC_CONTROL"
  }

  deployment_config_name = "CodeDeployDefault.ECSCanary10Percent5Minutes"

  ecs_service {
    cluster_name = aws_ecs_cluster.main.name
    service_name = aws_ecs_service.payments.name
  }

  load_balancer_info {
    target_group_pair_info {
      prod_traffic_route {
        listener_arns = [aws_lb_listener.https.arn]
      }
      target_group { name = aws_lb_target_group.payments_blue.name }
      target_group { name = aws_lb_target_group.payments_green.name }
    }
  }

  alarm_configuration {
    enabled = true
    alarms  = [aws_cloudwatch_metric_alarm.payments_5xx.alarm_name]
  }

  auto_rollback_configuration {
    enabled = true
    events  = ["DEPLOYMENT_FAILURE", "DEPLOYMENT_STOP_ON_ALARM"]
  }
}

이 구성이 핵심 서비스 배포의 표준 모양이다.

12. 이렇게 쓰면 망한다 — 안티패턴

안티패턴 1. 모든 서비스에 Blue-Green

오버엔지니어링 — 단순 서비스는 Rolling이면 충분.

안티패턴 2. 자동 롤백 신호가 모호하다

“CPU 50% 이상” 같은 임계는 일상이라 도움이 안 된다.

사용자 영향 지표 (5xx · 지연) 가 신호여야 한다

안티패턴 3. DB 변경을 한 번에 한다

v1·v2 공존 시점에 깨진다.

항상 3-Phase

안티패턴 4. 배포가 끝나면 잊는다

배포 후 30분 ~ 1시간은 평소보다 더 주의 깊게 봐야 한다.

13. 한 줄로 정리

배포 전략은 “위험을 작게 쪼개고 자동으로 되돌릴 수 있게 만드는” 설계이며,
Rolling · Blue-Green · Canary + Feature Flag + 3-Phase DB 가 합쳐져 안전망이 된다

14. 이 장의 핵심 정리

1. Rolling은 단순, Blue-Green은 안전, Canary는 점진.
2. Feature Flag로 “배포 ≠ 출시” 를 분리한다.
3. 자동 롤백은 사용자 영향 지표가 신호여야 한다.
4. 인프라는 create_before_destroy 로 안전하게 옮긴다.
5. DB 변경은 3-Phase 가 사실상 표준이다.
6. 배포 후 모니터링까지가 한 묶음이다.