Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

Contents

아마존 Auto scaling 가이드가 아니다. 아마존 Auto scaling을 분석을 하고 분석 결과를 토대로 구성방안을 세우는게 목적이다.

Auto Scaling

Auto scaling는 사용자가 정의하는 조건에 따라서 컴퓨팅자원과 네트워크 자원을 자동으로 늘이거나 줄이는 기능이다. 퍼블릭 클라우드에 Auto scaling를 적용할 경우 얻을 수 있는 잇점은 다음과 같다.
  • 자원을 탄력적으로 사용할 수 있다.
많은 자원을 필요로 하는 유저에게 자원을 더 할당하고, 그렇지 않은 유저에게서 자원을 회수 할 수 있기 때문에 효율적인 자원의 사용이 가능하다. 예컨데 클라우드 환경에서의 QOS(Quality of service)가 가능하게 한다.
  • 유저는 비용을 절약할 수 있다.
필요한 만큼의 자원을 사용할 수 있기 때문에, 비용을 절약할 수 있다.
  • 유저는 서비스 환경에 탄력적으로 대응할 수 있다.

Auto Scaling 요소

Auto Scaling는 두 가지 요소가 있다.
  • 서비스 제공자 입장 : 네트워크 장비
서비스 제공자 입장에서는 네트워크 대역폭이 Auto Scaling 대상이 된다. 여러대의 LB 장비로 Cluster를 구성해서 ELB를 서비스 하는데, Cludster의 특정 LB 디바이스가 더 이상 대역폭을 제공할 수 없다면, scale-up을 해야 한다. 이를 위해서 VIP별 트래픽 모니터링, 디바이스 전체 트래픽 모니터링을 해야 할 것이다. 관련된 내용은 ELB 서비스 구성문서를 참고하기 바란다. 이 문서에서는 자세히 다루지 않겠다.
  • 서비스 사용자 입장
서비스 사용자는 자신의 자원 사용량에 따라서, scale-up/down할 수 있어야 한다. CPU 자원이나, 네트워크 트래픽, 디스크 I/O등을 모니터링 하다가 일정 수준을 초과하면 scale-up해서 자원을 요청해서 서비스의 품질을 확보해야 하고, 반대의 경우 scale-down해서 자원을 돌려줌으로써 비용을 절약한다.

AWS 아키텍쳐

다음은 AWS 아키텍쳐다.

Auto Scaling는 Monitoring과 Deployment and Automation API를 이용해서 서비스를 전개한다. AWS의 아키텍쳐는 자세히 분석해볼 필요가 있을 것같다. 하부 인프라를 잘 설계하고, 각 인프라를 제어할 수 있는 API를 제공해서 이들 API의 조합으로 새로운 서비스를 개발하는 좋은 구조로 보인다. 언뜻 생각해도 Monitoring 모듈과 Deployment and Aytomation 모듈만 잘 만들어 놓으면, auto scaling 서비스의 개발은 Command Line Interface와 Web Interface만 수정하면 되는 것이니 쉽게 개발할 수 있을 테다.

Auto scaling이 필요한 시나리오

Auto scaling이 필요한 상황을 먼저 정리해 보자.
  1. 특정일에 서비스 이벤트가 잡혔다. 이벤트 기간동안에는 서비스 사용량이 늘어날 것이다. 이벤트가 시작하는 날에 VM을 늘리고, 이벤트가 끝나면 원래 상태로 VM 갯수를 되돌린다.
  2. 상시적으로 CPU, Disk I/O, 네트워크 I/O등을 모니터링 하다가 VM을 늘리거나 줄인다.

Auto scaling을 위해서 필요한 기술

모니터링

AWS는 아래의 요소를 모니터링한다.
  1. Disk I/O
  2. Network I/O
  3. Cpu Usage
모두 Hypervisor 레벨에서 수집할 수 있는 데이터들이다. KVM은 QMP를 이용해서 테스트 해본 결과 위의 정보를 모두 제공함을 확인 했다. Xen은 직접 테스트해보진 않았지만 역시 제공하는 걸 확인했다.

디스크사용량, 특정 프로세스의 자원 사용량등을 모니터링 요소로 하려면 유저가 직접 Agent를 설치하고, 이를 관리할 소프트웨어를 개발해야 한다. 하지만 굳이 Agent를 설치해 가면서 정보를 수집해야 할 필요가 있는지는 모르겠다.

먼저 디스크 사용량의 경우 모니터링한다고 해도 scaling하기가 애매모호하다. scaling은 VM을 늘이고 줄이는 것으로 제어하는데, 디스크의 경우 새로운 볼륨을 요청해야지 VM을 늘린다고 해서 할 수 있는게 없기 때문이다. 프로세스 모니터링도 마찬가지다. 프로세스 모니터링은 다른 관리적인 목적으로 사용할 수는 있겠지만 scaling 제어를 위한 목적으로 사용할 필요는 없을 것같다. CPU 모니터링으로 충분하지 싶다.

Cloud를 위한 Agent 방식의 모니터링 솔류션은 scaling 보다는 다른 관리의 목적으로 개발해야 하지싶다. 이에 대해서는 좀 더 조사가 필요하다.

ELB

Auto scaling은 특성상 ELB와 연동해서 사용하는 경우가 많다. MapReduce와 같이 많은 컴퓨팅 자원이 필요한 경우에도 scaling 서비스를 이용할 수는 있겠지만 예외로 하겠다.

ELB 기술은 ELB 서비스 구성을 참고한다.

유저 서비스 시나리오

유저 서비스 시나리오는 대략 다음과 같다.
  1. Launch할 VM과 VM의 타입을 설정한다.
에컨데 만들 VM의 Template를 선택.
  1. Auto scaling 그룹을 만든다.
Auto scaling 그룹의 이름과 이 그룹이 사용할 VM Template, availability zone, 생성될 vm의 갯수 등을 설정한다.
  1. Auto scaling 정책을 설정한다.
    1. Health Check : Health Check만 하는 단순한 유형이다. VM에 문제가 생기면, 새로운 VM을 만든다.
    2. Create Trigger : CloudWatch 모니터링 서비스와 연동한다. Auto scaling 그룹에 포함된 VM 인스턴스를 모니터링 하다가 정책에 걸리면, scaling을 한다.