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