Auto Scaling Scale-Out 테스트, Auto Scaling Scale-In 및 Termination policy 살펴보기

target tracking policy에 따라서 Auto Scaling의 Scale-Out을 테스트해보자

 

target tracking policy에서 기준으로 설정한 cpu 사용을 늘리기 위해 Auto Scaling으로 생성된 2개의 인스턴스에 Application Load Balancer를 통해 부하를 준다.

간단하게 ApacheBench 테스트를 통해 진행한다.

 

• public-ec2-a1에 ssh 접속한다.

퍼블릭 ip 주소를 복사한다.

cyberduck에서 ssh 접속한다.

ApacheBench가 내장되어 있는 https-tools를 설치한다.

• Application Load Balancer에 부하를 줄 수 있도록 소프트웨어 패키지를 설치한다.

 

• url에 총 20만개의 request를 보낼건데 1000개를 보내겠다는 의미이다.

 

• ApacheBench 테스트가 시작이 된 것이고, ALB로 계속 부하를 주게 된다.

 

• ALB의 타겟으로 설정되어 있는 EC2 인스턴스들의 평균 CPU 사용률 즉, 우리가 Auto Scaling Group의 Tracking Policy에서 Auto Scaling 작동의 기준이 되는 Metrics 타입인 평균 CPU 사용률을 살펴보자

CloudWatch를 연다.

 

• asg라는 태그를 가지고 있는 EC2 인스턴스 2개를 살펴보겠다.

 

• All metrics > EC2 > Per Instance Metrics > CPUUtilization 검색 
• asg-ec2 두개 선택
• 평균 CPU 사용률이 그래프로 상단에 보여지게 된다.

 

• Auto Scaling이 작동했는지 확인해보자

• ec2로 이동 
• 인스턴스가 2개에서 4개로 늘어난 것을 볼 수 있다.
• => 즉, Auto Scaling을 통해서 EC2 인스턴스가 추가로 생성된 것을 확인할 수 있다.

 

• Auto Scaling Group으로 이동하여 더 자세히 살펴보자
• Activity 탭을 연다.

 

• Tracking Policy에서 정한 값보다 커졌기 때문에  CloudWatch 알람이 Tracking Policy를 트리거로 desired capacity를 2->4로 올렸다.
• 그 순간에 desired capacity와 실제 capacity가 다르기 때문에 새로 인스턴스를 실행한다. (2->3, 3->4)

 

이렇게 Auto Scaling Group을 통해 인스턴스가 증가한 것을 Scale out 되었다 라고 표현한다.

 

Auto Scaling Group을 생성할 때 maximum capacity를 4로 설정했기 때문에 cpu 사용률이 아무리 높아져도 인스턴스가 4개보다 커지진 않는다.

 

load test 이후 충분한 시간이 흐르면 Auto Scaling Scale-In을 통해 인스턴스의 수가 감소한다.

Activity history에 남겨진 세부 내용을 보면

• cpu의 사용률이 tracking policy에서 정한 값보다 작아졌기 때문에 cloudwatch의 알람이 tracking policy를 트리거 해서 desired capacity를 4->3으로 줄였다. / 3->2로 줄였다. 그 차이만큼 인스턴스 하나를 찾아서 termination 시킨다.

라고 남겨져 있다.

 

실제로 ec2 인스턴스를 보면 4개 -> 2개로 줄어있다.

=> 이것을 Scale-In이라고 한다.

 

Termination policy는 어떤 기준으로 어떤 인스턴스를 termination 시킬지 설정하는 것이다.

• EC2 > Auto Scaling groups > Details > Advanced configurations > edit
  • Termination policies : Auto Scaling group을 통해 생성된 ec2 인스턴스가 tracking policy 등으로 termination(삭제) 될 때 어느 인스턴스를 우선적으로 삭제할것인가에 대한 기준
    • Default : auto scaling group 인스턴스중에 더 오래된 인스턴스 -> 비용 결제 시간이 더 가까워진 인스턴스 순으로 termination 시킨다. (먼저 생성된 인스턴스)
    • Alocation Strategy : Auto Scaling group을 생성할 때 인스턴스에 대한 할당 전략을 적용했을 때 그에 따라 termination할 인스턴스를 선택한다.
    • Closet To Next Instance Hour : 인스턴스중 다음 결제 시점이 더 가까운 인스턴스부터 termination
    • Newest Instance : 가장 최근에 만들어진 인스턴스부터 termination
    • Oldest Instance : 가장 오래된 인스턴스부터 termination
    • Oldest Launch Configuration : 가장 오래된 launch configuration으로 만들어진 인스턴스부터 termination
    • Oldest Lauch Template : 가장 오래된 launch template으로 만들어진 인스턴스부터 termination
    • Custom termination policy : 임의로 termination policy를 설정할 수도 있음
  • Suspended processes : 여러가지 프로세스가 한꺼번에 진행이 되는데 그 중 일정 프로세스를 일시 중단 시킬 수 있는 기능
  • Maximum instance lifetime : 인스턴스의 최대 수명으로 1초~1년 설정 가능하며 0으로 설정하면 특별히 정한 수명 없이 Auto Scaling group의 Scaling policy에 따라 인스턴스가 바로 생성되거나 termination 된다.
  • Default cooldown : Auto Scaling group의 Scaling policy에 따라서 인스턴스가 생성되거나 terminate 될 때 잠시 대기하게 되는 시간으로 0으로 설정하면 대기시간 없이 생성 혹은 termination 된다.

 

Auto Scaling으로 확장성과 탄력성을 가진 인프라를 구현해보았다.

Auto Scaling은 AWS 뿐만 아니라 Cloud Computing의 가장 큰 장점으로 꼽을 수 있는 기능이다.