멜번에서 어플리케이션 아키텍트 및 개발자로 일하고있는 노동자입니다.

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

Amazon Linux가 아닌 일반 머신에서는 반복적으로 AWS CLI를 설치하게되는데요, 그 과정을 단순히 정리해봅니다. RHEL계열은 아래과정과 대동소이하며, Debian계열의 Linux에서도 거의 비슷합니다.

우선 Python이 설치되어 있다고 가정합니다.

전체적인 과정

• 먼저 Python 패키지관리자인 PIP을 설치해줘야합니다.
• Python Packaging Authority에서 제공하는 스크립트를 사용하여 pip를 설치한 다음 AWS CLI를 설치합니다.

wget이나 curl을 이용해서설치스크립을 다운로드.

$> curl -O https://bootstrap.pypa.io/get-pip.py

Python으로 다운로드 받은 파일을 실행합니다.

$> python get-pip.py --user

설치된 패키지를 영구히 등록하려면 "./.local/bin"를 PATH에 추가 등록합니다.

$> export PATH=$PATH:./.local/bin

pip이 정상적으로 설치되었는지 다음과 같이 확인해 봅니다.

$> pip --version

이젠 pip으로 AWS CLI를 설치합니다.

$> pip install awscli --upgrade --user

ELB를 설정하다보면, 세션 체크가 필요한 어플리케이션의 경우, ELB뒤에 연결된 서버에서 다음 요청에서 기존의 서버에서 다른 서버로 분산되어 연결되면 다시로그인 한다거나하는 기존의 세션정보를 잃기때문에 사용자가 처다보고있는 화면이 이상하게 되어버립니다.

이런 경우 Sticky Sessions를 설정해서 쿠키 세션을 기준으로 트래픽을 분배하므로서 이러한 문제를 해결합니다.

주요 설정하게 되는내용은

 - ELB가 설정하는 쿠키를 사용할것인지(사용자가 쿠기가 만료될 시간(초)를 입력)

 - 어플리케이션에서 생성하는 쿠키를 사용할것인지(사용자가 쿠키이름을 입력)

Layer 4에서 설정하는 Classic Type의 ELB에서는 하단의 Description 하단에서 Edit stickyness 버튼을 선택해서 수정하면 됩니다.

Layer 7에서 설정하는 Application ELB에서는 ELB가 요청을 받아서 처리하게될 Target Group의 Attribute Section 에서 수정해줘야 합니다.

부라우저(아래는 크롬)에 AWSELB 로 쿠키가 생성되어 있는것을 확인할수 있습니다.

Test Environment

    - CentOS Linux release 7.3.1611 (Core)

    - Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-62-generic i686)

    - VirtualBox 5.1.24

Guest에서 "mount -t vboxsf share /mnt/share"를 해서 마운트를 시도하려다보면

mount: unknown filesystem type 'vboxsf' 오류가 나올것이다. 이것은 추가로 Guest OS에서 설치 해줘야하는 것이 있기 때문이다.

1. Prepare Addional Package for CentOS

위해서 다운받은(또는 본인의 설치된 VirtualBox디렉토리 어딘가에 있을수있다. 없다면 http://download.virtualbox.org/virtualbox에서 본인의 VirtualBox 맞는 버전의 ISO 파일을 받자. 그리고 이 ISO파일을 VirtualBox의 스토리지 콘틀러에 등록해서 Guest에서 마운트해서 사용할수 있도록 준비한다. 본인의 경우 : VBoxGuestAdditions_5.1.24.iso를 받아서 적용 했음.

2. 패키지를 Update해주고 추가로 필요한 모듈 설치

$> yum update

$> yum install gcc kernel-devel make

$> yum install bzip2

3. 그리고 재 부팅

$> reboot

4. 마운트될 디렉토리(나중에 사용될 공유디렉토리와, ISO를 받은 컨트롤러를 마운트할 디렉토리)생성 및 에드온ISO에있는 실행파일 실행킨다.

$> mkdir /mnt/share

$> mkdir /mnt/cdrom

$> mount -t auto /dev/cdrom /mnt/cdrom

$> cd /mnt/cdrom/

$> ./VBoxLinuxAdditions.run

이젠 호스트 컴퓨터와 CentOS Guest간에 공유할 준비가 되었다.

5. VirtualBox에서 등록해준 공유디렉토리 이름을 이용하여 마운트 해본다.

$> mount -t vboxsf share /mnt/share

*** Ubuntu의 경우 4번부터 실행하면 별다른 이상없이 공유할 폴더를 마운트하는데 문제가 없었습니다.