개요
Ncloud(네이버 클라우드) VPC 환경에서 AutoScaling 설정하는 방법을 정리해보겠습니다.
AutoScaling 서비스는 미리 등록한 설정에 따라 서버 수를 자동으로 증가 또는 감소시켜 안정적인 서비스를 유지하면서 비용을 절감할 수 있도록 해주는 서비스입니다.
그런데, 언제 서버 수를 증가, 감소 시킬 것인 가에 대한 이벤트 설정이 Classic 환경의 경우 오토스케일 그룹에 속한 서버들의 평균값을 기준으로 하지만, VPC 환경의 경우 이 방법 말고도 특정 서버를 지정해서 해당 서버를 기준으로 이벤트 설정을 할 수도 있습니다.
그래서 여기서는 사전에 준비된 서버를 기준으로 AutoScaling이 작동되는 것을 살펴보겠습니다.
기준 서버 생성
AutoScaling 이벤트 설정의 기준이 되는 서버 1대를 아래와 같이 미리 생성하겠습니다.
설정 순서
Auto Scaling 설정 순서를 요약하면 다음과 같습니다.
2. Auto Scaling Group 설정
3. Cloud Insight Monitoring Event Rule 설정
Launch Configuration 설정
Auto Scaling 설정은 우선 [Auto Scaling] - [Launch Configuration]에서 [Launch Configuration 생성] 버튼을 클릭하는 것으로 시작합니다.
서버 이미지 선택
서버 이미지는 Ncloud(네이버 클라우드) 에서 제공하는 기본 이미지를 선택할 수도 있고, 기존에 사용하던 서버로 만들어 둔 [내 서버 이미지]를 사용할 수도 있습니다. 여기서는 기본 이미지를 사용하는 것으로 하겠습니다.
⁃ CentOS 7.3, 7.8
⁃ Rocky Linux 8.6, 8.8
⁃ Ubuntu 16.04, 18.04, 20.04
Windows 서버 이미지 버전
⁃ Windows Server 2016 64bit English Edition
⁃ Windows Server 2019 64bit English Edition
서버 설정
스토리지 종류와 서버 타입 등을 선택합니다.
이름 설정
Launch Configuration의 이름을 입력합니다.
인증키 설정
인증키는 기존에 보유하고 있던 인증키를 이용해도 되고, 새로운 인증키를 설정해도 됩니다.
최종 확인
지금까지 설정한 내용이 이상 없는지 최종 확인을 하고 이상 없으면 [Launch Configuration 생성] 버튼을 클릭합니다.
Auto Scaling Group 설정
다음으로 Auto Scaling Group을 생성합니다. [Auto Scaling] - [Auto Scaling Group]에서 [Auto Scaling Group 생성] 버튼을 클릭합니다.
Launch Configuration 선택
위에서 생성했던 Launch Configuration을 선택합니다.
그룹 설정
여기서는 VPC와 Subnet 등의 네트워크 환경을 선택하고, 생성될 서버들의 이름과 최소, 최대 개수 등을 설정합니다.
- 서버이름 Prefix : 최대7자까지 지정할 수 있고, 나머지 이름의 뒷부분은 영문,숫자의 조합으로 무작위로 자동 생성됩니다.
- 서버 용량 : 최소, 최대, 기대 용량은 서버 대수를 의미하며 각각 0~30까지 입력 가능합니다.
-
쿨다운 기본값 : 새로운 서버가 생성되었다고 해도, init script 실행이나 업데이트 설치 등의 이유로 실제 서비스를 수행할 수 있을 정도로 준비되기까지는 시간이 소요될 수 있습니다. 즉, 쿨다운(Cooldown) 시간이란 실제 Scaling이 수행 중이거나 수행 완료된 이후에 모니터링 이벤트 알람이 발생하더라도 반응하지 않고 무시하도록 설정한 기간입니다.
값을 입력하지 않으면 기본값인 300초가 적용됩니다. - 헬스체크 보류기간 : 서버 인스턴스가 생성되어 상태가 ‘운영 중’으로 바뀌었더라도, 서버의 업데이트 설치 등 작업에 의해서 헬스 체크에 정상 응답하지 못하는 경우가 생길 수 있습니다.
이런 경우 헬스 체크 보류 기간을 지정하면 해당 기간 동안에는 헬스 체크에 실패하더라도 서버에 이상이 있다고 판단하지 않습니다.
값을 입력하지 않으면 기본값인 300초가 적용됩니다. - 헬스체크 유형 : 헬스체크 유형은 [서버]와 [로드밸런서] 중에서 선택할 수 있습니다.
로드밸런서 연결
- VPC 환경에서 로드밸런서를 생성하는 방법은 아래 문서를 참고하시면 됩니다.
네트워크 접근 설정
네트워크 접근에 필요한 ACG를 설정하고 선택합니다.
정책/일정 설정
정책과 일정을 여기서 바로 설정할 수도 있고 나중에 설정할 수도 있는데, 우선은 [정책 설정]에서 [서버 수 증가 정책]과 [서버 수 감소 정책]을 설정합니다.
통보 설정
서버가 생성될 때 또는 서버가 반납될 때 언제 통보를 받을 것인지 선택하고, 누가 언제 통보 받을 것인지 설정합니다.
통보 대상 설정
먼저 [통보대상 관리 그룹]을 선택하고, 다음으로 관리자와 통보 방법을 선택합니다.
[통보대상 관리 그룹]이 설정되지 않았을 경우에는 [통보대상관리] 버튼을 클릭해 통보를 받을 대상의 그룹을 설정합니다.
최종 확인
지금까지 설정한 Auto Scaling Group 내역을 확인하고 이상이 없으면 [Auto Scaling Group 생성] 버튼을 클릭합니다.
Event Rule 설정
지정한 서버를 모니터링 하다가 설정한 조건에 해당되면 즉, 지정한 Event가 발생하면 Auto Scaling 설정을 적용해 서버를 증가시키거나 감소시키기 위한 감시 규칙인 [Event Rule]을 설정합니다.
서버 증가 Event Rule 생성
VPC에서는 [Cloud Insight]로 모니터링을 하게 되므로 Event Rule 설정도 [Cloud Insight(Monitoring)] - [Configuration] - [Event Rule]에서 [Event Rules 생성] 버튼을 클릭합니다.
감시 상품 선택
Cloud Insight는 Server 뿐만 아니라 Load Balancer, Object Storage도 감시할 수 있는데 여기서는 처음에 생성했던 서버를 감시할 것이니 [Server(VPC)]를 선택합니다.
감시 대상 설정
맨 처음에 생성했던 서버를 선택합니다.
감시 항목 및 조건 설정
감시 항목 설정에서 [전체 보기]를 선택하고, [SERVER] 탭에서 [Metric ID]를 [cpu]로 검색한 후 평균 CPU 사용률 항목인 [SERVER/avg_cpu_used_rto]에서 [Level]과 [Condition], [Method], [Duration]을 선택합니다.
먼저 서버를 증가시키는 경우에 해당하는 감시 항목을 설정하겠습니다.
아래의 설정 내용은 “평균 CPU 사용률이 1분간 50% 이상일 경우 경고 수준으로 이벤트 통보를 한다“라는 설정입니다.
액션 설정
앞에서 설정한 이벤트가 발생했을 경우 어떤 액션을 취할 것인지 설정하게 되는데 앞에서 [Auto Scaling Group] 설정에서 생성했던 정책을 선택하면 됩니다.
여기서는 [CPU 사용률 50% 이상]인 경우이므로 서버를 증가시키는 정책을 선택합니다.
최종 확인
설정한 내용이 이상 없는지 최종 확인하고, 규칙 이름을 입력한 후에 [생성] 버튼을 클릭합니다.
서버 감소 Event Rule 생성
앞에서 생성한 [서버 증가 Event Rule]과 같은 방식으로 [서버 감소 Event Rule]을 생성합니다.
아래의 설정 내용은 “평균 CPU 사용률이 1분간 10% 이하일 경우 정보 알림 수준으로 이벤트 통보를 한다“라는 설정입니다.
액션 설정
여기서는 [CPU 사용률 10% 이하]인 경우이므로 서버를 감소시키는 정책을 선택합니다.
최종 확인
설정한 내용이 이상 없는지 최종 확인하고, 규칙 이름을 입력한 후에 [생성] 버튼을 클릭합니다.
Event Rule 생성 완료
서버 증가과 감소에 대한 Event Rule 2가지가 모두 생성된 것을 확인할 수 있습니다.
Stress Tool 설정
CPU 사용률에 따른 Auto Scaling 작동 여부를 테스트 하기 위해 서버에 Stress Tool을 설치해보겠습니다.
EPEL 리포지토리 설정
Stress Tool을 설치하기 위해서는 다음 명령어로 [EPEL 리포지토리]를 설정해야 합니다.
~# yum -y install epel-release
Stress Tool 설치
~# yum -y install stress
Stress Tool 실행
CPU 코어 개수 확인
CPU에 강제로 부하를 발생 시키기 위해서는 서버의 CPU 코어 개수를 확인해서 모든 코어에 부하를 발생시키는 것이 좋습니다.
CPU 코어 개수를 확인하는 방법은 아래 명령어를 입력하면 됩니다.
~# grep -c processor /proc/cpuinfo
명령어 테스트
CPU에 부하를 주는 명령어를 테스트 해보겠습니다.
~# stress --cpu 2 --timeout 60 --verbose
위 옵션의 내용은 다음과 같습니다.
- cpu: 몇 개의 코어에 부하를 발생 시킬 것인가
- timeout: 몇 초 동안 부하를 발생 시킬 것인가
- verbose: 상세 로그를 표시
CPU 부하 발생
부하 발생 테스트를 마쳤으니 실제 Auto Scaling 테스트를 위해 300초 즉, 5분 동안 부하를 발생 시켜보겠습니다.
~# stress --cpu 2 --timeout 300 --verbose
서버 증가 확인
Stress Tool로 부하를 발생 시키고 서버 리스트를 확인해보면 아래와 같이 Auto Scaling 설정에서 지정한 대로 서버가 생성되고 있는 것을 확인할 수 있습니다.
CPU 사용률 확인
[Cloud Insight]에서 서버 사용률을 확인해 보면 아래와 같이 5분간 CPU 사용률이 100%까지 올라간 것을 확인할 수 있습니다.
서버 반납 확인
Stress Tool로 부하를 발생 시키도록 설정한 5분이 지난 후에 서버 리스트를 보면 Auto Scaling으로 생성되었던 서버가 반납되고 있는 것을 확인할 수 있습니다.
이벤트 발생 확인
[Cloud Insight] - [Event]에서 서버 증가, 감소 관련 이벤트가 제대로 발생했는지 아래와 같이 그래프와 리스트로 확인할 수 있습니다.
이벤트 통보 확인
이벤트 통보에서 설정한 대로 아래와 같이 Email로 Auto Scaling 이벤트 발생과 완료에 대한 통보 메일이 도착한 것을 확인할 수 있습니다.
서비스 제한사항
Auto Scaling 설정과 서버 스펙 등에 대한 제한 사항을 정리해보겠습니다.
스펙 및 서비스 환경 제한 사항
- 총 디스크 사이즈 150GB 이하 서버만 가능
- Windows OS는 Windows 2016. 2019만 지원
- 내 서버 이미지의 경우, 원본 서버의 부팅 디스크 크기가 50GB인 경우만 지원(100GB 디스크에 대해서는 추후 지원 예정)
설정 제한 사항
- 고객별 생성 가능한 Auto Scaling Group 최대 수: 10
- 고객별 생성 가능한 Launch Configuration 최대 수: 100
- Auto Scaling Group당 생성 가능한 스케줄(Scheduled Action) 최대 수: 100
- Auto Scaling Group당 생성 가능한 Scaling Policy 최대 수: 10
- Auto Scaling Group당 생성 가능한 최대 서버 수: 30대
- Auto Scaling Group당 연결 가능한 Load Balancer 최대 수 : 10
상세 모니터링
Ncloud(네이버 클라우드) 에서는 기본 모니터링 외에 [상세 모니터링]도 지원하는데, [상세 모니터링]에서는 좀 더 자세하고 다양한 모니터링 항목 (Extended Metric)을 지원합니다.
예를 들어 CPU 사용과 관련한 모니터링 항목에서도 아래와 같이 [CPU idle ratio average] 항목들도 확인할 수 있습니다.
또한, 위와 같이 [Server] 탭에서는 CPU들의 평균 값을 모니터링할 수 있는 것에 비해, 상세 모니터링을 적용하면 아래와 같이 [CPU] 탭에서 CPU 코어별로 각각 모니터링을 할 수도 있습니다.
상세 모니터링 설정
상세 모니터링을 적용하는 방법은 서버를 선택하고 [서버 관리 및 설정 변경] 메뉴에서 [상세 모니터링 설정 변경] 메뉴를 선택합니다.
상세 모니터링 신청
상세 모니터링 신청 팝업에서 [예] 버튼을 클릭하면 상세 모니터링이 적용됩니다. 상세 모니터링 신청 후 실제 데이터가 수집되기까지는 약간의 시간이 소요되므로 잠시 기다렸다 확인해보면 됩니다.
용어 정리
Auto Scaling에서 사용되는 주요 용어들을 정리해보겠습니다.
| 용어 | 설명 | |
|---|---|---|
| Scale-in / Scale-out | Auto Scaling Group을 생성하여 고객이 설정한 Policy에 따라 사용하고 있는 가상 서버의 자동 확장(Scale-out) 및 자동 축소(Scale-in)하도록 제공합니다. | |
| Auto Scaling Group | 여러 개의 서버 인스턴스들을 Auto Scaling Group 이라는 하나의 그룹으로 묶어 놓게 됩니다. | |
| Launch Configuration | Auto Scaling Group에서 가상 서버를 시작 구성하는 데 사용하는 템플릿입니다. Auto Scaling Group을 생성할 때는 Launch Configuration을 지정해야 합니다. | |
| Auto Scaling Group의 최소 용량/최대 용량 | Auto Scaling Group의 최소/최대 서버 수를 말합니다. 최소 서버 수의 경우, 항상 이 값과 같거나 이 값보다 더 큰 서버 수가 유지됩니다. 서버를 한 대도 보유하지 않을 수 있게 하려면 0으로 설정합니다. | |
| 기대 용량 (Desired Capacity) | 서버의 수는 기대 용량값에 따라서 조정됩니다. 이 값은 최소 용량 이상, 최대 용량 이하여야 합니다. 이 값이 지정되어 있지 않으면 초기에 최소 용량만큼 서버를 생성합니다. | |
| 쿨다운 기본값(초) (Default Cooldown) | Default Cooldown(초) 새로운 서버가 생성되었다고 해도, Init-Script 실행이나 업데이트 설치 등의 이유로 실제 서비스를 수행할 수 있을 정도로 준비되기까지는 시간이 소요될 수 있습니다. 쿨다운(Cooldown) 시간이란 실제 Scaling이 수행 중이거나 수행 완료된 이후에 모니터링 이벤트 알람이 발생하더라도 무시하도록 설정한 기간입니다. | |
| 헬스체크 | Auto Scaling Group의 가상 서버에 주기적인 상태 확인을 수행하여 상태가 비정상인 가상 서버를 식별하도록 Health Check를 합니다. | |
| 헬스체크 보류 기간 | 서버가 생성되어 ‘운영중’으로 변경되었더라도 서버의 업데이트 설치 등 작업에 의해서 헬스 체크에 정상 응답하지 못하는 경우가 생길 수 있습니다. 이런 경우 헬스 체크 보류기간을 지정하면 해당 기간 동안에는 헬스 체크에 실패하더라도 서버 헬스에 이상이 있다고 판단하지 않습니다. | |
| 헬스체크 유형 | 서버와 Load Balancer 둘 중에 선택할 수 있습니다. Auto Scaling Group 설정에서 Load Balancer 이름을 지정한 경우에는 헬스 체크 유형 역시 Load Balancer로 설정합니다. 이런 경우 Auto Scaling은 Load Balancer 헬스 체크 방식과 기준에 따라 서버의 상태를 판단합니다. | |
| 반납 정책 | Auto Scaling 과정에서 추가된 서버에 대한 Scale-in 작업에 대해, 고객이 API 질의 형식으로먼저 반납할 서버를 지정할 수 있습니다. 기본 설정은 먼저 생성된 서버부터 반납합니다. | |
| Policy | Auto Scaling이 일어나는 방식을 정의하고 있는데, 이를 ‘Policy’로 정의하고 있습니다. Auto Scale-out 이 발생할 때, 몇 대의 가상 서버를 늘릴 것인지, 반대로 Scale-in이 발생할 때 몇 대의 가상서버를 줄일 것인지를 정의합니다. 대수로 정의할 수 도 있고, %로 정의할 수도 있습니다. | |
| Basic Metric | 기본적으로 제공되는 모니터링 항목 | |
| Extended Metric | 상세모니터링을 신청하면 제공되는 모니터링 항목 |
참고 URL
- Ncloud(네이버 클라우드) Auto Scaling 가이드
- Classic 환경에서 Auto Scaling 설정하기
- Cloud Insight Basic/Extended Metric 정리
문서 업데이트 내역
| 날짜 | 내용 |
|---|---|
| 2022-06-20 | 문서 최초 생성 |
| 2023-09-05 | 로드밸런서 연결하는 방법 안내 추가, 지원하는 서버 이미지 정보 업데이트 |