1. Auto Scaling
- Auto Scaling은 특정 이벤트나 시간대에 자동으로 서버 수를 늘리거나 줄여 수요 변화에 탄력적으로 대응할 수 있도록 돕는 서비스입니다.
- 모니터링 기반, 스케줄링 기반으로 서버 수를 자동으로 늘리거나 줄이기 때문에 서버를 미리 생성해둘 필요가 없어 인프라 운영 비용을 절감할 수 있습니다.
1-1. 스케줄링 정책
1. 모니터링 기반
- 실시간으로 시스템 지표 및 성능 데이터를 수집하고 이 정보를 기반으로 리소스를 동적으로 조정합니다.
- 이는 트래픽 패턴이 예측하기 어려운 경우에 유용합니다.
- 예시: CPU 사용률, 메모리 사용률, 네트워크 트래픽 등의 메트릭을 모니터링하고, CPU 사용률이 80%를 초과하면 자동으로 스케일 업을 수행하여 성능을 최적화합니다.
2. 스케줄링 기반
- 일반적으로 예측 가능한 트래픽 패턴이 있는 경우에 유용합니다.
- 예시: 매주 월요일 오전 9시부터 오후 5시까지 스케일 업을 수행하여 주중 업무 시간에 대응하거나, 큰 프로모션 이벤트가 예정된 날짜에 스케일 업을 수행합니다.
3. 관리자가 집접 수정
- 사용자가 직접 스케일링 정책을 설정하고 관리합니다.
- 사용자가 원하는 시점에 리소스를 추가하거나 축소할 수 있습니다.
- 예시: 사용자가 애플리케이션에 대한 트래픽 예측을 기반으로 스케일 업 또는 스케일 다운 명령을 수동으로 실행하거나, 클라우드 서비스 제어판을 통해 리소스 크기를 수동으로 조정합니다.
2. Auto Scaling 생성
- Auto Scailng으로 Web서버를 생성할거니 시작 전에 앞서 생성했던 Web01과 Web02 서버를 반납하겠습니다.
1. Service -> Auto Scaling을 클릭합니다.
2. Auto Scaling에 어떤 서버를 쓸 건지 구성을 해줘야 합니다. Launch Configuration 생성을 클릭합니다.
3. NCP에서 기본적으로 제공하는 이미지나 사용자가 생성해둔 이미지를 사용할 수 있습니다.
https://angrycloud.tistory.com/28에서 생성했던 Web 이미지를 사용하겠습니다.
4. 서버에 대한 설정도 할 수 있습니다.
스토리지는 SSD를 사용하고 서버 타입이나 사양도 그대로 사용하겠습니다.
NCP의 기본 이미지에 Init Script를 사용해서 Web서버를 생성할 수도 있지만 이미 Web서버 이미지를 사용중이므로 그냥 넘어가겠습니다.
5. Launch Configuration의 이름을 정하고 다음을 클릭합니다.
6. 인증키도 처음에 생성한 인증키를 사용하겠습니다.
7. 이 Launch Configuration로 생성될 서버의 설정들을 확인하고 Launch Configuration 생성을 클릭합니다.
8. Launch Configuration이 생성된걸 확인하고 Auto Scaling Group을 클릭합니다.
9. Auto Scaling Group 생성을 클릭합니다.
10. 방금 전에 생성한 Launch Configuration을 생성하고 다음을 클릭합니다.
11. 각종 설정을 해주고 다음을 클릭합니다.
# 식별하기 쉬운 이름으로 해줍니다.
Auto Scaling 그룹 이름 : test-web-acg
# 서버가 배치될 VPC를 선택합니다. 전 test vpc만 생성했으므로 test를 선택했습니다.
VPC : test
# 서버가 배치될 Subnet을 선택합니다. Web서버를 생성할 예정이니 Public을 선택했습니다.
Subnet : test-public-subnet
Auto Scaling으로 생성될 서버의 이름을 정합니다.
name-[영문10자][숫자3자]로 설정한 Prefix를 제외한 나머지 영문,숫자는 무작위로 자동 생성됩니다.
서버 이름 Prefix : web-ac
# 최소 유지되어야 할 서버의 수를 지정합니다.
최소 용량 : 2
# 서버를 최대 몇대까지 늘릴건지 수를 정합니다.
최대 용량 : 4
# Auto Scaling이 처음 동작할때 생성될 서버의 수 입니다.
기대 용량 : 2
# Auto Scaling 정책에 의하여 생성되는 서버들에 대해 상세 모니터링 옵션을 적용합니다.
# 활성화하면 수집된 데이터를 1분 주기로 확인할 수 있으며, Cloud Insight 요금 정책에 따라 과금됩니다.
상세 모니터링 적용 : 자유
# 새로운 서버가 생성되었다고 해도, init script 실행이나 업데이트 설치 등의 이유로 실제 서비스를 수행할 수 있을 정도로 준비되기까지는 시간이 소요될 수 있습니다.
# 실제 Scaling이 수행 중이거나 수행 완료된 이후에 모니터링 이벤트 알람이 발생하더라도 반응하지 않고 무시하도록 설정한 기간입니다.
# 디폴트값 300초를 넣겠습니다
쿨다운 기본값(초) : 300
# 서버가 생성되어 상태가 ‘운영중’으로 변했더라도, 서버의 업데이트 설치 등 작업에 의해서 헬스 체크에 정상 응답하지 못하는 경우가 생길 수 있습니다.
# 헬스 체크 보류 기간을 지정하면 해당 기간 동안에는 헬스 체크에 실패하더라도 서버 헬스에 이상이 있다고 판단하지 않습니다.
# 디폴트값 300초를 넣겠습니다
헬스 체크 보류 기간 : 300
# 서버와 로드밸런서를 선택할 수 있습니다.
# Auto Scaling으로 웹서버를 생성할 것이니 로드밸런서 연결을 위해 로드밸런서를 선택하겠습니다.
# [그룹 설정]에서 로드밸런서를 지정한 경우에는 헬스 체크 유형 역시 로드 밸런서로 설정합니다.
# 이런 경우 Auto Scaling은 Load Balancer 헬스 체크 방식과 기준에 따라 서버의 상태를 판단합니다.
헬스 체크 유형 : 로드밸런서
# 로드밸런서 타겟을 설정합니다.
# https://angrycloud.tistory.com/30에서 생성했던 ALB의 타겟을 그대로 사용하겠습니다.
# Auto Scaling으로 생성되는 서버들은 선택한 타겟에 자동으로 추가됩니다.
Target Group : test-web-tg
12. 웹서버를 생성할 것이니 서브넷은 퍼블릭을 선택하고 다음을 클릭하겠습니다.
13. 스케줄링 기반의 일정 설정과 모니터링 기반의 정책 설정을 선택 할 수 있습니다.
여기서는 모니터링 기반의 정책 설정을 선택하겠습니다.
# Auto Scaling을 언제 수행할 것인지 정합니다.
# 정책 설정은 특정 이벤트 발생 시 Auto Scaling을 수행하고, 일정 설정은 특정 시간대에 Auto Scaling을 수행합니다.
# 여기서는 정책 설정을 사용해보겠습니다.
일정 설정 : 정책 설정
# 서버 수 증가 정책은 모니터링 이벤트가 발생하면 가상 서버를 생성하는 역할을 수행합니다.
서버 수 증가 정책
# 어떤 정책인지 알기 쉽게 정합니다.
정책 이름 : web-cpu-50-over
# Scaling 정책은 3가지 방식으로 설정할 수 있습니다.
# 증감변경: 현재 그룹 크기와 상관없이 지정한 서버 대수를 직접 추가 또는 삭제하는 방법입니다.
# 비율변경: 현재 그룹 크기 대비 일정한 비율(%)로 서버를 증감시키는 방법입니다.
# 고정값: 그룹 크기를 지정한 값으로 고정시키는 방법입니다.
# 증감변경을 선택하고 1대씩 증가시키기 위해 1로 하겠습니다.
Scaling 설정 : 증감변경, 1
# Scaling 설정을 비율변경으로 선택했을 때반 활성화 됩니다.
최소 조정 폭
# Scaling이 수행되면 추가적인 알람이 발생하더라도 이에 반응하지 않도록 설정된 시간 입니다.
# Scaling의 수행이나 완료 여부에 상관없이 추가로 발생한 이벤트에 대해서 아무 동작을 하지 않게 됩니다.
# 디폴트값 300을 주겠습니다
쿨다운(초) : 300
# 서버 수 감소 정책은 모니터링 이벤트가 발생하면 가상 서버를 반납하는 역할을 수행합니다.
서버 수 감소 정책
# 어떤 정책인지 알기 쉽게 정합니다.
정책 이름 : web-cpu-50-over
# Scaling 정책은 3가지 방식으로 설정할 수 있습니다.
# 증감변경: 현재 그룹 크기와 상관없이 지정한 서버 대수를 직접 추가 또는 삭제하는 방법입니다.
# 비율변경: 현재 그룹 크기 대비 일정한 비율(%)로 서버를 증감시키는 방법입니다.
# 고정값: 그룹 크기를 지정한 값으로 고정시키는 방법입니다.
# 증감변경을 선택하고 1대씩 감소시키기 위해 1로 하겠습니다.
Scaling 설정 : 증감변경, 1
# Scaling 설정을 비율변경으로 선택했을 때반 활성화 됩니다.
최소 조정 폭
# Scaling이 수행되면 추가적인 알람이 발생하더라도 이에 반응하지 않도록 설정된 시간 입니다.
# Scaling의 수행이나 완료 여부에 상관없이 추가로 발생한 이벤트에 대해서 아무 동작을 하지 않게 됩니다.
# 디폴트값 300을 주겠습니다
쿨다운(초) : 300
14. 이벤트 발생시의 통보 설정을 합니다.
# 서버가 생성될때 알람을 보냅니다.
서버성생될 때 : 선택
# 서버가 반납될때 알람을 보냅니다.
서버반납될 때 : 선택
# 알람을 받을 대상자를 선택합니다.
# https://angrycloud.tistory.com/32에서 생성했던 웹관리자를 선택하고 추가를 클릭합니다.
통보설정 : 웹관리자
15. 설정했던 정보들을 확인하고 Auto Scaling Group 생성을 클릭합니다.
16. Auto Scaling Group이 생성되었습니다.
이제 Server 탭으로 가보겠습니다.
17. Auto Scaling Group에서 기대값을 2로 설정했던대로 서버 2대가 생성중이며 이벤트 발생 알람이 왔습니다.
18. 서버가 운영중으로 바뀜과 같이 이벤트 완료 알람도 왔습니다.
19. Auto Scaling 설정 중 선택했던 LB 타겟을 확인해보면 생성된 서버들이 자동으로 들어가 있습니다.
이 ALB는 https://angrycloud.tistory.com/30에서 DNS와 연동해놨으니 도메인으로 접속을 해보겠습니다.
20. 정상적으러 접속이 되었습니다.
이렇게 Auto Scaling으로 새로운 서버가 생성되어도 자동으로 ALB의 타겟에 등록되기 때문에 수동으로 등록해줄 필요가 없습니다.
3. Cloud Insight 연동
- Auto Scaling Group에서 서버 증감과 감소에 대한 정책을 만들었었습니다.
- 하지만 Auto Scaling Group 자체에 모니터링 기능은 없으므로 정책이 실행되기 위한 트리거를 설정한 필요가 있습니다.
- Cloud Insight에서 이벤트를 생성 후 Auto Scaling Group의 정책과 연동을 해보겠습니다.
1. Service -> Management & Governance -> Cloud Insight -> Configuration -> Event Rule을 클릭합니다.
2. Event Rules 생성을 클릭합니다.
3. https://angrycloud.tistory.com/33에서는 Auto Scaling 서비스를 생성하지 않아서 Auto Scaling Group(VPC) 카테고리가 없었지만 지금은 Auto Scaling을 생성했기 때문에 카테고리가 생겼습니다. 선택 후 다음을 클릭합니다.
4. 감시 대상 설정이 보이는데 마찬가지로 https://angrycloud.tistory.com/33에서 생성했던 test-web 그룹이 보이지 않습니다.
test-web 그룹은 Server(VPC) 카테고리에서 생성했기 때문입니다. 현재 보이는 그룹들은 Auto Scaling Group(VPC)에서 생성한 그룹들이기에 마찬가지로 Server(VPC) 카테고리에서는 보이지 않습습니다.
Auto Scaling Group 1개만 감시 대상에 넣을 것이기 때문에 감시대상 그룹을 만들지는 않고 보유 리소스 전체를 클릭하겠습니다.
5. 생성했던 Auto Scaling Group Target이 보입니다.
선택하고 다음을 클릭합니다.
6. 템플릿도 Auto Scaling Group(VPC)용으로 새로 생성해줘야 합니다.
템플릿 생성을 클릭합니다.
7. cpu 사용률 50% 초과와 미만, 2개의 템플릿을 만들어야 합니다. 우선 초과에 대한 템플릿을 생성하겠습니다.
이름을 적어주고 메트릭은 avg_cpu_used_rto을 선택, 다음을 클릭합니다.
8. 조근을 50 초과로 잡아주고 저장을 클릭합니다.
9. 생성한 템플릿을 선택하고 다음을 클릭합니다.
10. 액션 설정이 나왔습니다. Auto Scaling Group 설정에서 서버 생성과 반납 시 알람은 설정을 했었으니 바로 Auto Scaling 정책 탭으로 가겠습니다.
생성했던 Auto Scaling Group을 선택하고 정책이름을 누르면 Auto Scaling Group 생성시 만들었던 정책 목록이 나옵니다.
현재 선택한 템플릿은 CPU 사용률 50%를 넘었을 시 였으니 web-cpu-50-over를 선택하겠습니다.
이제 CPU 사용률이 50%가 넘어간다면 Cloud Insight에서 이벤트를 감지하고 여기에 연동된 Auto Scaling Group의 정책이 실행되어 서버가 생성되게 됩니다.
11. 이벤트 룰의 이름을 정하고 설정내역 확인 및 생성을 클릭합니다.
12. Auto Scaling Group의 이벤트 룰이 생성되었습니다.
13. 서버 생성에 대한 이벤트를 만들었으니 서버 반납에 대한 이벤트를 추가로 생성하겠습니다.
CPU 사용률 50 미만에대한 템플릿을 생성합니다.
10. 생성한 템플릿을 선택하고 다음을 클릭합니다.
11. 이번에는 Auto Scaling 정책에서 web-cpu-50-down을 선택합니다.
이제 CPU 사용률이 50 밑으로 내려가면 해당 Auto Scaling 정책과 연동되어 서버가 반납 됩니다.
12. 이벤트 룰의 이름을 정하고 생성을 클릭합니다.
13. 서버 생성, 반납에 연동 될 이벤트가 전부 만들어졌습니다. 이제 서버에 부하를 줘서 서버가 제대로 생성되고 반납되는지 확인해보겠습니다.
4. 서버 증감 및 감소
1. 서버에 부하를 주기위해 오토스케일링으로 생성된 서버중 한 곳에 접속해야 합니다.
공인IP가 달린 Bastion 서버를 통해 접속하거나 서버에 공인IP를 추가해서 직접 접속합니다.
Public IP : https://angrycloud.tistory.com/22
2. 서버에 부하를 주기위해 stress를 설치합니다.
# stress를 설치하기 위해서는 EPEL 저장소가 필요합니다.
# EPEL 저장소를 시스템에 추가합니다.
yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
# stress 명령어는 CPU, 메모리, 디스크 등 시스템 자원에 부하를 가하는 도구입니다.
# 이를 사용하여 시스템이 얼마나 튼튼하게 동작하는지 테스트하거나 성능 문제를 진단하는데 사용할 수 있습니다.
# stress을 설치합니다.
yum -y install stress
3. 오토스케일링 그룹의 CPU 평균 사용량 50%에 대한 이벤트를 만들었고, 서버들은 기본적으로 사용중인 사용량이 있으니 1개 서버의 CPU에 100% 부담을 줘서 50%를 넘기겠습니다.
# -c 코어수 : 지정된 코어 갯수에 100% 부하
stress -c 2
4. top 명령어로 확인해보면 cpu 사용률이 100%까지 올라갔습니다.
top
5. CPU 평균 사용률을 확인하러 Cloud Insight를 확인해보겠습니다.
Service -> Management & Governance -> Cloud Insight를 클릭합니다.
6. Auto Scaling Group(VPC) 대시보드를 확인해보면 CPU 사용률이 50%를 넘겼습니다.
사용률 50%를 1분동안 넘기면 이벤트가 발생하게 해놨으니 조금 기다려봅니다.
7. CPU 사용률 50% 초과 이벤트 발생 알람과 같이 서버 생성이 시작되었습니다.
8. 이벤트 완료 알람과 함께 서버 생성이 끝났습니다. 다시 Cloud Insight로 가보겠습니다.
9. 서버가 1대 추가되어 총 3대가 되었기에 CPU 평균 사용률이 33%가 되었습니다.
서버 반납에 대한 이벤트 룰은 CPU 사용률이 50% 미만으로 1분 이상 지속이었습니다.
하지만 쿨다운 300초를 줬기 때문에 바로 반납을 시작하지는 않고 서버가 성생된 15분에서 300초 후, 20분에 반납 이벤트가 실행됩니다.
10. 생성 5분 후 반납 이벤트가 발생하여 서버가 반납되었습니다.
*서버 반납은 오래된 서버부터 반납 됩니다.
서버를 미리 만들필요 없이 특정 이벤트나 일정에 맞춰 자동으로 서버를 생성하고 반납하는 Auto Scaling을 만들어봤습니다.
만약 Auto Scaling으로 생성한 서버 안의 데이터를 변경해야 한다면 Auto Scaling에 사용된 이미지를 바꾸고 Auto Scaling 설정을 수동으로 조작하여 생성 및 반납을 해야 모든 웹서버의 데이터를 바꿔 줄 수가 있습니다.
하지만 모든 서버에 부착하여 부착된 서버들이 같은 데이터를 사용할 수 있게 해주는 NAS를 사용한다면 그럴 필요가 없습니다.
다음 글에서는 NAS를 생성하여 Auto Scaling된 서버에 부착해보겠습니다.
