일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- influxdb 설치
- regex_search
- grafana dashboard
- c3 초
- CentOS7
- 1697
- selinux port 등록
- snmp
- python os
- c3 축 없애기
- subporcess path
- 백준
- python subprocess
- gcc 업데이트
- g++ 업데이트
- c++ 정규식
- centos pyhon 설치
- 정규식 컴파일
- gcc regex
- c3 축 가리기
- 정규식 활용
- snmp test
- linux시간으로 변경
- c3 second
- python popen
- InfluxDB
- telegraf
- semanage
- 정규식 문자열 출력
- c3 step graph
- Today
- Total
리셋 되지 말자
Auto Scaling 본문
ami 준비
nginx가 설치된 우분투 ami 이미지를 만든다.
- ubuntu 18.04 선택. t2 micro,
- 생성 시, 자동으로 nginx가 설치되도록 스크립트 추가. 설치만하면 실행 및 enabled 상태가 된다.
- ssh 접속, 80 포트 접속이 가능하도록 보안그룹 지정
- 생성 후, public ip 접속 테스트(nginx 동작 확인 완료)
- 인스턴스 종료 후, 우클릭하여 ami 이미지로 생성
이제 Nginx가 설치된 ami를 손에 넣었다. 이것을 이용해 Auto Scaling에 적용시켜보자.
여기서, ami ID를 기록해 두어야 함. 시작 템플릿 생성 시, ami 지정에 사용
시작 템플릿 생성
- 시작템플릿 메뉴로 이동하여 생성 시작
- 템플릿 이름과 설명 입력
- 기록해둔 ami ID로 검색하여 ami를 지정하고, 인스턴스 타입 지정
- 인스턴스 생성시에 사용할 키페어도 지정
- 네트워킹 설정에서 VPC를 지정. VPC가 하나밖에 없으면 자동으로 설정됨. 80, 22 port를 허용하는 보안그룹 지정
- 고급 세부정보를 펼치고,
- 사용자 데이터에 생성된 인스턴스의 HOSTNAME을 index.html에 출력하도록 설정. 이걸로 설정 마무리
Target Group
Load Balancer에 연결할 Target Group을 생성한다.
- 타겟 그룹 메뉴로 이동 후 생성 시작
- 타겟 그룹 이름 지정
- health check path 수정
- 현재는 생성되어 있는 인스턴스가 없으므로, 우측 하단의 'Create target group'을 클릭하여 타겟 그룹 생성 마무리
Load Balancer 생성
위에서 생성한 타겟 그룹을 대상으로 로드 밸런서를 생성한다
- 로드 밸런서 메뉴로 이동 및 생성 시작
- 로드 밸런서 유형은 Application Load Balancer 선택
- ALB 이름과 Scheme 지정. Scheme는 Internet-facing으로 지정하면, 로드밸런서의 도메인 주소로 접속 가능함.
- VPC를 지정하고, 가용존은 두 개를 선택. 이때 t2.micro는 2a, 2c에서 생성 가능하고 2b에서는 생성 불가능함을 주의
- 로드 밸런서는 ssh 접속이 불가능하다고 함(확실하지는 않음). 따라서 80 port를 허용하는 보안 그룹만 적용
- Listener에 위에서 생성한 타겟 그룹을 지정. 이걸로 로드 밸런서 설정 완료
Auto Scaling 그룹 생성
이제 본격적으로 오토 스케일링 그룹을 생성
- 오토 스케일링 메뉴로 이동하여 생성 시작
- 오토 스케일링 그룹 이름을 입력하고, 위에서 생성한 시작 템플릿을 지정
- VPC를 선택하고, 최소 두 개 이상의 서브넷(가용존) 선택.
- 기존 로드밸런서에 연결을 선택하고, 위에서 생성했던 로드 밸런서를 선택
- 그룹 크기를 지정. 최소 2개의 인스턴스가 부하를 분산 받는 상황에서, 부하가 많이 생기면 추가로 인스턴스가 증가하는지 테스트하기 위해 이렇게 지정.
- CPU 사용률이 80%를 넘어가면 인스턴스 수가 증가하도록 설정. 이것으로 설정 마무리. 다음 버튼을 계속 눌러 생성
Auto Scaling 그룹 상태 확인
정상적으로 오토 스케일링 그룹이 생성되었다는 가정 하에 상태 확인 진행
- 이름을 클릭하면, 세부 사항을 확인 가능
- 인스턴스 관리 탭에서 두 개의 인스턴스가 'InService' 상태인 것을 확인
- 로드 밸런서 메뉴로 이동
- 생성되어 있는 로드 밸런서를 클릭하고, 하단의 DNS 이름 확인
- DNS 이름을 복사하여 웹 브라우저를 통해 접속 테스트. 두 서버로 부하가 분산되는 것을 확인
- 캡처를 하지는 않았지만, 두 개의 인스턴스에 각각 접속하여 hostname이 맞다는 것을 확인했음
부하 테스트
위에서 cpu 사용량이 80%가 넘으면, 최대 4개 까지 인스턴스가 늘어나도록 지정했다. 실제로 잘 늘어나는지 확인해본다.
두 가지 방법을 생각했는데, 인스턴스에 접속하여 stress 프로그램으로 cpu 부하를 주는방법과 Jmeter와 같은 부하 테스트 프로그램으로 실제 http 요청을 많이 보내어 cpu에 부하가 걸리게 하는 방법이다.
간단한건 stress겠지만, 여기선 Jmeter 로 진행한다. 그리고 Jmeter를 설치하는 방법은 제외
하려고 했지만, Ubuntu에서만 다룸
- Jmeter 설치 on Ubuntu18.04 (패키지를 찾을 수 없다고 하면 apt update)
sudo apt install -y openjdk-8-jdk
sudo apt install -y jmeter
- Jmeter를 GUI로 접속
- Jmeter를 이용한 GET request 두번 확인(설정은 링크를 참조했음. 감사합니다!)
- 횟수를 지정하여 loop 요청(1초에 10명씩 계속 GET 요청) : 매우 매우 여유로움0
- 100/1
... 아무리 해도 80%가 안넘어서 실패. stress로 테스트 시작
- stress 설치
sudo apt install -y stress
- 로드실행
stress --cpu 1 --timeout 600
cpu 1개의 로드를 600초 동안 100%로 지정
- 300초 대기. 워밍업 시간이 300초.
- 오래 기다리면 instance가 4개로 증가한것을 확인할 수 있다
- hostname 확인. 총 4개의 server에 로드밸런서가 동작하는 것을 확인
- 부하가 끝나면, 인스턴스가 자동으로 줄어드는 것을 확인
'AWS' 카테고리의 다른 글
Certificate Manager (0) | 2021.09.07 |
---|---|
Route 53 (0) | 2021.09.07 |
인스턴스 실행 시 스크립트 실행 (0) | 2021.09.03 |
보안그룹 커스텀 (0) | 2021.09.03 |
VPC 생성 (0) | 2021.09.03 |