[AWS Networking] 로드밸런싱의 모든 것ELB

1. 학습목표

NLB -> ALB -> Web Server -> ALB -> WAS 로 이어지는 실무 아키텍처 구조 이해하기 

전체 아키텍처

 

2. 개념 

2-1. ELB의 종류(ALB, NLB)

고정 IP를 가진 NLB를 앞전에 (요청이 방화벽 이슈로 고정 IP를 요구하는 상황 多)

 

1️⃣ ALB (Application Load Balancer) = L7(HTTP/HTTPS) 로드밸런서

• 분산 기준: URL 경로(/cart), 호스트(aa.com), 헤더, 쿼리스트링 등 HTTP 레벨
• 강점
  • 라우팅 규칙이 매우 풍부(경로/호스트 기반, 리다이렉트, 고정 응답 등)
  • TLS 종료(HTTPS 복호화) 후, 내부는 HTTP로 넘기는 패턴이 쉬움
  • 마이크로서비스/다중 도메인/다중 API에 최적

• 한계
  • HTTP/HTTPS 중심(“TCP 그대로 통과” 같은 L4 역할은 제한적)

2️⃣ NLB (Network Load Balancer) = L4(TCP/UDP/TLS) 로드밸런서

• 분산 기준: IP/Port + 연결(커넥션) 단위의 네트워크 레벨
• 강점
  • 초고성능/초저지연, 대량 트래픽에서 유리
  • 정적 IP(EIP) 제공 가능 / 클라이언트가 “IP 고정”을 요구할 때 강력
  • TLS를 그대로 통과(pass-through) 시키거나, TCP 기반 프로토콜에도 대응
• 한계
  • HTTP 레벨의 “/path별 라우팅” 같은 건 못함

 

2-2. Listener Rule

url을 기반으로 분기

1️⃣ Listener(리스너)

• “어떤 포트/프로토콜로 들어오는 요청을 받을지”를 정의
• 예: ALB의 80(HTTP), 443(HTTPS) 리스너 / NLB의 443(TLS) 리스너 등

2️⃣ Listener Rule(리스너 규칙)

• 리스너가 받은 요청을 어떤 조건이면 어디로 보낼지를 정의
• ALB에서는 특히 강력:
  • Host 기반: api.example.com → API 타깃 그룹
  • Path 기반: /static/* → Web 타깃 그룹, /api/* → WAS 타깃 그룹
  • Header/Query 기반도 가능
  • 액션: forward(전달), redirect(리다이렉트), fixed-response(고정응답) 등

✳ 의미

• 외부 ALB: “정적 리소스/웹페이지/상품/결제/관리자” 등을 규칙으로 분기 가능
• 내부 ALB(Web 뒤): /api/* 는 WAS-A로, /auth/* 는 WAS-B로… 처럼 백엔드 서비스를 분해하기 좋음

path 또는 host를 통한 분기

2-3. Target Group

ㄴ로드밸런서가 트래픽을 보낼 ‘목적지 묶음’ + 헬스체크 기준

• 구성 요소
  • 대상(Target) 타입: EC2 인스턴스 / IP / (ALB는 Lambda도 가능) 등
  • 포트/프로토콜: 예) HTTP:80, HTTPS:443, TCP:3000 등
  • 헬스 체크 설정: 어떤 방식으로 “살아있다”고 판단할지
  • 트래픽 분산 방식 옵션(예: ALB 타깃 그룹 stickiness)

 

2-4. Sticky Session

ㄴ “같은 사용자를 일정 시간 같은 백엔드로 보내자” 참고자료

 

✳ 필요한 이유 : 세션을 서버 로컬 메모리에 들고 있을 때(서버에 종속된 세션)

 

✳ ALB의 스티키(대표)

• 쿠키 기반
  • ALB가 쿠키를 발급해서 “이 사용자는 이 타깃으로”를 유지
  • 만료 시간 설정 가능
• 장점: 간단히 상태를 유지
• 단점(중요)
  • 특정 서버 쏠림/핫스팟 가능
  • 서버 장애 시 사용자 경험이 흔들릴 수 있음
  • 오토스케일링/롤링배포에서 예측이 어려워짐

✳ NLB의 스티키(대표)

• HTTP 쿠키 같은 건 없고, 보통 소스 IP 기반의 연결 고정(affinity) 성격(구성/프로토콜에 따라 가능)

✳ 실무 권장 방향

• 가능하면 세션을 Redis/DB 같은 공유 저장소로 빼서(Stateless) 스티키 의존을 줄이는 게 운영/확장에 유리
•  

  

  ☝ 현사이트의 세션 스토리지는 어떻게 관리/운영되나?

• 다만 결제/인증 같은 일부 구간에서 어쩔 수 없이 필요할 때가 있음

 

2-5. Health Check 원리.

ㄴ헬스체크는 “로드밸런서가 이 타깃에게 트래픽을 보내도 되는가”를 자동 판단하는 장치
ㄴ핵심은 타깃 그룹 단위로 동작한다는 점

 

✳ 어떻게 동작하나

• 로드밸런서가 주기적으로 타깃에 요청을 보냄
  • ALB: 보통 HTTP/HTTPS로 GET /health 같은 엔드포인트 호출
  • NLB: TCP 연결 성공 여부 같은 L4 체크(또는 설정에 따라)
• 성공/실패를 누적해서 상태를 결정
  • 예: 연속 N번 성공하면 Healthy, 연속 M번 실패하면 Unhealthy
• Unhealthy면 트래픽 분배 대상에서 제외

✳ 운영에서 같이 알아야 하는 것

• Deregistration delay(드레이닝)
  ㄴ타깃을 빼기 시작할 때 “기존 연결/요청을 얼마나 기다려 줄지”
  → 롤링 배포/스케일 인 시 5xx 줄이는 핵심
• 헬스체크 엔드포인트 설계
  • 단순 “프로세스 살아있음” 체크인지
  • DB/캐시 연결까지 포함한 “의존성 체크”인지 너무 무겁게 만들면 헬스체크 자체가 장애를 유발할 수 있음

 

3. 심화 

✨ 언제 NLB -> ALB를 사용하는가? 

• 인바운드는 “목적지 IP 고정”, 아웃바운드는 “출발지 IP 고정”이 자주 이슈.

 

1️⃣ (인바운드 : 목적지)  B2B 파트너가 “IP 화이트리스트”를 요구하는 경우 (가장 흔함)

[상황]
자회사/물류사/파트너사가 우리 “관리자 API” 혹은 “주문 조회 API”를 호출해야 하는데,
그쪽 방화벽 정책이:
- 허용된 IP에서 들어오는 요청만 통과
- 도메인 기반 허용(DNS 기반)은 안 해주거나, 변경 절차가 너무 느림

1. 파트너 시스템(예: 물류사 출고 시스템)에서 우리 API 호출
2. 파트너 네트워크 경계(방화벽)에서 Destination(목적지) IP 기준으로 접속 허용/차단을 설정해야 함
3. 우리가 api.ourshop.com만 주면, 파트너 입장에서는
   • DNS가 어떤 IP를 주는지 바뀔 수 있고
   • “지금/내일/장애 시” IP가 바뀌면 방화벽 룰이 깨질 수 있음
4. 그래서 파트너가 “고정 IP를 달라”라고 요구
5. 우리 쪽에서 **NLB + EIP(고정 IP)**를 구성하고, 파트너에게 “이 IP로 접속”을 제공
6. 요청 흐름은 이렇게 됨:
   • 파트너🤛(고정 IP여기등록) → (인터넷/VPN) → NLB(고정 IP/EIP) → ALB(HTTP 라우팅) → Web/WAS
   • 파트너는 방화벽에 IP 딱 몇 개만 등록하면 끝
   • 우리 내부에서 ALB가 스케일/교체되어도 외부에서 보이는 접속 지점(IP)은 유지

현재 사이트는 대체적으로 해당 이유 때문에 NLB를 앞에 두는 것

 

 

2️⃣ 사내망/자회사 온프렘에서 전용망(VPN/Direct Connect)로 들어오는 경우

[상황]
자회사/본사 온프렘에서 “사내망”으로만 접근 가능한 운영/정산 기능이 있고,
연결은:
- Site-to-Site VPN 또는 Direct Connect
- 망분리/보안등급 때문에 라우팅/방화벽 정책이 매우 엄격

1. 자회사 온프렘 시스템이 우리 운영 API 호출 (사내망 전용)
2. 온프렘 방화벽/라우터는 보통 정책이:
   • “이 목적지 IP로 가는 트래픽만 터널로 보낸다”
   • “그 외는 차단”
3. 여기서 목적지가 유동이면(예: ALB IP 변동)
   • 라우팅 테이블/방화벽 룰이 자주 깨지거나
   • 변경 승인/배포를 매번 받아야 해서 운영이 불가능
4. 그래서 “터널 목적지는 고정 IP여야 한다”
5. 우리 AWS 측에서 NLB + EIP를 터널 종단(또는 사내 접근 지점)으로 둠
6. 흐름:
   • 온프렘 → VPN/DX 🤛 (고정IP가 정책) → NLB(EIP) → 내부 ALB/서비스 → WAS
   • “DNS로 들어와라”가 아니라 네트워크 장비가 ‘목적지 IP’로 정책을 걸기 때문에 고정 IP가 필요해지는 케이스.

 

 

3️⃣ (아웃바운드 : 출발지) 우리가 파트너를 호출할 때, 파트너가 “너희 출발 IP를 고정해라”라고 하는 경우 (아웃바운드)

[상황]
우리가 결제사/정산/물류/외부 API를 호출해야 함.
파트너 정책이:
- “허용된 소스 IP에서 오는 호출만 받겠다”

1. 우리 WAS가 파트너 API 호출을 시도
2. 그런데 AWS에서 그냥 나가면, NAT/경로/스케일에 따라 출발 IP가 바뀔 수 있음
3. 파트너는 “출발 IP 바뀌면 차단”이므로 장애가 생김
4. 해결을 위해:
   • NAT Gateway + Elastic IP로 “우리 출발 IP”를 고정하거나
   • 별도 egress 전용 구조를 둠
5. 흐름:
   • WAS → NAT Gateway(EIP) 🤛 (고정IP가 정책)  → 파트너 방화벽(소스 IP 검사) → 파트너 API
6. 실무 실제 상황 적용
   ㄴ특정 사무실에서 운영 파트너 오피스 시스템 접속 불가 현상  
   • 클라이언트가 WAS 로 "직접 (혹은 단순 라우팅만 거쳐)" 연결하면 IP패킷의 L3 헤더는 아래와 같이 유지
     라우터는 L2(MAC)만 바꾸고, L3(source, destination) IP는 안 바꾸는 것이 일반적  
     • Source IP(출발 IP) = 클라이언트 IP
     • Destination IP(도착 IP) = WAS IP
   • 그러나, 중간에 NAT/로드밸런서가 끼게 되면 출발 IP가 변경될 수 있음 
     Client  ->  ALB  ->  WAS (입장에선 source가 클라이언트가 아니라 ALB 또는 NAT gateway IP)
     (연결1)      (연결2)
     * NLB의 경우 클라이언트 IP 보존 옵션에 따라 클라이언트 source IP를 그대로 볼 수 있음