들어가며
VPC를 통해 Private, Public 서버를 각각 설정하고 각 서브넷안에 EC2를 생성해 접속해보는 실습을 진행하였다. 이번에는 ELB 와 Auto scaling 기능을 직접 사용해보며 AWS 에서 제공하는 서비스에 대해 공부해 볼 것이다.
ELB (Elastic Load Balancer)
ELB
ELB란 클라이언트의 서비스 요청 트래픽을 여러 서버로 분산시켜주는 서비스이다.
- EC2를 Target Group 에 할당 → ELB에 Target Group 연동
- Target Group에서 상태검사를 통해 정상적인 서버에만 요청 전달
- 수십대의 서버가 구성되어 있어도 클라이언트는 단일 web service endpoint로 접근
또한 ELB의 경우 완전 관리형 서비스로 시스템에 대한 업그레이드, 가용성, 관리 등은 AWS에서 지원해준다.
그럼 어떻게 동작하나?
ELB의 구성요소
- 리스너(Listener)
- 클라이언트 요청 수신
- 요청 내용 검사 후 결과에 따라 적절한 target Group 으로 전달
- 최소 1개의 리스너가 필요하고 최대 10개까지 설정 가능
- SSL 지원 : SSL 인증서로 HTTPS를 적용 가능
- 규칙(Rule)
- 우선순위, 조건, 동작으로 구성
- 요청 검사 과정에서 설정된 조건에따라 지정된 동작 수행
- 대상 그룹(Target Group)
- EC2, Lambda, IP address 등으로 구성
- 서버의 Health Check를 통해 서버 상태 모니터
ELB의 종류 4가지
- ALB(Application Load Balancer) → 가장 많이 사용
- Application 층에서 동작(L7) → URL 을 보고 부하분산을 시키는것
- 인증서 사용 가능
- ALB는 Public IP를 사용하며 DNS Name을 제공한다.
- LB(Network Load Balancer)
- Transport 층에서 동작(L4) → 대용량 트래픽 처리용
- 인증서 사용 가능
- GLB(Gateway Load Balancer) → 많이 사용안함
- Network / Transport 층에서 동작 (L3/L4)
- 네트워크 트래픽에 특화된 로드 밸런서
- 비대칭 트래픽 처리 기능 제공
- CLB(Classic Load Balancer) → 단종된 서비스
- Transport / Application 층에서 동작(L4/L7)
ELB 에서 중요한것은 Health Check 과정이다. Health Check를 HTTP 요청을 통해 진행하며 만약 200 응답이 오지않으면 트래픽을 그쪽으로 주지 않는다.
ELB 실습
서버가 여러대는 아니라 부하분산은 하지는 않지만 이제 ALB를 통해 접속을 하는것을 확인해 볼 것이다.
앞서 했던 실습의 경우는 Bastion 서버를 통해 web 서버에 접속하였는데 이번 실습에서는 ELB 중에 ALB를 통해 접속하는과정을 확인해 볼 것이다.
EC2 → 보안그룹 → 보안그룹생성
인바운드 규칙 HTTP, HTTPS → Any IPv4 로 보안그룹 생성, 아웃바운드 규칙 모든트래픽 any IPv4 허용
EC2 → 대상그룹 → 대상그룹생성
VPC는 직접만든 VPC로 설정
상태검사 경로는 / 를 설정해준다.
대상그룹은 web 서버로 둔다.
(아래에 보류 중인것으로 포함) 버튼 누르기.
아래처럼 target 그룹을 생성할 수 있다.
EC2 → 로드런밸싱 → 로드밸런서 → 로드밸런서 생성 → ALB 생성 (lab-edu-alb-web)
이때 체계의 경우 내부 LB도 사용할 수 있는데 3-Tier 구조에서 주로 사용한다. WAS 서버를 따로 있을때 내부 트래픽이 커지면 사용
네트워크 매핑→ VPC(사용하는 VPC)
가용영역은 두개 다 사용
리스너 및 라우팅
대상그룹 → 직접 만든 대상그룹 (가중치는 백분율로 얼마나 접근할지 정하는것이다. 실습에서는 1개)
아래 처럼 LB가 생성된다.
AWS 로드 밸런서는 트래픽이 늘어나거나 줄어듦에 따라 자동으로 규모를 조절(Scaling)하고 이 과정에서 내부 IP 주소가 수시로 변경될 수 있어서 DNS 이름을 통해 접근한다.
그럼 직접 접속해보면(LB의 DNS 주소)
접속되는것을 볼 수 있다.
Auto scaling
Auto Scaling이란?
서비스 트래픽 변화에 맞춰 EC2 인스턴스 수량을 자동으로 조절하는 기능이다.
EC2 Instance Auto Scaling
- Scale In & Out : 트래픽에 맞추어서버의 수량을늘리거나줄이는방식
- Scale Up & Down : 트래픽에맞추어서버의 성능 스펙 (vCPU, Memory)을향상시키거나낮추는방식
Auto scaling 의 구성 요소를 보면
- Launch Template(새로 만들어질 EC2의 설정값 묶음)
- AMI, 인스턴스 타입, 키페어
- 보안그룹, 서브넷/네트워크 설정(ENI)
- IAM Role, User Data(부팅 시 스크립트)
- 스토리지(EBS) 등
- Auto Scaling Group(관리 대상 EC2들을 논리적으로 묶는 그룹)
- Min / Max / Desired
- Min: 최소 유지 대수
- Max: 최대 확장 한도
- Desired: 현재 목표 유지 대수(ASG가 맞추려는 값)
- Min / Max / Desired
- Scaling Policies (스케일링 정책)
- 언제 늘리고/줄일지 기준을 정한다.
- Scheduled Scaling: 특정 시간대에 미리 증설/축소 (예: 매일 오전 9시 증설)
- Dynamic Scaling: 지표(메트릭) 기반 자동 조절 (예: CPU 60% 초과 시 증설)
- Predictive Scaling: 과거 패턴 학습 기반 예측 확장 (미리 늘려두는 방식)
그럼 어떤 흐름으로 진행될까?
트래픽/지표 증가로 Scale Out
- 인스턴스/서비스 지표(예: CPU, RequestCount 등) 수집
- 지표가 CloudWatch로 전달
- Scaling Policy 조건 충족 → Alarm 발생
- ASG가 Launch Template로 새 EC2 생성
- 새 EC2가 ASG + Target Group에 자동 등록
- Health Check 통과 후 트래픽 분산 시작
반대로 트래픽이 감소하면?
Alarm 조건 충족 → Scale In으로 인스턴스 수 감소
실습
EC2 → 이미지 생성할 서버 선택 → 작업 → 이미지 생성
이미지 생성 확인
인스턴스 → 시작템플릿
내 AMI 선택
auto scaling 을 할때 하나의 가용영역 안에서만 만들면 가용성이 낮아지기때문에 두개 이상의 서브넷을 둔다.
보안 그룹 = web server
auto 로 만들어질때 해당 웹서버임을 알리는 태그추가
EC2 → 오토스케일링 그룹 생성(lab-edu-template-autoscaling-web)
모니터링 확인
정책
Auto scaling은 대부분 상시적으로 유지보다는 이벤트가있을때 사용한다
최소 용량 1개는 원본 서버를 제외하고 Auto Scaling 그룹(ASG)이 새로 만든 서버만 계산한 숫자
이외에 설정은 다 기본값으로 설정
ec2로 오면 초기화 되어있는 ec2 인스턴스를 확인할수있다.
(오토스케일링으로 생성된 인스턴스)
서버 두개가 LB가 잘 되는지 확인해보면
두개 서버가 새로고침 했을때 바뀌는것을 볼 수 있다.
부하 주기 (Stress Tool)
EC2 모니터링을 보면 순간적으로 부하가 오른것을 볼 수 있다.
(CPU 사용량 30 이상이면 Auto scaling 하도록 설정)
auto scaling 으로 서버가 늘어난것을 볼 수있다.
실습의 흐름을 보면
1단계: 원본 서버(EC2) 구성 및 AMI 생성
- 환경 구축: 먼저 EC2를 하나 만들어서 웹 서비스(Streamlit 등)에 필요한 모든 패키지와 코드를 세팅한다.
- 이미지화(AMI): 서버의 상태를 그대로 찍어낸 AMI(Amazon Machine Image)를 만든다. 이 이미지가 향후 늘어날 모든 서버의 복제용이 된다.
2단계: 시작 템플릿(Launch Template) 작성
- 설계도 등록: AMI를 사용하여 새 서버를 만들 때 어떤 사양 (t3.micro, 보안 그룹, 키 페어, IAM 역할 등)을 사용할지 미리 정의해둔 설계도를 작성한다.
- 자동화 준비: Auto Scaling Group이 이 설계도를 보고 사람의 개입 없이 똑같은 서버를 찍어내게 된다.
3단계: Auto Scaling Group(ASG) 및 로드밸런서(ALB) 연동
- 관리자(ASG) 설정: 최소 1대, 최대 4대라는 규칙을 정하고 서버가 위치할 서브넷을 지정한다.
- 로드밸런서 연결: ALB를 ASG와 연결하여 새로 태어나는 서버들이 자동으로 ALB의 대상 그룹(Target Group)에 등록되도록 설정한다.
- 첫 복제본 생성: 설정을 마치면 ASG는 즉시 설계도를 보고 첫 번째 복제 인스턴스를 생성한다. (이때 원본 서버와 별개로 1대가 더 생기는 것이다.)
4단계: 부하 감지 (Scale Out 테스트)
- 트래픽 유입: 사용자는 ALB DNS 주소로 접속합니다. ALB는 ASG가 관리하는 인스턴스들에게 트래픽을 나눠준다.
- 부하 발생: Stress Tool 등을 통해 CPU 점유율이 설정값(30%)을 넘어가면 CloudWatch가 경보를 울린다.
- 서버 증설: ASG가 경보를 확인하고 AMI를 사용해 2번, 3번 서버를 최대 4대까지 자동으로 늘린다.
5단계: 부하 감소 및 서버 축소 (Scale In)
- 안정화: 부하가 사라지고 CPU 사용률이 낮아지면 ASG는 비용을 아끼기 위해 자동으로 늘렸던 서버들을 하나씩 삭제한다.
- 최종 상태: 설정된 최소 용량(1대)만 남기고 다시 평상시 상태로 돌아간다.
마무리
직접 ELB를 설정하고 Auto scaling 을 해보면서 서버의 증가와 감소를 직관적으로 보니 이해가 쉽게 되었다. 아직 실습으로 간단하게 진행했지만 추후에 프로젝트를 진행하면서 이때 배웠던 개념을 실습해보고 싶다. 또한 이 과정을 하면서 접속이 안되고 오류도 나고 healthy 도 unhealthy 가 자주되고 하면서 스트레스를 받았는데 찾아서 고쳐보니 서버안의 80 포트가 listen 중이지 않거나 보안그룹이 잘 못 되어있거나 하면서 작은 실수 하나들이 오랜시간을 잡았었다. 그래서 더더욱 보안그룹과 VPC 설정 등 기초적인 세팅을 잘하는것이 정말 중요하다는것을 느꼈다.
