로드 밸런서는 1990년대 말 웹 서비스가 단일 서버의 한계를 넘기 시작하면서 등장했다. 초기에는 F5나 Cisco의 물리 장비가 데이터센터 랙 안에서 트래픽을 나눴다. 그런데 클라우드 시대가 되면서 로드 밸런서 자체가 "관리해야 할 인프라"가 되었고, AWS ELB는 그것을 완전 관리형 서비스로 추상화했다.
그러나 ELB는 하나가 아니다. ALB(Application LB), NLB(Network LB), GLB(Gateway LB), 그리고 레거시 CLB가 있고, 각각은 서로 다른 OSI 계층에서 동작하며 근본적으로 다른 문제를 해결한다. 이 차이를 OSI 모델과 로드 밸런싱 알고리즘 이론으로 이해하면 시나리오 문제에서 자동으로 답이 보인다.
로드 밸런서의 핵심 역할은 들어오는 요청을 여러 백엔드 서버 중 하나로 분배하는 것이다. "어느 서버로 보낼지"를 결정하는 기준이 OSI 계층에 따라 달라진다.
L4(전송 계층) 로드 밸런싱: TCP/UDP 패킷의 소스 IP, 목적지 IP, 포트만 본다. HTTP 헤더 안을 들여다보지 않는다. 결정이 빠르고 레이턴시가 낮다. 단, "이 요청은 /api/users로 가야 하고 저 요청은 /static/으로 가야 한다"는 구분이 불가능하다.
L7(응용 계층) 로드 밸런싱: HTTP 헤더, URL 경로, 쿠키, 쿼리 파라미터를 파싱해서 라우팅을 결정한다