관리 메뉴

공부하는 개발자

AWS Auto Scaling 구축하기 본문

개발 공부 기록하기/03. AWS & Infra

AWS Auto Scaling 구축하기

lannstark 2020. 10. 15. 20:17
반응형

안녕하세요! 여러분 공부하는~개발자입니다 ^^

이번 시리즈에서는 EC2 AutoScaling 구축을 해보려고 합니다.

 

AWS를 사용하는 많은 운영 환경에서는 하나의 EC2 인스턴스가 아닌 여러 인스턴스를 사용하는데요, 트래픽이 갑작스럽게 몰리거나 특정 시간에 많은 인스턴스가 필요한 경우에 자동으로 대응하기 위해서입니다. 사람이 24시간 수동으로 대응할 수는 없으니까요!!

자 그럼, 이번 시리즈에서는 EC2 Auto Scaling 그룹을 만들어 간단한 Nginx + WAS만을 두고, 해당 WAS에 트래픽을 높여 새로운 인스턴스가 자동으로 생긴 후 트래픽이 분산되는지 테스트 해보도록 하겠습니다 ㅎㅎ

 

이번 포스팅에서는 우선 Auto Scaling 그룹을 만들어 CPU 사용량에 따라 자동 scale out이 되는지 확인해볼 예정입니다.

우선 EC2 Auto Scaling 그룹부터 만들어볼까요?!!

1. Auto Scaling 그룹 만들기 시작

AWS EC2 콘솔 side bar에서 <Auto Scaling 그룹> 항목을 선택하고

<Auto Scaling 그룹 생성> 을 선택하면 됩니다 ㅎㅎ

2. 시작 템플릿 vs 시작 구성

Auto Scaling 그룹을 만드는 첫 단계는 시작 템플릿 방식을 사용할지, 시작 구성 방식을 사용할지 선택하는 것입니다.

과거에는 시작 구성을 사용했지만 현재는 AWS에서는 시작 템플릿 방법 사용을 권장하고 있으며, 시작 템플릿이 시작 구성에 비해 버전 등 관리가 더 편하다고 합니다.

당연히 처음에 저희가 원하는 시작 템플릿은 준비되어 있지 않기 때문에 시작 템플릿 먼저 만들어보겠습니다.

3. 시작 템플릿 생성하기

EC2로부터 쉽게 시작 템플릿을 생성할 수 있습니다.

자, 시작 템플릿에 사용될 AMI를 만들기 위해 EC2를 하나 만들겠습니다.

Amazon Linux 2를 기본 AMI로 하여 t2.small로 만들었습니다 ㅎㅎ git과 JDK11만 빠르게 설치하고 인스턴스를 stop 시켜주었습니다.

sudo yum update
sudo yum install git
sudo amazon-linux-extras install java-openjdk11

그 다음, 작업 > 인스턴스에서 탬플릿 생성을 선택합니다.

적절한 시작 템플릿 이름과 버전을 입력해 주고요~

AMI와 인스턴스 유형은 채워져 있습니다. 키 페어만 적절하게 변경해 주면 되네요 ㅎㅎ

그후 보안 그룹만 설정해준 뒤 네트워크 설정은 제거, Auto Scaling에 적용 안됨이라 표시된 항목은 '템플릿에서 선택하지 않음'으로 변경했습니다.

여기까지 진행한 후 생성을 완료하면 됩니다!!

  • 이 포스트의 끝에서 알게 되었는데요! 여기서 <시작 템플릿>을 만들때 인스턴스를 대상으로 하는 AMI가 생성되지 않습니다. (Auto Scaling으로 인해 생긴 EC2에 git과 JDK 11이 설치되어 있지 않더군요 ㅠㅠ) 캡쳐본을 다시 살펴보니 amzn2-ami-hvm-2.0.x 으로 설정되어 있네요..

4. 시작 템플릿으로부터 Auto Scaling 그룹 생성

EC2 왼쪽 사이드바에서 시작 템플릿을 선택한후, 방금 만들었던 시작 템플릿을 찾아 작업 > Auto Scaling 그룹 생성을 눌러줍니다.

5. 시작 템플릿 또는 구성 선택

아까 Auto Scaling을 처음부터 만드려는 것과는 다르게, 시작 템플릿 항목이 모두 채워져 있네요

바로 다음을 눌러주었습니다.

6. 설정 구성

설정 구성 항목에서는 크게 2가지를 설정하게 됩니다.

구매 옵션 및 인스턴스 유형

[시작 템플릿 준수]는 시작 템플릿에서 정했던 구매옵션을 따르게 됩니다. 저는 t2.small을 선택했었고, 고급 세부 정보에서 스팟 인스턴스 요청을 하지 않았었죠 ㅎㅎ

그렇기 때문에 자동으로 t2.small에 온디맨드 인스턴스가 사용될 것입니다.

만약 [구매옵션과 인스턴스 유형 조합]을 선택하게 된다면, 온디맨드 기본 용량, 온디맨드/스팟 인스턴스 비율, 스팟 할당 전략, 인스턴스 유형과 추가 인스턴스 유형을 선택하게 됩니다 ㅎㅎ 조금 더 custom한 선택이라고 볼 수 있겠네요

저는 시작 템플릿 준수를 고르고 넘어갔습니다.

네트워크

인스턴스가 시작되는 위치를 지정하도록 네트워크 설정을 구성하는 항목입니다.

저는 default VPC를 선택했고 인스턴스를 실행할 가용 영역에서 default 서브넷을 2개 골랐습니다.

각각의 다른 가용영역은 서로의 장애로부터 격리될 수 있기 때문에 물리적인 재해로부터 보호됩니다.

Auto Scaling은 여러 AWS 리전에 분산할 수는 없지만, 한 리전 내 여러 가용영역에 걸쳐 분산할 수는 있습니다. EC2 Auto Scaling은 가용 영역간 인스턴스를 균일하게 분산하도록 합니다. 하지만 테스트, 개발, 중요하지 않은 경우 또는 지연 시간이 매우 짧은 경우 인스턴스가 더 적은 영역에 집중하도록 할 수 있습니다.

바로 다음~ 눌러주었습니다!

7. 고급 옵션 구성

고급 옵션 구성에서는 로드 밸런서를 Auto Scaling 그룹에 연결하거나 Auto Scaling 그룹에서 인스턴스가 정상인지 비정상인지 판단하는 방법에 대한 특정 요구사항을 정의합니다.

최종 구상도를 위해서는 필요한 설정이겠지만, 우선은 CPU 사용량에 따른 scale out만을 확인하고자 하니 넘어가도록 하겠습니다 🙂

다음 바로 눌러 주고요~

8. 그룹 크기 및 조정 정책 구성

그룹 크기

Auto Scaling 그룹의 원하는 용량, 최소 용량, 최대 용량을 설정할 수 있습니다.

저는 최대 용량만 2개로 늘렸습니다! 각 용량에 대한 설명은 다음과 같습니다.

  • 원하는 용량 : 그룹에서 시작하고 유지하려는 EC2 인스턴스 수
  • 최소 용량 : 이 미만으로 내려갈 수 없는 EC2 인스턴스 수
  • 최대 용량 : 이 초과로 올라갈 수 없는 EC2 인스턴스 수

조정 정책

수요에 따라 인스턴스 수를 동적으로 조정하기 위해 설정하는 정책입니다 ㅎㅎ

사용할 수 있는 지표 유형은 4가지네요

  • 평균 CPU 사용률
  • 평균 네트워크 입력/출력 (byte)
  • 대상당 Application Load Balancer 요청 수

저는 평균 CPU 사용률 70%로 선택했습니다 ㅎㅎ

지표에 포함하기 전 워밍업 시간(초)는 새로 시작된 인스턴스가 설정해둔 시간까지 조정 정책 지표에 포함시키지 않는다는 뜻입니다. 예를 들어, 제가 워밍업 시간을 100초로 해두었다면 새로 생긴 인스턴스가 CPU 사용률이 아주 높을지라도 조정 정책 지표 산정에 100초 동안은 포함되지 않습니다 ㅎㅎㅎ

확장 중에는 워밍업 중인 인스턴스를 그룹 지표를 산정하는데 포함시키지 않으며, 축소 중에 종료 중인 인스턴스를 그룹 지표를 산정하는데 포함시키지 않습니다. 추가적으로 확장 활동이 진행 중인 동안에는 축소 활동을 시작할 수 없다고 합니다.

다음~ 진행해보죠~

  • 생성 완료를 눌러본 후 알았는데요, t2.small이 ap-northeast-2b 에서 지원되지 않아 조정 정책 생성에 실패했습니다! ap-northeast-2aap-northeast-2c만 지원되네요. 조정 정책을 다시 만들어주었습니다.

9. 알림 추가, 태그 추가

Auto Scaling 그룹에 인스턴스가 시작/종료 될때마다 SNS 주제로 알림을 전송할 수 있다고 합니다. 우선은 PASS 하겠습니다~~ 태그 추가 역시 PASS 했습니다. 실무에서는 convention에 맞는 적절한 tag를 입력하면 됩니다.

10. 검토 및 Auto Scaling 그룹 생성

이제 지금까지 설정했던 내용들을 검토하고, Auto Scaling 그룹 생성을 눌러 주면 됩니다!!! 드디어!!

11. 완성!!

EC2 > Auto Scaling 그룹 > lannstark-auto-scaling > 세부 정보자동 조정에서

지금까지 설정했던 항목들을 확인할 수 있습니다 😄

인스턴스 관리에서는 현재 Auto Scaling 그룹에 포함된 EC2 인스턴스들을 확인할 수 있네요

12. CPU 테스트

자 이제 CPU 사용량을 높여 새로운 인스턴스가 잘 실행되는지 확인해보겠습니다 ㅎㅎㅎ

해당 인스턴스에 접속해서...

sudo yum update
sudo amazon-linux-extras install epel -y
sudo yum install stress -y

CPU에 부하를 주기 위해 stress를 다운로드 받고요,

stress --cpu 2

명령어를 이용해 cpu에 아주 그냥 부하를 콸콸 주었습니다

(아래는 top 명령어 입니다)

그랬더니 2분 30초 정도가 지나고 새로운 인스턴스가 생겼습니다 ㅎㅎ 2분 30초라니... 생각보다 꽤 걸리네요..

모니터링 툴을 보니, 실제 부하가 올라갔을때 18%(11:19) → 72%(11:25) → 89%(11:29) 단계적으로 올라가는데까지 약 10분 정도가 걸렸습니다. 이 역시 생각보다 꽤 걸리네요 ㅎㅎ... 모니터링과 실제 scale out 역시 차이가 있어 보입니다.

stress 명령어를 사용한지 2분 30초 정도가 지나서 새로운 인스턴스는 올라왔거든요.

15분 정도 더 기다려보니

인스턴스가 다시 사라져 한 대만 남게 되었습니다 ㅎㅎㅎ

다행히 설정한 그대로 잘 작동은 하네요 ㅋㅋㅋㅋㅋㅋ 생각보다는 조금 더 오래 걸려서 그렇지... 크흠.. 공식 설명서를 조금 읽어 봐야 겠네요..

 

넵 이상으로 Auto Scaling 그룹을 만들어 보고, CPU에 부하를 주어 scale out이 되었다가 CPU 부하가 사라지자 인스턴스가 다시 사라지는 것을 확인해보았습니다.

자 다음 번에는 이제 여기에 로드 밸런서를 붙여보겠습니다 ㅎㅎ 감사합니다 😂

반응형
0 Comments
댓글쓰기 폼