현대 로드 밸런서의 L4 vs L7 스위칭 패킷 해부학적 구조 해석과 DSR(Direct Server Return) 루팅 기법

장애 대응을 하다가 밤을 꼬박 새운 어제, 원인은 의외로 사소한 아키텍처 설계 미스였습니다. 저와 같은 실수를 반복하지 않으시길 바라며 이 글을 씁니다. 글로벌 규모의 서비스 시스템에서 단일 서버 노드가 수백만 건의 클라이언트 요청을 감내하는 것은 불가능에 가깝습니다. 서비스의 가용성 보장을 위해 사용자의 연결 점점을 분할하여 백엔드 클러스터로 리다이렉트 시켜주는 핵심 네트워크 미들웨어가 바로 로드 밸런서(Load Balancer)입니다. 엔지니어링 관점에서 로드 밸런서는 ISO OSI 7계층 참조 모델 중 어느 계층(Layer)의 헤더를 검사하고 조작하여 패킷을 배기하느냐에 따라 L4 계층의 IP/포트 기반 로드 밸런서와 L7 계층의 웹 어플리케이션(HTTP) 기반 로드 밸런서로 나뉩니다. L4 밸런서는 TCP 패킷 헤더의 근원지와 목적지 IP, MAC 장비 주소 등의 저수준 메타데이터만 훑어본 뒤 NAT(Network Address Translation) 기술로 패킷의 페이로드(Payload)를 아예 열어보지도 않은 채 타겟 내부 서버들에게 라운드 로빈 등 해싱 배분 처리를 실시합니다. 덧씌워진 암호화 트래픽(HTTPS)을 풀지 않고 즉시 토스하므로 오버레이 네트워크 연산 병목이 매우 적어 대규모 초당 접속(CPS) 방어선에 흔히 배치됩니다. 반면 Nginx나 HAProxy, 클라우드 벤더의 ALB(Application Load Balancer)와 같은 L7 로드 밸런서는 네트워크 엔벨로프를 완전히 벗겨내고 그 안에 숨겨진 본연의 HTTP 요청 문맥, 즉 Request URL 패턴이나 쿠키, 세션 속성에 따라 고지능적이며 동적인 리버스 프록시 스위칭을 단행합니다. 비디오 스트리밍 경로는 C드라이브 계열 마이크로서비스로 전송(Route)하고, 결제 API는 보안 모듈로 송신하는 API 게이트웨이의 기능을 흡수할 수 있습니다. 단, TCP 커넥션을 두 번 생성(클라이언트-로드밸런서-백엔드)하여야 하고, 인증서 복호화(TLS Offloading) 연산이 미들웨어에게 과중한 CPU 스로틀링을 부과한다는 기술적 비용을 치러야 합니다. 클라이언트로부터 수신하는 패킷은 일반적으로 몇십 바이트에 불과하지만 백엔드가 처리해 반환하는 응답 패킷(동영상, 고해상도 이미지)의 크기가 수십 메가바이트로 이질적일 경우, 모든 리스폰스 대역폭을 로드 밸런서가 받아내다가 병목 지점(Choke Point)으로 전락하는 비극이 발생합니다. 이 비대칭적인 다운스트림 트래픽 문제를 기적적으로 피하기 위한 구조적 해답이 바로 DSR(Direct Server Return) 기법입니다. DSR 모드로 세팅된 L4 로드 밸런서는 사용자 패킷의 IP 부분을 전혀 훼손하지 않은 채, 단지 데이터 링크 계층(MAC Address) 정보만 살짝 목적지 백엔드 서버의 MAC으로 바꿔치기하여 전송합니다. 패킷을 수신한 백엔드는 VIP(Virtual IP) 주소가 로컬 루프백 어댑터에 앨리어싱 되어있어 스스로가 진정한 수신 대상이라 착각하고 데이터를 생성합니다. 가장 경이로운 점은 이 응답 패킷을 완성한 백엔드 컴퓨터가 로드 밸런서를 거치지 않고, 공인 네트워크 라우터를 통해 클라이언트에게 곧장 직통 배송(Direct Feedback)한다는 사실입니다. 이에 따라 로드밸런서는 들어오는 미량의 핑 스트림만 관리하면 되기 때문에 한 대의 기기로 수백 테라바이트 급의 출구 응답 대역을 관장할 수 있는 어마어마한 인프라스트럭처 효율화를 이루게 됩니다.