대용량 트래픽을 처리하기 위해서는 AutoScaling이 필요하고, 부하를 분산시켜주기 위한 로드밸런서도 필요하는 사실을 알고 있었다.
하지만 실습을 통해 이를 실제로 만들다 보니, 구현하기 위해 필요한 서비스들이 더 많았고 처음보는 개념도 있었다.
0. 전체 구조 설명
Elastic Load Balancer (ELB)
- 외부/내부에서 들어오는 트래픽을 한 개의 엔드포인트를 통해 수신한다.
- 트래픽을 여러 EC2 인스턴스 등에 자동으로 분산할 수 있도록 한다.
- 로드밸런싱 알고리즘에 따라 트래픽을 Target Group으로 전달한다.
Target Group
- ELB와 실제 EC2 인스턴스 사이를 연결하는 중간 매개체
- 실제 트래픽을 전달할 대상(EC2 인스턴스, Lambda 함수, IP 등)의 목록을 관리하고, 상태를 감시(헬스체크)
- 헬스체크 후 살아있는 대상에게만 전달한다.
- Auto Scaling Group을 통해 생성한 인스턴스가 자동으로 TG에 등록된다.
Auto Scaling Group
- 설정된 조건에 따라 EC2 인스턴스를 자동으로 생성/제거하는 그룹
- 최소/최대/원하는 인스턴스 수를 설정할 수 있다.
- 시작 템플릿에 정의된 대로 EC2를 생성한다.
전체 흐름을 살펴보면,
- 사용자가 도메인이나 IP로 요청 → ELB 수신
- ELB는 요청을 Target Group에 전달
- Target Group은 연결된 EC2 인스턴스(ASG에 의해 자동 생성) 중 상태가 정상인 인스턴스에만 요청 전달
- ASG는 설정한 조건에 따라 자동으로 인스턴스 개수 조절함 (예: CPU 사용률이 70% 넘으면 1대 추가)
ELB가 트래픽을 자동으로 분산해주는데, Taget Group이 왜 필요한가?
-> ELB는 "어디로" 트래픽을 보낼지를 스스로 알지 못한다. 그 "어디로"를 알려주는게 Target Group!
- ASG가 인스턴스를 생성하면 자동으로 Target 그룹에 인스턴스가 등록된다.
- Target Group이 존재함으로서 헬스체크 로직을 분리할 수 있다.
정리하면,
- ELB = 트래픽을 분산하는 "배달 기사"
- Target Group = "배달주소 목록 + 주소가 유효한지 확인하는 시스템"
=> ELB는 Target Group이 없으면 "어디로 배달해야할지 모름"니다.
1. 기존 EC2 인스턴스로 AMI 이미지 생성
AMI란, Amazon Machine Image의 약자로, EC2와 같은 서버를 만들 때 바탕이 되는 이미지를 말한다.
EC2를 생성할 때 Ubuntu, Winodows와 같이 제공되는 이미지를 사용할 수도 있지만,
기존에 세팅하여 사용하던 EC2 서버를 그대로 이미지로 만들어 사용할 수도 있고
만든 이미지를 사용하여 AutoScaling 그룹을 생성할 수도 있다.
EC2 > 인스턴스 > 작업 > 이미지 및 템플릿 > '이미지 생성'
이미지 이름, 이미지 설명 을 입력한 뒤, 이미지 생성 버튼을 클릭한다.
꽤 시간이 지난 후에, 이미지가 대기중에서 사용 가능 상태로 바뀌게 된다.
(이미지마다 생성 소요 시간이 다른듯 한데, 저는 10분 이상 걸렸습니다.)
2. 시작 템플릿 생성
시작 템플릿이란,
Auto Scaling 그룹에서 인스턴스를 시작하는데 사용하는 템플릿으로 인스턴스 환경을 간편하게 복제하기위해 구성한다.
따라서 템플릿을 Auto Scaling 그룹에 지정시킴으로서, Auto Scaling을 통해 인스턴스를 늘리면 그 인스턴스 환경 구성이 템플릿에 설정된 환경에 따라 복제됨으로서 해당 서비스를 늘릴 수 있다.
즉, Auto Scaling 그룹이 확장하기 위한 EC2 환경 구성이 포함된 템플릿이다.
인스턴스의 AMI ID, 인스턴스 유형, 키페어, 보안그룹, 블록 디바이스 매핑 정보를 세팅하여 템플릿을 구성한다.
템플릿을 구성하면 수정이 불가능하다. 템플릿은 버전으로 구분되는데, 만약 옵션을 바꿔야한다면 새로운 템플릿을 생성하고 해당 템플릿 버전으로 변경해야 한다.
EC2 > 인스턴스 > 시작 템플릿 > 시작 템플릿 생성
2.1 템플릿 이름 및 설명
시작 템플릿의 이름과 템플릿 버전에 대한 설명을 작성한다.
2.2 애플리케이션 및 OS 이미지
내 AMI > 내 소유 > 생성했던 이미지 선택
Auto Scaling으로 확장시, 복제될 AMI를 선택한다.
2.3 인스턴스 유형
인스턴스 유형은 '프리티어 사용가능'한 t2.micro 로 선택해준다.
2.4 키 페어
키페어는 지난 EC2 생성에서 사용했던 키를 동일하게 사용했다.
2.5 네트워크 설정
기존 보안 그룹에 필요한 인바운드 규칙을 설정해두었기 때문에, 기존 보안그룹을 선택하였다.
만약, 기존 보안그룹이 없었다면 새롭게 생성하면 된다.
2.6 스토리지(볼륨)
스토리지 볼륨은 기본값으로 설정한뒤, '시작템플릿 생성' 버튼을 눌러주면 된다.
2.7 User Data Script 작성
트래픽 처리를 위해서는 autoScaling으로 생성된 인스턴스가 프로젝트를 정상적으로 실행하고 있어야, 부하를 분산하여 처리가 가능하다.
이때, 인스턴스가 생성될때마다 일일히 접속하여 프로젝트를 실행시켜주는 작업은 매우 번거롭고 불가능하다.
따라서 사용자 데이터 스크립트를 작성하여, 인스턴스가 처음 실행될 때 해당 스크립트를 실행하도록 하여, 자동으로 서비스를 시작하도록 구성할 수 있다.
e.g.
cd [실행할 파일의 위치]
[서비스 실행 명령어]2.8 시작 템플릿 생성 완료
시작 템플릿이 생성 완료되었다.
해당 시작 템플릿으로 만들어진 EC2 인스턴스에 접속해보면, UserData Script가 성공적으로 실행되어 바로 프로젝트가 실행된 모습을 확인할 수 있다.
3. Auto Scaling 그룹 생성
시작 템플릿을 생성하였으므로, 해당 템플릿을 바탕으로 Auto Scaling Group을 생성할 수 있다.
생성한 시작 템플릿을 체크박스 후, 작업 > Auto Scaling 그룹 생성 을 클릭한다.
3.1 시작 템플릿 선택
Auto Scaling Group의 이름을 작성하고, 생성한 시작템플릿을 선택한다.
3.2 인스턴스 시작 옵션 선택
EC2 인스턴스를 분배할 VPC와 가용영역(AZ)를 선택한다.
VPC는 기존 EC2와 동일한 VPC를 사용했고,
가용영역은 서울 리전을 기준으로 ap-northeast-2a 와 ap-northeast-2c를 선택했다.
(2개의 프라이빗 서브넷)
Q. 왜 프라이빗 서브넷을 선택하는가?
이 구조에서 클라이언트는 ELB의 DNS를 통해 접근하기 때문에, EC2 인스턴스가 퍼블릭 서브넷에 있을 필요는 없다.
오히려 보안상 EC2 인스턴스는 프라이빗 서브넷에 배치하는 것이 권장된다.
Q. 왜 2개의 가용영역을 선택하는가?
이렇게 2개의 가용영역을 지정함으로서, Auto Scaling을 통해 인스턴스를 만들 때 가용영역을 번갈아가며 50% 비중으로 인스턴스를 만들게 된다.
따라서 하나의 가용영역에 문제가 생겨도 상대적으로 영향을 덜 받을 수 있게 된다. (가용성 확보)
3.3 다른 서비스와 통합
현재 단계에서는 로드 밸런서 없음 을 선택하고 넘어간다.
이후 단계에서 로드밸런서를 생성후, 연결할 예정이다.
3.4 그룹 크기 및 크기 조정 구성
원하는 용량 : 1 / 원하는 최소 용량 : 1 / 원하는 최대 용량 : 3 으로 설정해준다.
- 원하는 용량 = 평상시에 유지하고 있을 인스턴스 수
- 최소 용량 = 그룹 내 최소 유지할 인스턴스 수
- 최대 용량 = 그룹 내 최대 유지할 인스턴스 수 (인스턴스가 지나치게 많이 추가되지 않도록 한다.)
- 0, 0, 0 -> 오토스케일링 그룹을 사용하지 않을 때
특정 지표값에 따라 AutoScaling Group을 관리할 수 있도록 설정해준다.
'대상 추적 크기 조정 정책'을 선택 후, 대상 값은 30으로 설정해준다.
이는 1개의 인스턴스가 가동되고 있는 상황에서, 1개의 인스턴스 평균 CPU 사용률이 30%가 넘어가면 새로운 인스턴스를 생성한다는 Auto Scaling 동작 조건을 걸어놓은 것이다.
사용할 수 있는 조정 지표 유형은 다음과 같다.
- 평균 CPU 사용률
- 평균 네트워크 입출력(byte)
- 대상당 Application Load Balancer 요청 수
인스턴스 워밍업 값(초)은 새로 시작된 인스턴스가 설정해둔 시간까지 조정 정책 지표에 포함시키지 않는다는 뜻이다.
예를 들어, 워밍업 시간이 300초라면, 새로 생긴 인스턴스의 CPU 평균 사용량이 30%가 넘더라도 초기 300초 동안은 조정 정책 지표에 포함하지 않아 Scale out이 동작하지 않는다.
맨 아래의 CloudWatch 내에서 그룹 지표 수집 활성화를 켜준다.
진행하는 프로젝트에서는 CloudWatch를 사용하기 때문에 설정한 것이므로, CloudWatch 서비스를 사용하지 않는다면 켜지 않아도 무방하다.
3.5 알림 추가
생략
3.6 태그 추가
EC2 관리의 편의성을 위해 다음과 같이 태그를 설정한 후,
Auto Scaling 그룹 생성 버튼을 클릭한다.
3.7 생성 완료
생성된 Auto Scaling 그룹을 보면, 위에서 설정했던 인스턴스 대로 생성된 모습을 확인할 수 있다.
(기본 인스턴스 1개)
4. 대상그룹(Target Group)생성
EC2 > 대상그룹 > 대상그룹 생성
4.1 그룹 세부 정보 지정
AutoScaling Group을 통해 생성된 EC2 인스턴스에 연결할것이기 때문에, '인스턴스'를 생성한다.
대상 그룹의 이름을 설정하고, Spring boot의 기본 포트인 80번 포트를 선택한다.
그리고 연결한 EC2가 위치해있는 VPC를 선택한다.
4.2 대상 등록
타겟 그룹을 통해 트래픽을 라우팅하기 위한 대상 그룹을 선택한다.
이전에 생성한 Auto Scaling 그룹을 라우팅 대상으로 선택해준다.
4.3 대상그룹 생성
대상 그룹을 생성하였다.
이제 로드밸런서를 대상그룹에 연결하는 단계만 남았다.
5. 로드밸런서(ELB) 연결
이제 AutoScaling 그룹을 생성했으므로, 해당 그룹내의 인스턴스들로 트래픽을 나눠주기 위한 로드밸런서를 연결할 차례이다.
ELB(Elastic Load Balancer)는 서로 다른 EC2 인스턴스들에 대한 하나의 엔드포인트를 제공하기 때문에,
사용자는 한 곳의 엔드포인트로 요청을 전송하면 ELB가 부하를 분산하여 처리한다.
5.1 로드밸런서 선택
EC2 > 로드밸런서 > 로드밸런서 생성
로드밸런서의 3가지 유형 중 하나를 선택하면 된다.
나는 Spring Application에 대한 로드밸런싱이 필요한 상황이므로, ALB를 선택한다.
5.2 기본 구성
로드밸런서의 이름을 설정한뒤, '인터넷 경계' 스키마와 'IPv4'를 선택한다.
인터넷 연결을 통한 트래픽이 발생할 것이므로 인터넷에 연결되어있어야한다.
5.3 네트워크 매핑
로드밸런싱할 인스턴스인 AutoScaling 그룹이 위치해있는 VPC를 선택한다.
가용영역도 마찬가지로 AutoScaling 그룹과 동일하게 설정한다.
5.4 보안그룹 선택
기존에 사용하던 보안그룹과 동일하게 선택한다.
5.5 리스너 및 라우팅
리스너를 통해 들어온 트래픽을 전달할 대상 그룹을 선택한다.
대상그룹은 3.대상그룹 에서 생성했던 그룹을 선택해주고, 로드밸런서를 생성해준다.
5.6 로드밸런서 생성 확인
이렇게 로드밸런서가 생성되었음을 확인할 수 있다.
생성된 로드밸런서는 http:// + DNS이름 + :80 의 주소로 들어가면 확인할 수 있다.
참고:
https://m.blog.naver.com/suin2_91/221969798385?recommendTrackingCode=2
'AWS' 카테고리의 다른 글
| Artillery 부하테스트 (0) | 2025.06.21 |
|---|---|
| [AWS][트러블슈팅] EC2 CPU100% 문제 해결 (1) | 2025.06.04 |
| [AWS] 로드밸런서 유형과 구성요소 (0) | 2025.05.19 |
| [AWS]Spring boot 프로젝트 EC2로 배포하기 (2) | 2025.05.16 |
| [AWS][트러블슈팅] S3 정적 웹사이트 호스트 오류 발생 (403 forbidden, 404 nosuchkey 오류) (0) | 2025.04.22 |