[AWS] Auto Scailing 그룹 및 옵션(정책)

Auto Scailing 그룹

---

https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/AutoScalingGroup.html

Auto Scaling 그룹 - Amazon EC2 Auto Scaling

Auto Scailing 그룹은 Auto Scailing이 관리하는 EC2 인스턴스 그룹이며, Auto Scailing 그룹 생성 시, 론치 환경설정 또는 론치 템플릿으로 몇 개의 인스턴스를 프로비전하고 실행할 것인지 지정해야 하며, Auto Scailing 그룹의 최소 및 최대 용량도 지정해야 한다. 생성 시 희망하는 인스턴스의 수를 지정하는 것도 가능하다.

최소 용량

Auto Scailing은 인스턴스 수가 최소 크기 이하로 내려가지 않도록 합니다. 이 값을 0으로 설정하면 새 인스턴스를 추가하지 않고 그룹 내에서 실행되는 모든 인스턴스를 종료시킵니다.

최대 용량

Auto Scailing은 인스턴스 크기가 최대 크기 이상이 되지 않도록 하며, 예산 제한선을 고려해 예기치 못한 수요에 의해 지나치게 많은 인스턴스가 추가되지 않도록 하는 안전장치 역할을 합니다.

희망 용량

희망 용량은 사용자의 필요에 따라 선택할 수 있으며, 최소 및 최대 크기 범위 이내에 있어야 합니다. 희망 용량을 입력하지 않으면 Auto Scailing은 최소 크기에 맞춰 인스턴스를 론칭하고, 희망 용량을 입력하면 해당 값에 맞춰 인스턴스를 추가 또는 종료시킵니다. 웹 콘솔에서는 희망 용량을 그룹 사이즈라고 부릅니다.

ALB(Application Load Balancer) 타겟 그룹 설정

---

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/introduction.html

Application Load Balancer란 무엇입니까? - Elastic Load Balancing

Auto Scaling 그룹에서 인스턴스에 유입되는 트래픽을 분산하려 한다면 Application Load Balancer(ALB)를 이용할 수 있습니다. Auto Scaling 그룹 생성 시 ALB 타겟 그룹에 연결하면, Auto Scaling이 새 인스턴스 생성 시 자동으로 ALB 타겟 그룹을 추가합니다.

애플리케이션 인스턴스에 대한 헬스 체크

---

Auto Scaling 그룹을 생성하면 미리 정한 최소 또는 희망 용량의 인스턴스가 항상 유지되며, 생성된 인스턴스의 헬스 상태가 좋지 못하면 Auto Scaling이 이를 삭제하고 새 인스턴스로 대체합니다.

Auto Scailing의 인스턴스 헬스에 대한 판단 기준은 EC2 헬스 체크를 따릅니다. 헬스 체크를 통해 메모리 고갈, 파일 시스템 오류, 네트워크 연결 오류, 시작 환경설정 오류는 물론 AWS가 처리해야 하는 시스템 문제 여부까지 확인할 수 있습니다.

이 과정에서 인스턴스 및 호스팅과 관련된 방대한 문제점을 찾아낼 수 있지만, 애플리케이션에 특화된 문제점은 발견하지 못할 수 있습니다.

ALB를 이용해 인스턴스의 트래픽을 라우팅하면, 로드 밸런서의 타겟 그룹에 대한 헬스 체크 환경설정을 할 수 있습니다. 타겟 그룹의 헬스 체크는 HTTP 응답 코드 200~499까지 확인할 수 있으며, Auto Scaling 그룹의 환경 설정을 통해 헬스 체크 확인 결과를 인스턴스 상태 모니터링에 반영할지 결정할 수 있습니다.

인스턴스가 ALB 헬스 체크에 실패하면 로드 밸런서는 해당 인스턴스에 대한 트래픽 전송을 중단하고, 인스턴스를 삭제 및 다른 인스턴스로 대체하며 ALB 타겟 그룹에 새 인스턴스를 추가한 뒤 새 인스턴스에 트래픽을 전송합니다.

Auto Scaling 옵션

---

Auto Scailing 그룹 생성 후, 최소 또는 희망 용량으로 유지되도록 내버려두는 방법도 있지만 인스턴스 수 유지라는 방법은 Auto Scailing의 여러 방법 중 하나일 뿐입니다.

Auto Scailing은 요구 수준에 맞춰 다양한 인스턴스 스케일링 옵션을 제공합니다.

수동 스케일링(Manual Scaling)

Auto Scaling 그룹 생성 후 최소, 희망, 최대 용량 값을 변경하면, 해당 내용이 즉시 반영됩니다. 희망 용량을 2에서 4로 변경하면 Auto Scaling은 즉시 2개의 인스턴스를 추가하며, 이미 4개의 인스턴스가 있는 상황에서 희망 용량을 2로 변경하면 Auto Scaling은 즉시 2개의 인스턴스를 종료합니다.

수동 스케일링은 이처럼 원하는 만큼 인스턴스 수를 직접 변경하는 방법입니다.

동적 스케일링 정책(Dynamic Scaling Policies)

S3, 로드 밸런서, 인터넷 게이트웨이, NAT 게이트웨이 등 대부분의 AWS 관리형 리소스는 탄력적입니다. 또한 워크로드가 증가하면 자동으로 성능 또는 용량을 스케일업하며, 이들 서비스에 대해서는 트래픽이 아무리 급증해도 AWS가 그에 대응해서 리소스를 추가합니다.

하지만 EC2 인스턴스의 경우 요구 수준에 맞는 성능 또는 용량을 설정하는 것은 사용자의 책임입니다.

CPU 활성화율, 메모리, 디스크 공간 등 인스턴스 리소스의 고갈은 인스턴스 가동 실패로 이어질 수 있으므로 사용자는 동적 스케일링 정책을 통해 중단 임계치에 도달하기 전에 인스턴스의 부담을 줄여야 합니다.

Auto Scaling은 이를 위해 그룹에 포함된 모든 인스턴스에 대해 다음과 같은 성능 지표를 제공합니다.

• 누적 CPU 활성화율
• 타겟 당 누적 요청 횟수
• 누적 네트워크 바이트-인
• 누적 네트워크 바이트-아웃

이들 지표 외에도 다양한 성능 지표를 확인할 수 있으며, CloudWatch 로그에서 추가 지표를 필터링할 수 있습니다. 예를 들어, 애플리케이션이 하나의 프로세스를 처리하는 데 걸린 시간을 측정하는 로그를 생성할 수 있으며, 이를 이용해서 하나의 프로세스 처리 시간이 너무 오래 걸린다면 Auto Scaling을 통해 새 인스턴스를 추가할 수 있습니다.

동적 스케일링 정책은 CloudWatch의 경고 상황을 모니터링한 결과에 따라 희망 용량을 증가시키는 방식으로 작동하며, 단순 정책, 단계별 정책, 타겟 추적 정책 등 세 가지가 있습니다.

단순 스케일링 정책(Simple Scaling Policies)

단순 스케일링 정책은 지표가 한계치에 도달하면 Auto Scailing이 희망 용량대로 인스턴스를 증가시키되, 다음과 같은 타입에 따라 증가 수준 또는 속도를 조절합니다. 단, Auto Scaling은 절대 그룹의 최대 용량을 벗어나게 인스턴스를 증가시키지 않습니다.

• ChangeInCapacity 지정 숫자만큼 희망 용량을 증가시킵니다. 예를 들어, 희망 용량을 4로 설정한 뒤 Auto Scaling이 지정 숫자인 2씩 증가시킬 수 있음
• ExactCapacity 현재 값에 상관 없이 용량을 지정 숫자만큼 증가시킵니다. 예를 들어, 희망 용량은 4로 설정했지만 이 정책을 통해 6으로 증가시킬 수 있음
• PercentChangeInCapacity 현재 용량의 비율을 기준으로 증가시킵니다. 희망 용량이 4인데 50%로 정책을 설정하면 Auto Scaling에 적용되는 총 희망 용량은 6입니다.

예를 들어 이미 4개의 인스턴스가 실행되고 있고, PercentChangeInCapacity의 속성 값이 50%인 단순 스케일링 정책을 생성했을 때, 지표가 한계치가 도달한 경우 Auto Scaling은 용량에 2를 추가하게 되며, Auto Scaling 그룹에는 총 6개의 인스턴스가 존재하게 됩니다.

Auto Scaling 조정 작업 종료 후에는 관련 정책을 다시 실행하기 전 휴식기(cooldown period)를 갖게됩니다. 기본 휴식기는 300초이지만, 0으로 설정해서 휴식기를 갖지 않도록 할 수도 있습니다. 인스턴스의 헬스 상태가 좋지 않은 경우, Auto Scaling은 휴식기 없이 해당 인스턴스를 교체합니다.

단계별 스케일링 정책(Step Scaling Policies)

애플리케이션에 대한 요구 수준이 급속히 증가하는 경우, 단순 스케일링 정책만으론 수요에 적절히 대응할 수 없으며, 단계별 스케일링 정책을 통해 리소스 사용량의 누적 지표에 따라 인스턴스를 추가할 수 있습니다. 

예를 들어, 4개의 인스턴스로 구성된 그룹이 있다고 했을 때, 평균 CPU 활성화율에 따라 인스턴스를 추가할 수 있습니다. CPU 활성화율이 50%를 초과하면, 2개를 추가하고, 60%를 초과하면 4개를 추가하는 방식입니다.

CloudWatch Alarm으로 평균 CPU 활성화율이 50%일 때 경고를 보내도록 했다면, 이를 이용해서 단계별로 희망 용량을 증가시킬 수 있습니다. 단계별 스케일링 정책을 작성할 때는 최소 한 단계에 해당하는 조정 값 또는 범위를 지정해야 합니다. 단계별 조정값은 다음과 같습니다.

• 하위 경계
• 상위 경계
• 조정 타입
• 희망 용량 증가 기준

상위 경계 및 하위 경계는 단계별 조정 업무를 수행할 지표의 범위를 정의합니다.

예를 들어 초기 단계를 하위 경계 50, 상위 경계 60으로 설정하고, ChangeInCapacity 조정 값을 2로 설정했다면 알람 발령시 Auto Scaling은 평균 CPU 활성화율을 기준으로 조정에 나섭니다. CPU 활성화율이 55%라면 하위 50, 상위 60 범위에 있으므로(50 <= 55 < 60) Auto Scaling 그룹은 희망 용량에 2를 추가합니다.

하위 경계 60, 상위 경계를 '무한'으로 설정하고 ChangeInCapacity 조정값을 4로 설정한 경우, 평균 CPU 활성화율이 62%일 때 조건을 만족하므로(60 <= 62 < '무한') 희망 용량에 4를 추가합니다.

단계별 스케일링 정책에서는 Auto Scaling이 새 인스턴스 추가를 위해 대기하는 시간인 준비기(warm-up time)을 지정할 수 있으며 기본은 300초 입니다. 단계별 스케일링 정책은 휴식기(cooldown period)를 갖지 않습니다.

목표 추적 정책(Target Tracking Policies)

단계별 스케일링 정책이 너무 복잡해 보인다면, 목표 추적 정책을 사용할 수 있습니다. 특정 지표와 타겟 값을 선택하면, Auto Scaling이 CloudWatch Alarm 생성, 인스턴스 개수 조정을 위한 스케일링 정책 생성 등 여러가지 업무를 처리합니다.

지표는 인스턴스에 추가되는 업무 부하와 비례적으로 변경되는 것이여야 하며, 그룹별 CPU 활성화율, 타깃별 요청 회수 등이 해당됩니다. ALB에 대한 총 요청 수와 같은 누적 지표는 업무 부하와 비례적으로 변경되지 않으므로 목표 추적 정책의 지표로는 정확하지 않습니다.

목표 추적 정책에서는 용량을 증가시키는 스케일 아웃(scale out) 정책은 물론 용량을 감소시키는 스케일 인(scale in) 정책도 추가할 수 있습니다. 스케일링 정책을 원치 않는 경우 스케일링 정책을 비활성화시키면 됩니다.

목표 추적 정책 또한 단계별 스케일링 정책처럼 준비기를 설정할 수 있습니다

예약된 작업(Scheduled Actions)

예약된 작업은 여러분의 워크로드 패턴이 예측 가능한 경우나 용량 변화에 선제적으로 대응해 수요 증가 이전에 충분한 인스턴스를 확보하고자 할 때 유용합니다.

예약된 작업 생성 시, 다음 사항을 설정합니다.

• 최소, 최대, 희망 용량 값
• 시작 날짜 및 시간

반복적인 패턴으로 업무를 처리하는 경우엔 일정 기간마다 반복되는 정책을 추가할 수 있고, 예약된 정책을 삭제하기 위한 종료 시점도 설정할 수 있습니다.

동적 스케일링 정책은 몇 개의 예약된 작업을 결합해서 사용하는 것도 가능합니다. 예를 들어, 온라인 쇼핑몰을 운영한다면, 손님이 몰리는 쇼핑 시즌에는 그룹 크기를 최대로 증가시키는 예약된 작업을 적용한 뒤, 상황에 따라 희망 용량을 증감시키는 정책을 동적으로 적용할 수 있습니다.

---

참고 사항

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=286769894 

AWS 공인 솔루션스 아키텍트 스터디 가이드 - 어소시에이트 3/e

https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/schedule_time.html

Amazon EC2 Auto Scaling에 예약된 조정 - Amazon EC2 Auto Scaling