네이버 클라우드 플랫폼의 상품 사용 방법을 보다 상세하게 제공하고, 다양한 API의 활용을 돕기 위해 [설명서][API 참조서]를 구분하여 제공하고 있습니다.

Auto Scaling API 참조서 바로가기 >>
Auto Scaling 설명서 바로가기 >>

Auto Scaling 서비스 소개

Auto-scaling이란

Scaling이란 서비스 요청이 늘어나면 이를 수용하기 위해 서버의 수를 늘려 연산 능력(capacity)을 향상시키고 반대로 서비스 요청이 줄게 되면 불필요한 서버의 수를 줄이는 action을 말합니다. 서버의 수를 늘려서 서비스 능력을 향상시키는 것을 scale-out이라고 하고, 반대로 서비스 요청이 줄어서 서버의 수를 줄여서 서비스 능력을 줄이는 action을 scale-in이라 합니다.

아래 그림처럼 보통 특정 서비스를 담당하는 복수의 서버들이 하나의 그룹을 이루어 로드밸런서에 등록되어 인터넷을 통해 들어오는 서비스 요청을 분산 담당하고 있습니다.

서비스 요청이 늘어나면 기존 서버의 부하가 늘어나므로 원활한 서비스 처리를 위해 아래 그림처럼 서버를 추가해야 합니다. 이러한 action을 scale-out이라 합니다.

이와 반대로 서비스 요청이 줄어들면, 많은 서버를 유지하기 위해 과도한 사용료를 낼 필요가 없으므로 아래 그림처럼 기존 서버들 중 일부를 제거합니다. 이러한 action을 scale-in이라고 합니다.

Auto Scaling이란 문자 그대로 이러한 scaling acation이 자동으로 이루어지는 서비스를 말합니다. 그리하여 Auto Scaling을 이용하면 아래 그림처럼 시간에 따라 서비스 요청(붉은 실선)이 늘거나 줄어드는 상황에서 서비스 요청이 늘어나면 자동으로 서버의 수를 늘려서 서비스 처리 능력(푸른 점선)을 향상시켜서 서비스가 원활하게 이루어지도록 하고, 반대로 서비스 요청이 줄어들면 자동으로 서버의 수를 줄여서 서버 사용료를 덜 내게 합니다.

서비스 요청에 따라 자동으로 scaling되는 서버 그룹을 Auto Scaling에서는 Auto Scaling Group이라고 부릅니다.
Auto Scaling은 서비스 용량을 Auto Scaling Group 소속의 서버 인스턴스의 수로 조정하게 되며, 서비스 용량은 Auto Scaling Group의 크기에 따라 조정됩니다.

Auto Scaling 서비스 도중 자동 Scale-out을 해야 하는 상황에서는 새로운 서버 인스턴스를 생성하여 서비스에 투입(launch)해야 하는데 서버 인스턴스를 생성하기 위한 각종 정보를 저장한 설정을 Launch Configuration이라 부릅니다.

Launch Configuration의 주요 항목으로 서버이미지 정보와 서버 사양 정보가 있습니다. 예를 들어, 서버이미지가 Linux이고 서버 사양이 1 CPU에 2GB 메모리라고 설정을 하면 이 정보를 틀(template)로 하여 1 CPU, 2 GB 메모리의 Linux 서버가 생성됩니다.

Auto Scaling 서비스 자체는 무료이나 Auto Scaling 서비스에 의해 만들어진 서버 인스턴스는 시간 요금제를 적용 받습니다. 시간 요금제 대한 자세한 정보는 네이버 클라우드 플랫폼 웹사이트의 서버 상품 안내 페이지에 (https://www.ncloud.com/product/compute/server) 있습니다.

Auto-scaling 서비스 구조

다른 서브-시스템과의 연동

Auto Scaling 서비스를 수행하는 서브시스템은 아래 그림과 같이 클라우드 서버, 로드밸런서 및 모니터와 연동하여 동작합니다. 그림 1-5와 같이 Auto Scaling 서브시스템은 서버 생성 또는 반납이 필요할 경우 클라우드 서버에 이를 요청하고 로드밸런서에 서버를 등록할 필요가 있으면 Load Balancer 서브시스템에 요청을 합니다. 모니터는 클라우드 서버 그룹을 모니터링하고 있다가 자원 사용량이 일정 수준을 넘으면 Auto Scaling에 알람을 통보하고 Auto Scaling을 서버를 생성 또는 반납하여 scale-out 또는 scale-in을 수행합니다.

Auto Scaling 서브시스템 내부 구조

Auto Scaling 서브시스템의 내부 구조는 아래 그림과 같습니다.

Auto Scaling 서브시스템은 다음과 같은 부분으로 구성됩니다.

  • API 처리 부분
  • 알람 처리 부분
  • 스케일링 액션 관리자(scaling action manager)
  • 내부 스케줄러
  • 내부 데이터베이스

각 부분은 다음과 같이 동작합니다.

  1. API 처리 부분
    사용자는 서버 그룹의 자원 사용량이 일정 기준을 넘으면 서버 그룹이 자동으로 스케일링되도록 API를 이용해 설정할 수 있습니다. 이때 사용자가 호출한 API를 처리하는 부분입니다.
  2. 알람 처리 부분
    서버 그룹의 자원 사용량이 정해진 기준을 넘으면 Monitor 서브시스템은 Auto Scaling 서브시스템에 알람을 통보합니다. 알람 처리 부분은 스케일링 액션 관리자를 작동시켜서 서버가 생성 또는 반납되어 Auto Scaling되게 합니다.
  3. 스케일링 액션 관리자
    사용자가 API를 이용해서 정해진 스케줄에 따라 서버 그룹이 자동으로 스케일링이 되게 설정하거나 직접 스케일링 액션을 요청하면 스케일링 액션 관리자는 다음과 같이 처리합니다.
    • scale-out을 해야 할 때, 클라우드 서버 서브시스템에 서버 생성을 요청한 후, 서버 인스턴스가 생성되면 그 서버 인스턴스가 로드밸런서에 등록되도록 로드밸런서 서브시스템에 요청합니다.
    • scale-in을 해야 할 때, 로드밸런서 서브시스템에 서버 인스턴스의 로드밸런서 삭제를 요청한 후, 삭제가 완료되면 클라우드 서버 서브시스템에 서버 반납을 요청합니다.
  4. 내부 스케줄러
    내부 스케줄러는 데이터베이스에 설정된 스케줄에 따라 스케일링 액션 관리자를 작동시켜서 서버가 생성 또는 반납되어 Auto Scaling되게 합니다.
  5. 내부 데이터베이스
    사용자가 API를 통해 조회 또는 설정을 요청하면 내부 데이터베이스에 접속해서 관련 정보를 읽거나 씁니다.

Auto Scaling 그룹 관리

Auto Scaling은 Auto Scaling Group의 크기(그룹 소속 서버 인스턴스 수)를 조정함으로써 이루어집니다. Auto Scaling이 되는 서버 인스턴스들의 그룹인 Auto Scaling Group을 생성하기 위해서는 서버 생성을 위함 설정 정보를 담고 있는 Launch Configuration을 먼저 생성해야 합니다. 이번 장에서는 Launch Configuration을 생성하는 방법과 Auto Scaling Group을 생성하는 방법을 설명합니다.

Launch Configuration 생성

Launch Configuration이란 새로운 서버 인스턴스를 서비스에 투입(launch)하기 위해 서버를 생성할 때 필요한 설정 정보를 말합니다. 쉽게 생각해서 관리 콘솔에서 서버를 생성할 때 사용자가 수동으로 선택하는 설정 항목들을 자동으로 입력하기 위해 하나의 설정으로 만들어 Auto Scaling 서비스에서 이용하는 것이라고 보면 됩니다. 따라서 Launch Configuration은 생성되는 Auto Scaling 서버의 템플릿(template)이라고 볼 수 있습니다.

Launch Configuration은 사용자가 정할 수 있는 Auto Scaling Group의 속성 중 하나여서, 그 Launch Configuration에 따라 Auto Scaling Group 소속 서버가 생성됩니다. 하나의 계정으로 100개 미만의 Launch Configuration를 만들 수 있습니다. Launch Configuration는 이름으로 식별하고 그 이름은 그 계정의 Launch Configuration내에서 고유합니다. 관리 콘솔을 통해 서버 인스턴스를 생성할 때, 사용자가 서버이미지, 서버 사양(product code로 표시), 로그인 키 및 적용 받는 ACG를 선택하듯이, 사용자가 Launch Configuration를 생성할 때 속성으로 그 값들을 지정할 수 있습니다. 그리고 Launch Configuration는 변경이 안 되고, 생성과 삭제만 가능하므로 생성할 때 실수하지 않도록 유의해야 합니다.

사용자가 직접 만든 내 서버이미지로 Auto Scaling Group 소속 서버를 만들고 싶으면, Launch Configuration의 회원 서버 이미지 번호(memberServerImageNo) 값으로 내 서버이미지의 식별번호(ID)를 지정하면 됩니다. 내 서버이미지를 만들 때는 이미지에 결함에 없어서 정상적으로 부팅이 되고 서비스가 될 수 있도록 주의해야 합니다. 만약 내 서버이미지에 결함이 있어서 정상적으로 첫 부팅이 되지 않아 게스트 OS 내부의 agent가 제대로 구동되지 않았다면, Auto Scaling은 그 서버 생성을 포기하고 반납한 뒤, 최대 5번 재시도하고 그래도 안 된다면, 더 이상 그 내 서버이미지로부터 서버를 생성하지 않도록, 서버 인스턴스 생성 및 서비스 적용 프로세스를 보류시킵니다. 자세한 내용은 '4.9.1 프로세스 보류 - LAUNCH' 항목에 나와 있습니다. 그리고 내 서버이미지의 디스크의 총 사용량이 너무 크면 (디스크 자체 크기보다 디스크의 사용량이 중요) 서버가 생성되는데 시간이 지나치게 많이 걸려서 적시에 Auto Scaling에 의해 서버가 생성되지 않을 수 있으므로 주의해야 합니다.

Launch Configuration를 생성할 때, 서버가 서비스에 투입 되기 직전에 실행될 초기화 script를 속성으로 지정할 수 있습니다. 이를 user data라고 부릅니다. 첫 부팅 후 설정 적용을 위해 리부팅이 되는데 리부팅 절차 마지막 단계로 user data가 실행됩니다.

Launch Configuration는 그 이름으로 식별되므로 Launch Configuration 이름은 한 계정 범위 안에서는 유일해야 합니다. RESTful API를 사용하여 생성하고 Launch Configuration를 싶으면 createLaunchConfiguration API를 호출합니다. 이 호출이 완료되면 Launch Configuration 생성이 완료된 상태여서 바로 사용 가능합니다. 호출을 하면 지정된 속성이 유효한지 확인하고 유효하지 않다면 호출은 실패합니다. 예를 들어 내 서버이미지의 식별자를 memberServerImageNo 값으로 지정해서 전달했는데, 그 식별자가 존재하지 않는다면 호출은 실패하고 클라이언트는 에러 메시지를 받습니다.

Auto Scaling Group 생성 및 확인

Auto Scaling Group은 전술한 바와 같이 특정 서비스를 유연하게 처리하기 위해 자동으로 서비스 능력을 scale-out하거나 scale-in하는 서버들의 논리적인 그룹을 말합니다.

Auto Scaling Group은 이름으로 식별되고 계정당 100개 미만으로 만들 수 있으며 이름은 한 계정 내에서 고유합니다. Auto Scaling Group은 속성으로 서버 생성에 필요한 Launch Configuration를 반드시 하나 가지고 있어야 하고 이 Launch Configuration를 템플릿(template)으로 하여 그 그룹의 서버를 생성합니다. 그리고 이 그룹의 크기(인스턴스 수)를 조정하여 scaling합니다. 그룹을 생성하기 위해서는 createAutoScalingGroup RESTful API를 호출하면 됩니다.

Auto Scaling Group의 주요 속성(파라미터 이름)은 다음과 같습니다.

속성 설명
desiredCapacity Desired Capacity. 정수형의 Desired Capacity에 따라 유지(maintain)해야 할 그룹 크기, 즉 Auto Scaling Group 소속 서버 인스턴스 수가 정해집니다.
launchConfigurationName Launch Configuration 이름. Auto Scaling Group 소속으로 생성될 서버 인스턴스의 설정 정보.
zoneNoList 영역 번호 목록. Auto Scaling Group 소속 서버 인스턴스가 생성되어 운영될 영역(zone)을 지정한다. 영역은 번호로 식별된다. 서버 인스턴스가 생성될 때 가용성을 높이기 위해 서버 인스턴스들이 특정 영역에 몰려 생성되지 않도록 균형을 유지하여 생성한다.
minSize 최소 크기. 최소 크기는 어떠한 경우에도 유지해야 하는, 그룹의 최소 서비스 용량(capacity)을 의미한다. Desired Capacity값은 최소 크기 이상이어야 한다. 이 속성은 보통 클라우드 모니터링 연동 scaling을 할 때, 서비스의 부하가 줄어들어도 이 최소 크기 밑으로는 그룹 크기가 작아지지 않도록 한다. 또 그룹을 생성 또는 갱신할 때 사용자가 실수로 Desired Capacity를 최소 크기 아래로 지정하려 하면 에러가 발생하도록 해서 사용자의 설정 실수를 방지한다.
maxSize 최대 크기. 이 속성은 그룹의 Desired Capacity가 커질 수 있는 최댓값을 정한다. Desired Capacity값은 최대 크기 이하여야 한다. 이 속성은 보통 클라우드 모니터링 연동 scaling을 할 때, 서비스의 부하가 아무리 늘어도 이 최대 크기를 초과하여 그룹 크기가 커지지 않도록 해서 사용자가 과도한 사용료를 내지 않도록 한다. 또 그룹을 생성 또는 갱신할 때 사용자가 실수로 Desired Capacity를 최대 크기보다 크게 지정하려 하면 에러가 발생하도록 해서 사용자의 설정 실수를 방지한다.
loadBalancerNameList 로드밸런서 이름 목록. 생성된 서버 인스턴스가 등록될 로드밸런서 이름(ID가 아님)을 의미한다. Auto Scaling Group을 생성할 때 Auto Scaling Group 소속 서버 인스턴스들이 등록될 로드밸런서를 지정할 수 있다. 다만 로드밸런서 이름은 한 번 정해지면 변경할 수 없다. Auto Scaling Group 소속 서버 인스턴스가 생성되어 첫 부팅과 리부팅을 하고 나서 '운영 중' 상태가 되면, 그 서버 인스턴스는 지정된 이름의 로드밸런서에 할당된다. 서버 인스턴스를 반납할 때는 먼저 로드밸런서에서 서버 인스턴스를 삭제한 후 반납한다. 자세한 내용은 "로드밸런서와의 연동"을 참고한다.
healthCheckTypeCode 헬스 체크 유형. 서버 인스턴스에 대한 헬스 체크 유형을 지정한다. 유효한 값으로 SVR(서버)과 LOADB(로드밸런서)가 있다. SVR: 서버 인스턴스가 작동이 중단(down)되었는지 행(hang)되었는지 확인하고, 문제가 있으면 그 서버 인스턴스의 헬스 상태에 문제가 있다고 기록한다. LOADB: 로드밸런서 자체의 서버 인스턴스의 헬스 체크 결과를 가지고 서버 인스턴스의 헬스 상태를 판정한다. 자세한 내용은 "서버 인스턴스 헬스 체크"를 참고한다.
healthCheckGracePeriod 헬스 체크 보류 기간. 서버 인스턴스가 생성되어 상태가 '운영 중'으로 변한 후에도 초기에는 서버 내부에서 application update와 같은 서비스 준비 작업을 수행하느라 서비스를 못할 수도 있다. 이에 헬스 체크를 보류할 기간을 지정해서 그 기간 동안에는 서비스를 수행하지 못해도 서버 헬스 상태에 문제가 있다고 보지 않는다. 자세한 내용은 "서버 인스턴스 헬스 체크"를 참고한다.

Auto Scaling Group 생성 확인

getAutoScalingGroupList RESTful API을 호출하면 그룹 생성을 확인할 수 있습니다. 그 그룹의 속성과 함께 소속 서버 인스턴스의 속성과 그 상태도 조회할 수 있습니다.

Auto Scaling Group 속성 변경

사용자는 수동으로 Auto Scaling Group의 속성을 언제든지 변경할 수 있습니다. RESTful API를 통해 Auto Scaling Group설정을 변경하고 싶으면 updateAutoScalingGroup API를 호출하면 됩니다. 파라미터로 전달되는 Auto Scaling Group이름이 변경 대상의 식별자입니다. 식별자 외에 다른 파라미터가 지정되면 그 파라미터는 변경되고 그렇지 않으면 변경되지 않은 상태로 남습니다. 새로운 속성값은 호출에 대한 응답이 왔을 때 적용됩니다.

아래는 변경 시의 유의 사항입니다.

  • 변경된 Launch Configuration 이름(Launch Configuration Name)은 등록 후 새로운 서버 인스턴스가 생성될 때 적용됩니다.
  • 다른 속성인 최소 크기(minSize), 최대 크기(maxSize), 헬스 체크 보류 기간(healthCheckGracePeriod)과 헬스 체크 유형(healthCheckType)은 등록 후 바로 적용된다. Desired Capacity과 zone 번호(no.)는 등록 후 보통 10 초 이내에 관련 프로세스가 진행됩니다.
  • minSize와 desiredCapacity, maxSize는 변경 이후에도 minSize <= desiredCapacity <= maxSize 라는 대소 관계를 유지해야 합니다.
  • desiredCapacity가 지정되지 않은 상태에서 지정한 새 최소 크기(minSize)가 현재 그룹 크기보다 크면, 그룹 크기가 자동으로 최소 크기(minSize) 값만큼 늘어납니다.
  • desiredCapacity가 지정되지 않은 상태에서 지정한 새 maxSize가 현재 그룹 크기보다 작으면, 그룹 크기가 자동으로 maxSize크기만큼 줄어듭니다.
  • setDesiredCapacity라는 RESTful API로도 Desired Capacity를 변경할 수 있습니다.
  • 연동 로드밸런서 이름은 변경할 수 없습니다.

Auto Scaling 계획 수립

Auto Scaling 계획은 아래 3가지 방식으로 분류할 수 있습니다.

  • 수동으로 scaling을 하는 방식
  • 자원 사용량을 계량하여 이를 기반으로 자동으로 scaling하는 방식
  • 스케줄에 따라 자동으로 scaling을 하는 방식

상술한 방식을 이용하여 Auto Scaling Group의 Desired Capacity 값을 변경하여 scale-out 또는 scale-in을 합니다.

수동 scaling

수동(manual) scaling은 이름 그대로 서비스 용량을 수동으로 정하는 것을 말합니다. 예를 들어, 특정 서비스의 요청이 2배 이상이 될 것으로 예상이 된다면, 사용자는 수동으로 그 서비스를 담당하는 Auto Scaling 그룹의 크기를 기존의 2배로 늘릴 수 있습니다.

이를 위해 사용자는 Auto Scaling Group의 Desired Capacity를 변경해야 합니다. RESTful API를 이용하여 setDesiredCapacity나 updateAutoScalingGroup을 호출하면 Desired Capacity를 변경할 수 있습니다. 언제든지 변경 가능하고 변경된 값에 맞춰서 그룹 소속 서버 인스턴스 수가 변합니다.

updateAutoScalingGroup 또는 setDesiredCapacity를 호출할 때, 변경할 Auto Scaling Group이름과 갱신하고 싶은 Desired Capacity을 지정하면 되는데, 이때 이 값이 minSize보다 크거나 같고 maxSize보다 작거나 같아야 합니다.

updateAutoScalingGroup을 호출할 때 유의할 점이 있는데, desiredCapacity가 지정되지 않은 상태에서 지정한 새 minSize가 현재 그룹 크기보다 크면, desiredCapacity가 자동으로 minSize크기만큼 늘어납니다. 또 desiredCapacity가 지정되지 않은 상태에서 지정한 새 maxSize가 현재 desiredCapacity보다 작으면, desiredCapacity가 자동으로 maxSize만큼 줄어듭니다.

클라우드 모니터링 연동 scaling

클라우드 모니터링 scaling

Auto Scaling은 클라우드 모니터링이 측정하는 서버 인스턴스의 자원 사용량에 따라 동적으로 scaling할 수 있습니다. 서비스의 부하가 높아서 CPU나 디스크 공간과 같은 자원을 많이 소모되어 가용 자원이 부족해서 서비스 원활하게 할 수 없다면 Desired Capacity를 증가시켜서 scale-out하고, 서비스 부하가 낮아져서 가용 자원이 남아 돈다면 그 때는 Desired Capacity를 낮춰서 scale-in합니다.

그 방법은 다음과 같습니다.

  1. 모니터에서 서버 인스턴스의 자원 사용량을 Auto Scaling그룹 평균으로 계량할 수 있습니다.
  2. 그 계측량이 사용자가 미리 정해놓은 일정 기준에 합치되면 알람(alarm) 이벤트가 발생합니다.
  3. 사용자는 그 알람 이벤트가 발생하면 그에 대한 대응으로 Auto Scaling Group의 정책을 수행하도록 미리 설정할 수 있는데, 그 정책에 따라 Desired Capacity를 변경합니다.
  4. 이로써 자원 사용량에 따라 scale-out 또는 scale-in할 수 있습니다.

예를 들어 CPU 사용률이 70% 이상인 상태가 5분 이상 지속되면 Desired Capacity를 30% 늘리고, CPU 사용률이 30% 미만인 상태가 10분 이상 지속되면 Desired Capacity를 20% 줄이게 설정하는 방법은 다음과 같습니다.

  1. 그룹 크기 3의 Auto Scaling Group을 생성하여 그 그룹 소속 서버를 생성 및 서비스에 투입합니다 (Launch).
  2. 이 그룹에 대한 정책으로 capacity를 늘리는 (scale-out) 정책과 capacity를 줄이는 (scale-in) 정책을 생성합니다.
    • 하나는 'out30p'라는 이름의 정책으로 현재 capacity를 30% 증가시킵니다.
    • 나머지 하나는 'in30p'라는 이름의 정책으로 현재 capacity를 20% 감소시킵니다.
  3. 그 Auto Scaling Group에 대한 알람(이벤트)과 그에 대한 대응을 설정합니다.
    • 그 Auto Scaling Group의 평균 CPU 사용량이 70% 이상 5분 이상 지속되면 알람이 발생하여 관리자에게 SMS나 메일로 통보함과 동시에 'out30p'라는 이름의 정책을 수행하도록 설정합니다.
    • 그 Auto Scaling Group의 평균 CPU 사용량이 30% 이하 10분 이상 지속되면 알람이 발생하여 관리자에게 SMS나 메일로 통보함과 동시에 'in30p'라는 이름의 정책을 수행하도록 설정합니다.
  4. 모니터는 그룹의 평균 CPU 사용량을 측정합니다.

서비스 부하가 증가하여 그 측정치가 70% 이상 5분 이상 지속되면, out3p라는 정책이 수행되어 capacity가 30% 증가합니다. 서버가 3대 있었으므로 30% 증가하여 서버가 4대가 됩니다. 그 후 서비스 부하가 줄어들어서 그 측정치가 30% 이하 10분 이상 지속되면, in3p라는 정책이 수행되어 capacity가 20% 감소합니다. 서버가 4대 있었으므로 20% 감소하여 서버가 다시 3대가 됩니다.

API를 이용한 클라우드 모니터링 연동 scaling

다음과 같은 순서로 설정합니다.

  1. Auto Scaling Group 생성
  2. 그 그룹에 대한 정책(policy) 생성
  3. 그 정책을 수행할 알람(이벤트) 설정
  4. 알람(이벤트) 통보와 그에 대한 대응 확인
Auto Scaling 그룹에 대한 정책 생성

Auto Scaling Group당 최대 10개의 scaling 정책을 생성할 수 있습니다. putScalingPolicy API를 호출해서 정책을 생성할 수 있는데 그 파라미터는 다음과 같습니다.

  • policyName: 정책 이름. 스케일링 정책의 식별자
  • autoScalingGroupName: 정책이 수행될 Auto Scaling Group 이름 (식별자)
  • adjustmentTypeCode: Group의 capacity를 조정하는 유형을 나타내는 코드. 변화량을 기존 capacity에 대한 비율로 조정하고 싶으면 PercentChangeInCapacity(PRCNT)로 설정
  • scalingAdjustment: 조정 수치. 유형이 PercentChangeInCapacity(PRCNT)이면 단위는 퍼센트(%)

보통은 scale-out 정책과 scale-in 정책 한 쌍을 생성합니다. API를 사용하여 앞에서 설명한 예를 구현한다면 각 파라미터의 값은 다음과 같습니다.

  1. scale-out 정책
    • policyName: out30p
    • autoScalingGroupName: asg-1
    • adjustmentTypeCode: PercentChangeInCapacity(PRCNT) (괄호안이 코드)
    • scalingAdjustment: 30
  2. scale-in정책
    • policyName: in20p
    • autoScalingGroupName: asg-1
    • adjustmentTypeCode: PercentChangeInCapacity(PRCNT) (괄호안이 코드)
    • scalingAdjustment: -20
정책을 수행할 알람 (이벤트) 설정

① 네이버 클라우드 플랫폼 관리 콘솔에서 monitoring 탭을 선택합니다.

② Auto Scaling 이벤트 설정 페이지를 엽니다.

③ Auto Scaling 그룹들이 나열되어 있는데 특정 그룹을 선택한 후 아래 그림처럼 알람(이벤트)이 발생할 기준과 그 대응으로 수행될 정책(policy)를 선택합니다. '예' 버튼을 클릭하면 적용이 됩니다. 모니터링 항목(metric)으로 CPU, memory, disk i/o 등이 있고 모두 최근 1분동안의 그룹 평균입니다.

알람 (이벤트) 발생과 그에 대한 대응 확인
  1. 네이버 클라우드 플랫폼 관리 콘솔 > monitoring 탭 > Auto Scaling 이벤트 로그 페이지를 엽니다. 알람 (이벤트) 발생 확인

  2. 이 알람으로 정책이 수행되어 해당 그룹의 Desired Capacity가 바뀐 사실을 getAutoScalingActivityLogList API로 확인

    getAutoScalingActivityLogList API를 호출할 때 autoScalingGroupName 파라미터 값으로 Auto Scaling 그룹 이름을 전달하면 최근의 Auto Scaling 관련 action 로그를 조회할 수 있다. 특히 actionCause 태그 값을 읽으면 Auto Scaling 행동(action)이 발생한 원인을 알 수 있습니다. 그 예는 다음과 같습니다.

    <actionCause>
    At 2015-06-04T11:34:02+0900 a monitor alarm ('CPU used(%) average' <= 30 % for 10 minutes) executed policy in20p changing the Desired Capacity from 1 to 0. At 2015-06-04T11:34:03+0900 an instance was taken out of service in response to a difference between desired and actual capacity, shrinking the capacity from 1 to 0. At 2015-06-04T11:34:03+0900 instance #121003 was selected for termination.
    </actionCause>
    

쿨다운 시간의 개념

그룹 소속 서버 수가 증가 또는 감소하는 scaling 행동(action)이 완료되었어도 그 효과가 나타나는데 일정 시간이 걸립니다. 보통 서버 생성 및 서비스 투입 (Launch) 완료 후 초기화 스크립트(user data)가 실행되어 애플리케이션이 설정되고 시작되는데 시간이 걸립니다. 그리고 새로 투입된 서버가 서비스에 투입되어도 기존의 요청은 기존 서버들이 담당하고 새로운 요청들을 새로 투입된 서버들이 분담하기 시작하므로 서버가 늘었다 해도 그 효과가 바로 나타나지 않습니다. 따라서 scaling 행동(action)이 진행되는 동안 그리고 scaling 행동(action) 완료 이후에 알람(alarm)이 발생하더라도 이에 반응하지 않는 쿨다운(cooldown) 시간이 필요합니다.

그 쿨다운 시간은 scaling 정책을 생성할 때 정책별로 지정할 수 있습니다. 정책별로 지정되어 있지 않다면 Auto Scaling 그룹의 디폴트(default) 쿨다운 시간이 지정되어 있어서 그 값을 따릅니다. 수동 scaling을 포함한 일체의 scaling 행동(action) 진행 중 또는 진행 완료 후 지정된 쿨다운 시간 동안 알람이 발생해도 이를 무시합니다. executePolicy API를 호출할 때 쿨다운 시간을 존중한다는 (honorCooldown) 옵션이 true이어도 이에 해당합니다.

알람을 무시할 것인 여부를 처리하는 상세 로직은 아래 도식과 같습니다.

자체 자원 사용량 계량을 기반으로 한 scaling

네이버 클라우드 플랫폼 모니터링에서 제공하는 모니터 항목(metric)의 계측량 외에 자체적으로 자원 사용을 계측해서 scaling을 하고 싶을 경우가 있을 것입니다. 예를 들어, Auto Scaling Group의 각 서버의 애플리케이션과 backend에 있는 database server 사이에 TCP연결이 존재하는데 그 연결 수에 측정하고 그 계측량에 따라 scaling을 하고 싶을 수 있습니다. 이때는 executePolicy API를 이용하면 됩니다. 이 API는 쿨다운 시간을 존중한다는 (honorCooldown) 옵션이 있는데 디폴트 false이고 명시적으로 true로 설정해야 쿨다운 시간을 존중합니다.

Scaling Adjustment 설정 유의 사항

  • adjustmentTypeCode 값이 ChangeInCapacity(CHANG) 또는 PercentChangeInCapacity(PRCNT) 유형일 때, scalingAdjustment가 양수이면 capacity가 증가해서 scale-out이 되고, scalingAdjustment가 음수이면 capacity가 감소해서 scale-in이 됩니다.
  • PercentChangeInCapacity(PRCNT) 유형의 scalingAdjustment의 최소 값은 -100입니다.
  • PercentChangeInCapacity 유형일 때 현재의 실제(actual) capacity와 퍼센트 값인 scalingAdjustment 값을 곱하고 100으로 나눈 변경량(change)이 정수가 아닌 수일 수 있는데 (즉 소수점 아래의 수를 가진), 이때는 소수점 아래 수를 잘라내서(truncate) 정수로 만드는데 (rounding 작업이라 부르는) 변경량에 따른 rounding 방법은 다음과 같습니다.
    • 변경량이 1보다 작은 양수이면 변경량은 1로 rounding 하고 (즉 round-up 또는 ceiling해서)
    • 1보다 큰 양수이면 소수점 이하의 수는 잘라내서(즉 round-down 또는 floor해서) 계산합니다.
    • scalingAdjustment 값이 음수이면 변경량이 음수이면서 정수가 아닌 수일 수 있는데, 그 값이 -1과 0 사이의 수라면 -1로 rounding합니다.
  • 변경량이 -1보다 작은 수라면 소수점 아래 수를 잘라내서 zero (0)에 가까운 정수로 만듭니다. 예를 들어, 변경량이 -4.3 이라면 -4로 조정합니다.

스케줄 기반 scaling

스케줄 기반 scaling은 원하는 시간에 서비스 용량을 변경하도록 스케줄을 짜서 하는 scaling 방식을 말합니다.

예를 들어, 어떤 서비스는 주말에 요청이 많아진다면 매주 주말이 되면 서비스 용량을 키우도록 스케줄을 설정하면 주말마다 자동으로 Auto Scaling Group 소속의 서버 인스턴스의 수가 늘어납니다.

Auto Scaling에서는 사용자가 원하는 시간에 사용자가 지정한 서비스 용량(capacity)을 갖추기 위해 scaling action을 행하도록 하는 기능을 제공하고 있습니다. putScheduledUpdateGroupAction RESTful API를 호출하면 스케줄에 등록된 액션(Scheduled Action)을 지정할 수 있습니다.

상기 기능은 일회성 스케줄 또는 반복 스케줄 기반으로 scaling action을 설정할 수 있습니다.

  • 일회성 스케줄 기반 설정은 예를 들어 서비스가 특별한 행사를 할 때 미리 그 지정된 행사 날짜에 scaling action을 행하도록 할 때 유용합니다.
  • 반면에 반복 스케줄 기반 설정은 예를 들어 서비스가 주말마다 요청이 많을 때 매 주말에 scaling action을 행하도록 하고 싶을 때 유용합니다.

유의 사항은 다음과 같습니다.

  • 스케줄에 따라 지정된 시간에 그룹의 Desired Capacity를 스케줄에 지정된 값으로 변경합다. 지정된 값으로 설정하므로 기존 값의 영향을 받지 않습니다. 즉 DC가 기존 DC의 150%로 증가와 같은 변경은 하지 않습니다.
  • 변경된 상기 값은 가만히 두면 영구적으로 변하지 않습니다. 스케줄이 끝나도 그 값은 변하지 않습니다.
  • 따라서 스케줄을 보통 한 쌍을 생성합니다. 예를 들어, 주말에 작업 부하가 증가한다면 주말이 시작되기 전에 scale-out을 하는 스케줄을 생성하고 주말이 끝나면 scale-in을 하는 스케줄을 생성합니다.
일회성 스케줄 기반 scaling action설정

RESTful API putScheduledUpdateGroupAction를 이용한 scaling action에 대한 일회성 스케줄 설정을 하기 위해 아래와 같이 recurrence는 지정하지 않고 startTime은 지정해야 합니다.

다음은 'asg-1'라는 이름의 Auto Scaling Group에 대해 'sa-1' 라는 이름(식별자)의 스케줄을 설정한 예입니다. 이 스케줄은 startTime 값으로 지정된 시각에 Auto Scaling Group의 desiredCapacity 속성을 10으로 설정합니다.

  • scheduledActionName (스케줄에 등록된 액션 이름): sa-1
  • autoScalingGroupName (Auto Scaling Group 이름): asg-1
  • startTime (시작 시간): 2014-03-24T19:00:00+09:00
  • desiredCapacity : 10
반복 스케줄 기반 scaling action설정

RESTful API putScheduledUpdateGroupAction을 이용한 scaling action에 대한 반복 스케줄 설정하기 위해 파라미터를 다음과 같이 지정하여 API를 호출합니다. 보통 두 번 설정하는데, 한번은 특정 기간 동안 capacity를 늘리기 위한 반복 스케줄을 설정(scale-out action 스케줄을 등록)하기 위해서이고, 나머지 하나는 특정 기간이 지나면 다시 예전 상태로 돌아가기 위해 (scale-in action스케줄 등록) 반복 스케줄을 설정하기 위해서입니다.

예를 들어, 어떤 서비스가 주말에 작업 부하가 늘고 주중에는 작업 부하가 줄어든다면, 매주 주말이 될 때 큰 Desired Capacity를 보유하기 위한 scale-out action 실행 스케줄 설정과 주말이 지나면 작은 Desired Capacity을 보유하기 위한 scale-in action 실행 스케줄 설정 2개를 아래와 같이 할 수 있습니다.

  1. 매주 주말이 되면 큰 서비스 용량을 보유하기 위한 Scale-out 액션 실행 스케줄 설정

    • scheduledActionName (스케줄에 등록된 액션 이름): sa-out
    • autoScalingGroupName (Auto Scaling Group 이름): asg-2
    • recurrenceInKST (반복 스케줄 설정): '30 14 Fri'
    • desiredCapacity : 10
  2. 주말이 지나면 작은 서비스 용량을 보유하기 위한 Scale-in 액션 실행 스케줄 설정

    • scheduledActionName (스케줄에 등록된 액션 이름): sa-in
    • autoScalingGroupName (오토스케일링 그룹 이름): asg-2
    • recurrenceInKST (반복 스케줄 설정): '0 6 Mon'
    • desiredCapacity : 3

반복 스케줄은 recurrenceInKST 파라미터로 지정하며 기준은 한국 시간대(KST = GMT+9)이고 형식은 crontab과 같습니다.

위와 같이 반복 스케줄을 설정하면 그 이후 매주 금요일 14시 30분이 되면 asg-2의 Desired Capacity를 10으로 설정합니다. 그리고 설정 이후 매주 월요일 6시가 되면 asg-2의 Desired Capacity를 3으로 설정합니다.

asg-2 그룹에 저 두 반복 스케줄만 설정해놓았다면 주말에는 Desired Capacity가 10 이었다가 주중에는 Desired Capacity가 3 이고 다시 그 다음 주말에는 다시 Desired Capacity가 10이 되는 것을 반복합니다.

그룹 asg-2는 스케줄에 따라 아래 그림과 같이 Desired Capacity가 변경됩니다.

스케줄 기반 scaling 관련 유의 사항
변경할 수 있는 Auto Scaling Group의 속성

scaling action에 대한 스케줄 설정을 하면 사용자가 원하는 시각에 Auto Scaling Group의 Desired Capacity와 함께 minSize, maxSize도 변경할 수 있습니다. 정확히 말하면 스케줄에 등록된 액션(Scheduled Action)를 생성 변경하는 인터페이스를 이용할 때, minSize, Desired Capacity, maxSize 이 세 파라미터 중 적어도 하나는 지정 해야 합니다.

세 파라미터는 스케줄에 의해 정해진 시각에 지정된 파라미터만 설정되고 지정되지 않은 속성은 변하지 않은 채로 남게 됩니다.

예를 들어, Auto Scaling Group의 minSize, desiredCapacity, maxSize 값이 0, 10, 20 인데, 스케줄에서 minSize 값과 Desired Capacity 값만 각각 10, 15로 설정했다면, 정해진 시각에 Auto Scaling Group의 minSize, desiredCapacity 값은 각각 10, 15로 설정되고 Auto Scaling Group의 maxSize 값은 변경되지 않습니다. 즉 20을 그대로 유지합니다. 그러나 만약 새로 설정한 값이 minSize <= desiredCapacity <= maxSize 대소 관계가 어긋나면 그 스케줄 적용은 실패합니다. 일례로, Auto Scaling 그룹의 minSize, desiredCapacity, maxSize 값이 0, 10, 20 인데 스케줄로 maxSize = 0으로 설정하고 나머지 두 값은 지정하지 않았다면, 정해진 시각에 Auto Scaling Group의 maxSize를 0으로 바꾸려 하나, 그럴 경우, Auto Scaling Group의 변경되지 않는 minSize값보다 새로이 설정될 maxSize가 작아져서 적용되지 않고 실패합니다.

스케줄 변경

putScheduledUpdateGroupAction RESTful API를 호출했을 때 scheduledActionName 파라미터와 동일한 Scaling Action이 존재하지 않으면 생성이 되고 이미 존재한다면 기존 속성을 API로 파라미터 값으로 변경합니다. 스케줄을 변경하기 위해 호출한 putScheduledUpdateGroupAction API에 파라미터가 지정하지 않으면 그 속성은 없어집니다 (비교: updateAutoScalingGroup API를 호출할 때는 지정되어 있지 않은 파라미터의 속성은 변경되지 않습니다).

스케줄이 영향을 주는 시간

스케줄 설정을 할 때 시작 시각과 종료 시각 파라미터가 있어서 마치 시작 시각과 종료 시각 사이에 그 스케줄의 Desired Capacity (이하 DC)나 minSize, maxSize가 Auto Scaling Group에 영향을 주는 것처럼 오인하기 쉬우나, 스케줄 설정이 적용될 시점에만 Auto Scaling Group의 Desired Capacity, minSize 또는 maxSize 값을 스케줄 설정의 DC, minSize 또는 maxSize으로 덮어 쓰는(overwrite) 방식으로 설정합니다. 그 시점 이후로는 영향을 주지 않습니다. 따라서 변경 이후 다른 요청이 없으면 계속 그 값이 유지되고, 새로운 다른 변경 요청이 있다면 DC는 다른 값으로 바뀔 수 있습니다.

예를 들어, 매주 금요일 18시에 DC를 10으로 변경하기로 설정한 상태에서, 17시에 사용자가 수동으로 DC를 5라고 설정했고, 19시에 15로 설정했다면, 17시에 DC가 5로 설정되고 나서 17시부터 18시 사이에는 DC가 5를 유지하고, 18시에 DC가 10으로 설정되고 나서 18시부터 19시 사이에는 DC가 10을 유지하고, 19시에 DC가 15로 설정되고 나서 19시 이후에는 새로운 요청이 들어오기 전까지 15를 유지합니다.

일회성 스케줄 기반 scaling action설정

일회성 스케줄을 설정하기 위해서는 recurrence는 지정하지 않고 startTime은 지정해야 합니다. 그러면 그 스케줄에 따라 startTime 시각에 Auto Scaling Group의 minSize, Desired Capacity 또는 maxSize가 설정됩니다. 일회성 스케줄에서는 endTime 값은 지정할 수 있으나 의미가 없습니다. 다만 endTime 값은 startTime보다 같거나 이후의 시각이어야 합니다. 일회성 스케줄 기반 설정은 문자 그대로 지정된 특정 시각에 단 한번 scaling action을 행하고 그 이후 그 스케줄은 자동으로 사라집니다.

반복 스케줄 기반 scaling action설정

반복 스케줄을 설정하면 첫 적용은 설정 이후 미래에 처음으로 일치하는 시각에 scaling 액션이 실행됩니다. 예를 들어, 매주 금요일 오전 5시에 scaling action이 실행되도록, 금요일 오후 2시에 설정했다면, 그 다음 주 금요일 오전 5시에 그 설정이 처음으로 적용됩니다.

반복 스케줄을 설정할 때의 시작 시각(start time)의 의미는 일회성 스케줄을 설정할 때와 달라서 반복 스케줄을 설정할 때 시작 시각이 지정되면, 그 시작 시각 이후에 recurrenceInKST (반복 스케줄 설정)이 적용되는 시각에 scaling 액션이 실행됩니다. 반복 스케줄을 설정할 때, 시작 시각을 명시하지 않으면 반복 스케줄 설정이 처음으로 적용되는 시점이 시작 시각으로 자동 계산됩니다. 종료 시각(end time)을 지정하면 그 종료 시각 이후에는 반복 스케줄은 자동으로 삭제됩니다. 당연히 그 반복 스케줄은 실행되지 않습니다.

스케줄 설정 변경

Scheduled Action을 변경하기 위해 해당 인터페이스를 이용할 때도 생성할 때와 마찬가지로 recurrenceInKST와 startTime 적어도 둘 중 하나는 지정해야 합니다. 그리고 생성할 때와 마찬가지로 minSize, Desired Capacity, maxSize 셋 중의 하나는 지정되어 있어야 합니다. 만약 기존의 스케줄이 일회성이었으나 변경할 때 recurrenceInKST를 지정하면 반복성으로 변경됩니다. 반대로 기존의 스케줄이 반복성이었는데 변경할 때 recurrenceInKST를 지정하지 않으면 일회성이 됩니다.

하나의 Auto Scaling Group에 대한 복수의 스케줄 설정 시 시작 시각 충돌

하나의 Auto Scaling Group에 대해 복수의 스케줄을 설정할 때 시작 시각(start time)이 먼저 설정한 스케줄의 시작 시각과 동일해서는 안됩니다(초 단위까지). 전술한 바와 같이 반복 스케줄을 설정할 때 시작 시각을 명시하지 않으면 반복 스케줄 설정이 처음으로 적용되는 시점이 시작 시각으로 자동 계산되는데, 이 시작 시각이 먼저 설정한 스케줄(반복 또는 일회성)의 시작 시작과 동일하면 설정 에러가 발생합니다. 종료 시각은 같아도 상관없습니다. 그리고 스케줄을 설정할 때 다른 Auto Scaling Group의 스케줄 시작 시각과 동일해도 상관없고 시작 시각만 다르면 반복 설정이 동일해도 문제 없습니다.

스케줄의 scaling 액션 시각의 차이가 작을 때의 행동

Auto Scaling은 특정 Auto Scaling Group안의 Scheduled Action의 실행 시각 순서에 따라 실행됩니다.

하나의 Auto Scaling Group에 대한 스케줄의 scaling 액션 시각이 완전히 동일하지는 않지만 차이가 많이 나지 않아서 어떠한 scaling 액션이 진행 중(in-progress)으로 완료가 안 된 상태에서 다른 스케줄의 scaling 액션이 행해질 시각이 되면 후자의 스케줄의 scaling 액션은 전자의 스케줄의 scaling 액션이 완료될 때까지 대기(pending) 상태가 됩니다.

예를 들어, A라는 스케줄이 매주 금요일 13시 정각에 Desired Capacity = 10으로 설정하고, B라는 스케줄은 매주 금요일 13시 1분에 Desired Capacity = 5로 설정되어 있는데, A 스케줄에 의해 금요일 13시 정각에 Desired Capacity = 10이 되는 scaling 액션이 행해지는데 아직 13시 1분이 지나도록 그 액션이 완료되지 않고 13시 10분이 되어서야 완료가 되었다면, B라는 스케줄에 의한 scaling 액션은 13시 10분에 시작되어 Desired Capacity = 5로 설정합니다.

Scheduled Action 실행 시각의 정확도

Scheduled Action에 설정한 실행 시작 시각은 지정된 시각 10 초 이내에 실제 실행이 시작됩니다. 그러나 스케줄이 적용될 시점에 다른 스케줄에 의한 scaling 액션뿐 아니라 어떠한 이유에 의해서건 scaling 액션이 이루어지고 있다면 그 scaling 액션이 완료된 시점에 대기 상태의 스케줄이 적용됩니다.

만약 대기 상태의 스케줄이 하나가 아니라 복수의 스케줄이라면 scaling 액션이 완료될 때, 가장 늦은 시각에 실행될 scaling 액션만 실질적으로 실행됩니다.

Scheduled Action 설정 제한
  • 하나의 Auto Scaling Group에 100개 이상의 Scheduled Action를 만들 수 없습니다.
  • 스케줄 설정의 미래 시각의 한계치는 없습니다 (예를 들어 한 달 이내만 스케줄할 수 있다든지 하는 제한). 따라서 설정할 때의 시작 시각은 미래의 시각이면 되고 그 미래의 제한은 없습니다. 종료 시각도 시작 시각보다 나중의 시각이면 되고 제한은 없습니다. 반복 스케줄 설정도 제한은 없습니다.
  • 하나의 Auto Scaling Group에 대해 하루에 행할 수 있는 SA의 수의 제한은 없습니다. 100개 이상만 아니면 됩니다.
putScheduledUpdateGroupAction를 호출할 때 recurrenceInKST, startTime 및 endTime의 사용 조합
  • startTime은 지정. recurrenceInKST와 endTime은 미지정
    일회성 설정이며, startTime일 때 한 번 스케줄에 의한 scaling 액션이 실행되고 바로 그 스케줄은 자동 삭제됩니다.

  • recurrenceInKST은 지정. startTime와 endTime은 미지정
    반복 스케줄 설정이며, 호출 이후 recurrenceInKST이 적용될 시점에 첫 scaling 액션 실행. 그리고 반복 실행 시점이 될 때마다 scaling 액션 실행. 즉 무한히 반복됩니다.

  • recurrenceInKST과 startTime은 지정. 그러나 endTime은 미지정
    반복 스케줄 설정이며, startTime 시각 이후에 recurrenceInKST이 적용될 시점에 첫 scaling 액션 실행. 그리고 반복 실행 시점이 될 때마다 scaling 액션 실행. 즉 무한히 반복됩니다.

  • recurrenceInKST과 endTime은 지정. 그러나 startTime은 미지정
    반복 스케줄 설정이며, 호출 이후 recurrenceInKST이 적용될 시점에 첫 scaling 액션 실행. endTime 이후로는 스케줄이 자동 삭제되면서 더 이상 scaling 액션을 반복하지 않게 됩니다.

  • recurrenceInKST과 startTime과 endTime은 모두 지정
    반복 스케줄 설정이며, startTime 시각 이후에 recurrenceInKST이 적용될 시점에 첫 scaling 액션 실행. endTime 이후로는 스케줄이 자동 삭제되면서 더 이상 scaling 액션을 반복하지 않게 됩니다.

  • startTime과 endTime은 지정. 그러나 recurrenceInKST은 미지정
    일회성 스케줄에서 endTime는 의미 없습니다. 단, endTime 값은 startTime과 같거나 이후의 시각이어야 합니다.

생성 가능한 Scheduled Action 수

Auto Scaling Group당 최대 10개의 Scheduled Action이 생성 가능합니다.

Auto Scaling 프로세스

여기서 프로세스(process)는 Auto Scaling 서비스를 하기 위해 진행되는 절차를 의미합니다.

주요 Auto Scaling 프로세스는 아래와 같습니다.

  • 서버의 인스턴스 생성 및 서비스 투입
  • 서버 반납
  • 헬스 체크
  • 로드밸런서에 서버 추가
  • Zone별 서버 인스턴스 수 리밸런싱
  • 스케줄에 따른 액션
  • 헬스에 문제가 생긴 서버 인스턴스 교체
  • 알람 통보

Auto Scaling용 서버 인스턴스 생성 및 서비스 투입

Auto Scaling이 서버 인스턴스를 생성하면 사용자가 수동으로 서버 인스턴스를 생성하는 것과 다를 바 없이 관리 콘솔과 서버 API를 통해 서버의 상태를 조회할 수 있습니다. 서비스에 적용되어 운영(running) 상태가 되면 사용자가 수동으로 만든 것과 다를 것 없이 사용자가 조작을 할 수 있습니다. 심지어 수동으로 서버 반납도 가능합니다.

다만 Auto Scaling Group상태와 속성을 조회하는 인터페이스를 호출하면, 그 Auto Scaling Group 소속 서버 인스턴스 상태 정보도 보이는데, 관리 콘솔이나 서버용 API 호출 결과와는 다릅니다. 서버의 상태가 서버가 생성/첫 부팅/첫 리부팅 도중인 서비스에 적용 전일 때는 pending 상태로 보이고, 생성이 완료되어 서비스 적용 이후에는 in-service로 보이고, 반납되고 있을 때는 terminating으로 보입니다.

내 서버이미지 또는 user data에 결함이 있어서 정상적으로 첫 부팅과 설정 적용을 위한 리부팅을 할 때 아래 절차가 제대로 진행되지 않는다면, Auto Scaling은 그 서버의 서비스 투입을 포기하고 자동 반납합니다.

  • 첫 부팅을 할 때, 게스트 OS 내부의 관리 agent 시작 실패(최장 60분 대기): OS 결함으로 인한 부팅 실패로 간주합니다.
  • 첫 부팅 후 설정된 설정 적용을 위해 리부팅을 할 때, 게스트 OS 내부의 관리 agent 시작 실패(최장 60분 대기): OS 결함으로 인한 리부팅 실패로 간주합니다.

이때 서버 인스턴스 생성에 실패했다는 activity log를 남기고 그 scaling action의 진행은 끝납니다. 최대 5번 서버를 생성 및 서비스에 투입하는 작업을 재시도하고 그래도 안 된다면, 그 Launch Configuration에 결함이 있는 것으로 확정하고 더 이상 그 Launch Configuration로부터 서버를 생성하지 않도록, 서버 인스턴스 생성 및 서비스 적용 프로세스를 보류시키는데, 이를 관리용 보류(administrative suspension)이라 부릅니다.

자세한 내용은 아래의 'Process 보류/재개' 항목에 나와 있습니다. 물론 사용자는 특정 Auto Scaling Group에 걸린 launch 프로세스 보류를 재개(resume)할 수 있습니다.

Auto Scaling용 서버 인스턴스 반납

사용자가 수동으로 만든 서버 인스턴스는 정지 상태일 때만 반납이 가능하나 Auto Scaling Group 소속 서버 인스턴스는 운영 중일 때도 Auto Scaling이 자동 반납할 수 있습니다. 이 프로세스는 scale-in action을 할 때뿐 아니라, 문제가 생긴 인스턴스를 교체해야 하거나 zone rebalancing을 할 때도 진행됩니다.

반납될 서버 선정 정책

특정 Auto Scaling Group에 대한 scale-in action을 할 때 또는 zone rebalancing을 진행할 때, Auto Scaling Group 소속 서버 인스턴스 중 어떠한 서버 인스턴스를 반납할 지 선정할 때 가장 오래 전에 생성한 서버 인스턴스가 선정됩니다.

물론 scale-in을 위해 서버 인스턴스를 반납할 때, zone 밸런스가 깨지지 않도록 반납될 서버 인스턴스 수가 zone별로 균등하게 정해집니다. 따라서 좀 더 정확히 말하면 scale-in action을 할 때 zone별로 가장 오래된 서버 인스턴스가 반납됩니다.

서버 인스턴스 상태가 '반납중'으로 표시되면, 이미 계약은 해지되어서, 사용료는 나가지 않고, 반납중(terminating) 상태의 서버 인스턴스는 Auto Scaling Group에서 이미 없어진 인스턴스 취급을 합니다.

Auto Scaling용 서버 인스턴스 반납 시의 예외 처리

사용자가 관리 콘솔이나 API를 통해 수동으로 생성한 서버 인스턴스는 다음과 같은 상태일 때 반납되지 못하나 Auto Scaling Group 소속 서버 인스턴스는 예외적으로 반납 대상이 되면 바로 반납이 됩니다.

  • 서버가 운영중(running)일 때는 반납이 안 됩니다. 정지 상태일 때만 반납 요청이 가능합니다.
  • 서버 반납 보호 설정이 되어 있을 때
  • 서버에 추가 스토리지가 붙어 있을 때, 추가 스토리지를 명시적으로 삭제하고 나서, 서버 반납이 가능합니다.

그리고 아래와 같은 경우에도 사용자가 관리 콘솔이나 API를 통해 수동으로 생성한 서버 인스턴스는 반납되지 못하는데 서버 인스턴스가 Auto Scaling Group 소속이어도 반납이 안 됩니다. 그럴 경우 수분 후에 서버 인스턴스 반납을 다시 시도합니다. 서버 인스턴스가 상기 상태를 벗어나면, 반납 재시도가 성공할 것입니다.

  • 사용자가 서버를 조작 중일 때 (예를 들어, 시작, 재시작, 정지 중일 때)
  • 사용자가 서버를 다른 서비스 객체와 연동 중일 때 (예를 들어, 로드밸런서에 서버 할당, 서버에서 공인 IP 할당 해제, 그 서버로부터 내 서버이미지 생성 중일 때, 또는 ACG 규칙을 설정 중일 때)
  • 서버에 대해 관리 작업을 하고 있어서 관리 콘솔에서 '설정중'으로 표시될 때 (예를 들어 관리자가 서버를 migration 중일 때)

Auto Scaling용 서버 인스턴스의 API를 이용한 수동 반납

사용자가 수동으로 반납할 서버 인스턴스를 지정해서 없앨 수도 있습니다. Auto Scaling에서 제공하는 인터페이스를 이용할 수도 있고, 사용자가 관리 콘솔이나 클라우드 서버용 RESTful API를 통해 특정 서버 인스턴스를 반납할 수도 있습니다.

Auto Scaling에서 제공하는 인터페이스 중 RESTful API를 사용하고 싶다면, terminateInstanceInAutoScalingGroup라는 API를 호출하면 됩니다. 특정 인스턴스 식별자를 파라미터로 전달해서 호출하면 됩니다. 호출 후 Auto Scaling Group관련 정보를 조회하면 호출 즉시 그 인스턴스의 상태가 반납중(terminating)으로 마킹되고 수 초 후에 실제 인스턴스 반납 프로세스가 진행됩니다.

이 인터페이스의 장점은 ShouldDecrementDesiredCapacity라는 Boolean type의 선택적 파라미터의 값을 true로 해서 전달하면 인스턴스를 반납할 때 Auto Scaling Group의 크기도 함께 1만큼 줄여서, Desired Capacity 값을 유지하기 위해 인스턴스 생성이 이루어지지 않는다는 것입니다.

서버 인스턴스가 terminateInstanceInAutoScalingGroup에 의해 이미 반납중이거나 이미 반납되었는데 다시 그 서버 인스턴스에 대해 그 API를 호출하면 HTTP status code 400의 사용자 에러가 납니다. 사용자가 관리 콘솔 등으로 그 서버 인스턴스를 반납중이거나 이미 반납이 되었을 때도 마찬가지로 HTTP status code 400의 사용자 에러가 납니다.

Scaling action중인 Auto Scaling Group 소속의 인스턴스에 대해 상기 API를 호출해도 'scaling action이 진행 중(in-progress)'이라는 HTTP status code 400의 사용자 에러가 나지 않고 성공합니다. 이때 Auto Scaling Group을 정보를 조회하면 그 인스턴스 상태가 반납중으로 표시되지만 관리 콘솔이나 서버 API로 조회해보면 그 인스턴스가 실제 반납이 되지 않는 것으로 보입니다. 실제적인 반납 프로세스는 scaling action이 끝나고 난 뒤에 이루어집니다.

사용자가 관리 콘솔이나 클라우드 서버용 RESTful API를 통해 특정 서버 인스턴스를 반납할 수도 있는데, 이때는 일단 서버 인스턴스를 정지 시킨 후 반납해야 합니다. 인스턴스가 반납이 되면, 실제(actual) capacity가 Desired Capacity보다 작아져서 capacity 유지를 위해 서버 인스턴스 생성 작업이 시작됩니다.

반납 대상 서버 인스턴스가 정지가 되지 않을 때

Auto Scaling 서비스 중인 서버 인스턴스를 반납할 때, 1 단계로 운영중인 서버 인스턴스를 먼저 정지시키는데, 서버의 메모리 고갈과 같은 문제로 정상적으로 정지가 되지 않을 수 있습니다. 정지 시도 후 5분을 기다려도 서버가 정지 완료되지 않는다면, Auto Scaling은 서버를 강제 정지시킵니다.

서버 인스턴스 헬스 체크(Health Check)

Auto Scaling Group 소속 서버 인스턴스의 헬스(health)를 주기적으로 체크하여 문제가 있을 경우, Desired Capacity를 유지 하기 위해, Auto Scaling Group 소속 서버 인스턴스들의 상태(status)를 'unhealthy'로 마킹합니다. 각 서버 인스턴스의 헬스 상태는 Auto Scaling Group을 조회하는 인터페이스를 이용하면 됩니다. Auto Scaling Group조회 결과의 Auto Scaling Group 소속 인스턴스 관련 속성에서 볼 수 있습니다.

'unhealthy'로 마킹된 이후 보통은 수 초 뒤에 Auto Scaling Group의 서비스 용량(capacity)을 유지 하기 위해, 그 문제의 서버를 반납하고 새로운 서버 인스턴스를 생성해서 서비스에 적용합니다.

이 헬스를 체크하는 방법으로 서버 인스턴스의 각종 상태를 체크해서 모니터하는 '서버'라는 이름의 방법과 로드밸런서의 헬스 체크 결과를 이용하는 '로드밸런서'라는 이름의 방법이 있습니다. 이 옵션은 Auto Scaling Group의 healthCheckTypeCode 속성 값으로 정할 수 있습니다.

Auto Scaling Group 소속 서버 인스턴스의 헬스 상태가 좋지 않다고 한번 마킹이 되면 (수동에 의한 마킹도 포함) 그 뒤로는 (1) healthCheckTypeCode 값이 '서버'이면 헬스 체크를 중단하고 (2) healthCheckTypeCode 값이 '로드밸런서'이면 마킹 이후의 로드밸런서의 서버 포트 헬스 체크 결과가 서비 인스턴스의 헬스 상태 정보에 반영되지 않습니다. 따라서 마킹 이후 다시 서버 포트가 UP 상태가 되어도 반영이 되지 않습니다.

서버 인스턴스에 대한 헬스 체크

healthCheckTypeCode 값으로 '서버(SVR)'를 지정하면 상태(status) 체크(check)로 모니터링 체크 결과가 통과(pass)가 아닌 실패(fail)이면 그 서버 인스턴스의 문제가 있는 것으로 봅니다. 서버 상태 체크는 보통 60초 간격으로 이루어지며 3회 연속 통과하지 못하면 그 서버가 'unhealthy'로 마킹합니다.

서버 상태 체크 항목은 다음과 같고 한 항목이라도 통과하지 못하면 서버 인스턴스의 문제가 있는 것으로 판단합니다.

  • 서버가 존재하는 물리적 호스트가 down되었는지 확인
  • 서버가 운영 중(running)인지 확인
  • Guest OS 내부의 관리 agent가 정상적으로 운영 중 (running)인지 확인
  • 서버가 행(hang)인지
  • 서버가 서비스에 투입된 이후 다시 부팅이 되었는지 (의도적이건 비의도적이건)
  • IP 주소가 할당되어 있는지 확인

Auto Scaling Group 소속 서버 인스턴스의 헬스 상태가 좋지 않다고 한번 마킹이 되면 그 뒤로는 healthCheckTypeCode 값이 '서버'이면 그 서버 인스턴스에 대해 헬스 체크를 중단합니다.

단, 사용자가 수동으로 그 서버 인스턴스의 헬스 상태를 'healthy'로 마킹할 수 있고 그럴 경우 다시 서버 상태 체크를 시작하나 서버 인스턴스가 unhealthy상태가 되면, 정상적이라면 수초 내에 인스턴스 반납이 시작되며, 일단 반납이 시작된 서버 인스턴스는 상태를 healthy로 변경하더라도 영향 받지 않고 반납이 완료됩니다.

로드밸런서를 이용한 헬스 체크

healthCheckTypeCode 값으로 '로드밸런서(LOADB)'를 지정하면 Auto Scaling Group 소속 서버 인스턴스들과 연동하는 로드밸런서가 행하는 헬스 체크 결과를 상태(status) 값에 반영합니다. 로드밸런서는 서버 포트별로 6초 간격으로 헬스 체크해서 2회 연속 체크 통과(pass)에 실패하면, 포트가 down된 것으로 판정합니다. 그리고 down된 포트를 6초 간격으로 헬스 체크하여 2회 연속 통과를 하면 포트가 다시 UP이 된 것으로 판정합니다.

Auto Scaling은 보통 150초마다 그 판정 값을 서버 헬스 상태 정보에 반영합니다. 로드밸런서 서비스를 받는 서버 포트가 하나 이상 내려간(down) 경우 그 서버는 'unhealthy' 하다고 마킹합니다. 150초마다 로드밸런서의 헬스 체크 결과를 Auto Scaling에 반영하므로, 반영 작업이 이루어지는 150초 사이에 로드밸런서에 등록된 서버 인스턴스가 잠깐 down되었다가 다시 살아난다면 반영이 안 될 수 있습니다.

그리고 한가지 유의할 점은 healthCheckTypeCode 값으로 로드밸런서(LOADB)를 지정한 경우에도 서버 헬스 체크는 함께 수행됩니다.

수동으로 헬스(health) 판정

상태 체크나 로드밸런서만 가지고 헬스 체크하기에 미흡할 수 있습니다. 따라서 서버 인스턴스 관리자가 직접 운영하는 자체 health check tool을 이용하여 또는 사람이 직접 인스턴스의 health를 판단하여 수동으로 특정 서버 인스턴스의 health를 판정할 수 있습니다. RESTful API를 이용할 때는 setInstanceHealth API를 호출하면 됩니다. API를 호출할 때 healthStatus 파라미터 값으로 'unhealthy' 하다고 설정하면, 보통 10 초 이내에 그 서버는 반납(terminating)되고 새로운 서버가 서비스에 적용(launch)되는 교체(replace) 프로세스가 진행됩니다.

헬스 상태가 좋지 않다고 마킹된 서버 인스턴스를 수동으로 'healthy' 하다고 마킹할 수 있으나, 보통은 'unhealthy' 하다고 마킹된지 보통 10초 이내에 교체 작업이 시작되므로 그 이후 'healthy' 하다고 마킹해도 소용없습니다. 그리고 status check에 의해 unhealthy로 마킹된 것을 수동으로 health라고 변경해도 실제 그 서버 인스턴스의 health에 이상이 있다면 곧 unhealthy로 다시 변경되어서 결국 서버는 반납됩니다. 그리고 서버 인스턴스 현재 헬스(health) 상태와 동일한 값으로 healthStatus 파라미터를 지정하여 setInstanceHealth API를 호출해도 실질적인 변화는 없습니다.

setInstanceHealth 액션의 shouldRespectGracePeriod 파라미터 이용

상기 API를 호출할 때, shouldRespectGracePeriod 파라미터를 지정해서 호출할 수 있습니다. 그 파라미터의 용도는 다음과 같습니다.

서버 인스턴스가 생성되어 서비스 적용이 완료된 이후 어느 정도의 기간 동안은 서버 내부에서 서비스를 위한 설정 작업이 진행되어 정상적인 서비스가 안될 수 있으므로, 이 기간 동안은 헬스 체크(check)를 보류하기 위해, Auto Scaling Group의 속성인 healthCheckGracePeriod 값(단위는 초)의 기간 동안은 헬스 체크를 보류합니다. Boolean type의 shouldRespectGracePeriod 파라미터의 값을 true로 지정하면 서비스 적용 시점 이후 healthCheckGracePeriod 기간이 지나기 전에 API를 호출하면 HTTP status code 400의 invalid parameter 에러가 발생합니다. shouldRespectGracePeriod 값을 명시적으로 false라고 지정하면, healthCheckGracePeriod 기간이 지나지 않더라도 헬스 상태 값을 변경할 수 있습니다. 현재는 서버 인스턴스가 서비스 적용 대기 단계(pending)에서 API를 호출하면, HTTP status code 400의 invalid parameter 에러가 발생합니다.

연동 로드밸런서와 healthCheckTypeCode의 조합

생성된 로드밸런서(Load-Balancer)를 연동 로드밸런서로 지정하고 healthCheckTypeCode 값을 '로드밸런서(LOADB)'로 지정하는 것이 일반적이지만 그렇지 않은 경우도 있습니다. 예외적인 경우에 대한 설명은 아래와 같습니다.

  • Auto Scaling Group을 생성할 때 연동할 로드밸런서 이름을 지정했으나 그 이름의 로드밸런서는 아직 생성되지 않았고 그 상태에서 healthCheckTypeCode 값을 로드밸런서로 지정했을 때 그 Auto Scaling Group 소속 서버 인스턴스가 생성되고 나서 서비스에 적용될 때 그 이름의 로드밸런서가 존재하지 않으므로 로드밸런서에 할당되지 않은 상태로 서비스에 적용되게 됩니다.

따라서 healthCheckTypeCode 값을 로드밸런서로 지정해도 헬스 체크를 할 로드밸런서가 없으므로 효력이 없으므로 기본 헬스 체크 방식은 서버 방식만 작동합니다.

  • Auto Scaling Group을 생성할 때 연동할 로드밸런서 이름을 지정하지 않았으나 healthCheckTypeCode 값을 로드밸런서로 지정했을 때, 연동할 로드밸런서가 없으므로 healthCheckTypeCode 값을 로드밸런서로 지정해도 효력이 없습니다. 그리고 이를 에러로 보지 않습니다. 나중에 Auto Scaling Group을 갱신할 때 healthCheckTypeCode 값을 서버로 변경할 수도 있습니다.
  • Auto Scaling Group을 생성할 때 존재하는 로드밸런서 이름을 연동할 로드밸런서로 지정하지 않았으나 healthCheckTypeCode 값을 서버로 지정했을 때, 그 Auto Scaling Group 소속 서버 인스턴스들은 로드밸런서에 할당되어 서비스를 하고 있지만 healthCheckTypeCode 값을 서버로 지정했으므로 로드밸런서가 할당된 서버 포트에 대한 헬스 체크를 하여 그 결과를 관리 콘솔의 서버 조회 화면에서 볼 수 있으나, Auto Scaling Group 소속 서버 인스턴스의 헬스 체크 속성에는 반영되지 않습니다.
  • 물론 Auto Scaling Group의 healthCheckTypeCode 값을 로드밸런서로 변경하면 그 이후로는 로드밸런서 헬스 체크 결과가 서버 인스턴스의 헬스 상태에 반영됩니다.
  • Auto Scaling Group을 생성할 때 healthCheckTypeCode 값을 지정하지 않으면, healthCheckTypeCode 파라미터는 필수는 아니고 디폴트 값은 '서버'입니다. 따라서 healthCheckTypeCode 값을 '서버'로 지정한 것과 동일한 효과가 납니다.

서버 인스턴스의 health는 자동으로 status check에 정해지기도 하지만 사용자의 요청으로 수동 마킹(marking)할 수도 있습니다. RESTful API를 이용하고 싶을 경우 setInstanceHealth를 호출하면 됩니다. 특정 서버 인스턴스의 'unhealthy' 하다는 파라미터로 지정해서 상기 API를 호출하고 나서, 그 서버 인스턴스가 소속된 Auto Scaling Group 정보를 획득하면 그 서버 인스턴스의 'unhealthy'로 표시됩니다. 그러면 보통 5초 안으로 그 서버 인스턴스의 반납 프로세스(terminating)가 시작됩니다.

상기 API를 호출할 때, shouldRespectGracePeriod 파라미터를 지정해서 호출할 수 있습니다. 그 파라미터의 용도는 다음과 같습니다.

서버 인스턴스가 생성되어 서비스 적용이 완료된 이후 어느 정도의 기간 동안은 서버 내부에서 서비스를 위한 셋업 작업이 진행되어 정상적인 서비스가 안될 수 있으므로, 이 기간 동안은 헬스 체크(check)를 보류하기 위해, Auto Scaling Group의 속성인 healthCheckGracePeriod 값(단위는 초)의 기간 동안은 헬스 체크를 보류합니다. Boolean type의 shouldRespectGracePeriod 파라미터의 값을 지정하면 (참고로 디폴트 값은 true) 서비스 적용 시점 이후 healthCheckGracePeriod 기간이 지나기 전에 API를 호출하면 HTTP status code 400의 invalid parameter 에러가 발생합니다. shouldRespectGracePeriod 값을 명시적으로 false라고 지정하면, healthCheckGracePeriod 기간이 지나지 않더라도 헬스 상태 값을 변경할 수 있습니다.

현재는 서버 인스턴스가 서비스 적용되기 이전 단계(pending)에서 API를 호출하면, HTTP status code 400의 invalid parameter 에러가 발생합니다.

그리고 수동 또는 자동으로 서버 인스턴스가 'unhealthy' 하다고 마킹되어도 사용자가 수동으로 'healthy'로 변경할 수는 있습니다. 그러나 보통은 'unhealthy' 하게 되면 5초이내에 서버 반납 프로세스가 시작되므로 프로세스 진행 전에 변경했다면 효과가 있지만, 반납 프로세스가 일단 진행이 되면, 그 이후로는 'health'로 마킹해도 계속 반납 프로세스가 진행됩니다.

그리고 status check에 의해 'unhealthy'로 마킹된 것을 수동으로 'healthy'로 변경해도 실제 그 서버 인스턴스에 문제가 있다면 곧 'unhealthy'로 다시 변경됩니다.

서버 인스턴스가 헬스 상태와 동일한 값으로 API를 호출하여 설정해도 실질적인 변화는 없습니다.

헬스에 문제가 있는 서버 인스턴스 교체

Auto Scaling의 주요 기능 중 하나는 Auto Scaling Group의 capacity(소속 서버 인스턴스의 수)를 Auto Scaling Group의 속성으로 지정된 Desired Capacity 수준으로 계속 유지하는 것입니다.

이를 위해 Auto Scaling Group 소속 일부 서버 인스턴스가 헬스에 문제가 있다고(unhealthy) 하다고 표시가 되면 그 Auto Scaling Group에 대해 scaling 행동이 진행되고 있지 않는 이상 보통 10 초 이내에 문제 있는 서버들이 반납되고 새로운 서버 인스턴스가 생성되는 프로세스가 시작됩니다.

교체 프로세스가 시작되면 Auto Scaling Group의 'unhealthy' 하다고 표시된 모든 서버 인스턴스들이 한번에 동시에 반납이 시작되고 그 모든 서버 인스턴스들의 반납이 완료되면 그 서버 인스턴스들을 대체할 새로운 서버 인스턴스가 생성되어 서비스에 투입되면 그 프로세스는 완료됩니다.

그리고 사용자가 Auto Scaling Group 소속 서버를 Auto Scaling 관린 인터페이스가 아닌 방법으로 반납(terminate)할 수 있습니다. 예를 들어, cloud server API나 관리콘솔을 이용하여 서버를 반납할 수 있습니다. 이럴 경우에도 서버 수를 Desired Capacity수준으로 유지하기 위해 자동으로 서버가 생성되어 서비스에 투입됩니다.

Zone별 Auto Scaling Group 소속 서버 인스턴스 수 rebalancing

Auto Scaling Group속성 중 서버가 존재할 zone들의 정보를 담은 속성이 있습니다. 서버가 생성될 때 가용성을 높이기 위해 가능하면 zone별 서버 수가 밸런스를 이루도록 서버를 생성합니다. 그리고 Auto Scaling Group의 zone 속성이 변하면, 새로운 zone별 서버 수가 밸런스를 이루기 위해 서버 수가 부족한 zone에는 서버를 생성하고, 서버 수가 많이 있을 필요 없는 zone의 서버는 일부 반납합니다. 이러한 프로세스를 zone rebalancing이라고 부릅니다. Auto Scaling Group의 zone 속성이 변할 때뿐 아니라, 서버가 생성될 때, 일시적으로 특정 zone이 가용하지 못해서, 어쩔 수 없이 zone 밸런스가 깨질 때가 있습니다. 이 경우 문제 있던 zone의 가용성이 회복되면 zone rebalancing 프로세스가 진행됩니다.

Auto Scaling Group의 zone구성을 갱신하면 새로인 갱신된 zone별로 서버 인스턴스가 밸런스를 이루도록 zone 리밸런싱 프로세스(process)가 진행되는데 예를 들어 설명하면 다음과 같습니다.

기존의 Auto Scaling Group의 zone번호가 #2, #3, #4이고 actual capacity가 6이었다면, 각 zone별로 2대씩 서버 인스턴스가 존재했을 것입니다. 즉 #2에 2대, #3에 2대, #4에 2대 존재했을 것입니다. 그런데 그 Auto Scaling Group의 zone번호 구성이 #4, #5로 갱신이 되었다면, #4에는 서버 3대, #5에는 3대가 존재해야 합니다. 따라서 새로운 zone 구성에서 밸런스를 이루기 위한 절차가 진행됩니다. 이를 리밸런싱(rebalancing)이라고 합니다. 위의 예에서 리밸런싱을 하기 위해서는, #2와 #3에 있던 서버 2대는 사라져야 하고, #4에서는 추가로 1 대 더 생성되어야 하고, #5에서는 새로 서버 3개가 만들어져야 합니다.

리밸런싱을 하기 위해 서버 인스턴스 생성과 반납이 둘 다 일어나야 한다면, 서비스 가용성을 위해 서버 생성 절차가 먼저 진행됩니다. 위의 예에서는 따라서 #4에 서버 1대, #5에 3대가 생성되어 서비스에 적용되는 절차가 먼저 진행됩니다. 따라서 일시적으로 서버 대수가 9대까지 올라갑니다. 새로운 서버가 서비스에 적용된 직후(healthCheckGracePeriod와 상관 없이), 없어진 zone에 있는 서버들의 반납 작업이 진행됩니다. 위의 예에서는 #2와 #3에 있던 서버 총 4대가 반납됩니다.

만약 Auto Scaling용 서버가 생성될 때, Auto Scaling Group의 속성으로 지정된 zone 중 일부가 가용하지 못한(unavailable) 상태라면, 일단 가용한 zone에만 서버가 생성됩니다. 그 후 문제 있던 zone이 가용성을 회복하면, 리밸런싱(rebalancing) 프로세스를 진행합니다. 물론 지정된 zone들 모두 가용하지 못할 때, 서버를 생성하려 하면, 서버 생성에 실패할 것입니다. 그 후 계속 주기적으로 서버 생성을 재시도하므로, zone이 가용성을 회복하면, 그 zone에 서버가 생성될 것입니다.

특정 zone에 문제가 있어서 가용하지 못하다고(unavailable) 판정이 나면, 그 zone에 돌고 있던 서버 인스턴스들은 반납을 하고 문제 없는 zone에 서버가 생성됩니다.

실제로 특정 zone에 문제가 있으나 아직 특정 zone이 가용하지 못하다고 판정되어 마킹(marking)되기 전에 Auto Scaling용 서버를 생성하려 하면, 문제 있는 zone에서 서버가 생성 안될 수 있습니다. 이 경우 그 scaling action은 최대 100분동안 진행 중(in-progress) 상태로 있다가 생성을 포기하고 그 서버 인스턴스를 반납합니다. 그리고 서버 인스턴스 생성에 실패했다는 activity log를 남기고 끝납니다.

ZONE REBALANCE 프로세스가 진행될 때 먼저 교체될 서버 인스턴스가 먼저 생성되는 LAUNCH 프로세스 완료 이후 서버 인스턴스를 반납하는 TERMINATE 프로세스가 진행됩니다. 따라서 일시적으로 Auto Scaling Group의 그룹 크기가 커져서 maxSize보다 더 커질 수 있습니다.

스케줄에 따른 액션 (Scheduled Action)

스케줄 설정에 따라 스케줄에 따른 액션 실행이 되면 Auto Scaling Group의 minSize, actual capacity 또는 maxSize이 변경됩니다. 변경 이후에도 minSize <= Desired Capacity <= maxSize의 대소 관계가 유지가 되면 적용이 되어 action 로그에 실행에 성공했다고 로그가 남습니다. 만약 대소 관계에 문제가 있으면 실행에 실패했다고 남습니다. 만약 스케줄에 의한 액션에 의해 DC가 변경되었다면, 후속 액션으로 scale-out 액션 또는 scale-in 액션이 행해집니다. scale-out 액션이 행해진다면 LAUNCH 프로세스가 진행되고, scale-in 액션이 행해진다면 TERMINATE 프로세스가 진행됩니다.

로드밸런서에 서버 인스턴스 추가

서버 인스턴스가 생성되어 서비스에 적용되는 LAUNCH 프로세스가 진행된 이후, 후속 프로세스로 그 서버 인스턴스가 Auto Scaling Group에 지정된 연동 로드밸런서에 할당되는 프로세스가 진행되는데 자세한 설명은 '6.1로드밸런서와의 연동' 항목을 보면 됩니다.

알람(alarm) 통보

모니터는 Auto Scaling 그룹의 자원 소모를 계량하고 사용자가 정해놓은 기준에 따라 (예를 들어 10분 이상 CPU 90% 이상 사용) 알람이 통보되면 사용자가 정해놓은 정책을 수행합니다. 자세한 설정 방법은 네이버 클라우드 플랫폼 설명서(구, 사용자 가이드)에 '상세 모니터링 사용 가이드' 있습니다.

Process 보류/재개

현재 scaling 액션을 행하기 위해 이루어지는 진행 절차(프로세스) 중 보류(suspend)와 재개(resume)이 가능한 프로세스는 다음과 같습니다. 괄호 안은 파라미터 값으로 입력할 문자열(string)입니다.

  • LAUNCH (LANCH): 서버 인스턴스 생성 및 서비스 투입
  • TERMINATE (TERMT): 서버 인스턴스 반납
  • HEALTH CHECK (HTHCK): 서버 인스턴스 헬스 체크
  • REPLACE UNHEALTHY (RPUNH): 헬스에 문제가 있는 서버 인스턴스 교체
  • ZONE REBALANCE (ZNRBL): Zone별 Auto Scaling Group 소속 서버 인스턴스 수 rebalancing
  • SCHEDULED ACTIONS (SCACT): 스케줄에 따른 액션
  • ADD TO LOAD BALANCER (ADTLB): 로드밸런서에 서버 인스턴스 추가
  • ALARM NOTIFICATION(ALMNO): 알람 통보

각 프로세스에 대한 설명은 다음과 같습니다.

LAUNCH (LANCH)

서버 인스턴스를 생성해서 서비스에 적용하는(launch) 프로세스를 보류/재개할 수 있습니다. LAUNCH가 보류된 상태에서는 그룹 크기 확대나 서비스 용량(capacity) 유지 등과 같은 서버 인스턴스가 생성되어야 할 상황에서도 생성이 보류됩니다. 다만 재개가 된 이후, 실제 서비스 용량(capacity)과 Desired Capacity의 차이가 난 경우와 같이 생성해야 할 상황이라면 서버 인스턴스 생성됩니다.

TERMINATE (TERMT)

서버 인스턴스를 반납(terminate)하는 프로세스를 보류/재개할 수 있습니다. TERMINATE가 보류된 상태에서는 그룹 크기 감소 등과 같은 서버 인스턴스가 반납될 상황이 되어도 반납 프로세스가 보류됩니다. 다만 재개가 되고 나서, 실제 서비스 용량(capacity)이 Desired Capacity보다 큰 경우와 같이 서버 인스턴스를 반납해야 할 상황이라면 서버 인스턴스는 반납됩니다.

HEALTH CHECK (HTHCK)

서버 인스턴스의 health에 문제가 있는지 status check를 이용하거나 로드밸런서를 이용하여 모니터링할 수 있습니다. HEALTH CHECK를 보류할 경우 설령 서버 인스턴스의 health에 문제가 생겨도 Auto Scaling Group 소속 서버 인스턴스의 헬스 상태를 'unhealthy'로 마킹(marking)하지 않습니다. 재개할 경우 그 이후 check 결과 헬스에 문제가 있으면 'unhealthy' 상태로 마킹됩니다.

REPLACE UNHEALTHY (RPUNH)

보통 서버 인스턴스의 health에 문제가 있으면, 그 인스턴스는 자동으로 반납되고 새로운 인스턴스가 생성 및 서비스에 적용되는 교체 프로세스가 발생합니다. 그러나 보류로 설정되면 인스턴스의 헬스 상태가 'unhealthy'로 마킹되어도 (자동으로 마킹되건 수동이건 상관 없이) 교체 프로세스가 진행되지 않습니다. 그러나 다시 프로세스가 재개 되면 이미 'unhealthy'로 마킹된 인스턴스와 이후 'unhealthy'로 마킹될 인스턴스들은 교체가 됩니다.

만약 REPLACE UNHEALTHY가 보류된 상태가 아니더라도 TERMINATE 프로세스가 보류되어 있다면, 헬스에 문제 있는 서버들에 대한 교체 프로세스는 진행되지 않습니다.

만약 REPLACE UNHEALTHY와 TERMINATE가 보류된 상태가 아니더라도 LAUNCH 프로세스가 보류되어 있다면, 문제의 서버는 반납은 되지만, 교체를 위해 새로운 서버 인스턴스가 생성되지 않습니다. 하지만 이렇게 되면 보통 Auto Scaling Group의 실제(actual) capacity가 Desired Capacity보다 작게 되어서 나중에 LAUNCH 프로세스가 재개되면, 서버 인스턴스가 생성됩니다.

ZONE REBALANCE (ZNRBL)

특정 Auto Scaling Group의 서버 인스턴스들이 지정된 zone별로 균등히 분포되어 있지 않은 경우 리밸런싱(rebalancing) 프로세스가 진행됩니다. 사용자가 Auto Scaling Group의 zone의 구성이 변경될 경우 발생합니다. 새로운 zone이 추가되거나 기존의 zone이 없어지면 프로세스가 진행됩니다. 그러나 이 ZONE REBALANCE 프로세스가 보류되어 있다면, 리밸런싱(rebalancing)이 실행되지 않는다. 그러나 재개가 되면 바로 리밸런싱(rebalancing) 프로세스가 진행됩니다.

ZONE REBALANCE 프로세스가 진행될 때 먼저 교체될 서버 인스턴스가 먼저 생성되는 LAUNCH 프로세스 완료 이후 서버 인스턴스를 반납하는 TERMINATE 프로세스가 진행됩니다. 따라서 일시적으로 Auto Scaling Group의 그룹 크기가 커져서 maxSize보다 더 커질 수 있습니다.

만약 ZONE REBALANCE 프로세스가 진행할 수 있어도 LAUNCH 프로세스가 보류되어 있다면, ZONE REBALANCE와 LAUNCH 프로세스 모두 진행되지 않습니다.

만약 ZONE REBALANCE 프로세스가 진행할 수 있어도 TERMINATE 프로세스가 보류되어 있다면, Auto Scaling은 그룹 크기를 maxSize의 110 %까지 키울 수 있고, 그 상태로 유지됩니다. 나중에 TERMINATE 프로세스가 재개 가능하게 되면, 반납될 서버 인스턴스들은 반납되어 zone 리밸런싱이 완료됩니다.

SCHEDULED ACTIONS (SCACT)

이 프로세스가 보류되면 지정된 미래 시각에 Scaling action이 이루어지도록 잡은 스케줄이 존재해도 실제 action이 발생하지 않고 취소(cancel)됩니다. Activity log에도 그 스케줄에 따른 액션은 취소된 것으로 기록됩니다.

재개가 되면 그 이후의 스케줄에 대해서는 Scaling action이 이루어집니다. 하지만 재개 전의 과거에 이루어졌어야 할 Scaling 액션(action)은 행해지지 않습니다.

만약 스케줄에 따라 액션이 행해질 때, SCHEDULED ACTIONS이 보류되어 있지 않아도, LAUNCH 또는 TERMINATE 프로세스가 보류되어 있다면, 스케줄에 따른 액션이 실행되어도 minSize, actual capacity와 maxSize가 변경되지만 그에 따른 LAUNCH 또는 TERMINATE프로세스가 진행되지 않습니다. Activity log에는 스케줄에 따른 액션이 실행 성공했다는 로그만 남고 아무런 액션이 없습니다. 액션이 없으니 action 로그가 남지 않습니다. 나중에 LAUNCH 또는 TERMINATE프로세스가 재개되면 그 때 AC와 DC에 차이가 있으면 액션이 행해집니다.

ADD TO LOAD BALANCER (ADTLB)

이 프로세스가 보류가 되면 서버가 생성되어 서비스에 적용되기 직전에 로드밸런서에 할당되던 프로세스가 진행되지 않습니다. 이 프로세스가 재개가 되면 재개 이후 생성된 서버 인스턴스들은 로드밸런서에 적용됩니다. 그러나 재개 전에 보류된 상태에서 생성된 서버 인스턴스들에게는 영향이 없습니다. 보류된 상태에서 서비스에 적용된 서버 인스턴스들을 로드밸런서에 할당하고 싶으면 수동으로 해야 합니다.

ALARM NOTIFICATION (ALMNO)

이 프로세스가 보류가 되면 모니터가 해당 그룹에 대해 알람(alarm)의 통보(notification)하는 보류합니다.

Activity log

Scaling action을 행하면 그 action 로그를 남깁니다. RESTful API getAutoScalingActivityLogList를 호출하면 최근 6주 동안의 action 로그를 조회할 수 있습니다. action 로그 레코드의 필드로 로그 식별자(번호)와 해당 Auto Scaling Group 이름, action에 대한 설명(description), 상세 설명(details), 액션 유발 원인(cause)과 상태(성공/실패) 및 액션 시작 시각과 종료 시각 필드가 있습니다.

알아두어야 할 점은 특정 scaling 액션이 행해지면, 그 액션 하나에 대한 로그 레코드 하나가 기록되는 것이 아니라, 액션으로 인해 생성 또는 반납되는 서버 인스턴스별로 로그 레코드가 기록된다는 점입니다.

예를 들어, 현재 특정 Auto Scaling Group의 AC(Actual capacity)가 5였는데 사용자가 수동으로 10으로 설정했다면, scale-out을 위해 5개의 서버 인스턴스가 생성됩니다. 이 경우 새로 생성되는 5개의 서버 인스턴스에 해당하는 action 로그 레코드가 기록되고 각각의 서버 인스턴스 생성이 성공했는지 실패했는지 기록이 남게 됩니다. 이때 액션 유발 원인(cause)에는 AC와 actual capacity에 차이가 있어서 서버 인스턴스가 생성된다는 메시지가 기록됩니다. 설명(description)란에는 어떤 서버가 서비스에 적용되었는지 상세 설명(details)란에는 서버 인스턴스가 생성된 zone 정보가 기록됩니다.

반대로 현재 DC가 10인데 사용자에 의해 수동으로 7로 설정되었다면, scale-in을 위해 3개의 서버 인스턴스가 반납됩니다. 이 경우 3개 서버 인스턴스에 해당하는 action 로그 레코드가 기록되고, 각각의 서버 인스턴스 반납 성공/실패가 기록에 남게됩니다. 이때 액션 유발 원인(cause)에는 AC와 DC에 차이가 있어서 서버 인스턴스가 생성된다는 메시지가 기록됩니다. 설명(description)란에는 어떤 서버가 반납되었는지 기록됩니다.

스케줄에 따라 scaling 액션이 행해지면, 그 하나의 스케줄에 의한 scaling 액션에 대한 action 로그 레코드가 그로 인해 생성/반납되는 서버 인스턴스들의 로그 레코드와 함께 기록됩니다. 만약 스케줄에 의한 설정 변경이 Auto Scaling Group에 잘 적용되면 상태가 성공으로 기록되고 스케줄 설정에 문제가 있어서 Auto Scaling Group에 적용되지 못하면, 예를 들어, 스케줄의 actual capacity 값이 Auto Scaling Group의 maxSize보다 크다면, 실패로 기록됩니다.

Auto Scaling interface 사용법

이 장에서는 사용자가 Auto Scaling 서비스를 이용하기 위한 환경을 구축하는 방법과 사용자 인터페이스를 통해 Auto Scaling 서비스를 이용하는 방법을 예시로 설명하고자 합니다.

참고로 기초적인 Auto Scaling 서비스 환경 구축과 사용 시나리오는 'Auto Scaling API 시작 가이드'에 별도로 기재되어 있습니다.

인터페이스(interface)와 그 관계

Auto Scaling 서비스를 이용할 수 있기 위한 사용자 인터페이스와 그 관계는 다음과 같습니다.

아래 첫번째 그림은 생성, 변경 및 조회를 위한 사용자 인터페이스와 그 관계를 나타낸 도식이고 두번째 그림은 삭제를 위한 사용자 인터페이스와 그 관계를 나타낸 도식입니다.

Auto Scaling 사용 환경 구축

현재는 Auto Scaling 서비스 사용자 인터페이스로 RESTful API를 제공하고 있습니다. 그리고 이 RESTful API를 사용자가 손쉽게 호출할 수 있도록 SDK를 제공하고 있습니다.

Auto-Scaling 서비스 API

Auto Scaling 서비스 API로 RESTful API를 제공합니다. API의 URL의 도메인 이름 부분은 모든 네이버 클라우드 플랫폼 서비스가 공통적으로 사용하고 있는 'api.ncloud.com'입니다. Auto Scaling 서비스를 사용하기 위해서는 URL의 최상위 경로(path)가 '/autoscaling/'이어야 합니다.

자세한 설명은 네이버 클라우드 플랫폼 웹사이트의 고객센터 > 자료실 > 사용 가이드 > API (우측 select box에서 선택)에 있는 'Auto-Scaling API reference' 문서와 '서버-로드밸런서 API' 문서에 기재되어 있습니다.

API 라이브러리 사용하기

API 라이브러리는 API client 프로그램 개발을 위한 SDK입니다. 이 SDK를 사용하면 에러 핸들링(error handling)과 같은 복잡한 처리를 사용자가 신경 쓸 필요 없어서 API client를 개발하기 편해집니다. 현재는 SDK로 Java 언어로 구현된 JAR를 제공하고 있습니다.

API 라이브러리에 대한 자세한 설명은 고객센터 > 자료실 > 사용 가이드 > API (우측 select box에서 선택)에 있는 'API 라이브러리 이용 가이드' 문서에 기재되어 있습니다.

RESTful API를 이용한 Auto Scaling 사용 예시

Auto Scaling은 다양한 방식으로 사용이 가능하지만, 이해를 돕기 위해 이 항목에서는 Auto Scaling 사용의 전형적인 예시를 제공합니다.

사전 준비 작업

사용자는 Auto Scaling을 할 계정으로 관리 콘솔에 들어가서 Auto Scaling에 의해 생성된 서버 인스턴스와 연동될 로드밸런서를 2개 생성합니다. 이 시나리오에서는 slb-1과 slb-2를 생성합니다. 로드밸런서를 생성할 때 그 룰로 다음 장에 생성될 CentOS 서버 인스턴스들의 기본 서비스인 ssh 포트 (22)를 서버 포트로 지정합니다.

Launch Configuration 생성

Launch Configuration은 Auto Scaling이 클라우드 서버 인스턴스를 생성하여 서비스에 적용하기 위해 사용되는 템플릿(template)입니다. 그 템플릿은 Auto Scaling이 서버 인스턴스를 생성하기 위한 모든 정보를 포함하고 있습니다.

Launch Configuration를 생성하기 위해 다음 요청 파라미터를 지정하여 createLaunchConfiguration API를 호출합니다.

- launchConfigurationName(론치 설정 명): lc-1
- serverImageProductCode(서버 이미지 상품 코드): SPSW0LINUX000009

위와 같은 파라미터를 전달하여 Launch Configuration를 생성을 요청하는 RESTful API는 아래 URL과 같습니다.

https://api.ncloud.com/autoscaling/?action=createLaunchConfiguration&launchConfigurationName=lc-1&serverImageProductCode=SPSW0LINUX000009&AUTHPARAMS

나머지 파라미터인 서버 상품 코드, login-key는 지정이 되어 있지 않아서, 디폴트 값이 지정됩니다. 서버 사양을 나타내는 서버 상품 코드의 디폴트 값은 최소 사양 값이고, login key의 디폴트 값은 사용자가 마지막으로 지정한 키입니다.

호출에 성공하면 그 결과로 HTTP status가 '200 OK'인 응답과 함께 HTTP 메시지 본체(message body)로 받은 아래와 같은 XML 문서를 볼 수 있습니다. 최상위 요소는 결과로써 받은 createLaunchConfigurationResponse 객체입니다. 그 객체는 returnCode 태그와 returnMessage 태그를 포함하고 있고, returnMessage 태그의 값이 success이고 returnCode가 0이면 액션이 성공한 것입니다. createLaunchConfigurationResponse 객체는 launchConfigurationList라는 launchConfiguration 객체를 항목을 하는 리스트 객체를 포함하고 있습니다. 그 launchConfiguration 객체에서 새로이 생성한 Launch Configuration의 내용을 확인할 수 있습니다.

<?xml version="1.0" encoding="UTF-8"?>
<createLaunchConfigurationResponse>
  <requestId>a3fc6c83-6adf-4c63-b1bc-05ee3c672fc2</requestId>
  <returnCode>0</returnCode>
  <returnMessage>success</returnMessage>
  <totalRows>1</totalRows>
  <launchConfigurationList>
    <launchConfiguration>
      <launchConfigurationName>lc-3</launchConfigurationName>
      <serverImageProductCode>SPSW0LINUX000009</serverImageProductCode>
      <serverProductCode>SPSVRSTAND000043</serverProductCode>
      <memberServerImageNo></memberServerImageNo>
      <loginKeyName>yh-nang-test</loginKeyName>
      <createDate>2014-02-13T13:52:50+0900</createDate>
      <userData></userData>
    </launchConfiguration>
  </launchConfigurationList>
</createLaunchConfigurationResponse>

Launch Configuration 생성 확인

방금 생성한 Launch Configuration이 의도대로 생성되었는지 확인하기 위해, 다음 요청 파라미터를 지정하여 getLaunchConfigurationList API를 호출합니다.

- launchConfigurationName (론치 설정 명): lc-1

호출에 성공하면 그 결과로 HTTP status가 '200 OK'인 응답과 함께 message body로 다음과 같은 XML 문서를 볼 수 있습니다. 결과로 받는 객체(최상위 요소)는 getLaunchConfigurationListResponse입니다. 그 하위 태그인 returnMessage 태그의 값이 success이고 returnCode가 0이면 액션이 성공한 것입니다. getLaunchConfigurationListResponse 객체는 launchConfigurationList 라는 launchConfiguration 항목들의 리스트 객체를 포함하고 있고 그 항목에 생성된 Launch Configuration 들의 명세가 보입니다.

<?xml version="1.0" encoding="UTF-8"?>
<getLaunchConfigurationListResponse>
  <requestId>9dc375e8-0a5d-40fe-a724-602ad84769f0</requestId>
  <returnCode>0</returnCode>
  <returnMessage>success</returnMessage>
  <totalRows>1</totalRows>
  <launchConfigurationList>
    <launchConfiguration>
      <launchConfigurationName>lc-1</launchConfigurationName>
      <serverImageProductCode>SPSW0LINUX000009</serverImageProductCode>
      <serverProductCode>SPSVRSTAND000043</serverProductCode>
      <memberServerImageNo></memberServerImageNo>
      <loginKeyName>yh-nang-test</loginKeyName>
      <createDate>2014-02-13T13:45:57+0900</createDate>
      <userData></userData>
    </launchConfiguration>
  </launchConfigurationList>
</getLaunchConfigurationListResponse>

Auto Scaling Group 생성

Launch Configuration이 생성되면 그 다음으로 Auto Scaling Group을 생성할 수 있습니다. Auto Scaling Group이란 공통의 서비스를 수행하는 서버 인스턴스들의 논리적 그룹으로 설정에 따라 자동으로 횡적인 scalilng이 가능합니다.

Auto Scaling Group을 생성하기 위해 다음 요청 파라미터를 지정하여 createAutoScalingGroup API를 호출합니다.

- autoScalingGroupName(오토스케일링그룹명): asg-1
- launchConfigurationName(론치설정명): lc-1
- desiredCapacity: 3
- minSize(최소사이즈): 1
- maxSize(최대사이즈): 10
- loadBalancerNameList.1(로드밸런서명리스트 1번째 항목): slb-1
- loadBalancerNameList.2(로드밸런서명리스트 2번째 항목): slb-2
- healthCheckGracePeriod(헬스체크보류기간): 600
- zoneNoList.1(ZONE번호리스트 1번째 항목): 2
- zoneNoList.2(ZONE번호리스트 2번째 항목): 3

호출에 성공하면 그 결과로 HTTP status가 '200 OK'인 응답과 함께 message body로 XML 문서 형식의 createAutoScalingGroupResponse 객체를 받습니다. 그 객체 내부의 returnMessage 태그의 값이 success이고 returnCode 태그 값이 0이면 성공한 것입니다.

Auto Scaling Group 생성 확인

방금 생성한 Auto Scaling Group이 의도대로 생성되었는지 확인하기 위해, 다음 요청 파라미터를 지정하여 getAutoScalingGroupList API를 호출합니다.

- autoScalingGroupName(오토스케일링그룹명): asg-1

호출에 성공하면 그 결과로 HTTP status가 '200 OK'인 응답과 함께 message body로 XML 문서 형식의 getAutoScalingGroupListResponse 객체를 받습니다. 그 객체 내부의 returnMessage 태그의 값이 success이고 returnCode 태그 값이 0이면 성공한 것입니다. 그 객체는 autoScalingGroupList라는 autoScalingGroup 객체들의 리스트 객체를 포함하고 있어서 생성된 Auto Scaling Group의 명세가 보입니다.

그리고 위와 같이 Auto Scaling Group이 생성되면 수십 분 이내에 Desired Capacity 만큼의 서버 인스턴스가 생성되어 서비스에 적용됩니다. Desired Capacity 만큼 서버 인스턴스가 만들어져서 상기 로드밸런서에 할당되면 정상입니다. 이 시나리오에서는 3대가 생성되어야 정상입니다.

수동 scaling

전 장에서 만들어진 Auto Scaling Group의 크기(그 그룹의 서버 인스턴스 수)를 수동으로 변경할 수 있습니다. 이를 위해 다음 요청 파라미터를 지정하여 setDesiredCapacity API를 호출합니다.

- autoScalingGroupName (오토스케일링그룹명): asg-1
- desiredCapacity: 5

성공하면 그 결과로 200 ok인 HTTP status와 함께 message body로 다음과 같은 XML 문서를 볼 수 있습니다. returnMessage 태그의 값이 success이면 성공한 것입니다. 그리고 나서 수 십 분 이내에 서버 인스턴스의 수가 Desired Capacity 만큼 되는 것을 관리 콘솔을 통해 확인할 수 있습니다.

Scaling 정책(policy) 생성

putScalingPolicy API를 호출해서 정책을 생성합니다.

scale-out을 할 policy와 scale-in을 할 정책 한 쌍을 생성합니다.

기존 capacity를.% 증가(scale-out)시킬 'out30p'라는 이름의 정책 생성
- policyName: out30p
- autoScalingGroupName: asg-1
- adjustmentTypeCode: PRCNT
- scalingAdjustment: 30
기존 capacity를.% 감소(scale-in)시킬 'in20p'라는 이름의 정책 생성
- policyName: in20p
- autoScalingGroupName: asg-1
- adjustmentTypeCode: PRCNT
- scalingAdjustment: -20

scaling 정책 생성 확인

getAutoScalingPolicyList API를 호출하여 'asg-1' 그룹에 설정된 정책을 조회합니다. 요청 파라미터는 다음과 같습니다.

- autoScalingGroupName: asg-1

Scaling 정책(policy) 수행

executePolicy API를 호출하여 사용자가 지정된 그룹의 정책을 수동으로 수행할 수 있습니다.

'out30p'라는 이름의 정책 수행

policyName: out30p

- autoScalingGroupName: asg-1

수행 후 Desired Capacity가 30% 증가한 것을 확인합니다.

'in20p'라는 이름의 정책 수행
- policyName: in20p
- autoScalingGroupName: asg-1

수행 후 Desired Capacity가 20% 감소한 것을 확인합니다.

액션(action) 스케줄 생성

미래의 특정 시각에 지정된 Auto Scaling 그룹이 자동으로 group size를 변경되도록 설정하고 싶다면 putScheduledUpdateGroupAction API를 호출합니다. 예를 들어, 주말이 되면 서비스 부하가 늘어나는 서비스가 있는데, 주말에만 서비스를 처리하는 서버 인스턴스의 수를 늘리고, 주말이 지나면 그 인스턴스 수를 줄여서, 사용료를 절감하고 싶을 때가 있습니다. 그렇다면 매주 금요일에 putScheduledUpdateGroupAction를 사용하여 Desired Capacity를 늘리고, 매주 월요일이 되면 Desired Capacity를 낮추도록 설정하면 됩니다.

짧은 시간에 스케줄에 의한 scaling 활동 여부를 확인을 위해 전에 생성한 Auto Scaling Group의 group size 변동을 15분마다 변경되게 다음과 같이 지정합니다.

매시 0분, 30분에 group size가. 되도록 Desired Capacity 설정

위와 같이 하기 위해 다음 요청 파라미터를 지정하여 putScheduledUpdateGroupAction API를 호출합니다.

- autoScalingGroupName (오토스케일링그룹명): asg-1
- scheduledActionName (스케줄액션명): sa-out
- desiredCapacity : 7
- recurrenceInKST (반복스케줄설정(한국시간존)): 0,30 * * * *
매시 15분, 45분에 group size가. 되도록 Desired Capacity 설정

위와 같이 하기 위해 다음 요청 파라미터를 지정하여 putScheduledUpdateGroupAction API를 호출합니다.

- autoScalingGroupName: asg-1
- scheduledActionName: sa-in
- desiredCapacity: 5
- recurrenceInKST: 15,45 * * * *

액션 스케줄 생성 확인

설정한 액션 스케줄을 조회하기 위해 다음 요청 파라미터를 지정하여 getScheduledActionList API를 호출합니다.

- autoScalingGroupName: asg-1

위와 같이 호출하면 asg-1 그룹에 설정된 스케줄들을 확인할 수 있습니다. 결과 XML 문서에서 scheduledUpdateGroupActionList 태그의 하위 태그로 scheduledUpdateGroupAction 태그들이 나열되어 있고 scheduledUpdateGroupAction 태그에 하위 항목의 각 스케줄의 명세가 기재되어 있습니다.

사용자는 관리 콘솔을 통해 매시 0분, 30분에 asg-1 그룹의 서버 인스턴스가 7대로 늘어나고, 매시 15분, 45분에는 asg-1 그룹의 서버 인스턴스가 5대로 변하는 것을 확인할 수 있습니다.

프로세스 보류: 스케줄에 따른 scaling action 프로세스 보류

Auto Scaling이 작동하기 위해 서버 생성(launch), 서버 반납(terminate)이나 스케줄에 따른 scaling action과 같은 여러 프로세스(진행 과정)가 존재합니다. 사용자는 이 프로세스들의 진행을 보류(suspend)할 수 있습니다.

이를 위해 다음 요청 파라미터를 지정하여 suspendProcesses API를 호출합니다.

- autoScalingGroupName: asg-1
- scalingProcessCodeList.1(scaling프로세스코드리스트): SCACT

스케줄 시각이 되어도 scaling action이 이루어지지 않는 것을 확인할 수 있습니다.

프로세스 재개: 스케줄에 따른 scaling action 프로세스 재개

전장에서 보류된 프로세스는 재개(resume)할 수 있습니다. 이를 위해 다음 요청 파라미터를 지정하여 resumeProcessesAPI를 호출합니다.

- autoScalingGroupName: asg-1
- scalingProcessCodeList.1: SCACT

scaling이 다시 수행되는 것을 확인할 수 있습니다.

Scaling 정책 삭제

deletePolicy API를 호출하여 정책을 삭제합니다. 요청 파라미터는 다음과 같습니다.

'out30p'라는 이름의 정책 삭제

policyName: out30p

- autoScalingGroupName: asg-1
'in20p'라는 이름의 정책 삭제
- policyName: in20p
- autoScalingGroupName: asg-1

액션 스케줄 삭제

이전 장에서 생성되어 스케줄을 삭제하기 위해 다음 요청 파라미터를 지정하여 deleteScheduledAction API를 호출합니다.

- autoScalingGroupName: asg-1
- scheduledActionName: sa-in

위와 같이 호출을 하면 지정된 asg-1 그룹의 지정된 스케줄 sa-in을 삭제합니다.

아직 삭제되지 않은 asg-1 그룹의 스케줄 sa-out을 삭제하기 위해 다음 요청 파라미터를 지정하여 deleteScheduledAction API를 호출합니다.

- autoScalingGroupName: asg-1
- scheduledActionName: sa-out

Auto Scaling Group 크기를 zero(0)로 변경

이미 생성된 Auto Scaling Group의 속성을 변경하기 위해 다음 요청 파라미터를 지정하여 updateAutoScalingGroup API를 호출합니다. 이 시나리오에서는 다음 장에서 asg-1 그룹을 삭제할 수 있도록 asg-1 그룹 소속의 모든 서버 인스턴스들을 반납하기 위해 Desired Capacity를 0으로 변경합니다. Auto Scaling Group의 그룹 크기가 0이어야 삭제 가능합니다.

- autoScalingGroupName(오토스케일링그룹명): asg-1
- desiredCapacity: 0
- minSize(최소 크기): 0
- maxSize (최대 크기): 0

주의: asg-1 그룹의 최소 크기는 1이므로 Desired Capacity만 0으로 변경하면 에러가 납니다. 따라서 반드시 updateAutoScalingGroup API를 호출할 때 Desired Capacity와 함께 최소 크기도 0으로 변경해야 합니다.

호출에 성공하면 그 결과로 HTTP status가 '200 OK'인 응답과 함께 message body로 XML 문서 형식의 updateAutoScalingGroupResponse 객체를 받습니다. 그 객체 내부의 returnMessage 태그의 값이 success이고 returnCode 태그 값이 0이면 성공한 것입니다.

Auto Scaling Group 삭제

asg-1 그룹을 삭제하기 위해 다음 요청 파라미터를 지정하여 deleteAutoScalingGroup API를 호출합니다.

- autoScalingGroupName(오토스케일링그룹명): asg-1

호출에 성공하면 그 결과로 HTTP status가 '200 OK'인 응답과 함께 message body로 XML 문서 형식의 deleteAutoScalingGroupResponse 객체를 받습니다. 그 객체 내부의 returnMessage 태그의 값이 success이고 returnCode 태그 값이 0이면 성공한 것입니다. 삭제 후 getAutoScalingGroupList 액션으로 확인이 가능합니다.

Launch Configuration 삭제

Launch Configuration은 그것을 참고하고 있는 Auto Scaling Group이 없어야 삭제 가능합니다. Lc-1 설정은 그것을 참고하고 있던 asg-1이 삭제되었으므로 삭제 가능합니다.

Launch Configuration을 삭제하기 위해 다음 요청 파라미터를 지정하여 deleteLaunchConfiguration API를 호출합니다.

- launchConfigurationName(론치 설정 명): lc-1

호출에 성공하면 그 결과로 HTTP status가 '200 OK'인 응답과 함께 message body로 XML 문서 형식의 deleteAutoScalingLaunchConfigurationResponse 객체를 받습니다. 그 객체 내부의 returnMessage 태그의 값이 success이고 returnCode 태그 값이 0이면 성공한 것입니다.

다른 서비스와의 연동

Auto Scaling은 클라우드 서버 서비스에 의존적인 서비스입니다. 이번 장에서는 Auto Scaling과 연동하는 여타 서비스(아래)와의 관계에 대해 설명합니다.

  • 로드밸런서
  • cloud 서버
  • user data (init-script)

Auto Scaling이 생성한 서버 인스턴스는 사용자가 직접 수동 생성하지 않았다는 것을 제외하고는 여느 서버 인스턴스와 별 다를 것이 없습니다. 따라서 그 생성된 서버 인스턴스와 연동 로드밸런서는 사용자가 직접 조작할 수 있습니다.

로드밸런서와의 연동

Auto Scaling은 로드밸런서(Load Balancer)와 연동할 수 있습니다. Auto Scaling Group을 생성할 때 연동할 로드밸런서를 지정하면, Auto Scaling Group 소속의 서버 인스턴스가 생성되어 서비스에 적용된 직후 지정된 로드밸런서에 할당(bind)됩니다. 그리고 Auto Scaling Group 소속 서버 인스턴스가 반납될 때, 첫 단계로 등록된 로드밸런서에서 할당 해제(unbind)되고 나서, 서버 반납 프로세스가 시작됩니다. Auto Scaling Group에 지정된 로드밸런서의 식별자는 로드밸런서 이름이므로 생성된 서버 인스턴스가 서비스 적용된 직후 지정된 이름의 로드밸런서에 자동 등록됩니다.

Auto Scaling Group 소속 서버 인스턴스의 헬스 체크(health check)는 로드밸런서를 이용해서 할 수도 있습니다. Auto Scaling Group의 healthCheckType 속성 값을 '로드밸런서(LOADB)'로 지정하면 됩니다. 서버의 서비스 적용 이후에도 서버 내의 서비스 프로그램이 실제 서비스에 적용되는 데 시간이 걸릴 수 있어서 (예를 들어, 서비스 프로그램 갱신) 로드밸런서의 헬스 체크 결과가 바로 정상으로 나오지 않을 수 있습니다. 이로 인한 오인(false-positive)을 막기 위해 헬스 체크를 사용자가 지정한 시간 동안 보류 (Auto Scaling Group의 healthCheckGracePeriod 속성 값으로 조정)할 수 있습니다.

로드밸런서에서 할당해제된 후 서버 인스턴스 반납 전 서버 연결 해제 대기

Auto Scaling Group 소속 서버 인스턴스를 반납하기 위해 첫 단계로 그 서버 인스턴스를 로드밸런서에서 할당 해제하는데 그 후 바로 서버 인스턴스를 반납(terminate)시키지 않습니다. 그 이유는 로드밸런서에서 할당 해제된 이후에도 서버 인스턴스가 처리하고 있는 TCP 연결이 있을 수 있기 때문입니다. Auto Scaling은 서버 인스턴스의 기존 연결이 모두 해제(connection draining)를 최대 15분 기다립니다.

로드밸런서와의 연동 관련 유의 사항

하나의 로드밸런서에 복수의 Auto Scaling Group의 서버들이 할당될 수 있나요?

하나의 Auto Scaling Group와 복수의 로드밸런서가 연동할 수 있고, 하나의 로드밸런서가 복수의 Auto Scaling Group에서 사용될 수도 있습니다.

하나의 Auto Scaling Group와 복수의 로드밸런서가 연동하게 하기 위해서는 Auto Scaling Group을 생성할 때, 연동할 로드밸런서로 복수의 로드밸런서 이름을 지정하면 됩니다. 하나의 Auto Scaling Group에 복수의 로드밸런서와 연동하는 경우는 보통 고 가용성(high availability)를 위해서입니다. 복수의 로드밸런서 중 하나에 전면 장애(failure)가 나도, 나머지 로드밸런서가 작동한다면, 서비스 전면 장애까지 이어지지 않을 것입니다. 그리고 클라우드 모니터링 연동 scaling을 할 때, 알람 이벤트 발생 여부는 연동하는 로드밸런서의 수는 상관이 없습니다. 왜냐하면 동적(dynamic) scaling에서 scaling 이벤트 발생 여부는 Auto Scaling Group 소속 서버 인스턴스의 부하로 결정되기 때문입니다.

물론 하나의 Auto Scaling Group에 복수의 로드밸런서와 연동하는 이유로 서비스 전면(front-end)에 있는 로드밸런서의 수를 늘려서 서비스 처리 능력(수용 가능한 동시 접속 수 증대 등)을 향상하려는 의도도 있습니다.

하나의 로드밸런서 이름이 복수의 Auto Scaling Group의 연동 로드밸런서 속성으로 지정될 수 있습니다. 하나의 로드밸런서가 복수의 Auto Scaling Group에서 사용되는 경우는 드물지만 이런 경우가 있을 수 있습니다.

특정 서비스를 담당하는 서버를 사용료 문제로 기존의 고가의 윈도우 서버에서 저가의 리눅스 서버로 변경하고 싶어할 수도 있습니다. 하지만 당장 리눅스 서버로 전면 교체하기에는 안정성이 걱정되어서, 일단 시험 삼아 리눅스 서버를 기존의 윈도우 서버와 함께 사용하여 안정성을 검증하고 싶어할 수 있습니다. 이럴 경우 윈도우 서버용 Launch Configuration를 속성으로 가진 Auto Scaling Group W와 함께 리눅스 서버용 Launch Configuration를 속성으로 가진 Auto Scaling Group X를 만들고, 그 두 Auto Scaling Group이 하나의 로드밸런서를 사용하게 합니다. 그러면 하나의 로드밸런서를 통해 들어오는 특정 서비스 요청은 Auto Scaling Group W 소속 서버 인스턴스와 Auto Scaling Group X 소속 서버 인스턴스로 분산 요청이 가게 됩니다. 보통 로드밸런서의 서비스 요청이 늘면 그 서비스 요청이 분산되어서 서버 인스턴스에 가게 되고, 따라서 Auto Scaling Group W와 Auto Scaling Group X 소속 서버 인스턴스 모두 부하가 늘어서 scaling이 되어야 할 상황이 되어 보통은 두 Auto Scaling Group모두 scale-out이 될 것입니다.

하지만 로드밸런서 알고리즘이 Round Robin(RR)이고, Auto Scaling Group 소속 서버 인스턴스 간의 성능 차이가 크다면, 서비스 요청이 늘더라도, 한 Auto Scaling Group 소속 서버 인스턴스의 부하는 별로 늘지 않지만, 다른 Auto Scaling Group 소속 서버 인스턴스에는 과부하가 걸려서, 그 Auto Scaling Group만 scale-out될 수 있습니다.

로드밸런서 알고리즘이 Least Connection(LC)이고, Auto Scaling Group 소속 서버 인스턴스 간의 성능 차이가 크다면, 성능이 좋은 서버 인스턴스를 가진 Auto Scaling Group은 요청을 더 빨리 처리할 것이고, 따라서 Least Connection 알고리즘에 의해, 성능이 더 좋은 서버 인스턴스를 가진 Auto Scaling Group로 서비스 요청이 더 많이 넘겨질 것입니다.

특정 Auto Scaling Group의 서버 인스턴스와 연동하는 로드밸런서에 Auto Scaling 서비스를 받지 않는 일반 서버를 등록할 수 있나요?

하나의 로드밸런서에 특정 Auto Scaling Group 소속의 서버 인스턴스들만 등록 가능한 것은 아닙니다. Auto Scaling 서비스 중인 서버가 아닌 일반적인 서버 인스턴스도 등록이 가능합니다. 그러한 서버 인스턴스들은 Auto Scaling Group 소속이 아니므로 당연히 Auto Scaling Group의 scale-in 상황에서도 반납되지 않습니다. 이러한 사용 케이스는 드물지만 미래의 Launch Configuration에서 사용될 새로 만든 내 서버 이미지를 시험하기 위해 그 이미지에서 생성한 서버 인스턴스를 AS와 연동하는 로드밸런서에 등록하는 경우 등이 있을 수 있을 것입니다.

특정 로드밸런서가 설정된 특정 Auto Scaling Group에 소속된 서버 인스턴스를 관리 콘솔의 로드밸런서 메뉴에서 삭제한 경우 어떻게 되나요?

Auto Scaling Group이 특정 로드밸런서와 연동하도록 설정을 하면 서버 인스턴스가 생성된 이후 서비스 적용 직후에 자동으로 로드밸런서에 등록됩니다. 하지만 그 이후 사용자가 임의로 그 서버 인스턴스를 연동하는 로드밸런서에서 삭제해도 됩니다. 만약 로드밸런서를 통해 health 체크를 하도록 설정했다면, 사용자가 임의로 로드밸런서에서 삭제한 서버 인스턴스는 로드밸런서를 통한 health 체크 대상에서 빠지게 됩니다. 심지어 사용자가 임의로 뺀 서버 인스턴스를 다시 그 로드밸런서에 등록해도 됩니다. 그러면 등록 이후는 다시 health 체크 대상이 됩니다.

하나의 scale-out 액션에 의해 복수의 서버 인스턴스가 생성되었는데, 서비스 적용 완료에 시간 차가 존재해서 한번에 서비스 적용이 되지 않는다면 어떻게 되나요?

서버 인스턴스 생성이 개시된 이후 Auto Scaling은 인스턴스가 서비스 적용이 완료되어 운영중(running) 상태가 되었는지 1분에 한번씩 확인합니다. 그 1분 안에 특정 Auto Scaling Group의 인스턴스들이 서비스에 적용되었다면 그 인스턴스들을 한번에 로드밸런서에 추가합니다. 따라서 인스턴스의 서비스 적용에 시간 차가 존재하면 로드밸런서 추가에도 시간차가 발생합니다.

예를 들어, 특정 Auto Scaling Group이 LAUNCH 프로세스에 의해 인스턴스 5대가 생성되고 있는데, 3 대가 7시 정각에서 7시 1분 사이에 서비스에 투입되었고, 나머지 2대는 7시 1분과 2분 사이에 투입되었다면, Auto Scaling 서브-시스템은 8시 1분에 그 3 대를 한꺼번에 동시에(all at once) 로드밸런서에 추가하고 나서, 그 추가가 완료된 이후 따로 나머지 2대를 로드밸런서에 한번에 추가합니다.

Auto Scaling 서비스 중인 서버와 연동하는 로드밸런서에 할당/할당해제 하려는데 그 로드밸런서가 변경 상태라면 어떻게 되나요?

Scale-out 액션을 실행하기 위해 서버를 새로 생성하고 나서 서비스에 적용된 직후, 로드밸런서에 할당하려는데 그 로드밸런서가 '적용 서버 변경' 또는 '설정 변경'과 같은 변경 중 상태라면 로드밸런서에 할당되지 못합니다. Auto-Scaling 서브-시스템은 10초에 한 번씩 로드밸런서가 변경 중인지 체크하고 로드밸런서가 정상 상태가 되었다면 할당합니다.

Scale-in 액션을 행하기 위해 서버를 반납하려 할 때, 그 서버들이 등록된 로드밸런서가 있다면 로드밸런서에서 그 서버 인스턴스를 삭제한 이후 (10분이 지나면 병렬로) 서버 반납 프로세스를 진행합니다. 그런데 로드밸런서가 '적용 서버 변경' 또는 '설정 변경'과 같은 변경 상태라면 로드밸런서에서의 삭제와 서버 반납 프로세스가 진행되지 못합니다. Auto-Scaling 서브-시스템은 1분에 한 번씩 로드밸런서가 변경 중인지 확인합니다. 만약 80분이 되도록 로드밸런서가 변경 중이라면 로드밸런서로부터의 할당 해제를 일단 포기하고 서버 인스턴스를 반납합니다. 그 후 로드밸런서가 계속 변경 중으로 남아 있던 장애가 정상 상태로 되돌아 오면 이미 반납된 서버 인스턴스는 자동 할당 해제됩니다.

연동하는 로드밸런서가 존재하지 않거나 중도에 로드밸런서가 삭제된다면 어떻게 되나요?

Auto Scaling Group을 생성할 때 지정한 로드밸런서는 생성 후 그 이름을 가진 로드밸런서를 삭제해도 문제 없습니다. 만약 Auto Scaling Group 소속의 서버 인스턴스가 생성되었는데, 지정된 이름의 로드밸런서가 존재하지 않는다면, 서버 인스턴스 생성에 성공해서 서비스에 적용되지만 로드밸런서 할당만 안될 뿐입니다. 심지어 삭제된 로드밸런서와 동일한 이름의 다른 로드밸런서를 나중에 생성하면, 그 후 생성되는 Auto Scaling Group 소속의 서버 인스턴스들은 그 로드밸런서에 할당됩니다. 연동할 로드밸런서 이름을 파라미터로 전달하면서 Auto Scaling Group을 생성할 때, 그 이름의 로드밸런서가 없어도 문제 없습니다. 위의 로드밸런서를 삭제했을 때처럼, Auto Scaling Group 소속 서버 인스턴스가 정상적으로 생성되어 서비스에 적용되지만 단지 로드밸런서 등록만 안될 뿐입니다.

클라우드 서버와의 연동

Auto Scaling 서비스 중인 서버 인스턴스에 반납 보호 설정 걸려 있을 때

Auto Scaling 서비스를 위한 서버 인스턴스가 생성된 이후 사용자는 그 서버 인스턴스에 관리 콘솔 등을 통해서 반납 보호 설정을 걸 수도 있습니다. 서버 관리 인터페이스를 통해서 그 서버를 반납하려 하면 반납 설정이 걸려 있어서 거부를 당하나, Auto Scaling에서는 예외적으로 반납 보호 설정이 걸려 있어도 무시하고 그 서버 인스턴스를 반납합니다.

Auto Scaling 서비스 중인 서버 인스턴스를 조작할 때

서버를 Auto Scaling용 사용자 인터페이스가 아닌 다른 인터페이스(클라우드 서버 API나 관리 콘솔)를 통해 조작할 수 있습니다. 각 조작의 결과는 다음과 같습니다.

  • 서버 정지: 사용자의 조작으로 서버가 정지되었거나 시스템 crash가 나서 정지가 되면 헬스(health) 체크를 통과(pass)하지 못하므로 수 분 후 서버 인스턴스의 문제가 있다고 보고 반납됩니다. 그 서버를 관리콘솔이나 API를 통해 시작시켜도 헬스(health)에 문제가 있다고 보고 서버를 반납합니다.
  • 서버 재시작: 사용자의 조작으로 또는 서버 crash로 인해 재시작이 되면 서버 헬스(health)에 문제가 있다고 보고 자동 반납이 됩니다.
  • 서버 반납: 서버를 사용자가 임의로 Auto Scaling용 사용자 인터페이스가 아닌 다른 인터페이스로 반납을 했다면, Auto Scaling Group의 Desired Capacity와 실제(actual) capacity가 차이가 나서 보통 10 초 이내에 Desired Capacity 수준을 유지하기 위해 새로운 서버 인스턴스가 생성됩니다.
  • 서버에 공인 IP 할당 또는 연동 로드밸런서가 아닌 다른 로드밸런서에 할당: 조작이 가능하며 유지가 됩니다. 만약 그 서버 인스턴스가 Auto Scaling의 액션을 위한 삭제 대상이 된다면, 일반 서버 인스턴스 반납 때와 마찬가지로 반납될 때 병렬로 공인 IP 할당해제와 로드밸런서 할당해제가 진행됩니다.
  • Auto Scaling Group 소속 서버 인스턴스가 반납 대상이 되어도 서버 상태가 '복제중' 또는 '설정중'이면 그것이 진행되는 동안에는 반납이 되지 않습니다.
  • 그 외에 'ACG 설정 변경'이나 '비밀번호 변경'과 같은 서버 인스턴스 운영 상태에 영향을 주지 않는 서버 관련 조작은 가능합니다.

Launch Configuration가 참고하고 있는 내 서버이미지를 삭제할 때

내 서버 이미지를 삭제하려고 하면 에러가 발생하며, 해당 Launch Configuration가 삭제된 이후 서버 이미지 삭제도 가능합니다.

Launch Configuration가 참고하고 있는 ACG(access control group)를 삭제할 때

ACG를 삭제하려고 하면 에러가 발생하며, 해당 Launch Configuration가 삭제된 이후 ACG 삭제도 가능하합니다.

Auto Scaling 서비스 중인 서버 인스턴스에 추가 스토리지가 붙어 있을 때

Auto Scaling 서비스를 위한 서버 인스턴스에 사용자가 추가 스토리지를 붙일 수 있습니다. 현재 정책상 서버 인스턴스에 추가 스토리지가 붙어 있으면, 그 스토리지를 명시적으로 삭제한 이후 서버 인스턴스 반납이 가능합니다. 하지만 Auto Scaling에서는 서버 반납 시 예외적으로 추가 스토리지와 서버 인스턴스를 한번에 반납합니다.

사용자 서버 계약 한도로 Auto Scaling이 되지 못할 때

현재 하나의 Auto Scaling Group 소속 서버 인스턴스는 최대 30개까지 생성 가능하나, 그 전에 사용자의 서버 계약 한도에 다다라서 더 이상 서버 인스턴스가 생성이 안될 수 있습니다. 기본 서버 인스턴스 생성의 계약한도는 계정당 50대이며, 사용자는 고객센터를 통해서 계약한도를 늘이도록 사전에 요청할 수 있습니다.

User Data (init-script)

Auto Scaling 되는 서버 인스턴스가 첫 부팅 후 저장한 설정을 적용을 위해 자동 리부팅이 되고 나서 서비스에 투입이 되는데, 리부팅 절차의 마지막 단계로 user data라고도 불리는 서버 init-script가 실행됩니다. User data는 전술한 바와 같이 Launch Configuration의 속성으로 지정되어 있습니다. 이 스크립트는 Launch Configuration를 생성할 때 BASE64로 인코딩(encoding)해서 그 내용을 문자열(string) 형식의 파라미터 값으로 전달해야 합니다. 그 스크립트 길이는 BASE64로 인코딩되었을 때는 21 KB 이내여야 하므로 encoding 전에는 16 KB 이하여야 합니다. 클라우드 서버에서 script내용 그대로 실행합니다. 따라서 실행할 스크립트 내용을 작성할 때 서버 OS에 문제를 일으키지 않도록 조심해야 합니다.

이 user data에 대한 유의 사항은 다음과 같습니다.

  • user data는 Linux에서는 root 권한으로 Windows에서는 관리자(administrator) 권한으로 실행됩니다.
  • Linux 서버에서는 그 script를 해독(interpret)할 프로그램이 설치되어 있으면, 어떠한 script도 user data로 설정해서 실행할 수 있습니다. Linux 환경에서는 script는 shebang('#!')으로 시작되고 그 다음에 interpreter의 경로가 지정되어 있어야 합니다. Script 서두에 Shebang라인이 없다면 source 명령으로 실행한 효과가 나타납니다.
  • Windows 서버에서는 현재 visual basic script만 user data로 실행이 가능합니다. Batch 모드로 실행됩니다.
  • CentOS 5.7에서 기본적으로 제공하는 script interpreter는 csh, bash, perl, python이 있습니다.
  • Linux 서버 이미지에 script interpreter를 추가하고 싶으면 내 서버 이미지를 만들 때 추가하면 됩니다.

부록

Auto-Scaling 관련 자원 사용 한계치

항목 이름 한계치
고객별 Auto Scaling Group 수 10
Auto Scaling Group당 로드밸런서 수 10
Auto Scaling Group당 zone 수 10
Auto Scaling Group의 max size 30
고객별 Launch Configuration 100
Launch Configuration당 ACG 수 5
Auto Scaling Group당 scheduled action 100
Auto Scaling Group당 scaling policy 100

Auto Scaling에서 사용되는 Date 데이터 타입의 날짜/시간 포맷

Auto Scaling에서 사용되는 Date 데이터 타입의 포맷은 ISO 국제 표준 ISO 8601을 준수합니다.

유효한 날짜 시간 포맷은 다음 예시와 같습니다.

- "2013-07-25T17:50:00+0900"
- “2013-07-25T08:50:00Z"
- "2013-07-25T17:50:00+09:00"
- “2013-07-25T17:50:00-09"

연월일(年月日)은 YYYY-MM-DD포맷으로 표기하고 시분초(時分秒)는 hh:mm:ss 포맷으로 표기합니다. 그리고 YYYY-MM-DD과 hh:mm:ss 사이에는 문자 'T'가 중간에 있어야 합니다 (공백 없이 대문자 'T'만). 그리고 끝에는 시간대(time zone) 관련 정보가 있어야 합니다. 국제 표준시(GMT/UTC)로 표기하고 싶으면 시분초 끝에 대문자 'Z'를 붙이면 됩니다. 지역 시간(local time)으를 표기하고 싶으면 국제 표준시와의 시간대 차이(offset)가 나는 시분(時分)을 +/-hhmm 형식으로 붙이면 됩니다.

예를 들어, 한국 표준시는 국제 표준시보다 9시간 빠르므로 '+0900'을 붙이면 됩니다. 위의 예시에서 (1)번은 한국 표준시 2013년 7월 25일 17시 50분 0초를 의미하고 (2)번은 그 시각을 국제 표준시로 환산한 값입니다. 시간대 표기는 위의 예시 (3)번과 같이 콜론(':')을 중간에 삽입하거나 (4)번과 같이 시간대 차이에서 분(minute) 관련 정보를 생략해도 됩니다.

자세한 정보는 아래 사이트를 참고합니다.

연관 정보 바로가기

아래 가이드에서 연관 정보를 확인할 수 있습니다.

""에 대한 건이 검색되었습니다.

    ""에 대한 검색 결과가 없습니다.

    처리중...