Auto Scaling이란, 서버에 부하가 발생할 때 자동적으로 서버 수를 늘리는 방식으로, 요청을 여러 서버로 분산시키기 위해 사용합니다. 일반적으로 Auto Scaling은 Elastic Load Balancer와 함께 사용되므로, EC2 인스턴스를 Auto Scaling 그룹으로 묶고, Auto Scaling 그룹 앞단에 Elastic Load Balancer를 배치합니다.
이번 포스팅은 ELB 사용법과 CI/CD를 이미 알고 있다는 전제로 작성되었기 때문에, 만약 ELB와 CI/CD에 대해 잘 모르실 경우 아래의 포스팅을 먼저 읽어주시기 바랍니다.
>> Elastic Load Balancer 사용법
>> 깃허브 CI/CD
이번 포스팅에서는 AWS EC2를 Auto Scaling 그룹으로 관리하는 방법에 대해 배워보도록 하겠습니다. Auto Scaling에 대한 개념은 Inpa Dev님께서 잘 정리해두셨으니, 아래의 링크를 참조해주세요.
>> Inpa Dev님 블로그
1. Auto Scaling 그룹의 필요성
Scale Out 방식으로 서버를 확장하고, 성능을 향상시키기 위해선 여러 개의 EC2 인스턴스가 필요하다. EC2 인스턴스를 추가하는 방법으로 우리는 두 가지를 생각할 수 있다. 바로 수동 추가와 자동 추가이다.
수동 추가는 말 그대로, 직접 EC2 인스턴스를 하나 더 생성하는 방식으로, 지금껏 우리가 EC2를 생성했던 방법으로 EC2를 추가 생성하는 것이다. 하지만, 이 방법의 한계점은 너무나도 명확하다. 16개의 EC2 인스턴스를 사용하는 상황을 가정해보자. 16개의 인스턴스를 반복 생성하는 일부터 여간 귀찮은 일이 아닐 것이다.
하지만, 이보다 더 큰 문제가 있다. 바로 애플리케이션의 수요가 매순간 변한다는 것이다. 그러므로 애플리케이션의 정확한 수요 예측이 어렵거나, 시간대 또는 요일에 따라 사용량이 크게 달라지는 경우라면, 인스턴스의 개수를 유동적으로 조절하는 일까지 해야 한다. (만약 인스턴스 종료 없이 항상 16개의 인스턴스를 유지한다면, 불필요한 비용 손실을 감당해야 할 것이다.)
이러한 이유에서 EC2를 추가로 생성할 때에는, 애플리케이션의 수요에 따라 EC2 인스턴스를 자동으로 추가하거나 종료할 수 있는 Auto Scaling 그룹을 사용하는 것이 좋다.
2. Auto Scaling 그룹 생성
1) AMI 생성하기
① 기존 EC2 인스턴스에 우클릭 > 이미지 및 템플릿 > 이미지 생성 버튼을 클릭한다.
② 이미지 이름을 지정한 후 이미지 생성 버튼을 클릭한다.
③ 좌측 메뉴 > 이미지 > AMI에서 아래와 같이 이미지의 상태가 available이 될 때까지 기다리자. 10~15분 정도 걸리는 것 같다.
2) 시작 템플릿 생성하기
① Auto Scaling 그룹 이름을 지정한 후, 시작 템플릿 생성 버튼을 클릭한다.
② 시작 템플릿의 이름을 지정한다.
③ 방금 생성한 AMI를 선택한다.
④ EC2를 생성할 때 사용한 인스턴스 유형과 키 페어를 선택한다.
⑤ EC2에서 사용하는 보안 그룹을 선택한다.
⑥ 고급 네트워크 구성 > 네트워크 인터페이스 추가 버튼을 클릭한다. EC2에서 사용하는 보안 그룹을 선택하고, 퍼블릭 IP 자동 할당을 활성화한다. 종료 시 삭제를 예로 설정한다.
⑦ 기존 EC2에 할당된 IAM Role을 적용한다. CI/CD를 위해 사용된 IAM Role로 자세한 내용은 아래의 포스팅을 참고하라.
>> EC2 IAM Role
⑧ 고급 세부 정보 최하단의 사용자 데이터에 인스턴스를 시작할 때 실행할 명령을 작성한다.
- 각자의 상황에 맞게 변경이 필요하다.
- 여기서는 파이썬 실행 파일을 무중단 실행하고, 프로젝트 디렉토리로 이동하여 jar 파일을 무중단 배포하고 있다.
- nohup의 결과물은 반드시 어딘가로 리다이렉션 해주어야 쉘 스크립트가 정상 동작할 수 있다.
#!/bin/bash
cd /home/ubuntu
nohup python3 send_mail.py > python_log.txt 2>&1 &
cd /home/ubuntu/.ssh/HelloThere
nohup java -jar hello_there-0.0.1-SNAPSHOT.jar > java_log.txt 2>&1 &
⑨ 한 번 생성한 시작 템플릿은 수정할 수 없다. 대신 시작 템플릿의 새로운 버전을 생성하는 것으로 간접적인 수정이 가능하다.
3) Auto Scailing 그룹 생성하기
① 다시 Auto Scailing 그룹 생성 화면으로 돌아와서, 방금 생성한 시작 템플릿을 선택한 후 다음 버튼을 클릭한다.
② VPC와 서브넷을 선택한다. 서브넷은 Default라고 적혀있는 가용 영역 중, 로드밸런서에서 사용 중인 가용영역을 선택하면 된다.
③ 기존 로드 밸런서에 연결을 선택하고 로드밸런서에서 사용하고 있는 대상 그룹을 선택한다.
④ Elastic Load Balancer 상태 확인 켜기와 CloudWatch 내에서 그룹 지표 수집 활성화에 체크하고 다음 버튼을 클릭한다.
⑤ 원하는 용량, 최소 용량, 최대 용량을 지정한다. 또한 크기 조정 정책은 평균 CPU 사용률이 80%를 넘었을 때 새로운 인스턴스를 생성하도록 지정해주겠다.
- 원하는 용량
- 평상시에 유지하고 있을 인스턴스의 수
- default는 최소 용량과 같다.
- 최소 용량 및 최대 용량의 범위 이내의 값이어야 한다.
- 최소 용량
- 사용할 인스턴스의 최소 개수
- 0을 입력하면 인스턴스가 모두 종료되기 때문에 항상 1 이상의 값을 입력해야 한다.
- 최대 용량
- 사용할 인스턴스의 최대 개수
- 인스턴스 워밍업
- 새로운 인스턴스가 시작되어 트래픽을 처리할 준비가 되기까지 걸리는 시간
- EC2 추가 생성이 잘 이루어지는지 테스트해보기 위해 2, 2, 2로 설정하였다.
⑥ 인스턴스 축소 보호는 선택하지 않고 다음 버튼을 클릭한다. 알림과 태그도 모두 생략한다.
3. Auto Scaling 동작 확인
1) EC2 인스턴스 생성 및 종료
① 좌측 메뉴 > Auto Scaling > Auto Scaling 그룹에서 본인의 Auto Scaling 그룹을 클릭한 후 활동 탭에 들어가면 Auto Scaling의 작업 기록을 확인할 수 있다.
- Auto Scaling 그룹의 원하는 용량을 2로 설정했기 때문에 2개의 인스턴스가 추가로 생성되었다.
② 이는 EC2의 인스턴스 탭에서도 확인할 수 있다.
- 참고로, UMCserver2는 Auto Scaling 그룹에 속하지 않는 기존 EC2 인스턴스이다.
- 이름이 없는 인스턴스가 Auto Scaling으로 추가된 인스턴스이다.
③ EC2 서버가 중간에 죽어버리는 상황이라 가정하고, 하나의 인스턴스를 종료시켜보자.
④ Auto Scaling 그룹의 활동 탭에서 EC2를 새로 Launch하였다는 기록이 확인된다.
⑤ 분명 인스턴스 하나를 종료시켰음에도 불구하고, EC2 인스턴스 탭에서 다시 두 개의 인스턴스가 동작하고 있다.
⑥ AutoScaling 그룹의 용량은 그룹 세부 정보의 편집 버튼을 클릭해 언제든지 변경할 수 있다.
⑦ 만약 Auto Scaling 그룹 사용을 끝내고 싶으면 원하는 용량, 최소 용량, 최대 용량을 모두 0으로 변경하면 된다.
⑧ 계속해서 AutoScaling 그룹을 사용하기 위해 용량을 아래와 같이 설정하자.
만약 인스턴스의 생성과 종료가 이유 없이 수시로 반복된다면, 쉘 스크립트를 잘못 작성했을 가능성이 높다. 자동 배포에 실패하여 인스턴스가 unhealthy 상태가 되면, Auto Scaling이 자동으로 해당 인스턴스를 종료하고 새로운 인스턴스를 생성한다. 이 과정이 무한히 반복되고 있는 상태라고 이해하면 된다.
2) EC2 인스턴스 접속
① 새롭게 추가된 인스턴스를 putty로 접속해보자.
② 기존에 사용하던 EC2 서버의 모든 파일이 그대로 넘어온 것을 확인할 수 있다. 또한 python_log.txt 파일이나 java_log.txt 파일이 생성된 것을 볼 때, 쉘 스크립트가 정상 수행되었음을 알 수 있다.
③ 서버가 정상적으로 가동되고 있기 때문에 로드밸런서의 대상그룹에서도 두 개의 인스턴스(기존 인스턴스, Auto Scaling 그룹 인스턴스)가 모두 healthy 상태여야 한다.
※ IP to Domain 매핑
Auto Scaling을 통해 실시간으로 생성되는 EC2의 경우 Public IP를 미리 알 수 없다. 그렇다면 어떻게 해야 IP를 도메인에 매핑할 수 있을까? 결론부터 얘기하면, 별도의 매핑 작업이 필요하지 않다.
아래의 포스팅에서 알 수 있듯, Route 53의 A 레코드(도메인 이름을 IP 주소로 매핑)의 트래픽 라우팅 대상은 ELB이다. 즉, DNS를 통해 해당 도메인에 접속하는 사용자의 트래픽이 로드 밸런서를 거쳐 여러 대상으로 분산 처리되는 것이다. 특히, 로드 밸런서는 Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 수행하기 때문에, 도메인 네임을 알고 있는 ELB가 알아서 대상 그룹의 EC2로 부하를 분산한다. 이를 도메인 로드 밸런싱이라 한다.
>> EC2에 HTTPS 적용하기
※ 도메인 로드밸런싱
도메인 로드밸런싱이란, DNS를 사용하여 도메인 이름에 연결된 여러 인스턴스로 트래픽을 분산하는 방식을 말한다. 다시 말해, 도메인 이름을 입력한 클라이언트의 요청을 여러 서버 또는 인스턴스로 효과적으로 분산시키는 작업인 것이다.
4. CodeDeploy 배포 그룹 수정
① CodeDeploy 서비스에 들어가 배포 > 애플리케이션을 클릭한 후 본인의 배포 그룹을 클릭한다.
② 편집 버튼을 클릭한다.
③ 환경 구성에서 Amazon EC2 Auto Scaling 그룹에 체크한 후 본인의 Auto Scaling 그룹을 선택한다.
- Amazon EC2 인스턴스는 선택해도 되고, 안해도 된다.
5. 기존 EC2 인스턴스 제거
만약 기존 EC2 인스턴스 없이 Auto Scaling으로만 EC2 인스턴스를 관리하고 싶다면, 기존 EC2 인스턴스(UMCserver2)를 ELB 대상 그룹과 Code Deploy의 배포그룹에서 Amazon EC2 인스턴스를 선택 해제하면 된다. 필요에 따라 기존 EC2 인스턴스를 종료해도 된다.
그러나, Auto Scaling으로 1~2개의 인스턴스만 사용할 것이라면, 기존 EC2 인스턴스를 그대로 놔두는 편이 더 좋다. 그 이유는 Auto Scaling 그룹의 인스턴스들은 생성과 종료가 자주 반복되는 탓에 간혹, 서버가 올바로 동작하지 않을 수 있기 때문이다.
[이미지 출처]
