이번 글에서는 AWS AMI(Amazon Machine Image)를 활용하여 Auto Scaling을 생성한 후 EC2 인스턴스 개수를 자동으로 늘리고 줄이는 것을 실습해 볼 것이다. EC2 인스턴스 내에서 스프링부트 서비스를 구동시킨 후 CPU 사용량에 따라 EC2 인스턴스 개수를 늘리고 줄일 것이며, EC2 인스턴스 개수가 늘어났을 때 각 인스턴스에서 구동되는 서비스가 ELB(Elastic Load Balancing)를 통해 정상적으로 호출되는지 확인할 것이다.
이 글은 아래와 같은 순서로 진행된다.
- 사전지식
- 사전작업
- AWS AMI 생성
- AWS Auto Scaling 생성
- Auto Scaling 테스트
1. 사전지식
1-1. AWS AMI(Amazon Machine Image)란?
AMI(Amazon Machine Image)란 인스턴스 생성에 필요한 모든 소프트웨어 정보를 담고 있는 템플릿 이미지다. 사용자들이 얼마든지 자신의 인스턴스에 맞게 생성할 수 있기 때문에 편리하며 생성 후 동일한 환경을 갖는 인스턴스를 한번에 생성할 수 있다. 또한 AWS 마켓에서 다양한 이미지를 구할 수도 있다(단 유료).
1-2. AWS Auto Scaling이란?
AMI로 EC2 인스턴스 이미지를 생성해 놓고, 트래픽 증가 시 사전에 정의된 정책에 따라 AMI를 통해 EC2 인스턴스 개수를 늘려서 트래픽 처리량을 늘리고, 트래픽이 감소한 경우 EC2 인스턴스 수를 줄여서 자원(비용)을 효율적으로 사용할 수 있게 해주는 서비스다.
2. 사전작업
- VPC 및 EC2 생성(https://twofootdog.tistory.com/27 참고)
- EC2 내 스프링부트 jar파일 존재(/home/ec2-user/toy-project-0.0.1-SNAPSHOT.jar)
- ELB 생성(https://twofootdog.tistory.com/29 참고)
3. AWS AMI 생성
우선 AWS AMI 를 만들어보도록 하자. 사전에 AMI를 만들지 않고 바로 Auto Scaling을 생성해도 되지만 이번 글에서는 기존에 만들어진 EC2 인스턴스로 AMI를 만든 후 AMI를 기반으로 Auto Scaling을 만들어볼 것이다(EC2 인스턴스로 AMI를 만들게 되면 EC2 인스턴스 내 존재하는 데이터가 그대로 이관되기 때문에 EC2 인스턴스 내에 사전에 만들어 놓은 스프링 서비스 jar파일도 그대로 이관된다).
우선 콘솔에로그인->EC2를 선택한다. 이미 EC2 인스턴스는 만들어진 상태이며 인스턴스 내부의 /home/ec2-user 디렉토리에 /home/ec2-user/toy-project-0.0.1-SNAPSHOT.jar 파일이 존재한다. EC2 인스턴스 선택 후 우클릭->이미지->이미지생성을 선택한다(EC2 인스턴스가 없는 상태에서도 AMI를 만들 수 있지만, 과정이 EC2 인스턴스 생성과 동일하기 때문에 이미 존재하는 EC2 인스턴스 기반으로 AMI를 만들었다).
이미지 이름을 입력하고 이미지생성 버튼을 클릭한다.
그리고 이미지->AMI로 가면 목록에서 방금 만든 AMI를 확인할 수 있다.
4. AWS Auto Scaling 생성
이제 이 AMI를 활용하여 Auto Scaling을 생성할 것이다.
우측의 Auto Scaling->Auto Scaliing 그룹을 선택한 후 Auto Scaling 그룹 생성을 선택한다.
Auto Scaling을 만들기 위해서는 우선 시작구성을 생성한 후 해당 시작구성을 기반으로 Auto Scaling을 등록한다.
1. AMI 선택 화면에서 좌측에 있는 내 AMI를 선택한 후 조금전에 만든 AMI를 선택한다.
2. 인스턴스 유형 선택 에서는 t2.micro(AMI와 동일)을 선택하고 3. 세부 정보 구성 에서는 이름을 적어주고 고급 세부 정보에서 사용자 데이터 부분에 Auto Scaling에 의해 시작되는 EC2 인스턴스에서 실행될 스크립트를 작성한다. 필자는 AMI를 만들었던 EC2 인스턴스에 스프링부트 서비스가 기동되고 있었고, Auto Scaling되는 EC2 인스턴스에서도 스프링부트 서비스가 수행되어야 하므로, 사용자 데이터에 jdk를 설치한 후, jar파일을 실행하는 명령어를 작성했다.
IP주소유형에는 모든인스턴스에 퍼블릭IP주소할당을 선택했다. 왜냐하면 각 인스턴스 내에 스프링부트 서비스가 정상적으로 실행되는 것을 확인하기 위해 SSH를 통해서 인스턴스에 직접 접속해 볼 것이기 때문이다(프라이빗한 인스턴스 구성을 하게 된다면 퍼블릭IP를 할당할 필요 없다).
4. 스토리지 추가에서는 Default값을 넣어주고 5. 보안그룹구성으로 넘어간다. 보안그룹구성에서는 기존에 EC2 인스턴스에 등록한 것과 동일한 보안그룹을 선택해준다. 여기서 주의해야 할 점이, 시작 구성 생성 시 선택한 보안그룹의 VPC가 추후 Auto Scaling 그룹 생성 시 지정하는 VPC가 같아야 하는점이다(다르면 Auto Scaling이 생성되지 않는다!!!). 필자는 Auto Scaling의 VPC도 기존에 존재하던 EC2 인스턴스의 보안그룹과 동일하게 갈 것이기 때문에 시작구성의 보안그룹도 EC2 인스턴스와 동일하게 선택했다.
시작구성생성 화면에서 검토를 완료하고 생성한다. 키페어는 기존에 발급해 놓은 키페어를 사용하거나 신규 키페어를 등록해서 사용한다.
시작구성생성 버튼을 클릭하면 시작구성생성이 완료되고 Auto Scaling 그룹을 생성하는 버튼이 생기게 된다. 해당 버튼을 클릭하여 Auto Scaling 그룹을 생성해보자. 이 화면에서 생성해도 되지만 이 화면에서 나간 후 Auto Scaling->Auto Scaling 그룹에서도 생성 가능하다.
1. Auto Scaling 그룹 세부 정보 구성 화면에서는
그룹 이름 : 임의로 입력
네트워크 : 임의로 만든 VPC를 사용할 것이고, 시작구성에서 등록했던 보안그룹이 속해있는 VPC여야 함
서브넷 : VPC내에 있는 서브넷 중 Auto Scaling 이 적용될 서브넷을 선택
로드밸런싱 : 로드밸런서를 통해 Auto Scaling을 해줄 것이기 때문에 체크
대상그룹 : 기존에 생성해 놓은 ELB의 대상그룹을 선택
상태검사유형 : ELB를 사용하므로 ELB선택
상태검사유예기간 : default 300초
2. 조정 정책 구성 화면에서는 인스턴스를 늘리고 줄이는 정책을 정한다.
"조정 정책을 사용하여 이 그룹의 용량 조정"을 선택
조정범위 : 1 ~ 3개의 인스턴스를 선택한다. 그러면 Auto Scaling으로 인스턴스 개수는 1~3개로 조정된다.
그리고 제일 밑에 "단계 또는 단순 조정 정책을 사용하여 Auto Scaling 그룹 조정" 을 선택한다.
그러면 그룹 크기 증가/감소 설정 화면이 나오는데 "새 경보 추가" 버튼을 클릭한다.
그러면 경보생성 화면이 뜨는데, 알림 보낼 대상은 체크 해제(이번 글에서는 알림은 보내지 않을 것이다)하고
CPU 사용율 평균이 >= 0.5% 인 상황이 최소 1번 5분 연속으로 발생하게 되면 경보를 생성하게 된다.
경보생성 완료 후 그룹 크기 증가는 다음과 같이 설정한다. 작업 수행은 "(인스턴스)추가"를 선택하고 옆에 숫자는 1(인스턴스 개수)를 선택한다.
그룹 크기 감소에서도 위와 동일한 방식으로 설정한다.
설정이 완료되면 다음과 같다.
CPU 사용율 평균이 0.5 이상일 때 EC2 1개가 추가 기동되며, CPU 사용율 평균이 0.4 이하일 때 EC2 1개가 제거된다.
설정이 완료되었으면 검토를 누른 후 등록한 정보 확인 후 Auto Scaling 그룹생성을 클릭한다.
성공적으로 Auto Scaling 그룹이 생성되면 잠시 후 인스턴스가 기동된다.
기동된 인스턴스에 SSH를 통해서 접속해보면, 스프링부트 서비스가 동작중인 것을 확인할 수 있다(서비스 구동 확인 및 로그 확인).
5. Auto Scaling 테스트
자 이제 Auto Scaling 을 테스트해보도록 하자.
테스트를 진행할 내용은 다음과 같다.
- CPU 사용율이 0.5% 이상이 되면 EC2 인스턴스가 1개씩 추가적으로 구동. 최대 3개까지 구동
- CPU 사용율이 0.4% 이하가 되면 EC2 인스턴스가 1개씩 제거됨. 최소 1개 구동
5-1. 인스턴스 증감 테스트
우선 CPU 사용율을 0.5% 이상이 되게끔 테스트를 진행해보자. 우선 맨 처음에 EC2 인스턴스는 1개다.
그러다가 CPU 사용율이 0.5%가 넘어간 후 5분이 되지 않아 목표 용량이 1->2로 변한 후
EC2 인스턴스 1개가 추가된다.
그 후 계속해서 서비스를 호출하게 되면 EC2 인스턴스 1개가 더 생성되게 된다.
EC2 인스턴스로 들어가서 로그를 확인해보면 3개 서버 모두 로그가 정상적으로 기록되며, 웹페이지도 정상적으로 뜨는 것을 확인할 수 있다.
5-2. 인스턴스 감소 테스트
다음으로 인스턴스 감소 테스트를 진행해보자. 서비스를 호출하지 않으면 CPU 사용율이 떨어지게 되고, 그러면 3개로 구동중이던 EC2 인스턴스 개수가 최소 개수(1개)까지 감소하게 된다.
EC2 인스턴스 1개 감소 중(3개 -> 2개)
EC2 인스턴스 1개 감소 중(2개 -> 1개)
최종적으로 EC2 인스턴스 1개 남음. 테스트 완료!!!!!!
참고
https://wildpup.cafe24.com/archives/890
AWS Auto Scaling을 이용하여 EC2 인스턴스를 자동으로 확장하기 | 야생강아지 WILDPUP
Auto Scaling은 사용자의 설정에 따라 자동으로 EC2의 인스턴스를 확장하거나 축소한다. 예를 들면 미국의 블랙프라이데이 같은 시즌을 이유로 웹 사이트에 이용자가 급증하여 트래픽이 폭주할 때에는 인스턴스를 늘려 성능을 유지하고 다시 이용자가 평소와 같은 수준으로 떨어질 경우에는 인스턴스를 자동으로 다시 줄여 비용을 줄이는 효과를 볼 수 있다.
wildpup.cafe24.com
https://galid1.tistory.com/369
AWS - AutoScaling 서비스 및 테스팅(부하발생기)
AutoScaling 서비스 - Cloud Watch서비스와 혼용하여 부하 또는 특정 상황에따라 인스턴스의 수를 증감할 수 있는 서비스 고려사항 1. 급격한 부하증가 CloudWatch를 통해 부하를 감지하여 AutoScaling하여 부하를..
galid1.tistory.com
https://browndwarf.tistory.com/40
AWS 자습 노트 - 9. Auto Scaling with Spring Boot
자습 시나리오 이번 포스팅은 지난 포스팅에 사용했던 시나리오에 Auto Scaling을 적용하는 내용이다. (단, 지난 번에 사용한 예제 중에 root path를 호출했을 때 불려지는 sampleweb.jar 만을 사용하였고, subnet..
browndwarf.tistory.com
'IT > AWS' 카테고리의 다른 글
| AWS CodeCommit으로 소스코드 관리하기(Git & SSH) (3) | 2020.02.07 |
|---|---|
| Windows10에 AWS CLI 설치(python과 pip 활용) (0) | 2020.02.06 |
| AWS ELB(Elastic Load Balancing) 생성 후 EC2 연동 & 외부 도메인 연동 (0) | 2020.02.03 |
| AWS Route 53에 도메인 등록하기(DNS 설정) (2) | 2020.02.03 |
| AWS VPC 생성 후 EC2 생성하기 (2) | 2020.01.30 |
댓글