테마
AWS ELB (Elastic Load Balancing)
1. 서버 부하 해결의 두 가지 패러다임
웹 서비스를 운영하다 보면, 사용자가 몰리면서 서버에 부하가 걸리는 상황이 반드시 발생한다. 이 문제를 해결하는 방법은 크게 두 가지가 있다.
1-1. Scale Up (수직 확장)
서버 한 대의 성능 자체를 높이는 방식이다.
기존에 사용하던 서버의 CPU, RAM, 디스크 등의 하드웨어 사양을 더 좋은 것으로 교체하는 것을 의미한다.
- 예시: CPU 2코어 / RAM 8GB 서버를 CPU 8코어 / RAM 32GB 서버로 업그레이드
- AWS에서는 EC2 인스턴스 타입(Instance Type)을 변경하는 것만으로 간단하게 수행할 수 있다
- 예:
t2.micro->t2.xlarge->m5.4xlarge
- 예:
장점:
- 구성이 매우 간단하다. AWS 콘솔에서 인스턴스를 중지(Stop)한 후, 인스턴스 타입을 변경하고 다시 시작(Start)하면 끝이다
- 애플리케이션 코드를 수정할 필요가 없다
- 데이터 정합성(Data Consistency) 문제가 발생하지 않는다 (서버가 한 대이므로)
한계:
- 하드웨어 성능에는 물리적인 한계가 존재한다. 아무리 좋은 서버를 사용해도 무한히 성능을 올릴 수는 없다
- 비용 대비 효율이 점점 떨어진다. 사양이 높아질수록 가격은 기하급수적으로 증가한다
- 서버가 한 대이므로 단일 장애점(Single Point of Failure, SPOF) 문제가 있다. 그 한 대가 죽으면 서비스 전체가 중단된다
1-2. Scale Out (수평 확장)
서버의 대수를 늘려서 트래픽을 분산하는 방식이다.
동일한 역할을 하는 서버를 여러 대 배치하고, 들어오는 요청을 각 서버에 나눠서 처리하게 한다.
- 예시: 서버 1대가 처리하던 트래픽을 5대로 나눠서 처리
- AWS에서는 같은 사양의 EC2 인스턴스를 여러 대 생성하여 구성한다
장점:
- 이론적으로 무한 확장이 가능하다. 트래픽이 늘면 서버를 더 추가하면 된다
- 한 대가 장애가 나더라도 나머지 서버들이 트래픽을 처리하므로 **고가용성(High Availability)**을 확보할 수 있다
- 비용 효율이 선형적으로 유지된다
필요한 것:
- 여러 대의 서버에 트래픽을 자동으로 분배해주는 장치가 필요하다
- 이 역할을 하는 것이 바로 **로드 밸런서(Load Balancer)**이다!
Scale Up vs Scale Out 비교
핵심 정리: Scale Up은 한계가 명확하므로, 대규모 서비스에서는 Scale Out + 로드 밸런서 조합이 사실상 표준이다. AWS에서 이 로드 밸런서 역할을 해주는 것이 바로 **ELB(Elastic Load Balancing)**이다.
2. ELB란? Elastic Load Balancing
2-1. ELB 개념
**ELB(Elastic Load Balancing)**는 AWS에서 제공하는 로드 밸런싱 서비스로, 여러 EC2 인스턴스에 들어오는 트래픽을 자동으로 분산시켜주는 역할을 한다.
쉽게 비유하면 은행 창구 안내원과 같다.
- 은행에 가면 여러 창구가 있고, 안내원이 "3번 창구로 가세요", "5번 창구로 가세요"라고 안내해준다
- 빈 창구(여유 있는 서버)로 고객(트래픽)을 안내하여 대기 시간을 줄여준다
- 만약 특정 창구가 문을 닫으면(서버 장애), 안내원은 그 창구로 고객을 보내지 않는다
ELB도 마찬가지로, 클라이언트로부터 들어오는 요청을 뒤에 있는 여러 EC2 인스턴스들에게 적절히 분배해주는 것이다.
2-2. ELB의 기본 동작 알고리즘 - 라운드 로빈(Round Robin)
ELB의 가장 기본적인 트래픽 분배 알고리즘은 **라운드 로빈(Round Robin)**이다.
라운드 로빈은 매우 직관적인 방식으로, 등록된 서버들에게 순서대로 돌아가며 요청을 분배한다.
| 요청 순서 | 분배 대상 |
|---|---|
| 1번째 요청 | 서버 A |
| 2번째 요청 | 서버 B |
| 3번째 요청 | 서버 A |
| 4번째 요청 | 서버 B |
| 5번째 요청 | 서버 A |
| ... | 번갈아 반복 |
서버가 3대라면 A -> B -> C -> A -> B -> C -> ... 순서로 분배된다.
ELB 라운드 로빈 분배 흐름
2-3. ELB의 주요 특징
| 특징 | 설명 |
|---|---|
| 자동 분산 | 등록된 인스턴스들에 트래픽을 자동으로 분배한다 |
| 헬스 체크 | 주기적으로 인스턴스 상태를 확인하여 정상적인 인스턴스에만 트래픽을 보낸다 |
| 자동 확장 | 트래픽 증가에 따라 ELB 자체의 용량도 자동으로 확장된다 |
| 고가용성 | 여러 가용 영역(Availability Zone)에 걸쳐 동작할 수 있다 |
| 보안 그룹 연동 | ELB에도 보안 그룹(Security Group)을 적용할 수 있다 |
| DNS 이름 제공 | ELB 생성 시 고유한 DNS 주소가 부여되며, 이 주소로 접속하면 자동 분산이 이루어진다 |
2-4. ELB의 종류
AWS에서는 용도에 따라 여러 종류의 로드 밸런서를 제공한다.
| 종류 | 약자 | 특징 | OSI 계층 |
|---|---|---|---|
| Classic Load Balancer | CLB | 가장 오래된 타입. L4/L7 모두 지원. 현재는 레거시(Legacy) 취급 | 4계층/7계층 |
| Application Load Balancer | ALB | HTTP/HTTPS 트래픽에 특화. URL 경로 기반 라우팅 지원 | 7계층 |
| Network Load Balancer | NLB | 초고성능, 초저지연. TCP/UDP 트래픽 처리에 적합 | 4계층 |
| Gateway Load Balancer | GWLB | 서드파티 가상 어플라이언스 배포 시 사용 | 3계층 |
참고: 이번 실습에서는 가장 기본적인 **Classic Load Balancer(CLB)**를 사용한다. 개념을 이해하기에 가장 직관적이기 때문이다. 실무에서는 ALB나 NLB를 더 많이 사용한다.
3. 헬스 체크(Health Check)
3-1. 헬스 체크란?
**헬스 체크(Health Check)**는 ELB가 주기적으로 뒤에 등록된 각 EC2 인스턴스의 상태(건강 상태)를 확인하는 메커니즘이다.
쉽게 말해, ELB가 각 서버에게 "너 살아있니?" 하고 물어보는 것이다.
3-2. 헬스 체크 동작 방식
ELB는 설정된 주기마다 각 인스턴스에 HTTP 요청(예: GET /index.html)을 보낸다.
- 정상 응답(HTTP 200)이 오면: 해당 인스턴스는 Healthy(정상) 상태로 판단하고 트래픽을 계속 분배한다
- 응답이 없거나 오류가 오면: 해당 인스턴스는 Unhealthy(비정상) 상태로 판단하고 트래픽 분배를 중지한다
- 비정상 인스턴스가 다시 정상 응답을 하면: 다시 Healthy 상태로 전환되어 트래픽 분배가 재개된다
3-3. 헬스 체크 설정 항목
| 설정 항목 | 설명 | 기본값 예시 |
|---|---|---|
| Ping Protocol | 상태 확인에 사용할 프로토콜 | HTTP |
| Ping Port | 상태 확인에 사용할 포트 | 80 |
| Ping Path | 상태 확인에 사용할 경로 | /index.html |
| Response Timeout | 응답 대기 시간 (이 시간 내에 응답이 없으면 실패) | 5초 |
| Interval | 헬스 체크 주기 (몇 초마다 확인할지) | 30초 |
| Unhealthy Threshold | 연속 실패 횟수 (이만큼 연속 실패하면 Unhealthy 판정) | 2회 |
| Healthy Threshold | 연속 성공 횟수 (이만큼 연속 성공하면 다시 Healthy 판정) | 10회 |
헬스 체크 동작 흐름
핵심 포인트: 헬스 체크 덕분에 서버 하나가 장애를 일으키더라도 사용자는 이를 인지하지 못한다. ELB가 자동으로 정상 서버에만 트래픽을 보내주기 때문이다. 이것이 바로 **고가용성(High Availability)**의 핵심이다.
4. 실습 흐름
이번 실습에서는 EC2 인스턴스 2대에 각각 다른 웹 페이지를 올려놓고, Classic Load Balancer를 통해 트래픽이 분산되는 것을 직접 확인한다.
실습 전체 아키텍처
4-1. 사전 준비: EC2 인스턴스 2대 생성
기존에 생성한 EC2 인스턴스가 있다면 하나를 더 만들고, 없다면 2대를 새로 생성한다.
두 인스턴스의 공통 설정:
- AMI: Amazon Linux 2
- 인스턴스 타입: t2.micro (프리 티어)
- 같은 보안 그룹 사용 (또는 동일한 규칙의 보안 그룹)
4-2. Apache 웹서버 설치
각 인스턴스에 SSH로 접속한 후, Apache 웹서버를 설치하고 시작한다.
인스턴스 1과 인스턴스 2 모두 동일하게 실행:
bash
# Apache 웹서버(httpd) 설치
sudo yum install -y httpd
# Apache 웹서버 시작
sudo service httpd start
# (선택) 인스턴스 재부팅 시 자동 시작 설정
sudo chkconfig httpd on설치가 완료되면 Apache 웹서버가 80번 포트에서 동작하게 된다.
4-3. 보안 그룹(Security Group)에 HTTP 80번 포트 추가
EC2 인스턴스에 외부에서 HTTP(80포트)로 접속할 수 있도록 보안 그룹 인바운드 규칙을 추가해야 한다.
보안 그룹 인바운드 규칙 설정:
| 타입 | 프로토콜 | 포트 범위 | 소스 |
|---|---|---|---|
| SSH | TCP | 22 | My IP (또는 0.0.0.0/0) |
| HTTP | TCP | 80 | 0.0.0.0/0 (모든 곳에서 접속 허용) |
설정 방법:
- AWS 콘솔 -> EC2 -> 해당 인스턴스 선택
- 하단의 Security 탭 클릭
- 보안 그룹 링크 클릭
- Inbound rules -> Edit inbound rules 클릭
- Add rule -> Type:
HTTP, Source:Anywhere (0.0.0.0/0)선택 - Save rules 클릭
4-4. 웹 페이지 생성 (index.html)
각 인스턴스에서 서로 다른 내용의 index.html 파일을 생성한다. 이렇게 해야 ELB가 어느 서버로 트래픽을 보냈는지 눈으로 확인할 수 있다.
인스턴스 1:
bash
sudo vi /var/www/html/index.htmlhtml
<html>
<body>
<h1>Hello World 1</h1>
</body>
</html>인스턴스 2:
bash
sudo vi /var/www/html/index.htmlhtml
<html>
<body>
<h1>Hello World 2</h1>
</body>
</html>확인: 각 인스턴스의 퍼블릭 IP(Public IP)로 브라우저에서 접속하여 "Hello World 1", "Hello World 2"가 각각 표시되는지 확인한다.
http://<인스턴스1-퍼블릭-IP>-> "Hello World 1" 표시http://<인스턴스2-퍼블릭-IP>-> "Hello World 2" 표시
4-5. Classic Load Balancer 생성
이제 두 인스턴스 앞에 ELB를 배치한다.
생성 순서:
- AWS 콘솔 -> EC2 -> 좌측 메뉴에서 Load Balancers 클릭
- Create Load Balancer 클릭
- Classic Load Balancer 선택 -> Create 클릭
Step 1: Define Load Balancer
| 설정 항목 | 값 |
|---|---|
| Load Balancer name | my-first-elb (원하는 이름) |
| Create LB inside | 사용 중인 VPC 선택 |
| Listener Configuration | HTTP / 80 -> HTTP / 80 (기본값 유지) |
Listener 설명: "외부에서 80포트로 들어온 HTTP 요청을, 뒤쪽 인스턴스의 80포트로 HTTP 프로토콜로 전달하겠다"는 의미이다.
Step 2: Assign Security Groups
- ELB에 적용할 보안 그룹을 선택한다
- HTTP(80포트) 인바운드가 허용된 보안 그룹을 선택해야 한다
Step 3: Configure Security Settings
- HTTPS를 사용하지 않으므로 이 단계는 건너뛴다 (경고 메시지 무시)
Step 4: Configure Health Check
| 설정 항목 | 값 | 설명 |
|---|---|---|
| Ping Protocol | HTTP | HTTP 프로토콜로 확인 |
| Ping Port | 80 | 80번 포트로 확인 |
| Ping Path | /index.html | 이 경로에 요청을 보내 확인 |
| Response Timeout | 5초 | 5초 내에 응답이 없으면 실패 |
| Interval | 30초 | 30초마다 확인 |
| Unhealthy Threshold | 2 | 2번 연속 실패 시 Unhealthy |
| Healthy Threshold | 10 | 10번 연속 성공 시 Healthy |
Step 5: Add EC2 Instances
- 앞서 생성한 인스턴스 1과 인스턴스 2를 체크하여 추가한다
- 이 두 인스턴스가 ELB 뒤에서 트래픽을 받게 된다
Step 6: Add Tags (선택)
- 필요시 태그를 추가한다. 건너뛰어도 무방하다
Step 7: Review and Create
- 설정 내용을 확인하고 Create 클릭
4-6. ELB 동작 확인
ELB가 생성되면, ELB 목록에서 해당 로드 밸런서를 선택하여 DNS name을 확인한다.
DNS 이름 예시:
my-first-elb-1234567890.us-east-1.elb.amazonaws.com참고: ELB는 고정 IP가 아닌 DNS 이름으로 접속한다. ELB의 IP는 내부적으로 변경될 수 있으므로, 항상 DNS 이름을 사용해야 한다.
동작 확인 방법:
- 브라우저에서 ELB DNS 주소를 입력하여 접속한다
- "Hello World 1" 또는 **"Hello World 2"**가 표시된다
- **새로고침(F5)**을 누르면, "Hello World 1"과 "Hello World 2"가 번갈아 표시된다
- 이것이 바로 라운드 로빈(Round Robin) 방식의 트래픽 분산이다!
주의: ELB 생성 직후에는 인스턴스 상태가
OutOfService일 수 있다. 헬스 체크가 완료되어InService상태로 바뀔 때까지 잠시(약 30초~1분) 기다려야 한다. 하단의 Instances 탭에서 각 인스턴스의 Status를 확인할 수 있다.
4-7. 헬스 체크 동작 확인 (장애 시뮬레이션)
이제 한 인스턴스를 일부러 중지(Stop)시켜서, ELB의 헬스 체크가 어떻게 동작하는지 확인한다.
테스트 순서:
인스턴스 2를 중지(Stop)한다
- EC2 -> 인스턴스 2 선택 -> Instance State -> Stop
ELB 상태 확인
- Load Balancers -> 해당 ELB 선택 -> Instances 탭
- 인스턴스 2의 Status가
InService->OutOfService로 변경되는 것을 확인 - (Unhealthy Threshold가 2이므로, 헬스 체크 2회 연속 실패 후 변경됨)
브라우저에서 ELB DNS로 접속
- 새로고침을 아무리 해도 "Hello World 1"만 표시된다
- 인스턴스 2가 Unhealthy이므로 ELB가 자동으로 트래픽을 보내지 않는다!
(선택) 인스턴스 2를 다시 시작(Start)하면
- 헬스 체크 성공 후 다시
InService상태로 돌아온다 - 다시 "Hello World 1"과 "Hello World 2"가 번갈아 표시된다
- 헬스 체크 성공 후 다시
이 과정이 보여주는 것: 서버 장애가 발생해도 사용자는 서비스 중단을 경험하지 않는다. ELB가 자동으로 정상 서버에만 트래픽을 분배해주기 때문이다.
5. ELB 삭제
실습이 끝나면 반드시 ELB를 삭제해야 한다. ELB는 운영 중인 시간과 처리한 데이터량에 따라 비용이 부과되기 때문이다.
5-1. 비용 구조
ELB의 비용은 크게 두 가지 요소로 구성된다.
| 비용 요소 | 설명 |
|---|---|
| ELB 운영 시간 | ELB가 존재하는 시간만큼 시간당 비용이 발생 (사용하지 않아도 존재하면 과금) |
| 데이터 처리량 | ELB를 통해 전송된 데이터(GB) 단위로 비용 발생 |
주의: ELB를 삭제하지 않으면 사용하지 않더라도 시간당 비용이 계속 발생한다! 실습용 리소스는 반드시 정리하는 습관을 들이자.
5-2. 삭제 순서
ELB 삭제:
- AWS 콘솔 -> EC2 -> Load Balancers
- 삭제할 ELB 선택
- Actions -> Delete 클릭
- 확인 팝업에서 Yes, Delete 클릭
EC2 인스턴스 삭제 (실습 완료 시):
- AWS 콘솔 -> EC2 -> Instances
- 삭제할 인스턴스 선택
- Instance State -> Terminate 클릭
삭제 체크리스트:
- [ ] Classic Load Balancer 삭제 완료
- [ ] 실습용 EC2 인스턴스 종료(Terminate) 완료
- [ ] 사용하지 않는 보안 그룹 정리 (선택)
정리
| 개념 | 핵심 내용 |
|---|---|
| Scale Up | 서버 한 대의 성능을 높이는 방식. 간단하지만 물리적 한계가 있다 |
| Scale Out | 서버 대수를 늘리는 방식. 무한 확장 가능하지만 로드 밸런서가 필요하다 |
| ELB | AWS의 로드 밸런싱 서비스. 여러 EC2에 트래픽을 자동 분산한다 |
| 라운드 로빈 | 등록된 서버에 순서대로 돌아가며 요청을 분배하는 알고리즘 |
| 헬스 체크 | ELB가 주기적으로 서버 상태를 확인하여 정상 서버에만 트래픽을 보내는 기능 |
| CLB | Classic Load Balancer. 가장 기본적인 ELB 타입 (현재는 ALB/NLB 권장) |
| 비용 | ELB 운영 시간 + 데이터 처리량 기준 과금. 실습 후 반드시 삭제할 것! |