개요
이 글은 AutoScalingGroup(이하, ASG)을 활용한 EC2 배포 전략을 다룹니다. ASG의 주요 기능과 배포 파이프라인에 대한 배경 지식이 필요합니다.
- AutoScalingGroup 주요 기능 정리: https://malwareanalysis.tistory.com/870
- AutoScalingGroup을 활용한 EC2 배포 파이프라인: https://malwareanalysis.tistory.com/871
실습 구조
실습자료 중 RollingUpdate, Canary는 저의 github에 공개되어 있습니다.
- RollingUpdate - https://github.com/choisungwook/portfolio/tree/master/aws/auto_scaling_group/examples/02_rollingupdate
- Canary - https://github.com/choisungwook/portfolio/tree/master/aws/auto_scaling_group/examples/02_canary
- Blue/green(goployer 오픈소스 사용) - https://github.com/choisungwook/portfolio/tree/master/aws/auto_scaling_group/examples/02_canary
ASG가 생성한 EC2 인스턴스는 현재 버전을 출력하는 nginx를 실행합니다. 예를 들어 launch template 버전이 v1이면 nginx 응답도 v1이 됩니다.
ASG는 ALB에 연결됩니다. ALB를 호출하면 EC2 인스턴스에서 실행 중인 nginx 응답을 받습니다.
각 시나리오에서 배포가 성공하면 ALB를 호출했을 때 업데이트된 버전인 nginx v2 응답을 받습니다.
ASG는 총 4대의 EC2 인스턴스를 실행합니다. 따라서 ASG Desired capacity는 4입니다.
ASG 배포전략 - RollingUpdate
RollingUpdate 배포전략이란?
RollingUpdate 배포전략은 새 버전의 인스턴스를 점진적으로 생성하면서 기존 인스턴스를 순차적으로 종료하는 방식입니다.
예를 들어 아래와 같은 ASG 설정이 있다고 가정해봅시다.
- Desired capacity: 4
- MinHealthyPercentage: 50
- MaxHealthyPercentage: 100
ASG 인스턴스 새로고침이 실행되면 최소 인스턴스 개수가 2대(총 인스턴스 4대의 50%)로 계산되므로, 인스턴스를 2대씩 교체합니다. 따라서 총 4대의 인스턴스는 2단계 과정을 거쳐 모두 교체됩니다.
위 예제처럼 일부 인스턴스를 점진적으로 선택해 배포하는 방식을 RollingUpdate라고 합니다. RollingUpdate의 장점은 구현이 간단하고 인스턴스를 단계적으로 교체하기 때문에 문제 발생 범위를 최소화할 수 있습니다.
ASG 배포전략 - RollingUpdate 실습
1. 먼저 Launch Template을 수정합니다. nginx의 index.html 파일을 수정해 응답 버전 정보를 업데이트했습니다.
launch template이 수정되면 launch template 버전이 자동으로 업데이트됩니다.
2. 인스턴스 새로고침을 실행합니다.
한번에 인스턴스 2대씩 RollingUpdate하도록 설정하고 롤백 API를 호출할 수 있도록 Desired Configuration을 설정합니다.
aws autoscaling start-instance-refresh \
--auto-scaling-group-name example2-rollingupdate \
--desired-configuration '{
"LaunchTemplate": {
"LaunchTemplateId": "lt-04674a4e772d0e5cf",
"Version": "2"
}
}' \
--preferences '{
"MinHealthyPercentage": 50,
"MaxHealthyPercentage": 100
}'
인스턴스 새로고침을 실행하면 AWS 콘솔에서 진행상황을 확인할 수 있습니다.
EC2 인스턴스 상태는 Instance management 탭에서 확인할 수 있습니다. 현재 예제에서는 2대씩 인스턴스가 Rolling Update되도록 구성했으므로, 2대의 인스턴스가 종료되고 2대의 새 인스턴스가 생성됩니다.
EC2 인스턴스 대시보드에서도 진행상태를 확인할 수 있습니다.
ASG RollingUpdate 예제 설정 보완
현재 예제 설정에서는 인스턴스 교체 시 기존 인스턴스가 먼저 종료된 후 새 인스턴스가 생성되었습니다.
즉, 인스턴스 새로고침 과정에서 일시적으로 2대의 인스턴스가 없어지는 상황이 발생했습니다. 이 시점에 갑작스러운 트래픽이 몰리면 남은 인스턴스에 과부하가 걸려 서비스 장애가 발생할 수 있습니다. 그렇다면 어떻게 새 인스턴스를 먼저 생성한 후 기존 인스턴스를 종료하도록 설정할 수 있을까요?'
해결책은 MaxHealthyPercentage 값을 높이는 것입니다. 현재 MaxHealthyPercentage=100으로 설정되어 있어 최대 4대의 인스턴스만 실행할 수 있습니다. MaxHealthyPercentage=150으로 변경하면 최대 6대의 인스턴스가 동시에 실행될 수 있어, 새 인스턴스가 먼저 생성된 후 기존 인스턴스가 종료되는 방식으로 작동합니다.
MaxHealthyPercentage를 늘리면 운영환경에서 안전하게 인스턴스를 배포할 수 있습니다. 하지만, 배포하는 동안 인스턴스 개수가 증가하여 비용이 증가하는 단점이 있기 때문에 팀의 상황에 맞게 MaxHealthyPercentage를 적절히 설정해야 합니다.
ASG 배포전략 - Canary
Canary 전략이란?
Canary 배포는 RollingUpdate와 유사하게 EC2 인스턴스를 점진적으로 교체하지만, 배포 과정에 일시 중지 시간이 있습니다. 이 중지 시간 동안 새로 배포된 기능에 문제가 없는지 모니터링합니다. 모니터링 결과 이상이 없으면 배포를 계속 진행하고, 문제가 발견되면 롤백을 실행합니다.
ASG에서 Canary배포 설정
ASG는 Canary 배포 전략을 위해 checkpoint 기능을 제공합니다.
교체된 인스턴스 비율이 checkpoint에 설정된 비율에 도달하면 인스턴스 새로고침이 일시 중단됩니다. 이 후 CheckpointDelay 시간만큼 대기한 후 인스턴스 새로고침이 재개됩니다.
- CheckPointPercentages: 검증을 위한 일시정지 지점
- CheckpointDelay: 일시 중지 시간
aws autoscaling start-instance-refresh \
--auto-scaling-group-name {ASG이름} \
--preferences '{
"CheckpointPercentages": [25, 50, 100],
"CheckpointDelay": 300
}'
ASG에서 Canary 전략을 사용할 때는 Desired Configuration을 함께 설정하는 것이 좋습니다. 이렇게 하면 롤백 API를 호출할 수 있습니다. Canary 배포는 다른 전략보다 시간이 오래 걸리므로, 문제 발견 시 롤백 API를 호출해 즉시 롤백할 수 있도록 준비하는 것이 중요합니다.
aws autoscaling start-instance-refresh \
--auto-scaling-group-name example2-canary-asg \
--desired-configuration '{
"LaunchTemplate": {
"LaunchTemplateId": "lt-0e984424fe3ba9f46",
"Version": "2"
}
}' \
--preferences '{
"MinHealthyPercentage": 50,
"MaxHealthyPercentage": 100,
"CheckpointPercentages": [20, 50, 80],
"CheckpointDelay": 300
}'
주의사항
CheckPointPercentages에 100을 포함하지 않으면 모든 인스턴스가 교체되지 않습니다.
예를 들어 아래 예제는 전체 인스턴스 중 25%만 교체하고 나머지 75%는 그대로 유지됩니다. 이처럼 일부 인스턴스만 교체하는 전략을 ASG에서는 partially refresh라고 합니다.
aws autoscaling start-instance-refresh \
--auto-scaling-group-name {ASG이름} \
--preferences '{
"CheckpointPercentages": [10, 25],
"CheckpointDelay": 300
}'
partially refresh 이후 나머지 인스턴스를 배포하려면 SkipMatching 기능을 사용합니다. 이 기능은 배포 내용에 차이가 없으면 해당 인스턴스를 건너뜁니다.
aws autoscaling start-instance-refresh \
--auto-scaling-group-name {ASG이름} \
--preferences '{
"CheckpointPercentages": [10, 30, 100],
"CheckpointDelay": 300,
"SkipMatching": true
}'
실습
1. UpdateRolling전략 실습과 동일하게 launch template을 수정하고 인스턴스 새로고침을 실행했습니다. Canary배포 전략에서는 인스턴스 새로고침 인자에 CheckpointPercentages, CheckpointDelay가 추가됩니다.
aws autoscaling start-instance-refresh \
--auto-scaling-group-name {ASG이름] \
--desired-configuration '{
"LaunchTemplate": {
"LaunchTemplateId": "lt-",
"Version": "2"
}
}' \
--preferences '{
"MinHealthyPercentage": 50,
"MaxHealthyPercentage": 100,
"CheckpointPercentages": [50, 100],
"CheckpointDelay": 300
}'
2. Checkpoint를 설정하면 아래그림처럼 인스턴스 새로고침 화면에서 Checkpoints=Enabled가 보입니다.
2025년 기준 Checkpoint에 도달한 후 남은 시간을 확인하는 방법은 없는 것으로 보입니다. 따라서 EventBridge로 인스턴스 새로고침 이벤트를 수신하고 Lambda로 알림을 보내는 방법이 최선입니다.
ASG 배포전략 - Blue/Green
Blue/Green은 구버전과 신버전 EC2 인스턴스를 동시에 실행한 후, 트래픽을 한 번에 신버전으로 전환하는 전략입니다. 주로 트래픽 라우팅이 필요한 API 애플리케이션에서 사용합니다. 트래픽을 신버전으로 완전히 전환한 후에도 롤백을 대비해 구버전 인스턴스를 일정 시간 유지합니다. 문제가 없으면 구버전 인스턴스를 삭제합니다.
안타깝게도 2025년 기준 ASG는 Blue/Green 배포 전략을 자체 기능으로 지원하지 않습니다. 현재는 RollingUpdate만 제공하며, Canary가 필요한 경우 checkpoint를 사용할 수 있습니다.
ASG 자체 기능으로 Blue/Green이 없지만 ASG를 활용하여 Blue/Green을 구현할 수 있습니다. 두 개의 ASG가 필요합니다. 신버전 EC2 인스턴스를 관리하는 ASG를 생성하고 ELB(예: ALB)에 연결한 후, 구버전 ASG를 제거하면 Blue/Green과 유사하게 배포할 수 있습니다. 다만, ELB TargetGroup에 인스턴스가 붙는 시간이 완벽히 동일하지 않아 트래픽 전환이 한 번에 100% 이루어지지 않습니다.
참고자료
'전공영역 공부 기록' 카테고리의 다른 글
| Argo CD v3.2 업데이트 내용: Application path에서 "." 또는 ""(공백)을 더 이상 사용할 수 없습니다. (0) | 2025.10.09 |
|---|---|
| AWS Auto Scaling group을 이용한 EC2인스턴스 배포 파이프라인 작성 방법 (0) | 2025.10.09 |
| AWS Auto Scaling Group 주요기능 (0) | 2025.10.08 |
| AWS EC2인스턴스의 UserData가 잘 실행되었는지 확인하는 방법 (2) | 2025.10.06 |
| AWS 모든 노드를 관리하는 Systems Manager의 원리와 기능 (0) | 2025.09.08 |