전공영역 공부 기록

AWS Auto Scaling Group 주요기능

악분 2025. 10. 8. 11:23
반응형

개요

이 글은 AWS Auto Scaling Group(이하, ASG)의 주요 기능에 대해 정리했습니다. ASG는 EC2 인스턴스를 그룹으로 관리하며, Auto Scaling이나 비정상 노드 자동 교체 등 EC2 인스턴스 관리를 위한 AWS 리소스입니다.

 

이 글에서는 다음 주제들에 대한 내용을 다룹니다.

  • ASG를 사용하면 좋은 4가지 사례는 무엇인가요?
  • Launch Template과 Launch Configuration의 차이점은 무엇이며, 어느 것을 사용하는 것이 권장되나요?
  • ASG의 Desired capacity, Min capacity, Max capacity는 각각 무엇을 의미하며 어떤 역할을 하나요?
  • Dynamic Scaling의 3가지 정책(Target tracking, Step scaling, Simple scaling)의 차이점은 무엇인가요?
  • 인스턴스 관리 정책 4가지(Launch before terminating, Terminate and launch, No policy, Custom behavior)는 각각 어떻게 동작하나요?
  • ASG 리밸런싱이란 무엇이며, 주의해야 할 점은 무엇인가요?
  • Target Tracking Scaling의 특징은 무엇이며, Scale-out과 Scale-in 시 동작 방식의 차이는 무엇인가요?
  • Instance refresh는 언제 사용하며, AWS API로는 어떻게 실행하나요?

 

이 글을 쓰게 된 배경

저는 커리어를 쿠버네티스로 시작했기 때문에 애플리케이션 배포는 오직 쿠버네티스에서만 이루어진다고 생각했습니다. 그러나 최근에는 상황에 맞게 적절한 배포 환경을 선택해야 한다는 것을 깨달았고, 쿠버네티스를 사용하는 비중이 점차 줄어들고 있습니다.

 

최근 AWS ASG를 사용하는 것이 적합하다고 판단한 애플리케이션이 있어서, 이 기회에 ASG의 주요 기능을 정리해 보고자 합니다.

 

사실 ASG나 쿠버네티스나 배포 개념은 동일하므로 큰 차이점은 없습니다. 다만 제가 ASG를 많이 사용해보지 않아 아직 익숙하지 않다는 점만 있었습니다.

 

Auto Scaling Group이란?

ASG는 EC2인스턴스 그룹을 생성하여 EC2인스턴스들을 효율적으로 관리합니다. 그룹으로 묶어 관리함으로써 단일 설정으로 동일한 EC2인스턴스 여러대를 쉽게 관리할 수 있습니다.

 

ASG는 언제 쓰면 좋나요?

제가 생각하는 ASG를 쓰면 좋은 사례는 아래 4가지입니다.

 

1. 동일한 EC2인스턴스를 2대 이상 생성해야 하는 경우

ASG는 같은 설정을 가지고 있는 EC2인스턴스를 언제든지 n개 생성할 수 있습니다. Auto Scaling을 사용하지 않으면 EC2인스턴스를 n개 생성해야 하는데, ASG는 EC2인스턴스 개수만 설정하면 됩니다.

 

2. EC2 인스턴스를 Auto Scaling 해야 하는 경우

Auto Scaling 설정을 통해 특정 조건이 충족되면 ASG가 EC2 인스턴스 수를 자동으로 조절합니다. ASG 없이 이러한 기능을 구현하려면 직접 관련 로직을 개발하거나 Lambda 등의 추가 서비스를 활용해야 합니다.

 

3. EC2 인스턴스 배포 파이프라인을 작성해야 하는 경우

ASG는 ASG API를 통해 새로운 EC2인스턴스를 배포하는 기능이 있습니다. 이 ASG API를 활용하면 EC2인스턴스 배포를 자동화할 수 있습니다. EC2인스턴스 배포 옵션은 새 인스턴스 생성 후 기존 인스턴스 제거(Rollingupdate), 기존 인스턴스 제거 후 새 인스턴스 생성 등이 있습니다.

 

4. 비정상 EC2인스턴스를 자동으로 교체해야 하는 경우

ASG는 비정상 EC2인스턴스를 발견하면 교체합니다. EC2인스턴스는 네트워크, 디스크 등의 이유로 비정상상태가 종종 발생하는데, 비정상 EC2인스턴스는 사람이 개입해서 해결하거나 EC2인스턴스를 교체해줘야 합니다.

 

ASG 장점

ASG 장점은 AWS의 "ASG benefits" 문서에 잘 설명되어 있습니다.

 

이 글에서는 "ASG를 언제 쓰면 좋나요?" 챕터에서 ASG의 주요 장점들을 이미 다루었습니다. 그러나 빠진 중요한 장점 하나는 가용성입니다.

 

ASG는 EC2 인스턴스를 생성할 때 여러 AZ(Availability Zones)에 균등하게 분산시킵니다. 이는 특정 AZ에 장애가 발생했을 경우에도 서비스가 계속 운영될 수 있도록 합니다. 다만, 모든 상황에서 여러 AZ에 EC2 인스턴스를 배포하는 것이 최적은 아닙니다. AZ 간 데이터 이동은 네트워크 비용이 발생하므로, 비용을 극소화해야 하는 경우에는 단일 AZ만 사용하는 경우도 있습니다.

 

ASG 리밸런싱

ASG는 기존 실행되고 있는 EC2인스턴스의 AZ 분산 상태를 확인하고, 균등하게 분산되어 있지 않으면 리밸런싱을 수행합니다.

 

아직 ASG 사용 경험이 많지 않아 리밸런싱을 직접 경험해보지는 않았지만, EKS karpenter consolidation과 비슷하게 생각하면 의도와 상관없이 노드가 자주 교체되는 현상으로 이해했습니다. 즉, 애플리케이션이 graceshtudown이 보장되지 않으면, ASG 리밸런싱 때문에 장애가 발생할 수 있습니다.

 

만약 ASG 리밸런싱으로 인한 장애 발생 가능성이 걱정된다면, Suspended Processes 옵션에서 원하지 않는 리밸런싱 액션을 설정해야 합니다. 예를 들어 AZ 리밸런싱을 비활성화하려면 “Suspended Processes=AZRebalance”를 설정하면 됩니다.

 

ASG가 관리하는 EC2 instance 설정은 어떻게 하나요?

EC2인스턴스를 생성하려면 VPC subnet, EC2 instance profile, Security Group, AMI 등이 필요합니다. 이러한 설정은 어떻게 관리할까요?

 

EC2인스턴스 설정을 관리하는 전용 AWS 리소스가 있습니다. 바로 Launch Template과 Launch Configuration입니다. ASG는 이 두 가지 중 하나만 사용하면 EC2인스턴스 설정을 별도로 구성할 필요가 없습니다. ASG는 EC2인스턴스 개수 관리와 Auto Scaling 정책 설정 등 EC2인스턴스의 관리 방식을 정의합니다.

 

앞서 이야기한 것처럼, EC2인스턴스 설정은 Launch Template 또는 Launch Configuration에서 합니다. 둘 중 하나를 선택해야 하는데, 특별한 이유가 없다면 Launch Template을 권장합니다. Launch Template은 버전 관리 등 Launch Configuration보다 더 많은 기능을 제공합니다.

 

아래 그림은 ASG가 Launch Template을 사용하여 EC2인스턴스를 설정한 예시입니다.

 

아래 그림은 Launch template에서 버전을 설정할 수 있다는 것을 보여줍니다.

 

아래 그림에서 보이는 것처럼 Launch template은 EC2인스턴스를 생성할 때 설정하는 옵션과 거의 유사합니다. Launch template은 AMI, EC2인스턴스 타입, key pair, VPC subnet, Storage, Security group, user data 등을 설정할 수 있습니다.

 

ASG에서 EC2인스턴스 개수 설정은 어떻게 하나요?

ASG가 관리하는 EC2 인스턴스 개수는 Desired capacity로 설정됩니다. ASG는 설정된 Desired capacity대로 EC2인스턴스 개수를 조절합니다.

 

Desired capacity 이외에 Min, Max capacity가 있는데, 이 두 capacity는 Auto Scaling에 사용됩니다.

 

ASG에서 Auto Scaling 설정은 어떻게 하나요?

Auto Scaling이란 ASG가 Scaling 설정에 따라 Desired capacity를 자동으로 조절하는 것입니다. 사용자는 Desired capacity 조절을 어떻게 할지에 대한 정책을 설정해야 합니다.

 

ASG의 Auto Scaling은 다음 3가지 유형이 있습니다.

  • Dynamic scaling: 실시간 상황에 따라 인스턴스 개수를 조절합니다. 이때 scaling 기준으로 CloudWatch metrics와 CloudWatch alarm을 사용합니다.
  • Predictive scaling: 과거 데이터를 분석하여 미래에 필요한 인스턴스 개수를 예측합니다. 과거 14일간의 데이터를 머신러닝으로 분석해 매시간 향후 48시간에 대한 수요를 예측합니다.
  • Scheduled actions: 특정 시간에 인스턴스 개수를 조절하도록 미리 일정을 설정합니다.

 

ASG는 Auto scaling을 설정했을 때 Desired capacity가 무분별하게 증가하거나 감소하는 것을 방지하기 위해 min, max 값으로 상한선과 하한선을 설정합니다.

  • Desired capacity: 현재 EC2 인스턴스 개수
  • Min capacity: Auto Scaling이 실행될 때 최소로 유지해야 하는 EC2 인스턴스 개수
  • Max capacity: Auto Scaling이 실행될 때 최대로 실행할 수 있는 EC2 인스턴스 개수

 

많이 사용하는 scaling은 Dynamic scaling입니다. Dynamic scaling은 3가지 scaling 정책이 있습니다.

  • Target tracking scaling: cloudwatch metrics을 기준으로 scaling을 합니다.
  • Step scaling: cloudwatch alarm을 기준으로 scaling으로 하고 여러 기준(step)을 설정할 수 있습니다.
  • Simple scaling: cloudwatch alarm을 기준으로 scaling으로 합니다.

 

Target Tracking Scaling은 목표를 달성하기 위해 필요한 Desired Capacity를 스스로 계산합니다. 사용자는 검사 기준이 되는 CloudWatch metric과 해당 metric의 Target value만 설정하면 됩니다. ASG는 현재 metric이 Target value보다 크면 Desired capacity를 계산하여 적절히 조정합니다. Desired capacity를 증가시킬 때는 공격적으로 EC2 인스턴스 개수를 늘리지만, 감소시킬 때는 보수적으로 줄입니다.

 

ASG 인스턴스 관리 정책(예: 비정상 노드 교체)

ASG는 EC2인스턴스의 비정상(Unhealthy) 상태를 감지하고 해당 EC2 인스턴스를 교체합니다. 이러한 비정상 노드 교체 기능은 인스턴스 관리(Instance Maintenance) 기능의 일부입니다. 인스턴스를 교체할 때 적용되는 규칙을 인스턴스 관리 정책(Instance Maintenance Policy)이라고 합니다. 

 

인스턴스 관리 정책은 총 4가지가 있습니다.

  • Launch before terminating: EC2인스턴스를 새로 생성하고 그 이후에 기존 인스턴스를 제거합니다.
  • Terminate and launch: 기존 EC2인스턴스를 제거하고 EC2인스턴스를 생성합니다.
  • No policy: 리밸런싱이 동작할 때는 Launch before terminating방식으로 동작하고 그 이외의 상황은 Terminate and launch로 동작합니다.
  • Custom behavior: 사용자가 직접 종료할 EC2인스턴스, 생성할 EC2인스턴스를 설정합니다.

 

아래 예제는 ASG가 비정상 인스턴스를 감지하고 교체하는 과정을 보여줍니다. 인스턴스 관리 정책으로는 No policy를 사용했습니다. 그림에서 볼 수 있듯이 ASG는 먼저 새로운 EC2 인스턴스를 생성한 후 기존의 비정상 인스턴스를 제거했습니다.

 

ASG로 배포한 EC2인스턴스는 어떻게 ELB와 연동하나요?

ASG는 AWS ELB(Network Load Balancer, Application Load Balancer)와 연동할 수 있습니다. ASG를 ELB에 연동하면 ASG가 생성한 모든 EC2 인스턴스가 ELB에 자동으로 연결됩니다.

 

ASG와 ELB를 연결할 때는 직접 ELB에 연결하는 것이 아니라 Target Group에 연결합니다. ASG로 생성된 EC2 인스턴스는 자동으로 이 Target Group에 추가되어 ELB와 연동됩니다. 주의할 점은 EC2 인스턴스가 ELB의 헬스 체크를 통과할 수 있도록 적절한 헬스 체크 기능을 구현해야 한다는 것입니다. 인스턴스에 적절한 헬스체크가 구현되어 있지 않으면 ELB 헬스체크가 지속적으로 unhealthy 상태를 반환하여 운영에 혼란을 발생시킵니다.

 

ASG로 배포된 인스턴스는 어떻게 재실행할 수 있나요?(Instance refresh)

ASG에서 EC2 인스턴스를 재실행기능은 없고 인스턴스 교체하는 인스턴스 새로고침이 있습니다. 인스턴스 새로고침은 AWS API 호출이나 AWS 콘솔에서 실행할 수 있습니다.

aws autoscaling start-instance-refresh \
    --auto-scaling-group-name {ASG이름}

 

인스턴스 새로고침은 ASG를 활용한 배포 파이프라인에서도 사용됩니다. 배포 파이프라인에 대해서는 다음 시간에 다룹니다.

 

다음 시간에 다룰 내용

이번 시간에는 ASG의 주요 개념과 기능을 다뤘습니다. 다음 시간에는 인스턴스 새로고침에 대해 더 자세히 살펴보고, ASG를 활용한 배포 파이프라인을 구체적으로 알아볼 예정입니다.

 

참고자료

반응형
저작자표시 비영리 변경금지 (새창열림)

'전공영역 공부 기록' 카테고리의 다른 글

Argo CD v3.2 업데이트 내용: Application path에서 "." 또는 ""(공백)을 더 이상 사용할 수 없습니다.  (0) 2025.10.09
AWS Auto Scaling group을 이용한 EC2인스턴스 배포 파이프라인 작성 방법  (0) 2025.10.09
AWS EC2인스턴스의 UserData가 잘 실행되었는지 확인하는 방법  (2) 2025.10.06
AWS 모든 노드를 관리하는 Systems Manager의 원리와 기능  (0) 2025.09.08
Kubeflow pipeline  (2) 2025.09.01

'전공영역 공부 기록'의 다른글

  • 현재글AWS Auto Scaling Group 주요기능

관련글

댓글

티스토리툴바