클라우드 컴퓨팅 & NoSQL/Amazon Web Service

Auto scaling out

Terry Cho 2013. 9. 11. 00:17

 

클라우드 컴퓨팅 서비스에서 서비스의 부하량과 사용량에 맞게 탄력적으로 컴퓨팅 자원을 늘렸다가 줄였다 하는 auto scaling 기능은 기존의 인프라가 가지지 못한 큰 장점 중의 하나이다. 아마존 클라우드 서비스는 이 auto scaling 기능을 서비스로 제공하고 있다.

 

Auto scaling의 기본 개념

아마존에서 제공하는 auto scaling의 기본 개념은 다음과 같다.

여러 개의 EC 인스턴스들을 auto scaling group이라는 하나의 그룹으로 묶어 놓는다. 그리고 각 인스턴스들은 ELB 로드 밸런서를 통해서 로드가 분산된다.

이 그룹을 Cloud Watch라는 아마존의 클라우드 모니터링 솔루션을 통해서 자동으로 감지하게 되는데, 사용자가 정의 해놓은 일정한 조건 (예를 들어 평균 CPU 사용율이 80% 이상이 5분 이상 지속)이 되면, Auto Scaling 기능을 동작 시키도록 설정해놓을 수 있다.

그러면 auto scaling 기능이 auto scaling group 내에서 사용되고 있는 동일한 VM 이미지를 스토리지로 부터 읽어서, 미리 규칙에 정해 놓은 인스턴스 크기에 수 만큼 인스턴스를 자동으로 추가하고 ELB에 연결한다.

 그리고 반대로 리소스의 사용량이 일정 상항 아래로 내려가게 되면 정해진 규칙에 따라서 EC2 인스턴스를 자동으로 제거하낟.

 


Amazon에서 Auto scaling 설정하기

1) Launch configuration 정의 하기

여기서는 Auto Scaling이 발생했을때, Scaling out 되는 인스턴스를 정의 한다. 어떤 크기의 인스턴스(인스턴스 타입)를 어느 AMI 이미지로 띄울지, EBS Block 디바이스 맵핑,Security Group등이 포함된다.

as-create-launch-config launch-config--image-id ami-00797213 --instance-type m1.large

 

2) Auto scaling group 정의 하기

다음으로는 Auto Scaling group을 정의 한다. group auto scaling이 될 EC2 인스턴스들이 정의 되는 일종의 그릇이다. group이 어느 availability zone (여러개의 Zone에 걸쳐서 정의 가능)들에 걸쳐서 정의 될지, 그리고 group 내에서 유지되는 최소,최대 ec2 인스턴스의 수를 정의하고, 앞에서 정의한 Launch configuration을 정의 함으로써 group 안에 생성되는 ec2 인스턴스의 타입을 정의한다.

as-create-auto-scaling-group TestGroup --launch-configuration MyLC --availability-zones us-east-1a --min-size 1 --max-size 1

min, max 값이 중요한데, min 값의 경우 cloud watch등으로 group내를 모니터링 하다가 ec2 인스턴스가 예측하지 못한 장애등으로 shutdown되었을 경우, 자동으로 Launch configuration에 정의된 EC2 인스턴스를 group내에 생성한다..

 

3) Auto scaling policy

다음은 Auto scaling이 일어나는 방식을 정의 한다. Policy라는 것으로 정의 하는데,Auto Scale out 이 발생할 때, 몇 개의 instance를 늘릴 것인지, 반대로 scale in이 발생할 때 몇개의 인스턴스를 줄일 것인지를 정의 한다. 개수로 정의할 수 도 있고, %로 정의할 수 도 있다.

 

예를 들어 30%의 인스턴스 수 만큼 늘리는 scale out 정책을 정의하면

Ÿ   Policy name = my-scaleout-policy

Ÿ   Auto Scaling group name = my-test-asg

Ÿ   Adjustment = 30

Ÿ   Adjustment type = PercentChangeInCapacity

다음과 같은 CLI 명령어를 이용해서 정책을 정의 한다.

as-put-scaling-policy my-scaleout-policy -–auto-scaling-group ASG --adjustment=30 --type PercentChangeInCapacity

명령을 실행하면 리턴 값으로 ARN 코드라는 것을 다음과 같이 리턴하는데,

arn:aws:autoscaling:us-east-1:987654321012:scalingPolicy:af521352-c2e3-8291-811b-a2a34asdfaf8a:autoScalingGroupName/ ASG:policyName/my-scaleout-policy

나중에 이 ARN 코드를 뒤에서 정의할 Action에 정의 하여, Scale Out이 발생할때, 이 정책에 따라서 인스턴스 수를 늘리도록 하낟.

 

4) Scaling condition (action)

그리고 마지막으로 Auto Scaling이 일어나는 조건 (시점)을 정의 한다.

Cloud Watch Alarm 기능을 이용하는데, Cloud Watch의 특정 모니터링 Matrix이 일정 조건을 만족하면 앞에서 정의한 Scaling policy에 따라서 인스턴스를 늘리거나 줄이도록 한다.

먼저 Cloud Watch에서 Alarm을 정의 한다.

Ÿ   Alarm name = AddCapacity

Ÿ   Metric name = CPUUtilization

Ÿ   Namespace = "AWS/EC2"

Ÿ   Statistic = Average

Ÿ   Period = 120

Ÿ   Threshold = 80

Ÿ   Comparison operator = GreaterThanOrEqualToThreshold

Ÿ   Dimensions = "AutoScalingGroupName=my-test-asg"

Ÿ   Evaluation periods = 2

위의 정의는 EC2 CPU의 평균 값이 80 이상으로 120초 이상 지속 될 경우 Alarm을 발생하도록 하고, 다음과 같이 Alarm이 발생하였을 때 앞에 정의한 policy를 수행할 수 있도록 아래와 같이 ARN값을 binding 시킨다.

Ÿ   Alarm action = arn:aws:autoscaling:us-east-1:123456789012:scalingPolicy:ac542982-cbeb-4294-891c-a5a941dfa787:autoScalingGroupName/ my-test-asg:policyName/my-scaleout-policy

 

이렇게 alarm 방식으로 scaling 하는 것 이외에도, Schedule에 따라서 scaling도 가능하다.

예를 들어 축구 경기가 있는날 치킨집 주문 시스템을 scale out 해놨다가 축구가 끝난후 2시간후 scale in 하거나, 월말 마감이 있는 시스템의 경우 매달 마지막 주에 scale out을 해놓는 시나리오등이 가능하다. Schedule 기반의 scalingas-put-scheduled-update-group-action 명령어를 이용해서 정의 하면 된다.

다음과 같이 특정 시간을 지정하는 방식을 사용할 수도 있고

Ÿ   Name of your scheduled action = ScaleOut

Ÿ   Auto Scaling group name = my-test-asg

Ÿ   Desired Capacity = 3

Ÿ   Start time = “2013-05-12T08:00:00Z”

또는 Unix Cron과 같이 특정 반복 패턴 별로 scaling을 할 수 있다

Ÿ   Name of your scheduled action = Scaleout-schedule-year

Ÿ   Auto Scaling group name = my-test-asg

Ÿ   Desired Capacity = 3

Ÿ   Recurrence = “30 0 1 1,6,12 0”

 

Amazon의 다른 인프라와 연계 하기

ELB 연동

VPC 연동

IP 연동

 

주의 할점

AMI 이미지에서 initialize configuration (startup script)를 잘 정의 해 놓을 것.

Zoo Keeper를 이용한 확장도 고려해볼만 함.

IP가 자기맘대로 지정되기 때문에, 제니퍼와 같은 고정 ip 솔루션 적용이 어려움

 

 

아래 참고 자료

--

ELB에 어떻게 꼽을까요?

http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/US_SetUpASLBApp.html

AutoScaleGroup을 만들때, LoadBalancerNames.member.1 = my-test-asg-loadbalancer parameter를 넣어서, auto scaling out group load balancer binding이 가능함.

 

ELB autoscaling group에 대해서 health check로 사용하려면

Ÿ   Auto Scaling group name = my-test-asg-lbs

Ÿ   Health check type = ELB

Ÿ   Health check grace period = 300

 

group 생성시, health check type ELB로 지정 가능

as-update-auto-scaling-group my-test-asg-lbs –-health-check-type ELB  –-grace-period 300 

 

 

 

IP는 어떻게 배정 할까요?

- EIP를 사용할 경우에는 EIP Pool에서 fetch에서 가지고 올 수 있음

- VPC에는 명시적으로 IP를 지정할 수 없음. auto scaling out 그룹에 subnet을 지정할 수 있음. 그러면 해당 subnet의 주소를 물고 올라옴

as-create-auto-scaling-group myvpcasgroup --launch-configuration myvpclc --availability-zones 
"us-east-1b,us-east-1a" --min-size 0 --max-size 10 --desired-capacity 10 --vpc-zone-identifier 
"subnet-610acd08,subnet-530fc83a"

 

VPC의 경우 ip 주소가 변경된다. 그래서 고정 ip를 이용해서 모니터링 해야 하는 jennifer등을 사용시에는 문제가 있을 수 있기 때문에, fix ip를 사용하는 instance auto scale out instance를 같이 합쳐서 사용하는 것이 좋다.

 

멀티 존의 경우 어떤 순서로 생기나요?

 

자세한 configuration 자료는 http://awsdocs.s3.amazonaws.com/AutoScaling/latest/as-qrc.pdf 를 참고

 

auto scale out 은 초기 설정은 복잡하지만 한번 해놓으면 거의 반복해서 재활용이 가능.

CPU 보다는 JMX 기반으로 thread count, 기타 factor를 사용하여 정교화 하는 것이 좋음

 

 

그리드형