L4 스위치 쉽게 이해하기 #2(Traffic Flow)
이번 문서 'L4 스위치 쉽기 이해하기'와 '서버 부하 분산 쉽게 이해하기', 다음에 이어질 문서인 'L4/L7 로드밸런싱 쉽게 이해하기'는 L4/L7 Network Swtich인 'F5 Networks' 장비를 기준으로 설명합니다. Alteon(Radware), Brocade, Cisco, Piolink, Pumkin, Citrix의 관점에서는 다소 다를 수 있습니다.
이번 문서에서는 사용자가 L4 스위치를 액세스 할 때의 트래픽 플로우는 어떻게 되는지 그에 따른 L4 로드밸런싱과 L7 로드밸런싱의 차이가 무엇인지 알아보겠습니다. L4 스위치는 단순히 Layer 4를 이용하여 로드밸런싱하는 것뿐만 아니라 실제 사용자가 직접 접근하는 프로토콜인 Layer 7까지 제어하며 로드밸런싱을 실시할 수 있습니다. Layer 4만을 제어하며 로드밸런싱 하느냐 Layer 4와 Layer 7 모두를 제어하며 로드밸런싱 하느냐에 따라 L4 스위치의 Virtual Server의 Type과 역할, 트래픽 플로우가 달라지게 됩니다.
즉 L4 Type Virtual Server와 L7 Type Virtual Server로 나뉘는 것이죠. 그리고 L4 스위치는 다수의 L4 Virtual server와 L7 Virtual Server를 가질 수 있답니다. 이것을 이해하기 위해서는 먼저 Layer 4와 Layer 7에서의 L4 스위치의 행동과 TCP의 3-way handshake에 대해 이해해야 합니다.
Layer 4와 Layer 7
Application Layer(7 Layer)
사용자가 UI로 접하는 응용 프로그램과 관련된 계층으로 HTTP,FTP,DHCP,SMTP,DNS 등이 있습니다. 여기에 속한 프로토콜들은 어떠한 방법으로든 사용자와 직접 접하게 됩니다.
(Data + HTTP Header)
Transport Layer(4 Layer)
송신자와 수신자의 논리적 연결(Connection)을 담당하는 부분으로, 신뢰성 있는 연결을 유지할 수 있도록 도와줍니다. 즉 endpoint(사용자) 간의 연결을 생성하고 데이터를 얼마나 보냈는지 얼마나 받았는지, 제대로 받았는지 등을 확인합니다. TCP와 UDP가 대표적입니다.
(Data + HTTP Header + TCP Header)
출처: OSI 7 Layer 쉽게 이해하기
[네트워크 엔지니어 환영의 AWS 기술블로그]
80이라는 숫자는 Port입니다. 여기서 왜 이름이 'L4 스위치'인지 드러나는군요. OSI 7 Layer 중 Layer 4의 정보인 Port를 사용하기 때문입니다. 서버는 다양한 서비스를 제공합니다. 하나의 서버에서 웹 서비스를 제공하더라도 80, 8080, 8888 Port 등 종류별로 다양한 웹서비스를 제공할 수 있습니다. 만약 Port를 모른 상태에서 IP 정보만을 가지고 접속한다면 어느 Port로 접속해야 할지 모르겠죠? 그래서 L4 스위치에는 외부에서 접속할 IP뿐만 아니라 Port를 명시해주어야 합니다.
출처 : L4 Switch 쉽게 이해하기
[네트워크 엔지니어 환영의 AWS 기술블로그]
앞서 TCP/IP 쉽게 이해하기 문서에서도 말씀드렸지만 기본적으로 L4 스위치는 통신하는 데 있어 IP(Layer 3)와 Port(Layer 4)가 필요합니다. 목적지에 도달하는 것(IP)뿐만 아니라 송신자와 수신자의 논리적 연결을 생성(Port)하고 데이터 전송에 기여하기 때문입니다. 또한 선택적으로 사용자와 서버가 사용하고자 하는 프로토콜인 Layer 7(HTTP, DNS, SMTP, FTP)에도 관여할 수 있습니다.
L4 스위치는 TCP 혹은 UDP의 특성을 이용/제어하여 송신자와 수신자의 논리적 연결을 생성할 뿐만 아니라 L4 스위치의 목적인 로드밸런싱을 실시합니다. 이를 'L4 로드밸런싱'이라고 합니다.
TCP / UDP를 이용하여 논리적 연결을 생성하는 것을 넘어 사용자와 서버가 사용하는 Layer 7의 프로토콜(HTTP, DNS, FTP 등)에 간섭하여 를 기반으로 로드밸런싱을 실시하거나 프로토콜의 헤더에 필요한 정보를 삽입할 수 있습니다. 이때 Layer 4의 TCP / UDP 헤더뿐만 아니라 Layer 7 프로토콜의 헤더를 제어합니다. 이를 'L7 로드밸런싱'이라고 합니다. 즉 L7 로드밸런싱은 Layer 4뿐만 아니라 Layer 7을 모두 수반하는 기능이라고 생각하시면 됩니다.
3-way handshake
TCP를 사용하는 송신자와 수신자는 데이터를 전송하기 전 먼저 서로 통신이 가능한 지 의사를 묻고 한 번에 얼마나 받을 수 있는지 등의 정보를 확인합니다. 앞서 언급했던 신뢰성 있는 통신을 하기 위함입니다. 데이터를 안전하고 빠지는 부분 없이 보내기 위함이지요. 여러분이 친구와 통화할 때를 어떻게 하시는지 떠올려보면 좋을 것 같습니다. 이것을 '3-way handshake'라고 부릅니다.
출처: TCP/IP 쉽게 이해하기
[네트워크 엔지니어 환영의 AWS 기술블로그]
사용자와 서버가 통신을 실시할 때 논리적 연결을 맺기 위해 TCP를 사용할 경우, 3-way handshake를 실시합니다. 사용자와 서버 사이의 중간에 L4 스위치가 존재한다면 L4 스위치가 중간에서 3-way handshake에 필요한 패킷(SYN, SYN/ACK, ACK)을 대신 서버/사용자에게 전달해주거나 L4 스위치 자신이 송/수신자가 되어 3-way handshake에 필요한 패킷(SYN, SYN/ACK, ACK)을 주고받습니다. 이것은 Virtual Server의 Type이 Layer 4이냐 Layer 7에 따라 달라지게 됩니다.
위의 그림은 3-way handshake를 실시할 때의 L4 스위치가 어떻게 행동하는가를 단면적으로 보여주는 그림입니다. 그림에선 L4 스위치가 3-way handshake 관련 패킷인 SYN, SYN/ACK, ACK 패킷을 Forwarding 하고 있군요. 모든 경우에서 L4 스위치가 그림에서의 역할처럼 행동하지 않으므로 '대략 저런 모습이구나' 정도만 생각하고 넘어가시면 될 것 같습니다.
이제 L4 스위치의 Virtual Server Type에 따라 어떻게 행동하지는 알아보도록 하겠습니다.
L4 Virtual Server의 트래픽 플로우
F5 Networks에서는 L4 로드밸런싱을 담당하는 L4 Virtual Server를 Performance L4 Type이라고 부릅니다. 말 그대로 L4에서의 성능을 극대화한 Virtual Server Type이라는 뜻이지요. Performance Type에서 L4 스위치의 역할은 트래픽 중개 및 제어보다는 전달(Forwading)에 초점이 맞추어져 있습니다. 그렇게 때문에 Layer 4 프로토콜인 TCP / UDP를 제어하면서 사용자가 전달한 요청을 그대로 Pool Member(실제 서버)에게 전달합니다.
3-way handshake 또한 예외가 아닙니다. 아래 그림을 보시면 3-way handshake의 패킷조차도 L4 스위치가 Pool Member(실제 서버)에게 전달합니다. 즉 3-way handshake를 실시하는 주체가 사용자와 서버이며 L4 스위치는 중간에서 전달하는 역할만 하게 됩니다. 아래 그림을 보시면 사용자(혹은 서버)와 L4 스위치가 3-way handshake가 아닌 사용자와 서버가 3-way handshake를 실시하며 L4 스위치는 단순 전달(로드밸런싱)의 역할만 하는 것을 볼 수 있습니다.
3-way handshake 이후 사용자가 데이터를 전달하면 그대로 Pool Member(실제 서버)에게 전달합니다. 이처럼 L4 스위치가 로드밸런싱과 연결 생성(Connection)에 집중하기 때문에 부하가 상대적으로 덜하여 성능을 극대화할 수 있습니다. 상위 프로토콜인 Layer 7에 대한 간섭을 원하지 않고 처리 성능을 극대화하여 더 많은 요청을 처리하고자 할 때 L4 Virtual Server를 쓰곤 합니다. 아니면 굳이 Layer 7을 제어할 필요가 없어도 좋겠죠 ㅎㅎ.
L7 Virtual Server의 트래픽 플로우
F5 Networks에서 L7 로드밸런싱을 담당하는 L7 Virtual Server를 Standard Type이라고 부릅니다. Layer 4의 TCP / UDP뿐만 아니라 Layer 7의 HTTP, FTP, SMTP, DNS 등의 프로토콜 헤더를 제어하거나 필요한 정보를 삽입할 수 있습니다. L4 스위치가 프로토콜의 헤더에 직접 개입하기 때문에 사용자 / 서버와 L4 스위치가 3-way handshake를 실시하고 패킷도 직접 받아서 처리 후 넘겨주게 됩니다. 전달보다는 중개자로서의 역할이 훨씬 큰 것이죠. 이를 Proxy라고 부릅니다. 아래 그림을 보시면 Proxy Server로서의 L4 스위치를 보실 수 있습니다.
먼저 사용자와 L4 스위치가 3-way handshake를 실시한 후, HTTP 요청을 받아들입니다. 그리고 부하분산할 Pool Member(실제 서버)를 선택한 뒤, L4 스위치와 서버가 3-way handshake를 실시하여 전달받은 요청을 Pool Member(실제 서버)에 전달하는 것을 볼 수 있습니다. 그럼 HTTP 헤더를 어떻게 제어하여 쓴다는 것일까요? 감이 잘 오지 않으실 겁니다. 제가 예전에 고객사로부터 받은 요청 중에는 이런 것이 있습니다.
고객 : 사용자가 인터넷 브라우저(IE, Chrome, Firefox 등)에 따라 제공되는 웹페이지를 다르게 하고 싶습니다. 그것을 L4 스위치에서 처리할 수 있을까요?
저의 답변은 다음과 같았습니다.
환영 : 그렇다면 들어온 요청의 HTTP 헤더에 있는 User-agent Header를 보고 브라우저 종류를 확인한 후, 각각 다른 URL로 Forwarding하면 가능합니다.
이처럼 L7 Virtual Server Type인 Standard Type을 사용하게 되면 HTTP 헤더를 제어할 수 있게 되므로 위의 사례처럼 다양한 로드밸런싱 혹은 전달(Forwarding)이 가능하게 됩니다. L4 스위치가 보다 적극적인 위치에서 임무를 수행하는 것이죠.
자~ 여기까지가 L4 스위치의 트래픽 플로우와 L4 / L7 로드밸런싱시 역할 변화입니다. 도움이 되셨으면 좋겠네요 ㅎ_ㅎ