33장. Elastic Load Balancer 지형 — ALB · NLB · GWLB

이 장에서 말하고자 하는 것

지금까지 우리는 사용자가 도메인을 거쳐
HTTPS로 들어오는 길까지 그렸다.

사용자 → DNS → CloudFront → ?

이제 그 트래픽을 실제 서버로 분산하는 도구를 본다.

Elastic Load Balancer (ELB)

ELB는 한 가지가 아니라 세 종류로 나뉜다.

이 장은 그 셋의 차이와 선택 기준을 정리한다.

1. Load Balancer가 왜 필요한가

서버를 한 대만 띄우면

사용자 → 서버 1대

세 가지 문제가 생긴다.

• 서버가 죽으면 서비스가 죽는다
• 트래픽이 늘면 한 대로 부족하다
• 새 버전을 배포할 때 끊긴다

서버를 여러 대로 늘리면 이 문제는 풀리지만
사용자가 어떤 서버로 가야 할지 결정할 수 없다.

이 결정을 대신해주는 게 Load Balancer다.

사용자 → Load Balancer → [서버1 · 서버2 · 서버3]

Load Balancer는

• 죽은 서버는 빼고
• 트래픽을 고루 분산하고
• 새 서버를 매끄럽게 합류시킨다

2. ELB의 세 종류

AWS의 Elastic Load Balancing은 세 가지로 나뉜다.

L7 / L4 / L3 의 차이가 핵심이다.

3. L4와 L7의 차이 — 누가 트래픽을 어디까지 보는가

네트워크는 계층으로 나뉜다.

L7  애플리케이션  HTTP / HTTPS의 내용
L6  표현
L5  세션
L4  전송         TCP / UDP의 포트
L3  네트워크     IP 주소
L2  데이터링크
L1  물리

• L4 LB(NLB)는 IP와 포트만 본다 → 빠르다
• L7 LB(ALB)는 HTTP 헤더 · 경로 · 쿠키까지 본다 → 똑똑하다

이 차이가 두 LB의 능력 차이를 만든다.

4. ALB — HTTP를 똑똑하게 분배

ALB는 HTTP/HTTPS 트래픽을 다룬다.

다음을 보고 라우팅을 결정할 수 있다.

• 경로 (/api, /admin)
• 호스트 (api.example.com vs admin.example.com)
• HTTP 헤더
• 쿼리 스트링
• HTTP 메서드 (GET / POST)

그래서

같은 ALB 뒤에 여러 서비스를 붙여
경로별로 다른 서비스로 보낼 수 있다

이게 MSA 진입점으로 ALB가 가장 흔히 쓰이는 이유다.

5. NLB — 빠르고 단순하게

NLB는 TCP / UDP 계층에서 동작한다.

• HTTP 헤더를 보지 않는다
• 그래서 빠르다 (지연 100µs 수준)
• 고정 IP를 가질 수 있다
• 초당 수백만 요청 처리

용도:

• 게임 서버
• WebSocket / gRPC 일부
• TLS만 패스스루로 넘기고 싶을 때
• 고정 IP가 필요한 환경 (방화벽 화이트리스트 등)

6. GWLB — 보안 장비를 가운데 끼우기

GWLB는 좀 다르다.

방화벽 · IDS · DPI 같은
보안 어플라이언스를 트래픽 경로에 끼우기 위한 LB다.

요청 → GWLB → [보안 장비들] → 원래 목적지

일반 서비스 운영에서는 거의 만질 일이 없다.

이름만 기억하고 넘어가도 충분하다.

7. 어떤 걸 골라야 하는가

선택 기준은 단순하다.

HTTP/HTTPS 서비스          → ALB
TCP/UDP · 초저지연 · 고정 IP → NLB
보안 장비 체인              → GWLB

이 책에서 만들 마이크로서비스 구조는 모두 HTTP 기반이므로

ALB 가 기본 선택지

다.

NLB는 36장에서 따로 다룬다.

8. ALB와 NLB의 짧은 비교

9. 우리 서비스에서

척추 그림에서 ELB가 들어가는 위치다.

[사용자]
   ↓
[CloudFront]
   ↓
[API Gateway]
   ↓
[ALB]   ← 여기, 이번 단원의 주제
   ↓
[ECS Task 1 · 2 · 3 ...]

ALB가 사용자가 만든 트래픽을
실제 컨테이너로 보내는 다리 역할을 한다.

10. 직접 확인해보기 — CLI

ALB 목록 보기

aws elbv2 describe-load-balancers

특정 ALB 상세

aws elbv2 describe-load-balancers \
  --names my-alb

헬스 상태 확인

aws elbv2 describe-target-health \
  --target-group-arn <tg-arn>

11. 코드로는 이렇게 생겼다 — Terraform

ALB 한 대를 만드는 가장 작은 코드다.

resource "aws_lb" "main" {
  name               = "msa-alb"
  internal           = false
  load_balancer_type = "application"
  subnets            = [aws_subnet.public_a.id, aws_subnet.public_b.id]
  security_groups    = [aws_security_group.alb.id]
}

load_balancer_type 에 "application" (ALB) · "network" (NLB) · "gateway" (GWLB) 중 하나가 들어간다.

ALB는 최소 2개의 AZ 에 걸쳐 만든다.

12. 이렇게 쓰면 망한다 — 안티패턴

안티패턴 1. 모든 트래픽에 NLB를 쓴다

NLB는 빠르지만 멍청하다.
경로 라우팅 · 헤더 검사 · 호스트 라우팅 같은 일을 못 한다.

HTTP라면 ALB가 거의 항상 정답

안티패턴 2. ALB를 한 AZ에만 둔다

ALB는 AZ마다 노드가 만들어진다.
한 AZ에만 두면 그 AZ가 죽으면 LB 자체가 죽는다.

최소 두 개 이상의 AZ에 걸친다

안티패턴 3. LB 없이 EC2를 도메인으로 직접 가리킨다

api.example.com → EC2 한 대의 IP

• EC2 IP가 바뀌면 끊긴다
• 한 대만 죽어도 서비스가 죽는다

운영 서비스에 LB는 사실상 필수

안티패턴 4. ALB의 인증서를 EC2/ECS 안에도 또 박는다

ALB에서 종료할 거면 EC2는 HTTP로 받게 둔다.
양쪽에 똑같은 인증서를 박으면 운영만 복잡해진다.

13. 한 줄로 정리

ELB는 ALB · NLB · GWLB 세 가지이며,
HTTP 기반 MSA에서는 ALB가 가장 자주 사용된다

14. 이 장의 핵심 정리

1. Load Balancer는 트래픽 분산과 장애 격리를 동시에 해준다.
2. AWS의 ELB는 ALB · NLB · GWLB 세 가지로 나뉜다.
3. ALB는 L7에서 동작해 경로 · 호스트 라우팅이 가능하다.
4. NLB는 L4에서 동작해 빠르고 고정 IP를 제공한다.
5. GWLB는 보안 장비 체인을 위한 특수 LB다.
6. ALB는 최소 두 AZ에 걸쳐 만든다.