Auto Scaling Group

> Auto Scaling: 미리 정해 놓은 규칙에 따라 워크로드(작업량)를 자동으로 확대 또는 축소할 수 있는 기술

 

> 클라우드가 제공하는 탄력성에 의해 만들어지고, 사용자의 요구 수준을 반영할 수 있는 기술

 

> 피크 워크로드에 맞춰 새 리소스를 자동으로 추가하고 환경설정하고, 처리 요구량이 줄어들면 해당 리소스를 감소시키기 때문에, 과잉 프로비전을 할 필요성이 사라짐

 

프로비전(provision)

 > 필요한 컴퓨팅 리소스들을 필요한 곳에 배치, 유휴 자원들을 다시 회수하는 일련의 작업들을 의미

 

Auto Scaling의 장점

: 동적 스케일링

 > 스케일 업 할 수 있는 서버의 수에는 제한이 없고, 필요한 경우 서버 두 대에서 수백 ~ 수만 대의 서버로 즉시 스케일 업할 수 있음

 

: 로드 밸런싱

 > 다수의 EC2 인스턴스에게 워크로드를 효과적으로 분배

 > 다수의 AZ에 분포된 EC2 인스턴스에 대한 워크로드도 자동으로 분배하도록 설정

 > 사용자가 정의한 규칙에 따라 워크로드를 효과적으로 관리할 수 있음

 

: 타겟 트래킹

 > 특정 타깃에 대해서만 Auto Scaling을 할 수 있으며, 사용자가 설정한 타깃에 맞춰 EC2 인스턴스의 수를 조정

 

: 헬스 체크와 서버 플릿 관리

 > Auto Scaling을 이용하면 EC2 인스턴스의 헬스 체크 상태를 모니터링할 수 있음

 > 특정 인스턴스의 문제가 감지되면, 자동으로 다른 인스턴스로 교체

 

> 서버 플릿

 : 다수의 EC2 서버에서 애플리케이션을 호스팅 하는 경우, 이들 일련의 EC2 서버 집합

 

EC2 Auto Scaling 활용

 시작 템플릿(Launch Configuration)

 > 인스턴스를 확장 또는 축소하려면 어떤 서버를 사용할지 결정해야 함

 > 시작 템플릿을 통해서 가능하며, AMI 상세 정보, 인스턴스 타입, 키 페어, 시큐리티 그룹 등 인스턴스에 대한 모든 정보를 담고 있음

 > but 시작 템플릿을 사용하고 있지 않고 시작 템플릿을 생성하지 않으려는 경우에는 대신 시작 구성을 생성

 > EC2 Auto Scaling이 사용자를 위해 생성하는 EC2 인스턴스 유형을 지정한다는 점에서 시작 템플릿과 비슷함

 

시작 구성에 포함되어야 할 것

 > AMI의 ID, 인스턴스 유형, 키 페어, 보안 그룹 등의 정보를 포함시켜서 시작 구성을 생성

 

Auto Scaling 그룹 생성

> 스케일업 및 스케일 다운 규칙의 모음으로 EC2 인스턴스 시작부터 삭제까지의 모든 동작에 대한 규칙과 정책을 담고 있음

 

Scaling 유형

 > 인스턴스 레벨 유지 :

기본 스케일링 계획으로도 부르며, 항상 실행 상태를 유지하고자 하는 인스턴스의 수를 지정할 수 있습니다. 일정한 수의 인스턴스가 필요한 경우 최소, 최대 및 원하는 용량에 동일한 값을 설정

 

 >수동 스케일링 :

기존 Auto Scaling 그룹의 크기를 수동으로 변경할 수 있습니다. 수동 스케일링을 선택하면 사용자가 직접 콘솔이나, API, CLI 등을 이용해 수동으로 인스턴스를 추가 또는 삭제해야 합니다. 해당 방식은 추천하지 않는 방식

 

 > 예측 스케일링 :

트래픽의 변화를 예측할 수 있고, 특정 시간대에 어느 정도의 트래픽이 증가하는지 패턴을 파악하고 있다면 일정별 스케일링을 사용하는 것이 좋습니다. 예를 들어 낮 시간대에는 트래픽이 최고치에 이르고 밤 시간대에는 트래픽이 거의 없다면 낮 시간대에 서버를 증설하고 밤 시간대에 스케일 다운 하는 규칙을 추가

 

 > 동적 스케일링 :

수요 변화 대응하여 Auto Scaling 그룹의 용량을 조정하는 방법을 정의합니다. 이 방식은 CloudWatch가 모니터링 하는 지표를 추적하여 경보 상태일 때 수행할 스케일링 규칙을 정합니다. 예를 들어 CPU 처리 용량의 80% 수준까지 급등한 상태가 5분 이상 지속될 경우 Auto Scaling이 작동돼 새 서버를 추가하는 방식입니다. 이와 같은 스케일링 정책을 정의할 때는 항상 스케일 업과 스케일 다운 두 가지의 정책을 작성

 

EC2 Auto Scaling은 다음과 같은 유형의 동적 스케일링 정책을 지원

 

 > 타겟 트랙킹 스케일링 : 미리 정의된 성능 지표를 이용하거나, 커스텀 성능지표(custom metric)를 사용하여 타깃 값으로 설정할 수 있음

 

 > 단순 스케일링 : 단 하나의 스케일링 설정에 따라 그룹의 현재 용량을 늘리거나 줄임. 예를 들어 CPU 활용지표가 80% 에 도달할 때 하나의 인스턴스를 추가하고, 40% 미만으로 떨어질 때 인스턴스 하나를 감소시키는 방식

 

 > 단계 스케일링 : 단순 스케일링은 특정 이벤트에 대해 매번 같은 액션을 한다면, 단계 스케일링은 좀 더 세분화 해서 단계를 나누어 규칙을 추가

 

인스턴스 삭제 정책

 > 스케일다운 정책이 적용되면, EC2 인스턴스가 삭제되며, 서버를 셧다운 하는 것은 리소스 관리 측면에서도 꼭 필요한 일 

 

 > 스케일다운 정책에서는 명확하게 몇 개의 인스턴스를 삭제할 것인지 정의할 수 있으며, 어떤 인스턴스를 먼저 셧다운 할 것인지 환경 설정을 통해 결정

 

인스턴스 삭제 정책은 매우 다양하지만 아래 두 가지가 대표적

 

• 사용자의 서버 플릿에서 가장 오랫동안 실행된 서버를 삭제. 가장 오랫동안 실행된 서버일수록 패치 수준이 낮고 메모리 누수 등의 문제가 누적해 있을 가능성이 크기 때문에 이를 삭제함으로써 최신의 성능 기준을 유지할 수 있다는 장점이 있음.
• 시간 단위 과금이 임박한 서버를 삭제. 이 서버를 삭제하면 Auto Scaling의 특유 장점을 최대한 살려, 과금 부담을 줄일 수 있음