레이어 4 로드 밸런싱은 네트워킹 전송 레이어(레이어 4)에 정의된 정보를 사용하여 클라이언트 요청을 서버 그룹에 분산하는 방법을 결정합니다. 특히 인터넷 트래픽의 경우, 레이어 4 로드 밸런싱은 패킷의 콘텐츠를 고려하지 않고 패킷 헤더에 기록된 소스 및 대상 IP 주소와 포트에 기반하여 로드 밸런싱 결정을 내립니다.
총 7개의 네트워킹 레이어가 있으며, 개방형 시스템 간 상호 연결[OSI] 참조 모델에 의해 정의됩니다. 자세한 내용은 아래의 OSI 및 인터넷 모델의 레이어를 참조하십시오.
로드 밸런싱에 대한 자세한 내용은 NGINX Plus를 사용한 애플리케이션 로드 밸런싱을 참조하십시오.
오늘날 "레이어 4 로드 밸런싱"이라는 용어는 일반적으로 로드 밸런서의 IP 주소가 웹 사이트 또는 서비스를 위해 클라이언트에 알려지는 위치에 배포되는 것을 의미합니다(예: DNS를 통해). 따라서 클라이언트는 로드 밸런서의 주소를 요청의 대상 IP 주소로 기록합니다.
레이어 4 로드 밸런서가 요청을 수신하고 로드 밸런싱 결정을 내릴 때, 요청 패킷에 대해 NAT(네트워크 주소 변환)를 수행하여 기록된 대상 IP 주소를 자체 주소에서 내부 네트워크에서 선택한 콘텐츠 서버의 주소로 변경합니다. 마찬가지로 로드 밸런서는 서버 응답을 클라이언트에 전달하기 전에 패킷 헤더에 기록된 소스 주소를 서버의 IP 주소에서 자체 주소로 변경합니다. (패킷에 기록된 대상 및 소스 TCP 포트 번호 역시 비슷한 방식으로 변경되는 경우도 있습니다.)
레이어 4 로드 밸런서는 TCP 스트림에 있는 처음 몇 개의 패킷에서 추출한 주소 정보를 기반으로 라우팅 결정을 내리며 패킷 콘텐츠를 검사하지 않습니다. 레이어 4 로드 밸런서는 공급업체에서 제공하는 전용 하드웨어 디바이스이고 독점적인 로드 밸런싱 소프트웨어를 실행하는 경우가 많으며, NAT 작업은 소프트웨어가 아닌 특화된 칩에서 수행될 수 있습니다.
레이어 4 로드 밸런싱은 상용 하드웨어가 지금처럼 강력하지 않고 클라이언트와 애플리케이션 서버 간의 상호 작용이 훨씬 덜 복잡했을 때 트래픽을 처리하기 위해 많이 사용된 아키텍처 방식이었습니다. 훨씬 정교한 로드 밸런싱 방법(예: 레이어 7)보다 계산이 덜 필요하지만, 이제 CPU와 메모리는 충분히 빠르고 저렴해져 대부분의 상황에서 레이어 4 로드 밸런싱의 성능 이점이 무시할 수 있거나 무의미해졌습니다.
레이어 7 로드 밸런서는 OSI 모델의 가장 높은 수준인 애플리케이션 레이어에서 작동합니다(인터넷에서 HTTP는 이 레이어의 주요 프로토콜입니다). 레이어 7 로드 밸런서는 HTTP 헤더의 다양한 특성과 URL, 데이터 유형(텍스트, 비디오, 그래픽) 또는 쿠키의 정보 등과 같은 메시지의 실제 콘텐츠를 기반으로 라우팅을 결정합니다.
전송되는 정보의 더 많은 측면을 고려하기 때문에 레이어 7 로드 밸런싱은 시간과 필요한 컴퓨팅 성능 측면에서 레이어 4보다 비용이 많이 들 수 있지만, 그럼에도 불구하고 전반적인 효율성이 향상될 수 있습니다. 예를 들어 레이어 7 로드 밸런서는 클라이언트가 요청하는 데이터 유형(비디오, 텍스트 등)을 확인할 수 있으므로 모든 로드 밸런싱된 서버에 동일한 데이터를 복제할 필요가 없습니다.
최신 범용 로드 밸런서(예: NGINX Plus 및 오픈 소스 NGINX 소프트웨어)는 일반적으로 레이어 7에서 작동하며 완전한 역방향 프록시 역할을 합니다. NAT를 사용하는 레이어 4 로드 밸런서처럼 패킷 단위로 트래픽을 관리하는 것이 아니라 레이어 7 로드 밸런싱 프록시가 전체 요청과 응답을 읽을 수 있습니다. 또한 클라이언트와 애플리케이션 서버 간의 트랜잭션을 완전히 이해하여 트래픽을 관리하고 조작합니다.
일부 로드 밸런서는 서비스 특성에 따라 레이어 4 또는 레이어 7 로드 밸런싱을 제공하도록 구성할 수 있습니다. 앞서 언급했듯이 최신 상용 하드웨어는 일반적으로 충분히 강력하기 때문에 레이어 4 로드 밸런싱으로 인한 컴퓨팅 비용 절감 효과가 레이어 7 로드 밸런싱의 유연성 및 효율성 향상이라는 이점을 능가할 만큼 크지 않습니다.
NGINX Plus와 NGINX는 Dropbox, Netflix, Zynga 등과 같이 트래픽이 많은 웹사이트에서 사용되는 동급 최고의 로드 밸런싱 솔루션입니다. 전 세계 3억 5천만개 이상의 웹사이트가 콘텐츠를 빠르고 안정적이며 안전하게 제공하기 위해 NGINX Plus와 NGINX Open Source를 사용하고 있습니다.
소프트웨어 기반 로드 밸런서인 NGINX Plus는 비슷한 기능을 갖춘 하드웨어 기반 솔루션보다 비용이 훨씬 덜 듭니다. NGINX Plus의 포괄적인 로드 밸런싱 기능을 사용하면 고도로 최적화된 Application Delivery Network를 구축할 수 있습니다.
서버 팜의 전면에 로드 밸런서로 NGINX Plus를 삽입하면 전체 웹사이트의 효율성, 성능, 신뢰성 및 확장성이 향상됩니다. NGINX Plus는 고객 만족도와 IT 투자 수익을 모두 극대화할 수 있도록 도와줍니다.
인터넷 트래픽에서 “레이어 4” 및 “레이어 7” 로드 밸런싱이라고 하는 것은 편리한 줄임말이지만 엄밀히 말하면 정확하지는 않습니다. 관심이 있으시면 계속 읽어보십시오.
7개의 네트워킹 레이어 개념은 개방형 시스템 간 상호 연결(OSI) 참조 모델에서 유래했습니다. 이 모델은 네트워크 기능을 7개의 추상화된 레이어로 구분하며, 일반적으로 번호(레이어 1 ~ 레이어 7)로 지칭합니다. 각 레이어에는 데이터가 패키징되고 전송되는 방식을 정의하는 표준이 있습니다. 무엇보다도 해당 표준은 요청 또는 응답을 구성하는 비트 스트림을 프로토콜 데이터 단위(PDU)라는 개별 패키지로 분할하는 방법을 정의합니다. 또한 이 표준은 각 PDU에 헤더 형태로 추가되는 메타데이터를 정의합니다. 예를 들어 메타데이터는 출발지 호스트 및 목적지 호스트의 주소를 지정할 수도 있습니다.
네트워크 기능의 다양한 측면을 서로 다른 레이어에 할당하면 각 계층의 처리가 단순화되는데, 이는 프로토콜이 자체 레이어의 PDU를 처리하는 방법과 헤더에 포함할 메타데이터만 알면 인접 레이어의 프로토콜이 자체 데이터 세분화 수준에서 PDU를 재패키징할 수 있기 때문입니다.
인터넷 프로토콜(IP) 스위트로 통칭되는 월드와이드웹의 트래픽을 위한 기본 프로토콜 간의 네트워크 기능 분포는 OSI 모델과 정확히 일치하지 않습니다. 이는 1984년 OSI 모델이 확정되기 전에 IP 스위트가 정의되고 구현되었기 때문입니다. 그럼에도 불구하고 IP 스위트의 다양한 프로토콜은 OSI 레이어와 대략적으로 일치하는 고유 기능을 수행합니다.
각 수준에는 여러 프로토콜이 정의되어 있지만 웹사이트 트래픽의 로드 밸런싱과 관련된 프로토콜 및 수준은 다음과 같습니다.
이 목록에서 명확히 알 수 있듯이, 인터넷 트래픽의 "레이어 4 로드 밸런싱"은 편리한 줄임말이지만 보다 정확한 용어는 "레이어 3/4 로드 밸런싱"인데, 로드 밸런서가 원본 및 대상 서버의 IP 주소(레이어 3)와 애플리케이션의 TCP 포트 번호(레이어 4)를 기반으로 결정을 내리기 때문입니다. 또한 HTTP가 OSI 레이어 5, 6, 7의 기능을 통합하므로 "레이어 7 로드 밸런싱"은 "레이어 5 ~ 7 로드 밸런싱"이라고 하는 것이 더 정확한 용어입니다.