🟢 Blue/Green 무중단 배포

왜 Blue/Green 배포를 배워야 할까?

금요일 오후 5시, 배포 담당자의 손이 떨립니다. "이번 릴리스, 오늘 안으로 나가야 합니다." 팀장의 메시지가 슬랙에 뜹니다. 기존 서버에 직접 코드를 덮어쓰는 인플레이스 배포(In-Place Deployment)를 실행합니다. 배포 중 3분간 서비스가 멈춥니다. 503 에러가 고객 화면에 나타나고, CS팀에 전화가 쏟아집니다.

설상가상으로 새 버전에 버그가 있었습니다. 롤백하려면 이전 코드를 다시 빌드하고 배포해야 합니다. 또 3분의 다운타임. 금요일 밤은 야근으로 바뀝니다.

이런 상황을 겪어본 적 있다면, 혹은 겪고 싶지 않다면, Blue/Green 배포가 답입니다.

Blue/Green 배포는 현재 운영 중인 환경(Blue)과 완전히 동일한 새 환경(Green)을 미리 준비한 뒤, 로드 밸런서의 트래픽을 한 번에 전환하는 전략입니다. 전환은 순간적이므로 다운타임이 제로(zero)입니다. 문제가 생기면? 트래픽을 다시 Blue로 돌리면 됩니다. 롤백도 순간적입니다.

Netflix, Amazon, 쿠팡 같은 대규모 서비스는 하루에도 수십 번 배포합니다. 이들이 사용자 눈치 없이 배포할 수 있는 비결이 바로 Blue/Green과 카나리 배포입니다.

이 실습에서는 AWS의 실제 서비스를 활용하여 다음을 직접 경험합니다:

• ALB + Target Group 조합으로 트래픽을 Blue/Green 사이에서 전환
• CodeDeploy의 트래픽 시프팅 정책(AllAtOnce, Linear, Canary)을 비교
• CloudWatch 알람 기반 자동 롤백을 설정하여 장애 시 즉시 복원
• 의도적으로 장애를 발생시키고 롤백이 정상 작동하는지 검증

아키텍처 개요

배포 흐름

비용 예측

Step 1: 두 개 Target Group 생성 (Blue/Green)

Blue/Green 배포의 핵심은 두 개의 독립적인 Target Group을 준비하는 것입니다. Blue Target Group에는 현재 운영 버전의 인스턴스가 등록되어 있고, Green Target Group에는 새 버전의 인스턴스가 등록됩니다. ALB의 리스너가 어떤 Target Group으로 트래픽을 보낼지 결정합니다.

헬스 체크 경로를 /health로 설정하는 이유는, 단순히 서버가 켜져 있는지가 아니라 애플리케이션이 정상적으로 요청을 처리할 수 있는지까지 확인하기 위해서입니다. 만약 DB 연결이 끊겼다면 서버는 살아있지만 /health는 500을 반환하게 됩니다.

# Blue Target Group
aws elbv2 create-target-group \
  --name lab-blue-tg \
  --protocol HTTP --port 80 \
  --vpc-id <VPC_ID> \
  --health-check-path /health \
  --target-type instance
 
# Green Target Group
aws elbv2 create-target-group \
  --name lab-green-tg \
  --protocol HTTP --port 80 \
  --vpc-id <VPC_ID> \
  --health-check-path /health \
  --target-type instance

Step 2: ALB 리스너 구성

리스너는 ALB가 수신하는 트래픽의 "입구"입니다. 프로덕션 리스너(포트 80)는 실제 사용자의 트래픽을 처리하고, 테스트 리스너(포트 8080)는 배포 전 내부 검증에 사용합니다. 이렇게 두 개의 리스너를 설정하면 Green 환경에 트래픽을 전환하기 전에 별도 포트를 통해 새 버전을 먼저 검증할 수 있습니다.

# 프로덕션 리스너 (Blue)
aws elbv2 create-listener \
  --load-balancer-arn <ALB_ARN> \
  --protocol HTTP --port 80 \
  --default-actions Type=forward,TargetGroupArn=<BLUE_TG_ARN>
 
# 테스트 리스너 (Green)
aws elbv2 create-listener \
  --load-balancer-arn <ALB_ARN> \
  --protocol HTTP --port 8080 \
  --default-actions Type=forward,TargetGroupArn=<GREEN_TG_ARN>

Step 3: CodeDeploy Blue/Green 배포 그룹 생성

CodeDeploy는 Blue/Green 배포의 전체 프로세스를 자동화합니다. Green 인스턴스 생성, 헬스 체크, 트래픽 전환, 이전 인스턴스 종료까지 모든 과정을 관리합니다. 배포 그룹 설정에서 terminateBlueInstancesOnDeploymentSuccess 옵션은 배포 성공 후 Blue 인스턴스를 자동으로 종료할지 결정합니다. 종료 대기 시간을 60분으로 설정하면, 문제 발견 시 60분 이내에 수동 롤백이 가능합니다.

aws deploy create-deployment-group \
  --application-name lab-cicd-deploy \
  --deployment-group-name lab-bg-deploy-group \
  --service-role-arn arn:aws:iam::<ACCOUNT_ID>:role/codedeploy-service-role \
  --deployment-style "deploymentType=BLUE_GREEN,deploymentOption=WITH_TRAFFIC_CONTROL" \
  --blue-green-deployment-configuration '{
    "terminateBlueInstancesOnDeploymentSuccess": {
      "action": "TERMINATE",
      "terminationWaitTimeInMinutes": 60
    },
    "deploymentReadyOption": {
      "actionOnTimeout": "CONTINUE_DEPLOYMENT",
      "waitTimeInMinutes": 5
    }
  }' \
  --load-balancer-info "targetGroupInfoList=[{name=lab-blue-tg},{name=lab-green-tg}]"

Step 4: 트래픽 시프팅 설정

트래픽 시프팅은 Blue에서 Green으로 트래픽을 어떤 속도로 전환할지 결정하는 핵심 설정입니다. 세 가지 방식이 있는데, 각각의 장단점을 이해하고 상황에 맞게 선택해야 합니다.

• AllAtOnce: 한 번에 100% 전환합니다. 가장 빠르지만, 문제 발생 시 모든 사용자가 영향을 받습니다. 개발/스테이징 환경에 적합합니다.
• Linear10PercentEvery1Minute: 1분마다 10%씩 점진적으로 전환합니다. 10분 후 100% 도달. 문제를 조기에 발견할 수 있지만 전환 시간이 깁니다.
• Canary10Percent5Minutes: 먼저 10%만 보내고 5분간 관찰 후, 이상이 없으면 나머지 90%를 한 번에 전환합니다. 프로덕션에서 가장 추천하는 방식입니다.

Step 5: 배포 실행 및 모니터링

배포를 실행하면 CodeDeploy가 자동으로 Green 환경을 생성하고, 헬스 체크를 수행한 뒤, 설정한 트래픽 시프팅 정책에 따라 트래픽을 전환합니다. 이 과정에서 CloudWatch 지표를 실시간으로 확인하는 것이 중요합니다. 특히 Green 환경의 5xx 에러율과 응답 시간(p99 latency)을 주시해야 합니다.

Step 6: 롤백 테스트

롤백은 "연습하지 않으면 실전에서 실패하는" 대표적인 작업입니다. 의도적으로 오류 버전을 배포하여 자동 롤백이 정상 작동하는지 반드시 검증해야 합니다. 자동 롤백이 제대로 설정되면, 새벽 3시에 배포가 실패해도 개발자가 잠든 사이 시스템이 알아서 복구합니다.

배포 전략 비교

각 배포 전략의 특성을 이해하면, 상황에 맞는 최적의 전략을 선택할 수 있습니다.

• In-Place 배포: 기존 서버에 직접 코드를 교체합니다. 다운타임이 발생하지만 추가 인프라 비용이 없습니다. 내부 도구나 개발 환경에 적합합니다.
• Rolling Update: 서버를 하나씩 순차적으로 업데이트합니다. 다운타임은 최소화되지만 신구 버전이 혼재하는 기간이 존재합니다.
• Blue/Green 배포: 완전히 동일한 새 환경을 준비하고 트래픽을 전환합니다. 다운타임 제로, 즉시 롤백 가능. 인프라 비용이 일시적으로 2배가 됩니다.
• 카나리 배포: Blue/Green의 변형으로, 소수의 트래픽만 먼저 새 버전으로 보내 검증합니다. 프로덕션 환경에서 가장 안전한 전략입니다.

트러블슈팅 가이드

핵심 개념 확인

완성 후 테스트 가이드

배포 파이프라인이 완성되면 아래 시나리오를 순서대로 테스트하여 전체 시스템이 정상 동작하는지 검증하세요.

실무에서 자주 묻는 질문

Q: Blue/Green 배포 중 데이터베이스 스키마 변경은 어떻게 하나요?

데이터베이스는 Blue와 Green이 공유하므로, 스키마 변경은 하위 호환성(Backward Compatible)을 유지해야 합니다. 예를 들어 컬럼을 삭제하려면: (1) 먼저 코드에서 해당 컬럼을 사용하지 않도록 수정하여 배포 (2) 이후 별도 마이그레이션으로 컬럼을 삭제합니다. 한 번의 배포에서 스키마 변경과 코드 변경을 동시에 하면 롤백이 불가능해질 수 있습니다.

Q: Blue 환경은 언제 종료해야 하나요?

Green 환경에 100% 트래픽이 전환된 후 즉시 종료하지 않는 것이 좋습니다. 최소 1시간~24시간은 유지하여, 늦게 발견되는 문제에 대해 롤백 여지를 남겨두세요. terminationWaitTimeInMinutes 설정으로 자동 종료 대기 시간을 제어할 수 있습니다.

Q: 동시에 여러 버전을 배포해야 하면 어떻게 하나요?

한 번에 하나의 Blue/Green 배포만 진행하는 것이 원칙입니다. 여러 기능을 동시에 배포해야 한다면, Feature Flag(기능 플래그)를 사용하여 코드 수준에서 기능을 켜고 끄는 방식을 권장합니다.

확장 아이디어

이 실습을 완료한 후 더 깊이 학습하고 싶다면 아래 주제를 시도해보세요.

1. ECS + Fargate Blue/Green: EC2 대신 ECS Fargate 서비스에 Blue/Green 배포를 적용하여 컨테이너 기반 무중단 배포를 구현합니다.
2. 가중치 기반 라우팅: ALB 리스너 규칙에서 가중치(weight)를 직접 조정하여, 10/90 → 30/70 → 50/50 → 100/0 순으로 더 세밀한 트래픽 시프팅을 구현합니다.
3. Lambda 훅 활용: CodeDeploy의 BeforeAllowTraffic/AfterAllowTraffic 훅에 Lambda 함수를 연결하여, 트래픽 전환 전후에 자동 통합 테스트를 실행합니다.
4. 다중 리전 Blue/Green: Route 53 가중치 기반 라우팅을 활용하여, 서울과 도쿄 리전 간 글로벌 Blue/Green 배포를 구현합니다.
5. Slack 연동 알림: SNS + Lambda + Slack Webhook을 연결하여, 배포 시작/성공/롤백 이벤트를 실시간으로 Slack 채널에 알림합니다.

배포 전략 의사결정 가이드

학습 정리

리소스 정리