이번 문서 'L4/L7 로드밸런싱 쉽게 이해하기'와 '서버 부하 분산 쉽게 이해하기', 'L4 스위치 쉽게 이해하기'는 L4/L7 Network Swtich인 'F5 Networks' 장비를 기준으로 설명합니다. Alteon(Radware), Brocade, Cisco, Piolink, Pumkin, Citrix의 관점에서는 다소 다를 수 있습니다.
서버 부하분산과 L4 스위치에 관한 마지막 이야기인 'L4/L7 Load Balancing(이하 L4/L7 로드밸런싱)'입니다. 지금까지는 L4/L7 Virtual Server의 트래픽 플로우와 네트워크 설정 / 구성을 계속 이야기했었죠. #1 ~ #10에서 다룬 내용도 중요하지만 L4 로드밸런싱과 L7 로드밸런싱을 구분하고 각 장단점을 아는 것도 중요합니다. 그래야만 L4 Virtual Server가 필요한 시점과 L7 Virtual Server가 필요한 시점을 파악하고 적재적소에 활용할 수 있기 때문입니다. 그런 의미에서 각 이번 문서에서는 L4 스위치의 본질인 L4 Virutal Server의 로드밸런싱과 L7 Virtual Server의 로드밸런싱의 정의와 이 둘이 갖는 차이에 대해서 보다 자세히 이야기하고자 합니다.
L4 / L7 Load Balancing에 대해 놓치기 쉬운 두 가지
L4/L7 로드밸런싱에 대한 이해에 앞서 혼동하기 쉬운 두 가지에 대해 언급하려고 합니다. 언급에 앞서 아래 내용은 모두 OSI 7 Layer와 관련이 매우 깊음을 알려드립니다. OSI 7 Layer 쉽게 이해하기를 아직 보지 못 하신 분은 링크를 참조하세요.
첫 번째
"L2 스위치는 이더넷 스위칭을, L3 스위치는 IP 라우팅을, L4 스위치는 서버 로드밸런싱을 한다는데 각자 자신이 속한 계층에서만 활용 가능한 것 아닌가요?"
네트워크 장비를 처음 접하시는 분이 흔하게 실수하는 것이 바로 각 계층에서 사용되는 스위치가 다른 계층에서는 사용되지 않는다고 생각하는 것입니다. 예를 들어 L4 스위치는 L3 혹은 L2 스위치의 용도로 사용할 수 없다고 생각하는 것에 해당합니다. 결론 먼저 말하면 그렇지 않습니다. OSI 7 Layer에서 설명하는 것처럼 데이터가 사용자에게 도달하기 위해서는 L1,L2,L3, ... , L7까지 순차적으로 올라가야 하며, 사용자가 데이터를 다른 이에게 전달하기 위해서는 L7, L6, L5, ..., L1까지 순차적으로 내려가며 이동해야 합니다. 그러므로 하위 레벨의 스위치가 데이터를 이해하게 하려면 상위 레벨 계층의 스위치가 그에 맞춰 데이터를 꾸며야 합니다. 다시 말해 상위 레벨의 스위치라면 자신의 아래 있는 모든 하위 레벨의 스위치를 이해해야 함을 의미합니다.
L4 스위치가 사용자의 요청을 받아 포트를 확인하고(Layer 4) 로드밸런싱을 하고자 할 때 서버와 L4 스위치 사이에 L2 스위치가 있다면, L4 스위치는 L2 스위치가 이해할 수 있는 Ethernet Frame Header를 씌워 전달해야 합니다. 다시 말해 Layer 4의 Segment에 Layer 3 IP Header를 덧씌우고 Layer 2 Ethernet Frame Header를 씌워 L2 스위치가 이해할 수 있는 이더넷 프레임을 만들어야 하는 것이죠.
또 다른 경우를 보겠습니다. L4 스위치가 사용자의 요청을 받아 포트를 확인하고(Layer 4) 로드밸런싱을 하고자 할 때 L4 스위치와 서버 사이에 라우터(L3 스위치)가 있다면, L4 스위치는 라우터가 이해할 수 있는 IP Header를 씌워 목적지를 알리고, 라우터에게 전달할 수 있도록 라우터의 MAC 주소를 Ethernet Frame Header에 덧붙여야 합니다. 라우터는 데이터를 받아 Ethernet Frame Header를 벗겨내고 IP 정보를 확인하고 목적지를 결정한 뒤 Next hop의 MAC 주소를 Ethernet Frame Header에 붙일 것입니다.
위의 두 가지 사례에서 알 수 있는 점은 상위 계층을 활용할 수 있는 장비들은 모두 하위 계층 또한 이해하고 활용할 줄 알아야 한다는 것입니다. L4 스위치와 라우터가 L3 IP 패킷과 L2 이더넷 프레임을 이해하지 못 한다면 직결된 장비에게 데이터를 보낼 수 없겠죠. 이를 거꾸로 말하면 L4 스위치 또한 IP Header를 이해할 수 있기에 라우터처럼 활용할 수 있고, Ethernet Frame Header를 이해할 수 있기에 L2 스위치처럼 사용할 수 있습니다. 라우터(L3 스위치) 또한 Ethernet Frame Header를 이해할 수 있기 때문에 L2 스위치처럼 사용할 수 있죠. 그러나 L4 스위치나 L3 스위치는 상위 레벨 헤더 분석을 할 수 있는 만큼 고가이기 때문에 하위 레벨의 역할에는 사용하지 않습니다. 그렇게 사용하는 것은 낭비겠죠. 할 수는 있으나 하지 않는 것입니다.
두 번째
"L4 Virtual Server는 TCP/UDP만을 다루는 로드밸런서이고, L7 Virtual Server는 주로 HTTP/HTTPS만을 다루는 로드밸런서 아닌가요?"
이는 반만 맞고 반은 틀린 말입니다. 첫 번째에서 언급했던 것처럼 상위 레벨의 역할을 수행하는 스위치는 하위 역할의 프로토콜을 모두 이해해야 합니다. HTTP 헤더를 분석할 수 있는 L7 Virtual Server는 로드밸런싱을 위해 하위 레벨인 TCP를 반드시 이해해야 하며 TCP Header를 분석할 줄 알아야 합니다. (TCP/IP 쉽게 이해하기를 참조하세요.) 즉 L4 Virtual Server는 L2, L3, L4 레벨을 이해할 수 있으며, HTTP 로드밸런싱을 위한 L7 Virtual Server는 L2, L3, L4, L7 레벨을 이해할 수 있음을 의미합니다. 아래 그림처럼 말이죠.
그렇다면 왜 L4 Virtual Server와 L7 Virtual Server를 나눠 사용하며 굳이 구분을 짓는 것일까요? 그냥 모든 레벨을 해석할 수 있는 L7 Virtual Server만 있으면 되는 것 아닐까요? 그렇지 않습니다. 사람이 모든 움직임에 에너지를 소모하듯 기계도 모든 트래픽 처리에 리소스를 소모합니다. 사용자의 요청을 로드밸런싱하는데 HTTP 헤더를 해석할 필요 없이 단순히 서버 부하분산에만 목적을 둔다면 HTTP 헤더 해석은 불필요한 리소스 소모에 불과합니다. 상위 레벨의 프로토콜 이해 없이 TCP/UDP 로드밸런싱이 필요하면 L4 Virtual Server를 사용하면 됩니다. HTTP를 비롯한 Layer 7 헤더 해석이 필요하다면 L7 Virtual Server를 사용하면 되겠죠. 그렇기에 불필요한 리소스 소모를 줄이고 각자의 역할에 집중할 수 있도록 역할을 구분 짓기 위해 Virtual Server를 분리하는 것입니다. HTTP 헤더를 이용한 로드밸런싱이 필요한 경우에만 L7 Virtual Server를 사용하면 되겠죠?
L7 Virtual Server라고 하면 HTTP/HTTPS 로드밸런싱이 대부분이기 때문에 HTTP를 위한 Virtual Server라고 생각하기 쉽습니다. AWS에서 제공하는 Elastic Load Balancer 중 하나인 Application Load Balancer 또한 HTTP/HTTPS를 위한 L7 로드밸런서이죠. 하지만 L7 Virtual Server는 다양한 Layer 7 프로토콜을 지원할 수 있습니다. F5 Networks BIG-IP 시리즈 L4 스위치의 Virutal Server Profile을 보면 알 수 있죠.
위는 F5 Networks BIG-IP 시리즈 L4 스위치의 Virutal Server Profile로 L7 Virtual Server의 성격을 정의하는 'Profile'입니다. Profile에 있는 프로토콜 중 하나를 선택하면 Virutal Server가 해당 프로토콜의 헤더를 분석하여 로드밸런싱할 수 있게 됩니다. 이처럼 L7 Virtual Server는 HTTP/HTTPS만을 활용하는 Virtual Server가 아닌 Layer 7의 프로토콜을 활용하는 Virtual Server입니다.(물론 벤더마다 차이가 있습니다.)
L4 Load Balancing
L4 로드밸런싱은 Layer 4(TCP와 UDP)에서 IP와 Port를 활용하여 서버부하분산을 하는 것을 의미합니다. 적합한 Virutal Server IP와 Port를 목적지로 들어온다면 골고루 서버에 부하 분산합니다. 뿐만 아니라 TCP와 UDP의 특징을 이용하기 때문에 TCP를 선택하거나 UDP를 선택하거나 두 프로토콜 모두를 선택하여 Virtual Server의 성격을 정의하여 Profile을 통해 (로드밸런싱이 아닌) 행동을 제어할 수 있습니다.
TCP를 사용할 경우 사용자와 서버가 논리적인 Connection(이하 커넥션)을 맺을 수 있도록 중간자의 입장에서 3-way handshake 실시를 지원합니다. 사용자와 서버가 생성하여 던지는 SYN, SYN/ACK, ACK Flag Packet을 순서대로 전달하죠. '3-way handshake 실시를 지원한다'는 모호한 표현을 쓴 이유는 F5 Networks Switch처럼 3-way handshake에 적극적으로 개입할 수 있는 L4 스위치도 있지만 매우 소극적으로 IP와 Port를 활용한 로드밸런싱 / 커넥션 생성만 하는 L4 스위치도 존재하기 때문입니다.
로드밸런싱의 기준점이 IP와 Port이기 때문에 TCP/UDP의 Header를 분석하여 로드밸런싱에 활용하지는 않습니다. 그래서 프로토콜 헤더를 통해 로드밸런싱하기보다 해당 프로토콜들의 특성으로 인한 행동을 제어하는 편입니다. 예를 들어 3-way handshake를 제어하거나 커넥션을 언제 끊을 것인지, 커넥션을 얼마나 유지할 것인지, Connection Time out에 도달하면 어떻게 할 것인지 등을 제어합니다.
위 그림은 L4 Virtual Server의 Profile로 Connection Time out에 도달하면 L4 스위치가 어떻게 행동할 것인지를 정의하는 'Reset on Timeout', Conenction의 유지 시간을 의미하는 'Idle Timeout', TCP 3-way Handshake의 제한 시간을 정의하는 'TCP Handshake Timeout' 등을 볼 수 있습니다.
TCP의 3-way/4-way handshake 의무를 해제하는 'Loose Initiation / Loose Close', 커넥션 삭제 직전 대기 시간을 갖는 'TCP Close Timeout'도 보입니다. 이처럼 L4 로드밸런싱은 IP와 Port를 활용해 부하분산을 실시하는 것을 의미하며 TCP / UDP의 특징을 활용한 그 밖의 부가 행동에 초점이 맞추어져 있음을 알 수 있습니다.
L7 Load Balancing
L7 로드밸런싱은 Layer 4(TCP와 UDP)를 넘어 Layer 7 프로토콜의 헤더를 분석하여 로드밸런싱을 실시하는 것을 의미합니다. IP와 Port를 사용하여 로드밸런싱을 하는 것은 같으나 Layer 7 프로토콜을 통해 사용자 정의 로드밸런싱을 실시하거나 Layer 7 프로토콜 헤더를 조작 / 활용할 수 있다는 특징이 있습니다. TCP와 UDP를 활용하기 때문에 L4 Virtual Server처럼 Layer 4 프로토콜과 Layer 4 프로토콜 Profile을 설정하며 Layer 7 프로토콜 Profile 선택을 통해 L7 Virtual Server의 성격을 정의합니다. 아래 그림을 보시면 L7 Virtual Server의 Layer 4 프로토콜 정의와 그에 따른 Layer 7 프로토콜 Profile을 보실 수 있습니다.
Layer 7 프로토콜은 Layer 4 프로토콜과 별개로 움직이는 것이 아닙니다. 어떤 프로토콜들은 TCP를 기반으로 움직이며 어떤 프로토콜들은 UDP를 기반으로 움직입니다. 예를 들어볼까요? HTTP는 TCP 기반의 프로토콜입니다. 그렇기 때문에 HTTP 통신을 하기 위해서는 반드시 3-way handshake를 실시하여 신뢰성 있는 연결을 생성하여야 합니다. 그다음에 HTTP GET을 통해 리소스를 얻어오거나 POST를 통해 업데이트를 실시하는 것입니다. 왜 L7 Virtual Server 설정시 Layer 4의 프로토콜을 정의해야 하는지 감이 오시나요?
한 가지 더 예를 들어 보겠습니다. DNS는 TCP/UDP 모두를 활용하는 Layer 7 프로토콜입니다. 기본적으로 DNS는 UDP를 사용하지만 전달해야 하는 패킷의 크기 달라지면 말이 달라집니다. UDP는 패킷의 크기가 512bit를 초과할 수 없기 때문에 DNS를 로드밸런싱 중 패킷의 크기가 512bit가 넘어버리는 경우, TCP를 사용합니다. 그렇기에 DNS를 제대로 로드밸런싱하기 위해서는 TCP 기반의 L7 Virtual Server와 UDP 기반의 L7 Virtual Server 모두 생성해야 합니다.
Layer 4 프로토콜과 Layer 4 프로토콜 Profile 설정을 끝마치면 Layer 7 프로토콜 Profile 선택을 통해 원하는 Layer 7 프로토콜 헤더를 활용할 수 있습니다. HTTP Profile을 먼저 살펴 볼까요?
HTTP Profile을 살펴보니 HTTP 헤더를 활용한 여러 기능들이 보입니다. Pool Member가 모두 Health Check Down일 경우 302 Response Code를 이용해 다른 URL로 이동시키는 'Fallback Host', HTTP Header 사용자가 원하는 사용자 정의 헤더를 집어 넣을 수 있는 'Request Header Insert', Source IP NAT시 사용자의 IP를 헤더에 담아 전달하는 'Insert X-Forwared-For'가 보입니다. 이처럼 그밖에 HTTP의 헤더를 통해 특정 Pool Member로만 로드밸런싱이 실시되도록 할 수 있습니다. 이 기능들 모두 L7 Virtual Server가 HTTP Profile을 보유하여 HTTP 헤더를 해석할 수 있기에 가능한 것이죠.
기타 다른 프로토콜의 Profile 또한 동일합니다. DNS Profile을 선택하면 DNS Server를 로드밸런싱하며 'Zone Transfer'에 대한 요청이 있을 때 L7 Virtual Server가 대신하여 Response하는 등의 행동을 할 수 있습니다. FTP Profile을 선택하면 FTP의 데이터 포트를 설정할 수 있으며(Default Port 20) 수 있죠.
위 내용을 종합해보면 L7 로드밸런싱은 Layer 4 프로토콜과 Profile을 활용할 수 있을 뿐만 아니라 Layer 7 프로토콜 Profile을 통해 Layer 7 프로토콜 헤더를 읽고 활용할 수 있음을 의미한다고 할 수 있습니다.
'Network Infra 쉽게 이해하기 > L4 & L7 Network 쉽게 이해하기' 카테고리의 다른 글
| Source IP NAT 쉽게 이해하기 (6) | 2021.11.21 |
|---|---|
| NAT 쉽게 이해하기 (19) | 2021.09.18 |
| L4 스위치 쉽게 이해하기 #10(이중화) (25) | 2021.03.02 |
| L4 스위치 쉽게 이해하기 #9(2, 네트워크 구성 두 번째) (14) | 2021.01.27 |
| L4 스위치 쉽게 이해하기 #9(1, 네트워크 구성) (10) | 2021.01.15 |
댓글