[Devops] Auto scaling - Scale in/out

Auto scaling이란?

 AWS Auto scaling을 사용하여 관련 또는 연결된 크기 조정 가능한 리소스에 대한 자동 크기 조정을 몇 분 만에 구성할 수 있다. 예를 들어 태그를 사용하여 프로덕션, 테스트 또는 개발과 같은 카테고리로 리소스를 그룹화할 수 있습니다. 그런 다음 각 카테고리에 속하는 크기 조정 가능한 리소스에 대한 크기 조정 계획을 검색 및 설정할 수 있습니다. 또는 클라우드 인프라에 AWS CloudFormation이 포함된 경우 리소스 컬렉션을 만드는 데 사용할 Stack 템플릿을 정의할 수 있습니다. 그런 다음 각 Stack에 속하는 크기 조정 가능한 리소스에 대한 scaling plan을 생성합니다.

 

AWS Auto Scaling은 다음 서비스 및 리소스에 대한 scaling plan을 지원합니다.

• Amazon Aurora - Aurora DB 클러스터에 프로비저닝된 Aurora 읽기 전용 복제본 수를 늘리거나 줄입니다.
• Amazon EC2 Auto Scaling - Auto Scaling 그룹의 용량을 원하는대로 늘리거나 줄여 EC2 인스턴스를 시작하거나 종료합니다.
• Amazon Elastic Container Service - Amazon ECS에서 원하는 태스크 수를 늘리거나 줄입니다.
• Amazon DynamoDB - DynamoDB 테이블 또는 전역 보조 인덱스의 프로비저닝된 읽기 및 쓰기 용량을 늘리거나 줄입니다.
• 스팟 플릿 - 스팟 플릿의 대상 용량을 늘리거나 줄여 EC2 인스턴스를 시작하거나 종료합니다.

 

Scaling Plan(크기 조정 계획)의 기능 및 이점

Scaling Plan 에서는 다음과 같은 기능을 제공한다.

• 리소스 검색 – AWS Auto Scaling은 애플리케이션에서 크기 조정할 수 있는 리소스를 찾는 데 도움이 되는 자동 리소스 검색을 제공합니다.
• 동적 크기 조정 - 크기 조정 계획은 Amazon EC2 Auto Scaling 및 Application Auto Scaling 서비스를 사용하여 트래픽 또는 워크로드의 변화를 처리하기 위해 크기 조정 가능한 리소스의 용량을 조정합니다. 동적 크기 조정 지표는 표준 사용률이나 처리량 지표, 또는 사용자 지정 지표일 수 있습니다.
• 기본 제공 크기 조정 권장 사항 – AWS Auto Scaling은 성능, 비용 또는 둘 사이의 균형을 최적화하는 데 사용할 수 있는 권장 사항이 포함된 크기 조정 전략을 제공합니다.
• 예측 크기 조정 - 크기 조정 계획은 Auto Scaling 그룹에 대한 예측 크기 조정도 지원합니다. 이를 통해 정기적 스파이크가 발생할 때 Amazon EC2 용량 크기를 더욱 빠르게 조정할 수 있습니다.

 

이런 Scaling Plan의 기능들과 이점을 사용하기 위해 우리는 AWS Auto scaling 을 사용한다.

 

 

Auto scaling을 위해 준비해야되는 항목들

1. private subnet의 EC2에 대한 Custom AMI 생성
2. Auto scaling을 위한 Launch Template 생성
   • AMI
   • Key pair
   • Network
   • Storage 등
3. Auto scaling 용 Application Load Balancer 구성

 

Private subnet의 EC2에 대한 Custom AMI 생성

 Private EC2 를 선택한 뒤 우클릭을 누르고 '이미지 및 템플릿' 선택 후 '이미지 생성'을 클릭한다. 앞에서 했던 것처럼 Tag 에서 'Name' 에 적절한 이름을 넣어주고 생성해준다.

 그렇게 이미지를 생성한 뒤, EC2 서비스에서 '이미지'의 'AMI'를 눌러보면, 잘 생성된 것을 확인할 수 있다.

 

 

Auto scaling을 위한 Launch Template 생성

그리고나서 Launch Template('인스턴스' -> '시작 템플릿')을 생성해준다. 

Launch Template을 생성하는 화면에서 "애플리케이션 및 OS 이미지"에서 아까 만들었던 ami-private-ec2를 선택한다.

 

그리고 해당 Launch Template을 만들 때에 특정 서브넷으로 국한시키지 않기 위해 'subnet'은 '시작 템플릿에 포함시키지 않음(Don't include in launch template)'을 선택한다.

Resource tag는 launch template으로 EC2를 만들 때에 붙이는 tag를 의미하는데 해당 예제에서는 공란으로 둔다.

 Launch Template을 만들고 난 뒤, 만들어진 Launch Template을 선택해보면, "작업(Actions)"에 다양한 항목들이 존재한다. 각 항목들의 의미를 살펴보자

• 템플릿으로 인스턴스 시작 - Launch instance from template  : 템플릿으로 인스턴스를 생성할 때 사용한다.
• 템플릿 수정(새 버전 생성) - Modify Template (create new version) : 템플릿을 수정할 때 사용한다.
• 기본 버전 설정 - Set default version : 템플릿을 수정하면 템플릿의 버전이 변경되는데, 수정한 템플릿의 버전을 해당 템플릿의 기본 버전으로 사용할 경우에 사용한다. 
• Auto scalilng 그룹 생성 - Create Auto scaling group : 해당 템플릿으로 Auto Scaling 그룹을 생성할 때 사용한다.
• 스팟 플릿 생성 - Create Spot Fleet : 템플릿으로 Spot instance를 생성할 때 사용한다.

 

Auto scaling 용 Application Load Balancer 구성

이제 Auto scaling 용 ALB를 생성해본다. 우선 Target group(대상그룹)을 만들어보자. 대상 유형은 인스턴스(instance)로 두고 대상 그룹 이름은 자유로 지정한다. 

 그리고 여기서는 대상 그룹에 어떠한 인스턴스도 포함시키지 않는다. 이후의 글에서 다루겠지만 해당 대상 그룹(Target Group)은 Auto scaling 그룹에 연결되는 ALB에 Target group이기 때문에, Auto scaling으로 생성되는 인스턴스들이 이 그룹에 자동으로 등록되기 때문에 어떠한 인스턴스도 포함시키지 않는다.

 

대상 그룹(Target group) 설정을 마쳤으면 로드밸런서를 생성해주는데, 신경써야할 부분은 해당 로드밸런서를 위한 보안 그룹을 생성해서 달아주는 것이고, 리스너 및 라우팅 란에서 '리스너'에 위에서 만든 대상 그룹(Target group)을 "다음으로 전달(Forward to)" 에 할당한다. 마지막으로는 잊지말고 Tag에서 "Name" 에 설정한 이름을 달아준다. 

 

이제 Auto Scaling을 위한 사전준비는 완료되었다. 이제 Auto scaling을 위한 Auto scaling group 생성을 하고 Scaling Policy를 지정해보도록 하자.

 

Auto Scaling 그룹 생성 및 Scaling Policy 지정

EC2 서비스의 왼쪽 리스트에서 "Auto scaling" -> "Auto scaling group" 을 클릭해서 Create Auto scaling group을 클릭한다. 그리고 위 사진처럼 설정화면이 나오는데 "Launch Template(시작 템플릿)"에서는 아까 만들었던 시작 템플릿을 클릭해준다. 

 

 VPC는 내부적으로 사용하고 있는 VPC를 선택해준다. 그리고 "가용 영역 및 서브넷(Availabilty Zones and Subnet)" 가 의미하는 바는 해당 Auto scaling group을 통해 생성되는 인스턴스가 어느 가용 영역, 어느 서브넷에 생성되는지를 명시하는 선택하는 입력란이다. 

Private subnet 선택하는 것 권장!

 설정화면에서 조금 더 내려보면, "인스턴스 유형 요구 사항 변경" 칸에서 '시작 템플릿 재정의'를 통해 인스턴스의 속성을 제어할 수 있다.

 

 

 이제 아까 만든 로드밸런서를 해당 Auto scaling group에 연결시켜준다. 또한 '모니터링'에서 Auto scaling group에 대한 지표를 받기 위해 해당 체크박스에 지표 수집을 활성화시켜준다.

 

"그룹 크기 및 크기 조정 정책 구성(Configuration group size and scaling policies)"가 Auto scaling group 설정에 가장 중요한 파트이다. 해당 파트에서 "그룹 크기(Group Size)"는 Auto scaling group에서 인스턴스를 몇 개까지 확장할 건지 몇 개까지 축소할건지를 의미하게 된다.

• "원하는 용량(Desired capacity)"는 Auto scaling group이 tracking policy나 EC2 instance의 상태에 따라서 활성화되기를 원하는 EC2 instance의 개수를 의미한다. 초기에 생성되는 인스턴스의 개수가 되기도 한다. 
• "최소 용량(Minimum capacity)"는 활성화될 수 있는 최소의 개수를 의미한다. 그래서 Auto scaling group에서는 해당 개수 아래로는 떨어지지 않는다.
• "최대 용량(Maximum capacity)"는 활성화될 수 있는 인스턴스의 최대 개수를 의미한다. 그래서 인스턴스가 많이 생기더라도 해당 개수를 넘어가지 않는다.

 또한 "크기 조정 정책(Scaling Policies)"는 Auto scaling이 작동하게 되는 기준을 의미한다. 따라서 이 정책에 따라서 인스턴스가 Scale Out (증가)하기도하고, Scale In (축소)하기도 한다.

 

 해당 예제에서 사용할 지표로는 "평균 CPU 사용률"이지만, '평균 네트워크 입력/출력', '대상 당 ALB 요청 수' 도 있다. 인스턴스 요구 사항은 Auto scaling에 적용되기까지의 시간을 의미한다. 

현업에서는 대상 값을 높게 잡지만 Auto scaling이 잘 작동하는지 확인해보기 위해 7로 낮게 잡았다.

 '인스턴스 축소 보호(Instance scale-in protection)'은 지표가 target value(대상 값) 아래로 내려와서 Scale-in이 발생할 때, Auto scaling으로 생성된 인스턴스가 삭제되지 않도록 해주는 항목이다. 인스턴스 축소 보호 활성화를 해주면, 인스턴스가 삭제되지 않는다. 해당 예제에서는 삭제할 수 있도록 비활성화해준다. 

 

위와 같이 Tag를 정해주면, Auto scaling으로 생성된 인스턴스의 Name 태그는 "asg-ec2"라는 값을 가지게 된다.

 

그렇게 Auto scaling group을 만들게 되면,

• 인스턴스 리스트에서 "asg-ec2"라는 이름을 가진 인스턴스 2개가 생성된 것을 볼 수 있다.
• 로드밸런서 대상 그룹에서 위의 두 개의 인스턴스가 포함된 것을 확인할 수 있다.

 

Auto Scaling Scale-Out 테스트

 Target Tracking Policy에 따라서 Auto Scaling Scale-Out이 되는 것을 확인해보자. 위에서 알 수 있듯이 Target Tracking Policy에서 설정한 '평균 CPU 사용률'을 높이기 위해 Auto scaling으로 생성된 두 개의 인스턴스에 ALB를 통해서 부하를 줄 것이다. Apache Bench Test를 통해서 이 부분을 진행한다. 

Apache Bench Test 이외에 JMeter와 nGrinder와 같이 부하 테스트를 할 수 있는 소프트웨어가 많이 있다. 

중지해놨던 Public 영역의 인스턴스를 재시작해준다. 해당 인스턴스에 접속한 뒤, Apache Bench Test를 다운받는다. 

# 루트 권한으로 변경
sudo su

# httpd-tools 라는 소프트웨어 패키지 안에 Apache Bench Test라는 소프트웨어가 포함되어 있다. 
# (다운받으려는 인스턴스에 Apache가 설치되어 있으면, 이미 Apache Bench Test가 깔려 있을 수 있다) 
yum install httpd-tools -y

 

 다운을 받았으면, 이제 로드밸런서에 부하를 줘보자. 

# 해당 URL로 총 '200000'개의 Request를 보내는데 동시에(즉, 한번에) 1000개를 보낸다는 의미이다. 
ab -n 200000 -c 1000 http://"로드밸런서 DNS Name"

 

부하를 주고 난 뒤, 아래와 같이 페이지를 들어간다.

AWS 콘솔에서 "CloudWatch" 서비스로 이동 후, "지표(Metrics)" -> "모든 지표(All metrics)" -> "EC2" -> "인스턴스별 지표(Per-instance Metrics)" => 'CPUUtilization'으로 지표 검색

 

 CPUUtilization(CPU 사용률)이 Auto scaling group을 만들 때 설정해둔 Target Value 값을 넘어가게 되면 Auto scaling을 통해 인스턴스가 생성된다. (Auto scaling group을 만들 때 설정해둔 Target Value는 7이었다.)

 

그렇게 어느 정도 시간이 흐르면서 CPU Utilization이 7을 넘기면 Auto scaling 에 의해서  Instance가 2개에서 총 4개로 Scale-Out이 발생한 것을 확인할 수 있다.

 또한 해당 Auto scaling group의 "활동(Activity)"에 들어가보면, 다음과 같이 인스턴스가 2개에서 3개, 3개에서 4개로 Scale-Out된 것을 확인할 수 있다.

 

Auto Scaling Scale-In 및 Termination Policy

 Scale-Out을 테스트하기 위해, 부하를 주다가 부하를 주지 않고 충분한 시간이 흐른 뒤에는, Scale-In이 발생한 것을 확인해볼 수 있다. ("Auto scaling group" --> "활동(Activity)")

 

 EC2 인스턴스의 리스트만 봐도 총 4개에서 2개로 줄어든 것을 확인할 수 있다. 

 그런데 종료된 인스턴스는 Auto scaling group에서 제거되는 인스턴스는 랜덤하게 선택되는 것이 아니다. Termination Policy에 따라서 종료되는 것이다. Termination Policy는 Scale-In이 발생할 때, 어떤 인스턴스를 종료시킬지에 대한 내용을 나타낸다. 

 

 해당 Auto scaling group의 페이지에 들어가서, "고급 구성(Advanced configurations)" 파트에서 종료 정책을 편집할 수 있다.

 

'종료 정책'에 여러 정책들이 있는데, 하나하나씩 알아보도록 한다. 

• Default 
  • Default에서는 정책이 크게 두 가지로 나뉜다. 첫 번째는 Auto scaling group의 인스턴스 중에 더 오래된 Launch 템플릿을 사용한 인스턴스를 선택하는 종료시키는 정책이 있다. 두 번째로는 동일한 Launch Template을 사용했다면, 인스턴스 중에 비용 결제 시간이 더 가까워진 인스턴스를 선택해서 종료시킨다. 
  • 위의 예제에서 Termination Policy가 Default 정책이었기 때문에, 'Auto scaling group' -> '활동(Activity)'를 들어가서 확인해보면 가장 먼저 생성된 인스턴스부터 종료된 것을 알 수 있다. (각 인스턴스의 Launch Template을 동일하다)
• Allocation Strategy 
  • 이 정책은 선호하는 인스턴스 유형이 변경된 경우 유용하다. 스팟 할당 전략이 lowest-price인 경우, 최저가 스팟 풀 N개 전체에서 스팟 인스턴스 배포를 점차 재분배할 수 있습니다. 스팟 할당 전략이 capacity-optimized인 경우, 사용 가능한 스팟 용량이 더 여유 있는 스팟 풀에서 스팟 인스턴스 배포를 점차 재분배할 수 있습니다. 또한 점차 우선순위가 낮은 유형의 온디맨드 인스턴스를 우선순위가 높은 유형의 온디맨드 인스턴스로 대체할 수 있습니다.
• Closest To Next Instance Hour
  •  다음번 결제 시간에 가장 근접한 인스턴스를 종료하는 정책이다. 이 정책은 시간제로 요금이 청구되는 인스턴스의 사용을 극대화할 수 있도록 합니다. Amazon Linux, Windows 또는 Ubuntu를 사용하는 인스턴스에만 초 단위로 요금이 부과됩니다.
• Newest Instance
  • 그룹에서 가장 새로운 인스턴스를 종료한다. 이 정책은 새로운 시작 구성을 테스트하지만 프로덕션 상태로 유지하고 싶지 않은 경우에 유용하다.
• Oldest Instance
  • 그룹에서 가장 오래된 인스턴스를 종료한다. 이 옵션은 Auto Scaling 그룹의 인스턴스를 새로운 EC2 인스턴스 유형으로 업그레이드할 때 유용하다. 따라서 이전 유형의 인스턴스를 새로운 유형의 인스턴스로 점진적으로 대체할 수 있다.
• Oldest Launch Configuration
  • 가장 오래된 Launch Configuration이 있는 인스턴스를 종료합니다. 이 정책은 그룹을 업데이트하고 이전 구성에서 인스턴스를 단계적으로 종료할 때 유용합니다.
• Oldest Launch Template
  • 가장 오래된 Launch Template 이 있는 인스턴스를 종료합니다. 이 정책을 사용하는 경우, 최신이 아닌 시작 템플릿을 사용하는 인스턴스가 먼저 종료되고 그다음으로 최신 시작 템플릿의 가장 오래된 버전을 사용하는 인스턴스가 종료됩니다. 이 정책은 그룹을 업데이트하고 이전 구성에서 인스턴스를 단계적으로 종료할 때 유용합니다.
• 사용자 지정 종료 정책(Custom termination policy)
  • 직접 종료 정책을 만들어서 활용할 수 있다.

 

 Auto scaling에서는 두 가지의 프로세스가 존재하는데 그 종류로는 '시작(Launch)', '종료(Terminate)'가 있다. 하지만 위 두 가지의 프로세스만 진행되면서도 위 사진에서 볼 수 있듯이 두 가지 이외의 여러가지 다른 프로세스들이 함께 진행된다. 

 

 '일시 중지된 프로세스(Suspended processes)'는 앞서 말한 여러가지 프로세스들 중에서 특정 프로세스를 일시 중단시키는 기능이라고 생각하면 된다. 

 '최대 인스턴스 수명(Maxium instance lifetime)' 은 말 그대로 인스턴스의 최대 수명을 의미한다. 

 

 '기본 인스턴스 워밍업(Default cooldown)' 은 Auto scaling group에서 Scaling policy에 따라서 인스턴스가 생성되거나 제거될 때, 잠시 대기하게 되는 시간을 의미한다. 

 

 

References

• https://www.inflearn.com/course/aws-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B8%B0%EB%B3%B8/dashboard
• https://docs.aws.amazon.com/ko_kr/autoscaling/plans/userguide/what-is-a-scaling-plan.html
• https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/ec2-auto-scaling-termination-policies.html