1. 소개

본 아티클은 클라우드(Cloud) 기술의 핵심 오토 스케일링(Auto Scaling)에 대한 정리이다.

2. 흐름

기본적인 흐름은 이미지 생성 -> 이미지 배포 -> 모니터링 -> 알람 -> Scale-Out (-> Scale-In) 이다.

3. 이미지 생성

• S/W를 설치하고 관련 스크립트까지 생성한다.

4. 모니터링

• 각 인스턴스가 얼마나 많은 리소스를 사용하고 있는지 감시해야 한다.
• 관련 리소스는 CPU, Disk I/O, Network I/O 등이다. 이들의 임계치와 조건 설정이 필요하다.

5. 알람

• 모니터링 결과 임계점 이상 올라가면 트리거에 의하여 scale-out 하기 위해 알람을 보낸다.
• 모니터링 결과 임계점 미만 내려가면 트리거에 의하여 scale-in 하기 위해 알람을 보낸다. 
• 알람 방식은 E-mail 등이다.

6. 그룹핑

• 인스턴스를 모아놓은 논리적 단위다. (최소/최대 인스턴스 수는 이 그룹과 매핑된다)
• 예: 최소 1개, 최대 10대
• 자동 생성되는 VM의 이름 정책이 필요하다.

7. 규칙 생성

• 조건 : CPU 사용률, 로드 밸런서 사용량, 기타 사용자 정의 수치
• 최소/최대 인스턴스 수

8. 로드 밸런서 연결

• 신규 생성되는 VM을 LB에 자동 등록하는 정책

9. 기타 기능

• 오토 힐링 (구글) : HTTP Health Check 사용 시 일정시간 응답이 없으면 인스턴스 재기동
• AWS 쿨 다운 : 최종 변경 작업 이후 다음 변경 작업까지 대기 시간
• AWS 수동 스케일링 : [Desired]에서 원하는 용량을 늘리거나, CLI에서 set-desired-capacity 명령을 사용

10. 예제

• CPU 사용률이 80%를 5분 이상 넘을 때 인스턴스 수를 2배 증가시킨다. 만약 (AWS) 쿨 다운이 1분이라면 1분 내에는 다시 작업이 발생하지 않는다.

11. 관련 S/W

• Chef, Puppet, Docket, Vagrant, Packer, Serf

12. 관련 링크

• http://sarc.io/index.php/aws/545

13. 단상

• DB의 경우는 급증하는 요청을 견디기 위해 다른 방안을 고민 : 캐시 서버 도입, 읽기 전용 서버(Read replica) 추가, 비즈니스에 따른 분산 (샤딩), CPU를 많이 사용하는 로직을 DB가 아닌 AP단에서 처리 등