블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'Auto Scale out'에 해당되는 글 4

  1. 2016.06.13 오토 스케일 아웃(Auto scale out)을 사용해 보자 (1)
  2. 2013.09.11 Auto scaling out (1)
  3. 2011.03.10 Amazon EC2 Auto Scale out Architecture
  4. 2011.03.10 Auto Scale out에 대한 메모..
 


구글 클라우드에서 Auto scale out을 사용해 보자


조대협 (http://bcho.tistory.com)


클라우드의 가장 큰 장점중의 하나는 들어오는 부하에 따라서 서버를 늘리고 줄일 수 있는 유연성에 있다. 그중에서도 부하량에 따라서 서버를 자동으로 늘리고 줄여 주는 auto scaling 기능은 거의 필수라고 할 수 있다.


이 글에서는 구글 클라우드 COMPUTE SERVICE에서 오토스케일링을 설정하는 방법에 대해서 알아보도록 한다.


오토 스케일링을 설정하는 절차를 보면 다음과 같다.


  • 인스턴스 템플릿 정의

  • 인스턴스 템플릿으로 managed group 생성

  • 로드 밸런서 연결


인스턴스 그룹과 로드밸런서의 개념등은 이전의 로드밸런서를 이용한 부하 분산 글 (http://bcho.tistory.com/1113) 를 먼저 꼭 참고 하기 바란다.


인스턴스 템플릿 정의


인스턴스 템플릿이란, 인스턴스를 생성할때의 설정값 (디스크 이미지, 인스턴스 사이즈, 네트워크 설정)을 미리 정해놓고, 인스턴스를 생성할때 템플릿에 정의된 설정값에 따라서 인스턴스를 생성하게 해주는 설정 값의 모음이다.


디스크 이미지 생성

인스턴스 템플릿을 통해서 인스턴스를 생성할때는 디스크 이미지를 선택하도록 되어 있는데, OS와 각종 서버 프로그램 (웹서버)등 이 미리 설치되어 있는 이미지를 생성해놓고, 이 이미지로 템플릿을 생성해놓고, 오토 스케일링 시에, 이 이미지로 인스턴스를 생성하게 한다.  아니면 일반 이미지 (OS만 설치되어 있는 이미지)를 사용하여 템플릿을 만들고 서버가 기동될때 마다 자동으로 필요한 소프트웨어 (애플리케이션, 미들웨어)등을 설치할 수 있도록 스크립트 처리를 할 수 있지만 이 방식은 서버가 기동할때 마다 설치에 걸리는 시간이 있기 때문에, 그 다지 권장하지 않는다.


인스턴스 생성 및 소프트웨어 설치

디스크 이미지를 생성 하는 방법은 인스턴스를 하나 생성해서, 그 인스턴스에 필요한 소프트웨어나 애플리케이션을 모두 설치 한다.


스냅샷 생성

다음으로 인스턴스의 스냅샷을 생성해야 한다.

스냅샷은 Compute Engine 메뉴에서 Snapshots 메뉴를 선택하고 Create snapshot  메뉴를 선택하면 스냅샷을 추출할 수 있다. 스냅샷 추출 메뉴에서는 아래와 같이 스냅샷의 이름을 선택하고 “Source disk” 항목에서, 스냅샷을 추출할 디스크를 선택해야 하는데, 앞에서 생성한 인스턴스의 디스크를 선택하면 된다.




디스크 생성

이 스냅샷을 가지고 디스크를 생성한다. 디스크 생성은 Compute Engine에서 Disks 메뉴를 선택 한다.



다음으로 Create Disk 메뉴를 선택한후에, 디스크 이름을 as-image-disk로 선택하고, Zone을 asia-east1-a 로 지정한다. 다음으로, 어느 소스에서 디스크를 만들지를 선택하기 위해서 Source type을 snapshot으로 선택하고 앞에서 생성한 snapshot을 선택한다.




이미지 생성

디스크가 생성 되었으면 이 디스크를 이용해서 인스턴스 이미지를 생성한다. Compute Engine 메뉴에서 Images를 선택한다.






다음 Create an image 메뉴를 선택하면 아래와 같은 화면이 나오는데, image 이름을 입력하고, 아래와 같이 Source disk를 앞에서 생성한 as-image-disk 를 선택한다.




템플릿 생성

이미지 생성이 끝났으면 이 이미지를 가지고 인스턴스 템플릿을 생성해보자. Compute Engine 메뉴에서 Instance templates 메뉴를 선택한다.



다음으로 Create instance template를 선택해서 새로운 템플릿을 생성한다.

템플릿에 들어가는 내용은 인스턴스를 생성할때 들어가는 내용과 동일하다.

단 템플릿을 만들때 Boot disk를 앞에서 생성한 as-image를 선택해준다.




다음으로, 이 템플릿으로 생성된 인스턴스가 기동될때 자동으로 애플리케이션을 기동하기 위해서 템플릿 설정시 Management 부분에서 Start up script 부분을 아래와 같이 서술해 준다. 아래 스크립트는 예전에도 몇번 다루었지만, 이 이미지내에 설치되어 있는 node.js 애플리케이션을 자동으로 기동해주는 스크립이다.



오토 스케일링 그룹 생성

이제 오토 스케일링 을 지원하기 위한 그룹을 생성하기 위해서 템플릿 생성이 끝났다. 이제, 이 템플릿을 이용해서 오토 스케일링을 지원하는 그룹을 생성해보자


Compute Engine 메뉴에서 Instance groups 를 선택하고 그룹 생성을 선택하자.

그룹 이름을 입력하고, 그룹을 배포한 Zone을 선택한다. (asia-east1-a)를 선택하였다.

다음으로 creation method에서 Use instance template을 선택하고, 앞단계에서 생성한 as-instance-template 을 선택한다.


그리고 아래에 Autoscaling을 on으로 선택한다.

다음에 나오는 Autoscale based on 은 오토스케일링 조건을 어떤 기준으로 할것인가를 선택하는 것인데, 여기서는 CPU를 기반으로 하였고, target CPU가 50% 이상이 지속되면 자동으로 오토 스케일 아웃을 하도록 하였다. (보통 80% 내외가 적절값인데, 여기서는 테스트를 위해서 오토 스케일링이 쉽게 되게 하기 위해서 수치를 낮추었다.)




Minimum number of  instance 는 이 그룹에서 유지되는 최소한의 인스턴스 수이다. 부하가 없어서 스케일 다운이 되더라도 최소한으로 운영되는 인스턴스 수이다. 다음으로 나오는 Maximum number of instances 는 최대로 스케일 아웃이 될 수 있는 인스턴스 수이다 즉, 이 그룹의 위의 설정에 따라서 1~10개의 인스턴스 사이를 부하에 따라서 자동으로 스케일링 인/아웃을 하게 된다.


마지막에 표신된 Cool-down period는

“The cool down period is the number of seconds the autoscaler should wait after a virtual machine has started before the autoscaler starts collecting information from it. This accounts for the amount of time it can take for a virtual machine to initialize.

https://cloud.google.com/compute/docs/autoscaler/scaling-cpu-load-balancing “

오토 스켈링으로 자동으로 생성된 인스턴스가 그룹에 조인할때 까지 대기하는 시간을 정의한다. 인스턴스가 생성이 되더라도, start up 스크립트를 실행하고 애플리케이션을 실행하는 등 자체 준비 시간이 필요한데, 이 시간을 기다리지 않고 바로 로드밸런서에 붙여 버리게 되면 당연히 준비가 안되었기 때문에 에러가 난다. 그래서 cool-down period는 서버가 준비될때 까지의 시간이라고 생각 하면 된다.

로드 밸런서 설정

그룹 생성이 끝났으면 이 그룹을 로드밸런서에 연결 해줘야 한다.

로드밸런서 설정 및 연결은 앞의 글 http://bcho.tistory.com/1113 을 참고하기 바란다.

테스트

이제 모든 설정이 끝났다. 테스트를 해보자.

오토 스케일링을 적용한 그룹을 모니터링 해보면 아래와 같이 앞에서 설정한대로 한개의 인스턴스만 기동되고 있음을 확인할 수 있다.




Apache ab 부하 테스트 툴을 이용해서 부하를 넣어보자.

%ab -n 1000 -c 100 http://130.211.11.38/

로 해서 100개의 클라이언트로 각각 1000개의 부하를 아래 처럼 주었다.




콘솔에서 오토스케링을 적용한 그룹을 살펴보면, 다음과 같이 인스턴스가 자동으로 늘어난것을 확인할 수 있다.


오토스케일링에 대한 몇가지 추가적인 내용들


앞에서 기본적인 CPU 기반의 오토스케일링에 대해서 알아보았다. 오토 스케일링에 대해서 몇가지 추가적인 사항을 정리해보면 다음과 같다.

오토스케일링 조건

앞의 예제에서는 간단하게 CPU 기반의 오토스케일링 규칙을 정의했는데, 오토 스케일러는 다음과 같은 조건에 의해서 스케일링이 가능하다.

  • CPU

  • 로드밸랜서의 사용량

  • Custom metric

  • 위에 3가지를 조합한 값


CPU는 앞에서 이미 살펴보았고, 이외에 로드밸런서의 Utilization이 높아지는 경우 스케일링이 가능하다.

다음으로 흥미로운 것은 Custom metric인데, 인스턴스의 모니터링 지표를 사용자가 직접정의할 수 있다. CPU뿐 아니라 IO또는 애플리케이션 서버 (Tomcat, Django 등)의  응답 시간이나 Idle Thread의 수 등을 모니터링 지표로 정의한 후에, 이 지표가 일정 값이 넘어가면 오토 스케일 아웃을 시킬 수 있다.

(자세한 내용은 https://cloud.google.com/compute/docs/autoscaler/scaling-cloud-monitoring-metrics#custom_metrics_beta  참고)


그리고 마지막으로 위의 3 지표를 조합해서 스케일링 조건을 정의할 수 있다.

예를 들어서 CPU 사용량이 60% 이거나 로드밸런서의 타겟 인스턴스의 Utilization이 50% 이거나, 타겟 인스턴스의 Custom metric 값이 1000 일때 스케일링을 하도록 할 수 있다.


오토 스케일링을 결정하는 상세한 조건에 대해서는 https://cloud.google.com/compute/docs/autoscaler/understanding-autoscaler-decisions

를 참고하기 바란다.

AutoHealing

오토 스케일링 그룹의 경우 Auto healing 이라는 기능을 제공하는데, HTTP health check를 이용하는 경우에, 인스턴스가 일정 시간 동안 응답이 없으면 문제가 있는 인스턴스라고 생각하고, 자동으로 재 기동을 해준다. (현재는 베타)

https://cloud.google.com/compute/docs/instance-groups/?hl=en_US&_ga=1.104223488.1034565888.1463987102#disabling_creation_retries_mode

Monitoring managed instance groups with health checks

Beta

This is a Beta release of Autohealing. This feature is not covered by any SLA or deprecation policy and may be subject to backward-incompatible changes.

You can apply HTTP health checks to managed instance groups to verify that services are running properly on the instances in that group. If a health check determines that a service has failed on an instance, the group automatically recreates that instance. These checks are more precise than simply verifying that a server is in a RUNNING state.

결론

지금까지 구글 클라우드의 오토 스케일 아웃 기능에 대해서 알아보았다. 클라우드 컴퓨팅에서 많은 장점을 제공하는 기능인 만큼 잘 숙지하여 적용을 하고, 특히나 서비스 부하 모델에 맞는 적절한 Min,Max 인스턴스 수의 설정과 스케일링 조건을 설정하여 (테스트를 통하여) 자원을 효율적으로 사용하고 부하에 적절하게 대응할 수 있도록 하자.



Auto scaling out

클라우드 컴퓨팅 & NoSQL/Amazon Web Service | 2013.09.11 00:17 | Posted by 조대협

 

클라우드 컴퓨팅 서비스에서 서비스의 부하량과 사용량에 맞게 탄력적으로 컴퓨팅 자원을 늘렸다가 줄였다 하는 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를 사용하여 정교화 하는 것이 좋음

 

 

'클라우드 컴퓨팅 & NoSQL > Amazon Web Service' 카테고리의 다른 글

Auto scaling out  (1) 2013.09.11
Amazon의 CDN 서비스 Cloud Front  (0) 2013.09.10
Amazon Route 53 DNS 서비스  (0) 2013.09.09
Amazon Elastic Load Balancer  (2) 2013.09.09
Amazon Direct connect  (0) 2013.09.06
Amazon VPC (Virtual Private Cloud) 소개  (3) 2013.08.18

Amazon EC2 Auto Scale out 아키텍쳐http://docs.amazonwebservices.com/AutoScaling/latest/DeveloperGuide/index.html?Welcome.html

  1. Cloud Watch를 통해서, 이미 기동중인 Instance를 모니터링 한다.
  2. Instance의 CPU나 Throughput을 기반으로 해서 Scale out 여부를 결정한다
  3. Scale out을 하게 되면, 해당 Instance의 AMI를 추가로 Provisioning 한다.
  4. Elastic Load Balancer에 새롭게 추가된 Instance를 연결해준다.

기본적인 아키텍쳐인데, 전형적인 Scale Out 방식이고, Image에 올라가 있는 (VM)의 Application의 Scale out은 지원하지 않고, 개발자 스스로 대비해야 한다.
Apache와 같은 웹서버나, 클러스터링이 되어 있지 않은 Tomcat과 같은 WAS는 가능하겠지만, 아래 글에서 처럼, Oracle이나 MySQL과 같은 DBMS나 JMS등은 Scale out 자체가 불가능 하기 때문에, 자체로 클라우드 대비 아키텍쳐로 디자인 해야 한다. 


Auto Scale Out을 고민할 일이 있어서.. Amazon EC2를 봤는데..
역시나..
EC2는 기본적으로 IaaS이기 때문에, CPU나 어느 조건 이상이 되면 Config 된데로, Scale out이 되는데, AMI 이미지 똑같은 것을 하나 더 띄우고, Load Balancer에서 연결해주는 형태..

즉, 일반적인 웹서버나 클러스터가 안되어 있는 Tomcat등은 그럭저럭 먹힐거 같은데..
WebLogic,JBoss 등은 어렵다는 이야기, 결국 API로 WLS등 모니터링해서 Scale out할 수 있게 해주고, AMI 이미지도 Instance별로 별도 고려가 되야 하는 형태..

Scale out은 아무래도 PaaS가 유리한듯..

그리고, DB Auto Scale out 이야기 하시는분들 있는데, 일반적인 RDB에서는 안되거든요? Oracle에서 2 Machine 이상 도는거 보셨어요? (RAC기준). RDB에서 Scale out할려면, Sharding 아키텍쳐로 설계가 되도 쉽지 않고, 오로지 CDC를 이용한 Query Off Loading 방식만 가능한데, 이 경우에도 WAS에서 Connection Pool이 Scaled out된 DB Instance를 볼 수 있어야 합니다. 물론, HBase와 같은 Column DB는 당연히 Scale out이 고려된 솔루션이니까는 가능합니다만....

WAS와 DB Scale Out 아키텍쳐 정리해야 하는데.. 귀찮다..ㅜㅡ
맥주나 한잔하고 자야 쓰겄습니다.
요즘 집중력 저하야... 딘따..