💡 Author's Note (탐구자의 시선) 본 포스팅은 특정 클라우드 벤더(AWS, GCP 등)의 공식 가이드라인이나 시니어 아키텍트의 권위서가 아닙니다. 엔터프라이즈 환경에서 대규모 트래픽이 다운되지 않고 분산되는 백엔드 네트워크 원리가 궁금해, 로드 밸런싱 알고리즘과 OSI 계층 데이터를 바탕으로 직접 추적해 본 'IT 인프라 탐구 기록'입니다.

엔터프라이즈 서버 아키텍처 : L4/L7 로드 밸런싱(Round Robin vs Least Connection) 탐구

 수백만 명의 유저가 동시에 접속하는 글로벌 서비스나 대규모 수강 신청 시스템이 마비되지 않고 버티는 이유는 무엇일까? 단일 서버의 하드웨어 스펙을 끌어올리는 스케일 업(Scale-up) 방식은 물리적, 경제적 한계가 뚜렷하다. 결국 여러 대의 서버를 병렬로 배치하여 부하를 분산하는 스케일 아웃(Scale-out) 구조를 취해야 하는데, 이때 밀려드는 트래픽의 교통정리를 담당하는 핵심 인프라가 바로 로드 밸런서(Load Balancer)다. 네트워크 계층별 로드 밸런싱의 차이와 그 이면에서 작동하는 트래픽 분배 알고리즘의 원리를 엔지니어링 관점에서 뜯어보았다.

OSI 계층에 따른 분산 : L4 vs L7 로드 밸런싱

 로드 밸런서는 트래픽을 어느 계층(Layer)의 데이터를 기준으로 판단하고 분배하느냐에 따라 크게 L4와 L7으로 나뉜다.

 L4 로드 밸런싱은 전송 계층(Transport Layer)에서 동작한다. 클라이언트의 IP 주소와 포트(Port) 정보만을 바탕으로 패킷을 각 서버로 분배한다. 데이터의 내부(콘텐츠)까지는 들여다보지 않기 때문에 처리 속도가 매우 빠르고 연산 부하가 적어, 거대한 트래픽을 1차적으로 쳐내야 하는 대규모 서비스의 앞단에 주로 배치된다.

 반면 L7 로드 밸런싱은 애플리케이션 계층(Application Layer)까지 올라간다. HTTP 헤더, 쿠키, URL 경로 등 요청의 구체적인 페이로드(Payload)를 모두 분석한다. 예를 들어 URL에 '/image'가 포함되어 있으면 이미지 전용 서버로, '/video'가 있으면 미디어 서버로 정밀하게 라우팅할 수 있다. 대신 패킷을 일일이 열어봐야 하므로 L4에 비해 장비의 연산 부하가 크다.

부하 분산의 뇌 : Round Robin과 Least Connection

 장비의 계층적 차이만큼이나 중요한 것이, 도대체 '어떤 기준'으로 다음 트래픽을 특정 서버에 넘겨줄 것인가를 결정하는 분산 알고리즘이다.

 가장 직관적이고 고전적인 방식은 라운드 로빈(Round Robin)이다. 1번 서버, 2번 서버, 3번 서버 순으로 들어오는 요청을 차례대로 균등하게 배분한다. 각 서버의 스펙이 동일하고 연결 하나당 처리 시간이 비슷할 때 가장 뛰어난 효율을 보여준다.

📝 인프라 노트 : 라운드 로빈의 한계와 Least Connection의 도입
 만약 어떤 유저는 단순 텍스트만 요청하고, 다른 유저는 무거운 파일 다운로드를 요청한다면 어떻게 될까? 라운드 로빈 방식은 서버가 현재 얼마나 헉헉대고 있는지(처리 부하)를 무시하고 기계적으로 트래픽을 쑤셔 넣는다. 결국 특정 서버에만 무거운 작업이 몰려 서버가 뻗어버리는 병목 현상이 발생할 수 있다.

 이를 해결하기 위해 등장한 것이 최소 연결(Least Connection) 알고리즘이다. 로드 밸런서가 각 서버의 현재 활성화된 세션(연결) 수를 실시간으로 파악하여, 가장 연결 수가 적고 여유로운 서버에 새로운 트래픽을 배정하는 동적인 분산 방식이다.

 엔터프라이즈 환경에서는 이러한 알고리즘들에 서버의 스펙 차이를 가중치로 부여하는 가중치 라운드 로빈(Weighted Round Robin) 등을 혼합하여 시스템을 최적화한다. 보이지 않는 백엔드의 세계에서 단 1밀리초의 지연과 단 1%의 병목을 줄이기 위해 설계된 로드 밸런싱 아키텍처는, 웹 서비스 생존을 위한 가장 정교한 공학적 방어선이다.