오토 스케일 아웃(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 인스턴스 수의 설정과 스케일링 조건을 설정하여 (테스트를 통하여) 자원을 효율적으로 사용하고 부하에 적절하게 대응할 수 있도록 하자.