네이버 클라우드 실습12 - Auto Scaling + Cloud insight(Monitoring)

준비물 : VPC, Subnet, ACG 등이 미리 만들어져 있어야 함.

모든 IP, 모든 포트 열어둔 상태

 

Auto Scaling을 통해 서버를 특정 조건에서 생성하거나 반납할 수 있다.

Auto Scaling 설정 후 Cloud insight(Monitoring)를 통해서 Event 발생(CPU 과부화) 시 서버가 생성되고 반납 되는지 확인한다.

1. Launch Configuration 생성

서버가 생성될 때 어떻게 생성할 것인지 정한다.

Auto Scaling -> Launch Configuration -> Launch Configuration 생

기본 이미지

부팅 디스크 크기 : 50GB

이미지 타입 : OS

OS 이미지 타입 : CentOS

서버 이미지 이름 : centos-7.8-64

스토리지 종류 : SSD

서버 타입 : Standard

Init Script : 선택 없음

Launch Configuration 이름 : auto-launch

인증키 설정 : 보유하고 있는 인증키를 사용하거나 새로운 인증키 생성

최종 확인 후 Launch Configuration 생성

2. Auto Scaling Group 생성

Auto Scaling -> Auto Scaling Group -> Auto Scaling Group 생성

Launch Configuration 선택

• Auto Scaling Group 이름 : auto-test-group
• VPC : test
• Subnet : test-subnet
• 서버 이름 : auto
• (아래 그림과 다름)
• 최소 용량 : 1
• 최대 용량 : 5
• 기대 용량 : 3
• 쿨다운 : 100
• 헬스 체크 보류 기간 : 100
• 헬스 체크 유형 : 서버

네트워크 접근 설정

정책/일정 설정

정책 설정

• 서버 수 증가 정책
  • 정책 이름 : increase
  • Scaling 설정 : 증감변경, 1 server
• 서버 수 감소 정책
  • 정책 이름 : decrease
  • Scaling 설정 : 증감변경, 1 server

통보 설정

• 통보 내역
  • 서버 생성, 서버 반납
• 담당자 설정
• 혹시 통보 대상이 없을 경우 통보대상관리를 눌러서 등

최종 확인 후 Auto Scaling Group 생성

생성이 완료되면 Server가 하나 생성중인 것을 확인 할 수 있다.

3. Event Rule 설정

Cloud Insihgt를 활용하여 Event rule을 설정하면 서버 등의 모니터링 도중 특정 Event 발생 시 Auto Scaling 정책을 적용해 서버를 증감할 수 있다.(Cloud Insight 상품을 이용 중이 아닌 경우 신청을 눌러서 구독)

 

감사 대상 설정

Cloud Insight(Monitoring) -> Configuration -> Event Rule -> Event Rule 생성

감시 상품 선택 -> Server(VPC)

이번 실습에서는 서버의 CPU 평균 사용량만을 기준으로 증감 설정을 하기 위해 Server(VPC)를 선택한다.

여러 상품을 이용 중인 경우 항목이 많을 수 있다. Auto Scaling Group이 생성된 이후 충분한 시간이 지나지 않았다면 항목이 없을 수도 있다.

감시 대상 설정 -> 전체 보기(현재 사용중인 모든 서버가 나온다.)

Auto Scaling 설정 이후 자동으로 생성된 서버를 선택한다.(서버 이름은 정해준대로 auto로 시작한다.)

감시 항목 설정 -> 전체 보기

CPU 평균 사용량이 50% 이상이고, 1분 이상 유지될 경우를 조건으로 설정한다. 

• 메트릭 : SERVER/avg_cpu_used_rto 
• 레벨 : Warning
• 조건 : >= 50
• 집약 방법 : AVG
• 지속 시간 : 1

액션 설정 -> 알림 메시지 발송

통보 대상 선택

액션 설정 -> Auto Scaling 정책

• Auto Scaling Group 이름 : auto-test-group
• 정책 이름 : increase

기본 정보

• 룰 이름 : increase-test

Event Rule(increase-test) 생성 완료

서버를 반납하는 조건을 설정한 Event Rule을 하나 더 생성해야 한다.

감시 항목 설정 -> 전체 보기

CPU 평균 사용량이 10% 이하고, 1분 이상 유지될 경우를 조건으로 설정한다. 

• 메트릭 : SERVER/avg_cpu_used_rto 
• 레벨 : Warning
• 조건 : <= 10
• 집약 방법 : AVG
• 지속 시간 : 1

액션 설정 -> 알림 메시지 발송 설정 -> Auto Scaling 정책

• Auto Scaling Group 이름 : auto-test-group
• 정책 이름 : decrease

기본 정보

• 룰 이름 : decrease-test

Event Rule(decrease-test) 생성 완료

 

Event Rule에 2개의 Rule이 생성되었다.

 

4. 공인 IP 신청 후 MobaXterm으로 서버 접속

생성된 서버는 공인 IP가 없기 때문에 공인 IP를 신청한다.

Server -> Public IP -> 공인 IP 신청

새로 만들어진 서버를 선택

생성된 공인 IP로 MobaXterm을 이용해 root 계정으로 서버에 접속한다.

5. 과부하 테스트

epel 패키지 설치

yum -y install epel-release

stress 패키지 설치

yum -y install stress

CPU 개수 확인

grep -c processor /proc/cpuinfo

CPU : 2개

stress 명령어

--cpu : 몇 개의 CPU 코어에 부하를 발생 시킬 것인지

--timeout : 몇 초 동안 부하 발생시킬 것인지

--verbose : 로그 표시

• 3000초 동안 CPU 2개에 부하를 발생시킨다.(아래 그림과 다름)
• 시간을 일부러 넉넉하게 설정

stress --cpu 2 --timeout 3000 --verbose

6. 모니터링

Cloud Insight(Monitoring) -> Dashboard -> Service Dashboard / Server(VPC) 선택

CPU Utilization Average를 보면 사용량이 100%를 유지하는 것을 확인할 수 있다.

서버가 3대로 증가하였다.

통보 설정을 한 경우 이메일로 알려준다.

서버가 모두 운영중으로 바뀐 뒤 과부하를 없앤다.

CTRL + C 를 눌러 실행 중인 stress를 종료한다.

CPU 사용량이 다시 0% 가까이로 감소하였다.

이게 왜 서버가 반납이 안되는지 생각을 해봤는데, 로드 밸런서를 쓰지 않기 때문인 것 같다.

사실 Auto Scaling은 로드 밸런서와 함께 써야 한다. 서버가 서로 유기적으로 연결되어 있지 않으면 서버를 아무리 추가해도 부하는 나눌 수 없기 때문이다. 로드 밸런서를 써야 서버 수가 늘어났을 때 부하를 분배해 줄 수 있다.