개요
안녕하세요. 이 글에서는 이전 글에 이어 Auto Scaling Group(이하 ASG)을 활용한 EC2 인스턴스 배포 파이프라인에 대해 설명합니다.
- 이전 글 AWS Auto Scaling Group 주요기능: https://malwareanalysis.tistory.com/870
이 글에서는 다음 주제들에 대한 내용을 다룹니다.
- EC2 인스턴스 배포 파이프라인에서 ASG가 담당하는 역할은 무엇이며, 왜 ASG를 사용하는 것이 좋을까요?
- Launch Template을 수정하면 자동으로 인스턴스가 배포될까요, 아니면 추가 작업이 필요할까요?
- 인스턴스 새로고침(Instance Refresh)은 어떤 API를 통해 실행하며, 파이프라인 로직은 어떻게 구성되나요?
- MinHealthyPercentage와 MaxHealthyPercentage 설정값은 인스턴스 교체 방식에 어떤 영향을 미치나요?
- 'Terminate and Launch'와 'Launch and Terminate' 방식의 차이는 무엇이며, 서비스 무중단을 위해서는 어떤 설정이 필요한가요?
- Desired Configuration을 사용한 롤백과 Launch Template을 직접 변경하는 방식의 차이점은 무엇인가요?
- 인스턴스 새로고침 강제 취소 기능은 언제 사용하며, 주의해야 할 점은 무엇인가요?
- 안정적인 배포 파이프라인 구축을 위해 반드시 최적화해야 점은 무엇일까?
EC2인스턴스 배포 파이프라인이란에서 ASG의 역할은?
EC2인스턴스 배포 파이프라인에서 ASG의 역할은 새로운 버전의 EC2 인스턴스를 생성하고 기존 인스턴스를 종료하는 것입니다. ASG는 선택한 배포전략(Rolling update, Blue/Green, Canary)에 따라 EC2 인스턴스 교체 방식을 결정합니다.
EC2인스턴스 배포 파이프라인에서 ASG를 활용하는 이유는 ASG가 제공하는 다양한 유용한 기능 때문입니다. EC2 인스턴스를 수동으로 배포하는 과정은 복잡하고 자동화하기 어렵지만, ASG는 이미 많은 자동화 기능을 지원하여 파이프라인 구성을 쉽게 해줍니다.
- EC2 인스턴스 설정정보에 대한 버전 관리 지원
- EC2 인스턴스 헬스체크 자동 실행
- RollingUpdate, Blue/Green 등 다양한 배포전략 구현 가능
- Auto Scaling 기능 활용 가능
- ELB와의 간편한 연동
- 롤백기능 지원
배포 파이프라인에서 ASG를 사용하려면 AWS AutoScalingGroup API를 호출해야 합니다.
파이프라인 로직
파이프라인 로직은 간단합니다.
- launch template을 수정하고 버전을 올립니다.
- ASG에서 launch template 버전을 1번에서 설정한 버전으로 합니다. 만약 실행 중 롤백을 원한다면 Desired configuration에서 launch tempalte 버전을 수정해야 합니다. 이 내용은 이 글의 롤백 방법챕터를 참고해주세요.
- ASG start-instance-refresh API을 호출하여 인스턴스를 배포합니다.
launch template은 EC2 설정을 관리하며 버전 관리 기능을 제공합니다. 즉 EC2 설정을 변경할 때마다 새 버전이 생성됩니다. 아래 그림은 launch template의 버전입니다.
ASG는 laucn template 버전의 설정대로 EC2인스턴스를 생성합니다. launch template 버전을 수정하면 해당 버전 설정대로 EC2인스턴스가 생성된다는 의미입니다.
주의할 점은 launch template을 수정해도 자동으로 EC2 인스턴스가 배포되지 않는다는 것입니다. 새 설정을 적용하려면 직접 인스턴스 새로고침을 실행하여 인스턴스를 배포해야 합니다.
인스턴스 새로고침은 AWS console 또는 AWS ASG API를 호출하면 됩니다.
aws autoscaling start-instance-refresh \
--auto-scaling-group-name {ASG 이름}
인스턴스 새로고침 중 롤백은 원한다면 Desired configuration을 설정해야 합니다. launch tempalte버전을 수정하는 방법은 버전을 확정하는거여서 롤백이 안되지만, Desired configuraiton은 의도한 상태이기때문에 기존 상태로 롤백할 수 있습니다.
aws autoscaling start-instance-refresh \
--auto-scaling-group-name {ASG이름} \
--desired-configuration '{
"LaunchTemplate": {
"LaunchTemplateId": "lt-",
"Version": "1" # 원하는 launch template 버전
}
}'
인스턴스 새로고침 진행상황은 AWS 콘솔에서 쉽게 확인할 수 있습니다.
롤백시 롤백 진행상황도 AWS콘솔에서 확인할 수 있습니다.
인스턴스 새로고침이 실행되면 어떻게 인스턴스가 교체될까?(instance replacement method)
인스턴스 새로고침이 실행되면 인스턴스는 어떻게 교체될까요? 기존 노드가 모두 종료된 후 새 인스턴스가 생성될까요? 아니면 새 인스턴스가 먼저 실행된 후 기존 노드가 종료될까요?
정답은 설정에 따라 노드 교체 방식이 달라집니다. MinHealthyPercentage와 MaxHealthyPercentage를 조절하여 인스턴스 교체 수와 방법을 설정할 수 있습니다. ASG는 이러한 설정값을 기반으로 인스턴스 새로고침 시 유지해야 할 최소 및 최대 인스턴스 수를 계산합니다. AWS 공식 문서에 따르면 최소 및 최대 인스턴스 계산 공식은 다음과 같습니다.
- 참고자료: https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/APIReference/API_InstanceMaintenancePolicy.html
- 최소 정상 인스턴스 수 = Desired Capacity × (MinHealthyPercentage / 100)
- 최대 정상 인스턴스 수 = Desired Capacity × (MaxHealthyPercentage / 100)
예를 들어 ASG가 다음과 같이 설정되어 있다고 가정해봅시다.
- ASG Desired capacity: 1
- MinHealthyPercentage: 90
- MaxHealthyPercentage: 100
aws autoscaling start-instance-refresh \
--auto-scaling-group-name {ASG이름} \
--preferences '{
"MinHealthyPercentage": 90,
"MaxHealthyPercentage": 100
}'
Desired Capacity가 1대이므로 최대 인스턴스 개수는 1대입니다. Desired Capacity × MaxHealthyPercentage/100는 1 × 100/100으로 계산되어 1이 됩니다. 따라서 인스턴스 새로고침 시 기존 인스턴스를 종료한 후 새 인스턴스를 실행합니다.
위 설정은 운영환경에서 서비스 장애를 발생시키는 설정입니다. 왜냐하면 인스턴스 새로고침하는 동안 실행중인 인스턴스가 한개도 없기 때문입니다. 아래 그림을 보면 기존 인스턴스는 종료되었고 새로운 인스턴스는 생성 대기중입니다.
서비스 장애 없이 인스턴스 새로고침을 하려면 새 인스턴스가 먼저 생성된 후 기존 인스턴스가 종료되는 'Launch and terminate' 설정이 필요합니다. 아래 그림은 인스턴스 새로고침에서 Launch and terminate 설정이 작동하는 방식을 보여줍니다. 이 방식에서는 기존 인스턴스가 새 인스턴스가 생성될 때까지 서비스를 계속 실행하므로 장애가 발생하지 않습니다.
MinHealthyPercentage와 MaxHealthyPercentage 설정이 헷갈린다면 AWS 콘솔의 도움을 받아 계산할 수 있습니다. 또는 ChatGPT 등 AI 도구를 활용해 적절한 값을 설정하는 것도 좋은 방법입니다. 핵심은 인스턴스 새로고침 과정에서 서비스 장애가 발생하지 않도록 하는 것입니다.
MinHealthyPercentage과 MaxHealthyPercentage의 자세한 설명은 아래 AWS블로그를 참고하시면 좋습니다.
테라폼에서 인스턴스 새로고침 호출하는 방법
테라폼에서 ASG를 수정할 때 자동으로 인스턴스를 새로고침하는 방법이 있습니다. aws_autoscaling_group 리소스의 instance_refresh 속성을 사용하면 됩니다.
resource "aws_autoscaling_group" "demo" {
name = "${var.project_name}-rolling-asg"
instance_refresh {
strategy = "Rolling"
preferences {
min_healthy_percentage = 50
max_healthy_percentage = 100
instance_warmup = 30
}
}
롤백 방법
롤백은 두 가지 방법이 있습니다.
1. launch template을 수정하고 인스턴스 새로고침을 실행
첫 번째 롤백 방법은 ASG에서 launch template을 롤백하려는 버전으로 변경한 후 인스턴스 새로고침을 실행하는 것입니다.
2. 롤백 API를 호출하는 방법
두번째 롤백 방법은 롤백 API를 직접 호출하는 방법입니다. 이 방법을 사용하려면 선행조건으로 Desired configuration을 설정해야 합니다. Desired configuration은 인스턴스 새로고침 시 원하는 launch configuration을 지정하는 방식입니다.
aws autoscaling start-instance-refresh \
--auto-scaling-group-name {ASG이름} \
--desired-configuration '{
"LaunchTemplate": {
"LaunchTemplateId": "lt-",
"Version": "1" # 원하는 launch template 버전
}
}'
Launch template을 직접 설정하는 것과의 주요 차이점은 desired configuration이 롤백 API를 사용할 수 있다는 점입니다. Desired configuration은 원하는 상태로 변경하는 개념이기 때문에 배포 중 문제가 발생하면 기존 상태로 롤백이 가능합니다. 반면, ASG launch configuration을 직접 변경하는 방식은 이미 확정된 상태로 변경하는 것이므로 롤백 API를 사용할 수 없습니다.
Desired configuration을 사용하면 아래 그림처럼 Start rollback 버튼이 활성화됩니다. 이 버튼은 롤백 API를 호출합니다.
또한, Desired configuration은 인스턴스 새로고침 히스토리에 기록됩니다.
롤백이 시작되면 인스턴스 새로고침은 진행 중인 작업을 즉시 중단하고 롤백을 시작합니다. 이때 인스턴스 새로고침 상태는 'rollback in progress'로 변경됩니다.
롤백이 완료되면 Rollback status가 "Successful"로 변경됩니다.
인스턴스 새로고침 강제취소
인스턴스 새로고침 강제취소 기능은 2025년 9월에 출시되었습니다. 이 기능은 API나 AWS 콘솔을 통해 사용할 수 있습니다. 인스턴스 새로고침 강제 취소는 배포를 잘못했거나 신속하게 취소할때 사용할 수 있습니다.
인스턴스 강제 취소를 할 때 주의할 점은 설정이 변경된 인스턴스와 기존 인스턴스가 함께 존재한다는 것입니다. 아래 그림처럼 launch template 버전 1과 2로 생성된 인스턴스가 동시에 운영됩니다. 따라서 강제 취소 후에는 빠른 시간 내에 인스턴스 새로고침을 다시 실행해야 합니다.
파이프라인을 위한 ASG 최적화
파이프라인에서 가장 중요한 요소는 안정성과 롤백 기능입니다. 파이프라인 실행마다 서비스 장애가 발생하면 팀원들은 배포를 두려워하게 되고, 결국 해당 파이프라인을 사용하지 않게 됩니다. 또한 문제 발생 시 즉시 롤백할 수 있는 기능이 필수적입니다.
저는 아직 ASG 사용경험이 많지 않지만 며칠간 공부한 결과, 아래 부분을 최적화하는 것이 중요하다고 생각합니다.
- 애플리케이션이 안전하게 종료되는가?
EC2 인스턴스에서 실행 중인 애플리케이션은 인스턴스 종료 시 안전하게 종료되는지 확인해야 합니다. 내가 잘 알고 있는 애플리케이션이면 상관없지만, 대부분은 잘 알지 못하는 애플리케이션니다. 따라서 개발자와 소통하여 애플리케이션을 안전하게 종료하는 방법을 의논해야 합니다. ASG설정에서는 lifecycle hook을 설정하여 ASG가 EC2인스턴스를 종료하기 전에 안전하게 종료될 수있도록 해야 합니다.
- 인스턴스는 하나의 메인 애플리케이션만 실행
인스턴스에서 여러 애플리케이션이 실행되면 병목현상이 발생할 확률이 높아지고, 문제 발생 시 디버깅이 어렵습니다. 또한 배포할 때마다 신경 쓸 것이 많아져 배포 자체를 기피하게 됩니다. 이런 복잡한 문제를 예방하기 위해 인스턴스에서는 메인 애플리케이션 하나만 실행하는 것이 좋습니다.
- 인스턴스 배포 시간 단축
EC2 인스턴스는 부팅 후 애플리케이션 실행에 필요한 파일을 다운로드하고 설치합니다. 이 시간이 길어지면 배포 시간이 늘어나고, 시간이 지날수록 혹시 문제가 생긴 것이 아닐까 하는 불필요한 의심이 생깁니다. 따라서 인스턴스 배포 시간은 최대한 단축하는 것이 좋습니다.
ASG에서 배포 시간을 단축시키는 대표적인 방법은 다음 세 가지입니다.
첫째, golden AMI를 만드는 것입니다.
둘째, 헬스 체크 시간을 조절하는 것입니다. ASG는 EC2 또는 ELB 헬스 체크를 따르는데, 부팅을 최적화하여 헬스 체크 시간을 적절히 조절해야 합니다.
셋째, 인스턴스 새로고침 시간인 instance_warmup을 조절하는 방법입니다. ASG는 2025년 기준으로 rolling update만 지원하는데, instance_warmup 필드가 Rolling Update 사이클 시간입니다. 이 시간이 불필요하게 길면 배포 시간도 그만큼 늘어납니다.
마치며
이번 시간에는 ASG를 활용한 EC2 인스턴스 파이프라인에 대해 간단히 살펴봤습니다. ASG 기능이 매우 잘 구현되어 있어 파이프라인을 어렵지 않게 구성할 수 있습니다. 하지만 핵심은 파이프라인으로 인한 서비스 장애가 발생하지 않도록 세부 옵션들을 적절히 조절하는 것입니다.
다음 시간에는 ASG를 활용한 배포 전략(Rolling Update, Blue/Green, Canary)에 대해 살펴볼 예정입니다.
참고자료
- instance 새로고침 override 설명: https://aws.amazon.com/ko/blogs/compute/introducing-instance-maintenance-policy-for-amazon-ec2-auto-scaling/
- https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/APIReference/API_InstanceMaintenancePolicy.html
- https://aws.amazon.com/ko/blogs/compute/introducing-instance-refresh-for-ec2-auto-scaling/
- ASG blue/green 배포: https://aws.amazon.com/ko/blogs/compute/retaining-metrics-across-blue-green-deployment-for-predictive-scaling/
- https://aws.amazon.com/ko/about-aws/whats-new/2025/09/amazon-ec2-auto-scaling-forced-cancellation-instance/
'전공영역 공부 기록' 카테고리의 다른 글
| AWS Auto Scaling Group 배포 전략 (0) | 2025.10.12 |
|---|---|
| Argo CD v3.2 업데이트 내용: Application path에서 "." 또는 ""(공백)을 더 이상 사용할 수 없습니다. (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 |