1. Benefits of Auto Scaling
Adding Auto Scaling to your application architecture is one way to maximize the benefits of the AWS cloud. When you use Auto Scaling, your applications gain the following benefits:
• Better fault tolerance.
Auto Scaling can detect when an instance is unhealthy, terminate it, and launch
an instance to replace it.You can also configure Auto Scaling to use multiple Availability Zones.
If one Availability Zone becomes unavailable, Auto Scaling can launch instances in another one to compensate.
• Better availability.
Auto Scaling can help you ensure that your application always has the right amount of capacity to handle the current traffic demands.
• Better cost management.
Auto Scaling can dynamically increase and decrease capacity as needed.
Because you pay for the EC2 instances you use, you save money by launching instances when they
are actually needed and terminating them when they aren't needed.
(scale in/out 동일)
- manual scaling : manually increase the size of the group
- dynamic scaling : create a scaling policy to automatically increase the size of the group based on a specified increase in demand.
- scheduled scaling : increase the size of the group at a specific time
- Scale in Process
. scale in 이벤트 발생 , auto scaling group 크기 감소를 위해 삭제할 인스턴스 선택
. 선택한 인스턴스를 standby 상태로 변경
. auto scaling group 에서 인스턴스 제거
. health check 대상에서 fail 로 떨어지면 auto scaling group 에서 삭제
- lifecycel hooks (custom action 수행) 하는동안 새로운 인스턴스가 또 생성되는 것을 방지하기 위해 인스턴스는 pending state 로 시작함
: pending -> pending:wait -> pending:proceed -> Inservice
- scale in 수행시에는
: Terminating -> Terminating:wait -> Terminating:Proceed -> Terminated
- Auto Scaling Limits (limit 증가 요청 가능/ 현재 limit 에 대한 확인 가능해야함)
. Launch configurations 100
. Auto Scaling groups 20
. Scaling policies per Auto Scaling group 50
. Scheduled actions per Auto Scaling group 125
. Lifecycle hooks per Auto Scaling group 50
. SNS topics per Auto Scaling group 10
. Load balancers per Auto Scaling group 50*
. Step adjustments per scaling policy 20
* can attach or detach at most 10 load balancers at a time
- scaling & LB 설정
- Launch configuration 은 새로 만들거나 기존에 있던걸 선택하면 됨
- 기존 launch configuration 사용하는 경우
. LB를 생성할 region 선택
. 사용할 Launch configuration 선택하고 auto scaling group 생성
- launch configuration 을 새로 만들 경우
. LB를 생성할 region 선택
. auto scaling group 을 만들어 둔게 없다면 먼저 만들고 launch configuration 생성
. AMI 선택 -> 인스턴스 타입 선택 (인스턴스의 H/W configuration) -> 상세 설정 (Name, IAM role 설정, Public IP 할당 여부, User data 설정 등) -> security group 설정 -> launch configuration 생성 요청 -> keypair 선택 (인스턴스에 접근해야 한다면 keypair 를 꼭 사용해야함)
- Auto scaling group 생성
. configure auto scaling group 상세 페이지에서
a. 그룹 이름, 타입 설정
b. 그룹 size (최초 인스턴스 생성 개수, VPC 네트워크를 꼭 선택해야함 / T2 와 같은 인스턴스 타입을 사용하려면 VPC 환경이 필요하고 EC2_Classic 같은 타입은 VPC 가 필요하지 않음 )
* T2 인스턴스는 중간 정도의 기본 성능을 발휘하면서 워크로드의 필요에 따라 성능을 크게 높이는 버스트 기능을 제공하도록 설계 (Virtual Private Cloud(VPC)로 T2 인스턴스를 시작해야 하며 EC2-Classic 플랫폼에서는 지원되지 않습니다)
* EC2-Classic 과 VPC 의 차이점
(http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-vpc.html#differences-ec2-classic-vpc)
c. 상세 설정에서 Receive traffic from Elastic Load Balancers 와 auto scaling group 에서 사용할 ELB 선택
d. ELB 에서 health check 를 하려면 ELB 상세 설정에서 health check type 설정
e. auto scaling 정책에서 group initial size 선택 후 설정 내용 리뷰
f. 그룹 생성
* ELB 가 auto scaling gropu 에 정상적으로 연결되었는지 확인
. auto scaling group 선택
. Details 탭에서 Load Balancers 를 보면 ELB 연결 여부가 보여짐
. Activity History 에서 status 컬럼을 보면 auto scaling 인스턴스를 확인할 수 있고 인스턴스가 생성되는 동안의 상태는 In progress 이며 완료된 이후에는 successful 로 변경됨
. 인스턴스 탭의 Lifecycle 컬럼에서 인스턴스 상태가 InService 로 변경되면 traffic 을 받을 준비가 된것임
health status 에서 healtch check 결과를 보여줌
