Load Balancing & Traffic Management

1. Overview

로드 밸런싱과 트래픽 관리(Load Balancing & Traffic Management)는 수백 대의 분산 서버로 밀려드는 10만 TPS의 폭풍을 단 1건의 요청 유실 없이 정확하게 쪼개고 분산시키는 현대 인프라의 거대한 '교통 통제소'를 해부합니다.

학습자는 IP 주소와 포트(Port)만 보고 무식하지만 압도적인 속도로 패킷을 넘겨버리는 L4(전송 계층) 로드 밸런서와, HTTP 헤더와 쿠키(Cookie) 안의 내용을 까보고 스마트하게 길을 찾아주는 L7(응용 계층) 로드 밸런서의 물리적 트레이드오프를 뜯어봅니다. 나아가 Round Robin, Least Connections 등 부하를 찢는 트래픽 분산 알고리즘을 장악합니다. 마지막으로, 단순히 트래픽을 넘기는 것을 넘어 헬스 체크(Health Check)로 죽은 서버를 도려내고, 글로벌 트래픽을 가장 가까운 데이터센터로 쏴주는(GSLB) 무결점 트래픽 라우팅 아키텍처를 설계하는 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• OSI 7 Layer LB: L4 (TCP/UDP, IP/Port 라우팅, NAT) vs L7 (HTTP/HTTPS, URL/Cookie 라우팅, SSL Termination).
• Load Balancing Algorithms: Round Robin, Least Connections, IP Hash.
• Health Checks & Failover: Active/Passive 상태 감지, 죽은 노드 절연(Isolation).
• Global Traffic Management: GSLB (Global Server Load Balancing), Anycast, Geo-routing.

Out-of-Scope

• 네트워크 프로토콜 딥다이브: TCP Handshake, IP 패킷 구조 $\rightarrow$ 08-01 OSI Model & TCP/IP 영역으로 위임.
• 쿠버네티스 Ingress/Service 설정: K8s 내부의 Kube-proxy 라우팅 구현 $\rightarrow$ 09-02 CI/CD & DevOps 영역.

Boundaries

• L4의 깡통 속도 vs L7의 지능: L4 로드 밸런서는 패킷의 껍데기(IP/포트)만 보고 즉시 포워딩(NAT)하므로 마이크로초(us) 단위의 극단적인 속도를 내지만, "유저가 로그인했는지(쿠키)" 알 방법이 없어 정밀 라우팅이 불가능합니다. 반면 L7 로드 밸런서(NGINX, ALB)는 패킷을 완전히 뜯어서 HTTP 헤더까지 다 까본 뒤 "이 URL은 A 서버로, 저 쿠키는 B 서버로" 영리하게 보내지만 파싱 오버헤드로 인해 속도가 느려집니다. 트래픽이 100만 TPS를 넘어가는 엔터프라이즈 환경에서는 L4를 맨 앞에 두어 1차 타격을 방어하고, 그 뒤에 L7 여러 대를 세워 정밀 타격을 분담하는 2단 콤보(Layering) 트레이드오프가 필수적임을 명확히 합니다.

3. Counterexample

• Sticky Session의 역습: 트래픽 분산을 위해 L7 로드 밸런서를 세웠지만, 백엔드 서버가 로컬 세션(Stateful)을 쓰고 있어서 어쩔 수 없이 'Sticky Session(특정 유저는 특정 서버로만 고정)' 설정을 켰습니다. 이벤트가 터지자 유명 인플루언서 1명이 1번 서버에 배정되었고, 그를 따라 들어온 팬들도 모조리 1번 서버로 빨려 들어갑니다. 로드 밸런서가 아무리 "다른 서버가 비어있다"고 소리쳐도 Sticky 룰 때문에 트래픽을 분산하지 못하고 1번 서버만 불타 없어지는 최악의 안티 패턴입니다.
• Health Check의 부재 (좀비 라우팅): 백엔드 서버 5대 중 1대가 멈춰서 에러(500)를 뿜고 있습니다. 로드 밸런서에 '헬스 체크(Health Check)' 주기를 설정해 두지 않거나 너무 길게(5분) 설정했습니다. 로드 밸런서는 그 서버가 죽은 줄도 모르고 계속 트래픽의 20%를 좀비 서버로 쑤셔 넣어, 전체 유저의 1/5이 5분 동안 에러 화면을 보게 만드는 어처구니없는 설정 누락 참사입니다.

4. Prerequisites

• OSI 7계층 (Basic): Transport 계층(L4)과 Application 계층(L7)의 구분. (08-01 OSI Model)
• 수평 스케일링 (Basic): Stateless 아키텍처의 중요성. (07-03-01 Scale-out)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 스피드와 지능의 결투, L4 vs L7 (L4 vs L7 Load Balancing)

• Why to Learn: 대규모 트래픽 앞단에 라우터를 배치할 때, 패킷 껍데기만 볼 것인지 아니면 HTTP 헤더까지 다 까볼 것인지에 따른 컴퓨팅 오버헤드와 기능적 한계를 장악하기 위함입니다.
• What to Learn:
  • Concepts: L4 Load Balancer (TCP/UDP, NAT, DSR), L7 Load Balancer (HTTP/HTTPS, SSL Termination, Reverse Proxy).
  • Skills: NGINX(L7)와 HAProxy/AWS NLB(L4)의 적정 레이어 배치 설계.
• How to Learn:
  • 1단계: L4의 무식한 질주: L4는 클라이언트가 보낸 TCP 패킷의 출발지/목적지 IP와 포트만 봅니다. 내용물(페이로드)은 전혀 보지 않고 도착지 IP만 백엔드 서버 IP로 쓱 바꿔치기(NAT)해서 넘깁니다. 너무 가벼워서 초당 수백만 건을 처리하는 괴력을 해부합니다.
  • 2단계: L7의 정밀 타격: L7은 패킷을 조립해 HTTP 요청서 전체를 읽습니다. "URL이 /video네? 이건 비디오 전용 서버로 보내야지." "HTTPS 암호화가 되어있네? 여기서 내가 복호화(SSL Termination)해서 뒤로는 평문으로 넘겨야지." 엄청나게 똑똑하지만 CPU를 미친 듯이 갉아먹는 오버헤드를 뜯어봅니다.
• Implement: 파이썬 가상 L7 라우터 스크립트. 들어오는 HTTP 헤더(User-Agent: Mobile)를 정규식으로 파싱하여, 모바일이면 Mobile_Backend_List로, 아니면 Desktop_Backend_List로 라우팅하는 분기문 데모(L4에서는 절대 불가능한 논리적 라우팅).

Recommended

Core Topic 02: 분배의 방정식, 라우팅 알고리즘 (Routing Algorithms)

• Why to Learn: 트래픽의 성질(짧은 요청 vs 긴 스트리밍)에 따라 단순히 $1/N$로 나누는 것이 능사가 아님을 깨닫고, 백엔드 서버의 스레드 고갈을 막는 최적의 공식을 세우기 위함입니다.
• What to Learn:
  • Concepts: Round Robin (라운드 로빈), Least Connections (최소 연결), IP Hash (IP 기반 해시), Weighted (가중치 기반).
  • Skills: 워크로드 특성(CPU Bound vs I/O Bound)에 맞는 알고리즘 취사선택.
• How to Learn:
  • 1단계: Round Robin의 배신: 서버 A, B, C에 1-2-3-1-2-3 순서로 나눠줍니다. 그런데 A에 배정된 요청들은 유독 파일 다운로드라 10분씩 걸리는 무거운 요청이었습니다. 라운드 로빈은 이를 무시하고 계속 A에 할당하여, 결국 A 서버만 뻗어버리는 블라인드 분배의 한계를 해부합니다.
  • 2단계: Least Connections의 방어: 로드 밸런서가 뒤를 돌아봅니다. "지금 A 서버는 연결된 커넥션이 100개고, C 서버는 10개네? 그럼 새로 온 요청은 무조건 C로 보내!" 백엔드의 실시간 부하 상태를 모니터링하며 트래픽을 조율하는 능동적 밸런싱을 뜯어봅니다.
• Implement: Least Connection 라우팅 시뮬레이터. 서버 3대의 active_connections 정수 변수 추적. 무작위 길이(1초~5초)의 요청이 들어오면 min(active_connections)를 찾아 해당 서버에 배정(Connection +1)하고 딜레이 후 반환(Connection -1)하는 동적 밸런싱 터미널 렌더링.

Practical

Core Topic 03: 죽은 자를 솎아내다, 헬스 체크와 페일오버 (Health Check & Failover)

• Why to Learn: 서버가 불타서 크래시 나는 상황에서도 유저들은 단 1초의 서비스 중단(Downtime)도 느끼지 못하게 만드는 '고가용성(High Availability)'의 심장 박동 메커니즘을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Health Check (Active vs Passive), Failover (장애 조치), Isolation (격리), Graceful Shutdown.
  • Skills: 로드 밸런서의 타임아웃, 주기, 연속 실패 횟수(Threshold) 파라미터 미세 튜닝.
• How to Learn:
  • 1단계: Active 헬스 체크: 로드 밸런서가 5초마다 백엔드 서버의 /health 엔드포인트를 찔러 봅니다. 서버 A가 3번 연속 응답이 없으면 즉시 라우팅 리스트에서 삭제(Isolation)하여, 이후 들어오는 유저 트래픽이 죽은 서버로 흘러가는 것을 물리적으로 100% 차단하는 기전을 해부합니다.
  • 2단계: 복귀(Recovery): 10분 뒤 서버 A가 재부팅되어 헬스 체크에 다시 '200 OK'를 3번 연속 응답합니다. 로드 밸런서가 다시 라우팅 리스트에 슬며시 끼워 넣어 트래픽을 붓기 시작하는 자동 치유(Auto-healing)를 뜯어봅니다.
• Implement: 헬스 체크 워치독(Watchdog) 파이썬 스크립트. 백그라운드 스레드가 2초마다 백엔드 서버 3대 목록에 핑을 때림. 수동으로 서버 1개의 포트를 내리면, 워치독이 [Server 1 DOWN - Removed from Pool] 로그를 찍고 라우터 배열에서 삭제해 유저 트래픽 유실을 막아내는 데모.

Advanced

Core Topic 04: 대륙을 넘나드는 지배, GSLB (Global Load Balancing)

• Why to Learn: 단일 데이터센터(IDC)가 지진이나 정전으로 통째로 날아갔을 때, 전 세계의 트래픽을 태평양 너머의 다른 데이터센터로 우회시키는 전 지구적 BCP(사업 연속성) 아키텍처를 설계하기 위함입니다.
• What to Learn:
  • Concepts: GSLB (Global Server Load Balancing), DNS Routing, Anycast, Geo-location Routing, Active-Active vs Active-Passive.
  • Skills: 클라우드 Route53 등을 활용한 지역(Region) 기반 뷰(View) 라우팅 및 재난 복구(DR) 스위칭.
• How to Learn:
  • 1단계: DNS 레벨의 거짓말: 일반 로드 밸런서는 IP 하나로 트래픽을 받아 뒤로 넘기지만, GSLB는 DNS 서버 자체가 로드 밸런서입니다. 서울에서 접속한 유저가 google.com의 IP를 물어보면 한국 IDC의 IP를 알려주고, 뉴욕에서 물어보면 버지니아 IDC의 IP를 줘서 아예 패킷이 태평양을 건너지도 않게 만드는 마법을 해부합니다.
  • 2단계: 대륙 간 페일오버(Active-Passive): 평소에는 한국 IDC(Active)로 모든 트래픽을 보냅니다. 한국 IDC에 불이 났습니다. GSLB가 헬스 체크 실패를 감지하고, google.com의 IP를 묻는 모든 한국 유저에게 일본 IDC(Passive)의 IP를 던져주어 5분 만에 전사 서비스를 복구(DR)하는 클라우드의 경이를 뜯어봅니다.
• Implement: Geo-DNS 라우팅 분기문 모사. 클라이언트의 접속 IP를 GeoIP 라이브러리(가상 데이터)로 국가 코드 판별. KR이면 10.0.0.1(서울 서버), US면 192.168.0.1(미국 서버) 문자열을 반환. 만약 서울 서버 status=down 상태일 때 KR 요청 시 일본 서버 10.1.0.1로 대체 반환(Fallback)하는 DR 스크립트 로직 작성.

7. Terminology

8. References

Primary

• [P1] CS2023 - Networking and Communication (NC) - Network Applications (Load Balancing)
• [P5] SFIA - Network Design (NTDS) - Traffic Management

Secondary

• [Systems Performance: Enterprise and the Cloud] Brendan Gregg - Load Balancing and Network Scalability
• [High Performance Browser Networking] Ilya Grigorik - L4 vs L7, Load Balancing

Industry

• [AWS Elastic Load Balancing Documentation] - ALB (L7) vs NLB (L4) differences
• [Cloudflare Learning Center] - What is Global Server Load Balancing (GSLB)?

9. Final Checklist

Primary

• L4 로드 밸런서(IP/Port 기반)와 L7 로드 밸런서(HTTP 헤더 기반)가 패킷을 처리하는 OSI 계층의 물리적 차이와 이로 인한 속도(Latency) 트레이드오프를 설명할 수 있는가?
• 라운드 로빈(Round Robin) 라우팅 방식이 백엔드 서버 성능이 모두 동일하지 않거나 요청의 처리 시간이 제각각일 때 왜 심각한 핫스팟(Hotspot) 붕괴를 일으키는지 증명할 수 있는가?

Secondary

• NGINX나 AWS ALB(L7)가 클라이언트와 맺은 무거운 HTTPS(TLS) 연결을 맨 앞단에서 복호화(SSL Termination) 해버리고, 뒤쪽 백엔드 서버와는 평문(HTTP)으로 통신하여 백엔드 CPU를 구원하는 구조를 해부할 수 있는가?
• 백엔드 서버가 죽었을 때 로드 밸런서가 이를 헬스 체크(Health Check)로 솎아내어 트래픽을 차단하는 과정에서, 설정된 'Threshold(실패 허용 횟수)'가 짧을 때와 길 때 발생하는 리스크를 저울질할 수 있는가?

Industry

• 무상태(Stateless) 아키텍처를 강제하는 클라우드 환경에서, 굳이 IP Hash나 Sticky Session을 활성화하여 트래픽을 특정 노드에 묶어두려 할 때 감수해야 하는 인프라 스케일 아웃 파괴의 대가를 논증할 수 있는가?
• 지진으로 도쿄 데이터센터 전체가 날아갔을 때, GSLB(Global Server Load Balancing)가 DNS 응답 레코드를 즉시 서울 데이터센터 IP로 엎어쳐서 글로벌 트래픽을 우회(Failover)시키는 DR 아키텍처를 설계할 수 있는가?