sol 개발 블로그 로고
Published on

AWS ASG 개요와 실습 방법

Authors
  • avatar
    Name
    Chan Sol OH
    Twitter

목차

ASG 개요

AWS에서는 EC2 인스턴스 생성 API 호출로 아주 빠르게 서버를 생성하고 제거할 수 있다. 이를 이용해서 Auto Caling Group을 만들 수 있는데 ASG 자체는 무료지만 생성하는 EC2 인스턴스의 값은 지불해야한다.

Auto Sacling Group (ASG)의 특징은

  1. 증가한 부하에 따라 자동적으로 EC2를 추가해서 스케일 아웃하는 것.
  2. 줄어든 부하에 따라 EC2 인스턴스를 제거해서 스케일 인하는 것.
  3. 매개변수로 최대 최소 EC2 인스턴스 수를 지정하는 것.
  4. ASG가 ELB에 연결되면 ASG가 생성하는 EC2는 자동적으로 ELB에 연결된다
  5. EC2 인스턴스가 unhealthy하다고 판단하면 제거하고 새로운 EC2를 다시 생성한다.

ASG는 처음 최소 EC2 인스턴스 수만큼 가지고 있다가 부하가 증가하고 기존 EC2로 커버할 수 없다고 판단하면 인스턴스를 계속 생성한다. 다만 최대 인스턴스 수를 넘기지 못한다.

ELB에 ASG를 붙이면 ASG가 생성한 모든 인스턴스에 균등하게 부하를 분산한다. 당연하게 ELB는 인스턴스의 healty-check를 수행하고 unhealthy하다고 판단하면 ASG가 인스턴스를 종료하고 새롭게 생성한다. 그래서 ELB와 ASG를 함께 사용한다.

CloudWatch와 함께 쓰이는 ASG

CloudWatch 알림을 바탕으로 ASG가 스케일 인,아웃할 수 있다. CloudWatch는 몇몇 지표(평균 CPU 사용량, 사용자 지정 지표)를 모니터링하면서 알림을 발생한다. 예를 들어 ASG 전체 인스턴스의 평균 CPU 사용량이 많아지면 경보가 울리고, ASG는 이에 따라 인스턴스를 생성한다.(스케일 아웃). 반

ASG 실습

  1. ASG 이름 작성, Launch Template 생성
  2. 템플릿 이름를 작성, Quick Start 선택해서 OS 선택, 인스턴스 타입 선택 등등 ASG가 생성하는 EC2 인스턴스의 설정을 작성한다. EC2 설정과 똑같다.
  3. 템플릿 생성하고, 인스턴스 launch option에서 VPC와 AZ를 설정
  4. 로드 밸런서와 대상 그룹 선택
  5. 그룹 크기 (최소, 최대 인스턴스 수). ASG 생성

ASG를 생성하고 인스턴스에 변화가 생기면 활동(activity) 파트에 알림이 발생하고, activity history에 과거 기록이 작성된다. 문제가 있다면 Security Group이나 User Data 스크립트의 문제다. ASG 최대 인스턴스 수를 수정해서 인스턴스 수를 늘리는 것을 볼 수 있다. 스케일 아웃과 마찬가지로 스케인 인은 원하는 인스턴스 수를 줄이면 자동으로 인스턴스 하나를 제거한다. 아래 그림은 스케일 아웃했을 때 그림.

인스턴스 수 자동으로 늘리기

ASG 스케일링 정책

  • Dynamic Scaling Policies
    • Target Tracking Scaling : 가장 간단함. ASG 인스턴스들의 평균 CPU 사용률을 추적하여 40% 및으로 유지
    • Simple/Step Scaling : 전체 ASG에 대한 CPU 사용률이 70%를 초과하는 경우 CloudWatch 알림이 발생하고 2개 유닛을 생성, 그리고 전체 30% 및으로 떨어면 1개 유닛을 삭제. 생성할때와 제거할 때 몇개씩 할지 정할 수 있다.
    • Scheduled Aciton : 예상된 스케쥴에 따라 ASG 정책을 수정. 예를 들어 매일 오후 5시에 이벤트가 있으니 최소 인스턴스 수를 매일 오후 5시에 자동으로 늘려놓는다.
  • Predictive Scaling
    • 지속적으로 부하를 예상하고 미리 스케일링을 수행한다.
    • 머신러닝을 이용하기 때문에 쉬워서 향후 더욱 대두될 것

스케일링 지표

  1. CPU 사용률 (CPUUtilization) : 평균 CPU 사용량. 인스턴스를 잘 사용하고 있기 때문에 CPU 사용률이 올라감으로 스케일링에 있어서 좋은 지표
  2. 대상 별 요청 수 (RequestCountPerTarget) : 인스턴스은 한번에 1000개의 요청에 적절히 응답하므로 이에 맞춰서 스케일링할 수 있다.
  3. 평균 네트워크 입출력량 (Average Network In/Out) : 데이터 업,다운로드가 많으면 그 인스턴스는 병목현상이 발생해서 다른 요청을 처리할 수 없을것. 그래서 네트워크 입출력량을 통해 스케일링을 수행할 수 있다.
  4. 커스텀 매트릭 : CloudWatch에 작성 가능!

Scaling Cooldowns

ASG가 스케일 아웃, 인을 수행한 후 300초 정도 Cooldown 기간을 가진다. 이 기간 동안은 ASG가 인스턴스를 생성하지도 제거하지도 않는다. 새로운 인스턴스가 안정화되도록 기다리고 스케일링 지표의 양상을 살펴보기 위함

  1. 스케일링 액션 발생
  2. ASG가 Cooldown 기간인가?
    • 예 : 액션을 무시한다.
    • 아니오 : 인스턴스를 생성하거나 제거한다.

EC2 대신 바로 실행 가능한 AMI를 이용하는 것이 인스턴스 생성 시간을 줄여 신속하게 서비스 할 수 있다. 또한 Cooldown 기간을 줄여 더 세밀한 동적 스케일링할 수 있다.

동적 스케일링 실습

  1. Auto Scaling 탭에서 동적 크기 조정 정책 생성
  2. 대상 추적 크기 조정 : 평균 CPU 사용량 40%로 설정
  3. 최대 인스턴스 수 3개로 설정
  4. 실행중인 인스턴스에 접속해서 CPU 사용량 100%되도록 스트레스 발생
  5. 모니터링 탭에 CPU 사용량이 늘어난 것을 확인하고 인스턴스가 새롭게 생되는 것을 확인
  6. 스트레스를 끄고 스케일링하는 것을 확인

ASG instance refresh

인스턴스 리프레시의 목표는 launch template을 업데이트하고 ASG의 모든 인스턴스를 재생성하는 것이다. 인스턴스를 종료한 다음 다시 나타날 때까지 기다리는 대신 ASG의 instance refresh를 사용할 수 있다.

launch template에 새로운 AMI로 인스턴스 정보를 업데이트했고 새로운 AMI를 생성할 때 기존 template으로 만든 인스턴스를 전부 제거하는 것이 아니라 미리 설정한 Healthy Percentage 내로 조금씩 인스턴스를 제거하고 새로운 인스턴스를 생성한다. 이렇게 조금 제거하고, 새롭게 만들고를 반복해서 Healthy Percentage를 보장하면서 모든 인스턴스를 업데이트할 수 있다.

다만, 인스턴스를 생성하자마자 트래픽을 처리할 수 없기 때문에 warm-up time(인스턴스 사용 대기 시간)이 필요하다