클라우드 환경의 장점은 무엇일까요?
fail over에 대한 빠른 인지와 처리, 자동화? 비용? 개발 및 인프라 구성에 대한 편의성? 이에 따른 개발 속도와 서비스 생산성 증대?
많은 장점이 있겠지만, 저는 그중에서도 단연 으뜸은 탄력, 유연성이 아닐까 생각합니다.
그리고 Auto Scaling은 이러한 클라우드의 장점을 가장 잘 표현할 수 있는 서비스라고 생각합니다.
AWS EC2 Auto Scaling이란?
애플리케이션의 로드를 처리할 수 있는 정확한 수의 EC2 인스턴스 보유를 보장할 수 있습니다. 최소 인스턴스 수를 지정할 수 있으며, EC2 인스턴스 수는 이 값 아래로는 내려가지 않습니다. 최대 인스턴스 수를 지정할 수 있으며, EC2 인스턴스 수는 이 값을 넘기지 않습니다. 조정 정책 값에 따라 EC2 인스턴스가 시작 혹은 종료됩니다.
이를 통해 다음 이점을 기대할 수 있습니다.
-
내결함성 향상
비정상 상태일 때를 감지하여 종료한 다음 이를 대체할 인스턴스를 시작합니다. 혹은 복수의 AZ에 배포하도록 ASG를 구성하였을 때 하나의 AZ가 사용 불가 상태가 되어도, 다른 AZ에 같은 수의 인스턴스가 새로 배포되어 비교적 비슷한 품질의 서비스를 제공할 수 있습니다. -
가용성 향상
현재 트래픽 요구를 처리할 수 있는 적절한 용량을 갖출 수 있습니다. -
비용 관리 개선
필요에 따라 동적으로 인스턴스 수를 확장, 축소하면서 사용한 EC2 인스턴스에 대해서만 비용을 지불하므로 비용 절감을 기대할 수 있습니다.
Auto Scaling 제한
리전 제한
- 리전별 시작 구성: 200
- 리전별 Auto Scaling 그룹: 200
Auto Scaling 그룹 제한
- Auto Scaling 그룹당 조정 정책: 50
- Auto Scaling 그룹당 예약된 작업: 125
- Auto Scaling 그룹당 수명 주기 후크: 50
- Auto Scaling 그룹당 SNS 주제: 10
- Auto Scaling 그룹당 Classic Load Balancer: 50
- Auto Scaling 그룹당 대상 그룹: 50
조정 정책 제한
- 조정 정책당 단계 조정: 20
Auto Scaling API 제한
- 한 번에 최대 20개의 인스턴스 ID에 AttachInstances, DetachInstances, EnterStandby 및 ExitStandby를 사용할 수 있습니다.
- 한 번에 최대 10개의 로드 밸런서에 AttachLoadBalancers 및 DetachLoadBalancers를 사용할 수 있습니다.
- 한 번에 최대 10개의 대상 그룹에 AttachLoadBalancerTargetGroups 및 DetachLoadBalancerTargetGroups를 사용할 수 있습니다.
Auto Scaling 수명 주기
이 그림은 Auto Scaling 수명 주기를 표현한 그림입니다.
Scale out
Scale out 이벤트가 발생할 수 있는 경우는 다음과 같습니다.
- 수동
- 자동 (조정 정책에 따른)
- 예약
수동으로 desired capacity를 늘리는 방법
1. 콘솔에서 변경하기
EC2 콘솔 화면 > 탐색 창(왼쪽 패널)의 Auto Scaling Groups 선택 > 변경을 하고자하는 Auto Scaling Group 선택 > Details 탭에서 Edit 선택 > Desired에서 한 개씩 원하는 용량 증가하면서 올리기
2. CLI를 사용하여 변경하기
set-desired-capacity 명령을 사용하여 변경합니다.
aws autoscaling set-desired-capacity --auto-scaling-group-name my-asg --desired-capacity 2 --honor-cooldown
–honor-cooldown 옵션을 지정해주어 기본 동작을 재정의하고 휴지 기간이 완료될 때까지 기다릴 수 있습니다.
-
휴지 기간?
Auto Scaling 그룹에 구성할 수 있는 설정으로 이전 조정 활동이 적용되기 전에 인스턴스를 추가로 시작하거나 종료하지 않도록 합니다. 조정 정책을 사용하여 동적으로 조정하면 휴지 기간이 완료될 때까지 대기한 후에 조정 활동을 재기합니다. 하지만 수동으로 조정하는 경우 기본적으로 휴지 기간이 적용되지 않습니다. 만일 인스턴스가 비정상적 상태인 경우 휴지 기간이 완료될 때까지 대기하지 않고 비정상적 인스턴스를 교체합니다. EC2 인스턴스가 inService 즉, 가용 상태에 도달하기까지 수 분의 시간이 걸립니다. 휴지 기간이 없다면, 조정 정책에 의해 Max 만큼의 인스턴스가 생성될 수 있습니다. 적절한 휴지 기간은 이러한 상황에 매우 유리하게 작용합니다. -
기본 휴지
기본값은 300초입니다. 단순 조정 정책의 모든 동적 조정 활동에 자동으로 적용되며, 필요한 경우 수동 조정 활동에 적용되도록 요청할 수 있습니다. -
조정 특정 휴지
조정 특정 휴지 기간은 기본 휴지 기간보다 우선합니다. 특정 기준 또는 지표에 따라 인스턴스를 종료하는 Scale in 정책에서 자주 사용됩니다.
인스턴스를 종료할지 여부를 결정하는데 굳이 300초라는 휴지 기간을 둘 필요가 없기 때문에 더 적은 시간을 소요하도록 설정한다면 비용 절감의 효과를 기대할 수 있습니다.
만일 여러 인스턴스를 시작하는 경우 휴지 기간은 마지막 인스턴스가 시작된 시점에 적용되기 시작합니다. 수명주기 후크는 휴지 기간에 영향을 미칠 수 있습니다. 휴지 기간은 해당 인스턴스가 Wait(대기) 상태를 벗어날 때까지 시작되지 않습니다.
조정 정책을 걸어 자동으로 이벤트를 주는 방법
1. 대상 추적 조정 정책
- Target tracking scaling
특정 측정치의 목표 값을 기준으로 그룹의 desired capacity를 늘리거나 줄입니다.- 대상당 애플리케이션 로드 밸런서 요청 수
- 평균 CPU 사용률
- 평균 네트워크 입력 (바이트)
- 평균 네트워크 출력 (바이트)
2. 단계 또는 단순 조정 정책
-
Step scaling
조정 값(임계치) 초과의 정도에 따라 desired capacity를 늘리거나 줄입니다. -
Simple scaling
조정 값에 따라 desired capacity를 늘리거나 줄입니다.
예약된 시간에 이벤트를 주는 방법
서비스 카테고리에 따라 블랙프라이데이, 크리스마스, 명절, 이벤트(마케팅)가 있는 날 등 미리 트래픽 증가를 예상할 수 있는 날이 있을 것입니다.
동적 설정을 해두었더라도 미리 리소스를 확보해둔다면 좀더 양질의 서비스를 제공할 수 있을 것입니다.
1. 콘솔에서 생성하기
EC2 콘솔 화면 > 탐색 창(왼쪽 패널)의 Auto Scaling Groups 선택 > 변경을 하고자하는 Auto Scaling Group 선택 > Scheduled Actions 탭에서 Create Scheduled Action 선택 > 설정 지정 > Create
- Min, Max, Desired Capacity 중 하나 이상을 사용하여 그룹의 크기 지정합니다.
- Recurrence 옵션을 선택합니다. Once, Cron, Every을 선택할 수 있고 반복일정을 선택한 경우 Start Time 과 End Time을 지정할 수 있습니다.
2. CLI를 사용하여 변경하기
put-scheduled-update-group-action명령을 사용합니다.
aws autoscaling put-scheduled-update-group-action --scheduled-action-name scaleup-schedule-year --auto-scaling-group-name my-asg --recurrence "0 0 25 12 0" --desired-capacity 3
Scale in
Scale in 이벤트가 발생할 수 있는 경우는 위의 Scale out과 동일하게 수동, 자동(설정값에 따른), 예약이 있습니다.
Stand by 상태로 만들기
1. 콘솔
EC2 콘솔 > 탐색창(왼쪽 패널) Auto Scaling Groups > Group 선택 > Instances 탭에서 인스턴스 선택 > Actions, Set to Standby
2. CLI
enter-standby 이용.
aws autoscaling enter-standby --instance-ids ${instance_id} --auto-scaling-group-name ${instance_group} --should-decrement-desired-capacity
- Stand by와 Detach의 차이점?
Stand by 상태의 인스턴스는 서비스에서는 분리되지만 여전히 ASG에 의해 관리되며, 자동으로 로드밸런서에서 분리됩니다. Detach를 할 경우 하나의 독립된 인스턴스가 되며, 다른 ASG에 연결도 가능합니다.
위 글은 AWS 설명서의 문서를 바탕으로 작성되었습니다.
comments powered by Disqus