AWS Certified Developer - Associate (DVA-C02) #11 Domain 3-3 배포: 배포 전략
#10 IaC와 서버리스 배포에서 배포 도구를 정리했으니, 배포 도메인의 마지막은 무중단으로 안전하게 갱신하는 전략 자체입니다. 시험은 “다운타임 없이, 위험을 줄이며, 문제가 생기면 빠르게 되돌리는” 방법을 묻습니다.
in-place vs blue/green #
| 구분 | in-place | blue/green |
|---|---|---|
| 방식 | 기존 인스턴스 위에서 교체 | 새 환경(green)에 배포 후 트래픽 전환 |
| 다운타임 | 가능 | 없음 |
| 롤백 | 재배포 필요(느림) | 트래픽을 blue로 되돌리면 끝(빠름) |
| 비용 | 낮음 | 일시적 두 배 |
핵심: blue/green은 빠른 롤백과 무중단이 강점입니다. “배포 실패 시 즉시 되돌려야 한다"의 답은 보통 blue/green입니다. 단점은 일시적으로 두 환경을 운영하는 비용입니다.
트래픽 전환 방식 #
새 버전으로 트래픽을 옮기는 방식은 세 가지입니다. CodeDeploy와 SAM이 이 이름을 그대로 씁니다.
| 방식 | 동작 |
|---|---|
| Canary | 처음에 일부 비율(예: 10%)만 보내고, 일정 시간 뒤 나머지 전부 |
| Linear | 일정 비율씩 단계적으로(예: 10분마다 10%) 증가 |
| All-at-once | 한 번에 100% 전환 |
카나리,선형은 새 버전을 일부 트래픽으로 먼저 검증하므로 위험이 낮습니다. “신규 버전을 소수 사용자에게 먼저 노출해 지표를 본 뒤 확대"의 답은 카나리입니다.
Lambda 버전,별칭과 가중치 라우팅 #
#2에서 본 별칭이 여기서 핵심이 됩니다.
- 버전(Version). 게시할 때마다 생기는 불변 스냅샷(
:1,:2). - 별칭(Alias). 특정 버전을 가리키는 포인터(
prod→:2). - 가중치 라우팅. 별칭이 두 버전에 트래픽을 비율로 분배합니다(예:
:2에 90%,:3에 10%).
이 가중치를 점진적으로 올리는 것이 Lambda의 카나리/선형 배포입니다. SAM에서는 AutoPublishAlias와 DeploymentPreference(예: Canary10Percent5Minutes)로 선언하면 CodeDeploy가 자동으로 트래픽을 옮기고, 실패하면 롤백합니다.
“Lambda 새 버전을 10%만 보내고 문제없으면 전체로"의 답은 **별칭 가중치 라우팅(SAM DeploymentPreference 카나리)**입니다.
API Gateway 점진 배포 #
API Gateway도 스테이지의 카나리 설정으로 일부 트래픽을 새 배포로 보낼 수 있습니다. 스테이지 변수와 함께 쓰면 환경별,버전별 분기가 가능합니다.
ECS/EC2 배포 전략 정리 #
- ECS. CodeDeploy로 blue/green(새 태스크 세트에 배포 후 리스너 전환). 롤백이 빠릅니다.
- EC2(CodeDeploy). in-place 또는 blue/green. appspec 수명 주기 훅의
ValidateService로 배포 검증. - Elastic Beanstalk. Immutable/Blue-Green이 가장 안전.
자동 롤백 #
배포가 실제로 건강한지 판단하고, 나쁘면 자동으로 되돌리는 것이 운영의 핵심입니다.
- CloudWatch 알람 연계. 배포 중 에러율,지연 알람이 울리면 CodeDeploy가 자동 롤백합니다.
- 배포 실패 시 롤백. 수명 주기 훅 검증 실패, 헬스 체크 실패 시 이전 버전으로 복귀.
- SAM/CodeDeploy의 카나리 배포는 알람과 묶어 “지표가 나빠지면 확대 중단 + 롤백"을 자동화합니다.
“새 버전 배포 후 에러율이 치솟으면 자동으로 되돌려라"의 답은 CloudWatch 알람 + CodeDeploy 자동 롤백입니다.
전략 선택 빠른 표 #
| 요구사항 | 정답 |
|---|---|
| 무중단 + 빠른 롤백 | Blue/Green |
| 신버전을 소수에게 먼저 노출 | Canary |
| 비율을 단계적으로 증가 | Linear |
| Lambda 새 버전 점진 전환 | 별칭 가중치 라우팅 |
| 지표 악화 시 자동 복귀 | CloudWatch 알람 + 자동 롤백 |
시험 출제 패턴 #
- “배포 실패 시 즉시 이전으로 되돌려야 한다.” → Blue/Green.
- “새 기능을 사용자 10%에게 먼저.” → Canary.
- “Lambda 신버전에 트래픽을 점진적으로.” → 별칭 가중치 라우팅(SAM DeploymentPreference).
- “배포 후 에러율 급증 시 자동 롤백.” → CloudWatch 알람 + CodeDeploy.
- “EC2 배포 후 애플리케이션 정상 여부 검증.” → appspec
ValidateService훅.
자주 만나는 함정 #
1) blue/green과 in-place 롤백 속도 혼동 #
blue/green은 트래픽만 되돌리면 롤백이 즉시입니다. in-place는 재배포가 필요해 느립니다.
2) 버전과 별칭 혼동 #
버전은 불변 스냅샷, 별칭은 가리키는 포인터(+가중치 분배)입니다. 가중치 배포의 주체는 별칭입니다.
3) 자동 롤백을 헬스 체크만으로 생각 #
지표 기반 자동 롤백은 CloudWatch 알람 연계가 핵심입니다.
정리 #
이번 글에서 잡은 것:
- in-place(저비용,느린 롤백) vs blue/green(무중단,빠른 롤백,두 배 비용)
- 트래픽 전환. Canary(일부 먼저), Linear(단계 증가), All-at-once
- Lambda 별칭 가중치 라우팅으로 버전 간 점진 전환(SAM DeploymentPreference)
- CloudWatch 알람 + CodeDeploy 자동 롤백으로 지표 악화 시 복귀
다음: Domain 4-1 관측 #
배포까지 마쳤습니다. 마지막 도메인은 18%의 트러블슈팅과 최적화입니다. #12 관측에서는 CloudWatch Logs,Metrics,Alarms, X-Ray 분산 추적, 그리고 EMF(Embedded Metric Format)로 로그에서 지표를 뽑는 방법을 정리하겠습니다.