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단에서 처리 등