[AWS] Auto Scaling Group(ASG)이란? 쉽게 특징 정리 (Minimum/Maximum Capacity, Scaling Policy, Termination Policy, Instance Protection)

◇  공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇

 

 

 

Auto Scaling

스케일링(Scaling) 이란 서버의 컴퓨팅 파워를 늘리거나 줄이는 것을 말한다.

컴퓨팅 파워를 늘리는 방법에는 2가지가 있다.

• Scale Up (수직적 확장): 컴퓨팅의 성능을 높임.
• Scale Out (수평적 확장): 같은 성능의 컴퓨팅의 갯수를 늘림.

반대로 컴퓨팅을 줄이는 방법.

• Scale In (수평적 축소)
• Scale Down (수직적 축소)

 

[Auto Scaling]

Auto Scaling은 ELB와 함께 사용하는 경우가 많으며, ELB의 Target Group 아래의 리소스에 장애가 발생하거나 부하가 증가할 때, Auto Scaling이 자동으로 새로운 리소스를 생성하여 ELB의 Target Group에 추가한다.

 

반대로 부하가 줄어들면 Target Group 내의 리소스를 줄이는 것도 가능합니다.
Auto Scaling을 이용함으로써 시스템의 가용성과 비용 효율성을 높일 수 있다.

 

 

Auto Scaling 사용할 수 있는 AWS 서비스

• EC2
• RDS: Aurora
• DynamoDB
• ECS
• ...etc

 

 

Auto Scaling Group (ASG)

 

 

Auto Scaling Group은 애플리케이션의 수요에 따라 EC2 인스턴스의 수를 자동으로 조정하는 기능이다.

이를 통해 리소스를 효율적으로 관리하고 비용을 최적화할 수 있다.

ASG

최소, 최대, 원하는 인스턴스 수 등의 파라미터에 따라 AWS 리소스의 스케일링(스케일 아웃/인)을 자동으로 수행한다.
Auto Scaling의 Health Check에 의해 Auto Scaling 그룹 내의 정상적인 리소스 수가 필요한 리소스 수보다 적을 경우나, AWS 리소스의 부하 상황에 따라 자동으로 새로운 리소스가 시작된다.

 

📌) VPC 및 서브넷

ASG를 만들 때 VPC와 서브넷을 지정해야 한다.

 

📌) 최소, 최대, 원하는 인스턴스 수

1. Minimum Capacity: 최소 인스턴스 수.
   트래픽이 적더라도 설정한 인스턴스 수를 유지한다.
2. Maximum Capacity: 최대 인스턴스 수.
   트래픽이 급증하더라도 이 수를 초과하지 않는다.
3. Desired Capacity: ASG가 유지하려는 인스턴스의 목표 수.
   ASG는 이 수를 유지하기 위해 인스턴스를 추가하거나 제거한다

https://www.geeksforgeeks.org/create-and-configure-the-auto-scaling-group-in-ec2/

 

📌) Launch Configuration와 Launch Template (Scale Out 기동 템플릿)

ASG가 Scale Out(확장)할 때, 새로 추가될 EC2 인스턴스를 시작할 때 사용할 설정을 정의한다.

여기에는 AMI ID, 인스턴스 유형, 키 페어, 보안 그룹, 블록 디바이스 매핑 등이 포함됩니다.

https://www.geeksforgeeks.org/create-and-configure-the-auto-scaling-group-in-ec2/

 

📌) Health Check 와 Grace Period

• Health Check 유형: EC2, ELB 등 인스턴스의 상태를 확인할 방법을 지정한다.
• Health Check Grace Period: 인스턴스 시작 후 헬스 체크를 시작하기 전에 기다리는 시간(초).

 

 

 

Scaling Policy (스케일링 정책)

스케일링은 AWS 리소스의 부하 상황이나 일정에 따라 자동으로 실행될 수 있으며, 수동으로도 수행할 수 있다.

스케일링이 발생하는 조건과 스케일 아웃/인을 수행하는 작업을 "Scaling Policy"에 설정한다.

 

1. Manual Scaling (수동 스케일링) : 지금부터 인스턴스는 4대로 운영
2. Dynamic Scaling (동적 스케일링) : CPU 사용량이 90%가 되면 인스턴스 2대로 운영
   1. Simple Scaling
   2. Step Scaling
   3. Target Tracking Scaling
3. Predictive Scaling (예측 스케일링) : 과거 사용량 패턴을 학습해서 미래의 인스턴스 수 정함
4. Scheduled Scaling (스케줄 기반 스케일링) : 오후 6시에 인스턴스 2대 추가

 

📈 1. Manual Scaling (수동 스케일링)

사용자가 수동으로 스케일링을 수행한다.
예시) 인스턴스 수를 3대로 설정

📈 2. Dynamic Scaling (동적 스케일링)

실시간 성능에 따라 자동으로 스케일링을 수행한다.

스케일링 발생 조건에 따라 "Simple Scaling", "Target Scaling", "Target Tracking Scaling"으로 나뉜다.

【Simple Scaling】 하나의 임계값 기준

특정 메트릭스(CPU 사용률 등 시스템 성능에 관한 데이터)에 대한 하나의 임계값을 기준으로 스케일링을 수행한다.
예시) 300초 동안 평균 CPU 사용률이 50%를 초과하면 인스턴스를 1대 추가하도록 설정

【Step Scaling】여러개의 임계값 기준, 단계적으로 스케일링

특정 메트릭스에 대한 여러(mutiple) 임계값을 기준으로 단계적으로 스케일링을 수행한다.
예시) 300초 동안 평균 CPU 사용률이 50%를 초과하면 인스턴스를 1대 추가하고, 90%를 초과하면 2대를 추가하도록 설정

【Target Tracking Scaling】

특정 메트릭스가 지정된 목표 값이 되도록 스케일링을 수행한다. 인스턴스 수의 증감은 AWS에서 조정된다.
예시) 평균 CPU 사용률이 30%가 되도록 설정되어 있습니다.

 

📈 3. Predictive Scaling (예측 스케일링)

과거의 성능 데이터를 바탕으로 미래의 리소스 수요를 예측하여 최적의 리소스 수를 맞추도록 스케일링을 수행한다.
예시) 과거 1주일의 CPU 사용률 데이터를 기반으로 인스턴스 수를 조정하도록 설정

📈 4. Scheduled Scaling (스케줄 기반 스케일링)

일정한 날짜와 시간에 1회만 또는 정기적인 일정에 따라 스케일링을 수행한다.
예시) 매일 오전 8시 30분부터 인스턴스 수를 4대로 설정

 

 

 

Auto Scaling의 Health Check

리소스가 EC2 인스턴스인 경우, Auto Scaling의 Health Check 유형에는 "EC2"와 "ELB"가 있다.

• EC2 - 인스턴스의 상태 체크 결과를 확인한다
• ELB - 지정된 연결 대상에 대한 응답 확인을 수행한다

Auto Scaling의 Health Check에서 이상이 발생한 리소스는 자동으로 종료된다.
Default(기본)으로 "EC2"가 활성화되어 있고, "ELB"는 비활성화되어 있지만,
"EC2"와 "ELB" 모두 활성화하는 것이 권장된다.

[EC2는 ON, ELB는 OFF의 경우]

만약 Auto Scaling Group의 Health Check 설정에서 "EC2"가 활성화되고 "ELB"가 비활성화된 경우, ELB에서 Health Check에 문제가 있어도, EC2의 Health Check가 정상이라면 인스턴스는 계속 실행된다.

 

예를 들어, ELB Health Check에서 지정된 URL에 문제가 발생(HTTP 404 오류 등)하더라도, 인스턴스 자체는 정상적으로 동작할 수 있으므로 ALB에서 부하가 분산되지 않게 되지만 인스턴스가 종료되지 않는다.

인스턴스가 종료되지 않으면 새로운 인스턴스가 시작되지 않아서 서비스가 중단될 가능성이 있다.

Health Check 설정에서 "ELB"도 활성화하면, ELB에서 Health Check에 응답하지 않는 인스턴스가 종료되고 새로운 정상 인스턴스가 시작됩니다.

 

 

Termination Policy 종료 정책 (Scale In 순서)

ASG가 스케일 인(Scale In) 할 때, 어떤 우선 순위로 인스턴스를 종료 시킬지를 정의한다.

• Default Termination Policy - 기본적으로 선택되는 규칙
• Custom Termination Policy - 따로 고급 설정으로 선택가능한 규칙

 

Default Termination Policy (📌기본) 

Auto Scaling Group의 Default Termination Policy는 인스턴스를 종료할 때 자동(기본)으로 적용되는 규칙으로, 다음과 같은 조건을 순서로 인스턴스를 종료한다

 

1. AZ Rebalancing: 먼저, Auto Scaling은 모든 가용 영역(AZ) 간의 인스턴스 수가 균형을 이루도록 한다. 특정 가용 영역에 인스턴스가 많다면 그 영역의 인스턴스를 우선적으로 종료한다.
2. Oldest Launch Configuration: 여러 (Launch Configuration 또는 Launch Template)을 사용하는 경우, 가장 오래된 Launch Configuration으로 생성된 인스턴스를 우선적으로 종료한다. 이는 최신의 런치 구성을 유지하는 데 유용하다.
3. Closest to Next Billing Hour: 위의 두 조건으로도 동일한 인스턴스가 여러 개 있을 경우, 다음 결제 시간이 가장 가까운 인스턴스를 종료한다. 이렇게 하면 비용 절약을 극대화할 수 있습니다.
4. Random Selection: 위의 조건을 모두 만족하지 않는 경우에는 무작위로 인스턴스를 선택하여 종료한다.

https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-termination-policies.html

 

 

Custom Termination Policy

1. Newest Instance: 가장 최근에 시작된 인스턴스를 먼저 종료
2. Oldest Instance: 가장 오래된 인스턴스를 먼저 종료
3. Oldest Launch Configuration: 가장 오래된 Launch Configuration을 사용하여 시작된 인스턴스를 먼저 종료
4. ClosestToNextInstanceHour: 다음 결제 청구 시간이 가장 가까운 인스턴스를 먼저 종료

 

Scale In 시 특정 리소스가 종료되지 않도록 하려면 "Instance Protection(인스턴스 보호)"를 활성화해야 한다

 

---

 

🤔 SAA-C03 문제

다음과 같은 환경이 있습니다: 두 개의 가용 영역(AZ)에 걸친 Auto Scaling 그룹이 있고, AZ-a와 AZ-b로 불립니다. AZ-a에는 4개의 EC2 인스턴스가 있고, AZ-b에는 3개의 EC2 인스턴스가 있습니다. Auto Scaling 그룹은 기본 종료 정책(Default Termination Policy)을 사용하고 있습니다. 어떤 인스턴스도 축소(scale-in) 이벤트에서 보호되지 않습니다.

만약 축소 이벤트가 발생하면, Auto Scaling은 어떻게 진행할까요?

1. Auto Scaling은 종료할 인스턴스를 무작위로 선택합니다.
2. Auto Scaling은 모든 인스턴스 중에서 가장 오래된 런치 구성을 가진 인스턴스를 종료합니다.
3. Auto Scaling은 4개의 EC2 인스턴스가 있는 가용 영역을 선택한 후 계속 평가를 진행합니다.
4. Auto Scaling은 모든 인스턴스 중에서 다음 결제 시간이 가장 가까운 인스턴스를 종료합니다.

정답

정답. 3번