Grace Period /Scaling Cooldowns on AWS AutoScaling & Stress 테스트

AWS에서의 Scaling은 처음에 설정해보고 테스트해보면 그 편리성과 예전과는 비교할수 없을만큼 용이함에 모든것이 이해된것 처럼 생각되지만, 막상 프로젝트에서 이를 구현하다보면 기본 개념이 정리되지 않아서 그 문제를 찾기 어려운 경험이 있었습니다. 다시한번 쭉 살펴보면서 몇가지 정리해 보았습니다.

AutoScaling 설정은 보통 다음과 같은 과정을 거치게됩니다.

1. AutoScaling 그룹에서 사용할 템플릿(Configurtion)을 정의

   : 개발 인스턴스 설정하는 것도 거의 동일합니다.

    - 어떤 형태의 인스턴스를 사용할것인지 선택  : 리눅스종류, 스토리지, SecurityGroup, 사용할키페어

    - IAM Role 지정

2. 정의된 템플릿을 이용하여 AutoScaling Group 정의

    - 몇개의 인스턴스부터 시작할것인지

    - Scaling될 AZ들 선택

    - 임계치설정

        - 인스턴스를 어떤 경우에 증가 할 것인지

        - 인스턴스를 어떤 경우에 감소 시킬 것인지

    - 이미 운영중에도 대부분의 임계치 값을 변경시킬수 있습니다.

나의 경우 그 동안 몇가지 개념때문에 트러블슈팅에 애를 먹은 경험이 있는데, 아래 임계치 설정에대한 개념의 좀 부족했던것 같습니다.

Health Check Type :

    EC2 - Amazon EC2에서 제공한 상태 확인 (기본)

    ELB - Elastic Load Balancing에서 제공한 상태 확인

Health Check Grace Period :

AutoScaling을 하는 입장에서는 해당 인스턴스의 상태를 체크해서 리소스를 늘려야할지 줄여야할지 판단해야하는데

이때 언제 이 상태를 체크하느냐가 문제가 될수있습니다.

일단, AutoScaling이 작동하기 위해서는 인스턴스가 InService상태가 될까지는 기다려야 합니다.

Health Check Grace는 ELB로부터 Health Check를 받고 얼마만큼 기다려야하는가와 관련이 있습니다.

보통은 그래서 어플리케이션이 구동되는데 3분이 걸리면 최소한 180초(3분)를 잡으라고 되어있지만, 

실상 이것은 ELB에서 Health체크의 임계값에 따라 결정되어야하며

    

Healthy인지 Unhealthy인지 Threshold값과 Interval 설정을 고려해서 설정해야 하겠습니다.

증상 : 이러한 소요기간보다 Health Check Grace를 적게잡으로 의도하지 않게 서버서비스가 올라올때 이미 서버가 ScaleUp되어있는 현상이 있을수있습니다.

Scaling Cooldowns : 

Health Check Grace Period와 약간 혼동스러운 부분이 있는데, 인스턴스 상태값(Not ELB)을 체크하여 AutoScaling 스케일작업을 결정할때 일반적으로 서버가 시작되도 어플리케이션 구동(예를들어 무거운 WAS서버등)의 준비 시간이 필요하기 때문에 이러한 추가 시간을 설정해주도록 해서 이러한 조정작업을 중지하도록 조치 할수 있습니다.

http://docs.aws.amazon.com/autoscaling/latest/userguide/Cooldown.html

http://docs.aws.amazon.com/autoscaling/latest/userguide/healthcheck.html

    

어떻게보면 AuotoScaling 자체가, 시스템의 성능보다는 신뢰성을 높이는데 촞점이 맞추어져있지만, 고객이나 엔드유저 입장에서는 이러한 임계값간의 Gap으로 인하여 성능에관한 이슈로 발전 될 수도 충분히 있습니다. 이러한 임계값을 최적화 하므로서 이러한 이슈를 최소화 할 수 있다고 봅니다.

요즘 경량화된 컨테이너 사용으로 베이스이미지를 사용하는 경향이 있는데...그리도 서버를 프로젝트에 맞게 프로비저닝하는 시간도 무시할수 없습니다.  완전한 베이스 이미지로부터 프로비저닝하기보다는 프로젝트에 최적화된 기본 베이스를 더 적극 활용하므러서 이러한 Threshold간의 Gap을 줄일수 있는 포인트라 할수 있겠습니다.

Stress Tool 사용

AutoScaling을 설정을 하다보면 설정한 환경이 의도대로 작동하는지 테트해 봐야겠지요. 

이런 경우 간단히 사용할수 있는 stress 사용을 정리해보았습니다.

(이왕이면 htop과 같은 툴도 같이 설치하면  OS레벨에서 실제 변화되는 수지를 확인하면서 AWS가 어떻게 반응하는 확인이 더 수월하겠습니다.)

1개 core CPU에 60초가 부하테스트

$> stress -c 1 -t 60

4개 core CPU에 60초가 부하테스트

이때 예를 들어 코어가 1개라도 4개를 지정하여 실행하면 X4배 만큼 부하를 주게됩니다.(프로세스 4개 생성)

$> stress -c 4 -t 60

256M(메로리를 지정하지 않으면) X 3 를 소비하는 60초간 부하 즉 256M를 소비하는 3개의 프로스가 부하를 주게됩니다.

$> stress -m 3 -t 60

300M X 2를 소비하는 60초간 부하

$> stress -m 2 --vm-bytes 300M -t 60

1G(기본값)의 2개의 프로세스로 Disk 60초간 테스트

$> stress -d 2 -t 60

512M의 2개의 프로세스로 Disk 60초간 테스트

$> stress -d 2 --hdd-bytes 512M -t 60

CPU, Memory 그리고 Disk에 모두 테스

$> stress -c 4 -m 2 -d 1