Close
Close full mode
logo만렙 개발자 키우기

L4 & L7

Git RepositoryEdit on Github
Last update: 9 months ago by nowwaterReading time: 10 min

L4 스위치

image

로드밸런싱(서버 부하 분산)을 처리하는 장비이다.

외부에서 들어오는 모든 요청은 서버가 아닌 L4 스위치를 거쳐야 하며, 모든 요청은 L4 스위치가 받아서 서버들에게 적절히 나누어준다.

L4 스위치는 부하 분산뿐만 아니라 TCP, UDP, HTTP 같은 protocol들의 Header를 분석하여 그 정보를 바탕으로 부하 분산을 실시하고, 거기에 더해 Source IP 혹은 Destination IPNAT(Network Address Translation)하여 보낼 수 있다.

클라이언트와 서버가 3-way handshake를 거쳐 논리적 연결이 생성되었음을 나타내는 Connection을 생성하면, L4 스위치 역시 Connection를 생성하여 리스트를 관리한다. (이 과정에서 3-way handshake 또한 L4 스위치를 통해 실시한다)

논리적 연결을 통해 데이터를 주고받던 서버 혹은 클라이언트가 4-way handshake(연결 종료 과정)를 실시하여 Connection을 제거하면 4-way handshake의 중재자인 L4 스위치 또한 Connection을 삭제한다.

L4 ConnectionConnection Time Out 값을 가지는데, 일정 시간 동안 사용되지 않은 Connection을 삭제하고 클라이언트와 서버 측에 필요 시 Connection을 새로 맺도록 Reset flag 가 담긴 Packet을 전송할 수 있도록 한다.

L4 스위치가 필요한 이유

서버가 한 대만 존재하고, 이 서버는 웹 서비스를 제공한다고 가정한다. 그리고 공인 IP 123.111.43.2를 가지고 있으며 사용자들은 이 IP로 접속한다 (By DNS 과정 !)

사용자가 점점 늘어나 서버를 늘려야 할 상황이 되었다. 그래서 서버를 한 대 더 늘리고 123.111.43.3의 IP를 할당했다. 외부에서 웹 서비스에 접속하기 위해 123.111.43.2 혹은 123.111.43.3 의 IP로 접속해야 한다. 지금까지 사용자들은 123.111.43.2로만 접속을 해왔다. 따라서 123.111.43.3 으로도 접속할 수 있다고 알려줄 수 있을 것이다.

하지만 서버가 3대, 4대, 5대 ... 계속 늘어난다면 이 방법이 통할까? 새로 늘어난 IP 주소를 공지함으로써 부하가 어느정도 나누어질 수는 있겠으나, 고르게 분산되는 것은 장담할 수 없다. 그래서 필요한 것이 로드밸런싱이다. 로드밸런싱을 하면 일일이 서버에게 요청을 전달할 필요 없이 L4 스위치에 모든 요청을 전달하고 L4 스위치가 서버들에게 요청을 그대로 전달하는 것이다.

image

위의 그림에서 알 수 있듯이, 모든 요청을 L4로 받기 때문에 L4 스위치만이 공인 IP 123.111.43.1을 갖게 되며, 모든 사용자들은 이 공인 IP로 요청을 보낸다. 따라서 서버들이 공인 IP를 가질 필요가 없어진다. 서버들은 오직 L4 스위치를 통해서만 통신을 하게 되므로, L4와 서버는 사설 IP를 통해 통신을 주고받는다. 또한 L4 스위치를 두고 나니 서버가 사설 IP를 갖게 되어 외부에서 서버의 IP를 알 수가 없어서 서버에 직접 접속할 방법이 사라졌다. 이는 다시 말해서 외부에서 서버에 악의적인 트래픽 공격(DDoS 등)을 하고자 하여도 서버의 IP를 모르기 때문에 직접적인 공격이 불가능해졌다.

L4 스위치의 구성 요소

image

로드밸런싱은 IPPort를 필요로 한다.
=> OSI 7계층 중 Layer4의 정보인 Port를 사용하기 때문에 이름이 L4 스위치이다.

서버는 다양한 서비스를 제공한다. 하나의 서버에서 웹 서비스를 제공하더라도 80, 8080, 8888 Port 등 종류별로 다양한 웹 서비스를 제공할 수 있다. 만약 Port를 모른 상태에서 IP 정보만을 가지고 접속한다면 어느 Port로 접속해야 할지 모를 것이다. 그래서 L4 스위치에는 외부에서 접속할 IP 뿐만 아니라 Port를 명시해줘야 한다.

이렇게 외부 사용자들이 접속 시 사용하는 IP(123.111.43.1)와 Port(80)을 갖고 있는 L4 스위치의 구성 요소를 Virtual Server 라고 한다.
또한 Virtual Server의 IP를 VIP(Virtual Server IP) 라고 부른다.

L4 스위치는 다수의 Virtual Server를 가질 수 있다.
Virtual Server에 도달한 요청을 서버(IP와 Port가 명시된)들의 집합에 전달하게 되는데, 이 집합을 Pool이라고 한다. 특정 Virtual Server에 전달된 요청들은 그 Virtual Server에 연결된 Pool에만 전달된다.

Pool의 소속원으로서 IP와 Port로 구성되는 서버를 Pool Member라고 한다. Pool은 다수의 Pool Member로 구성된다. Pool Member는 단순 IP가 아닌 IP와 Port로 이루어진 서버이기 때문에 IP가 같더라도 Port가 다르면 엄연히 다른 Pool Member이다.


L4 Load Balancing

Layer 4(TCP와 UDP)에서 IP와 Port를 활용하여 서버 부하 분산을 하는 것을 의미한다.

적합한 Virtual Server IP와 Port를 통해 목적지로 들어온다면 골고루 서버에 부하를 분산한다. 뿐만 아니라 TCP와 UDP의 특징을 이용하기 때문에 TCP를 선택하거나 UDP를 선택하거나 두 프로토콜 모두를 선택하여 Virtual Server의 성격을 정의해 Profile을 통해 행동을 제어할 수 있다.

image

F5 Networks의 L4 Virtual Server Ptorocol 정의

TCP를 사용할 경우 사용자와 서버가 논리적인 커넥션을 맺을 수 있도록 중간자의 입장에서 3-way handshake 실시를 지원한다. 사용자와 서버가 생성하여 던지는 SYN, SYN/ACK, ACK Flag Packet을 순서대로 전달한다. 3-way handshake에 적극적으로 개입할 수 있는 L4 스위치도 있고, 매우 소극적으로 IP와 Port를 활용한 로드밸런싱/커넥션 생성만 하는 L4 스위치도 존재한다.

로드밸런싱의 기준점이 IP와 Port이기 때문에 TCP/UDP의 Header를 분석해 로드밸런싱에 활용하지는 않는다. 그래서 프로토콜 헤더를 통홰 로드밸런싱을 하기 보다는 해당 프로토콜들의 특성으로 인한 행동을 제어하는 편이다. 예를 들어 3-way handshake 를 제어하거나 커넥션을 언제 끊을지, 커넥션을 얼마나 유지할 것인지, Connection Time out에 도달하면 어떻게 할 것인지 등을 제어한다.

image

F5 Networks의 L4 Virtual Server의 Profile

  • Reset on Time : Connection Time out에 도달하면 L4 스위치가 어떻게 행동할 것인지 정의
  • Idle Timeout : Connection의 유지 시간을 의미
  • TCP Handshake Timeout : TCP 3-way handshake의 제한 시간을 정의
  • Loose Initiation / Loose Close : TCP의 3-way/4-way handshake 의무를 해제할 수 있다.
  • TCP Close Timeout : 커넥션 삭제 직전 대기 시간을 정의

이처럼 L4 로드밸런싱은 IP와 Port를 활용해 부하 분산을 실시하는 것을 의미하며, TCP/UDP 의 특징을 활용한 그 밖의 부가 행동에 초점이 맞추어져 있음을 알 수 있다.


L7 Load Balancing

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의 성격을 정의한다.

image

F5 Networks의 L7 Virtual Server Protocol과 Protocol Profile 정의

Layer 7 프로토콜은 Layer 4 프로토콜과 별개로 움직이는 것이 아니다. 어떤 프로토콜들은 TCP를 기반으로 움직이며 어떤 프로토콜들은 UDP를 기반으로 움직인다. 예를 들어, HTTP는 TCP 기반의 프로토콜이다. 그래서 HTTP 통신을 하기 위해서는 반드시 3-way handshake를 실시하여 신뢰성있는 연결을 생성해야 한다. 그런 다음에 HTTP GET을 통해 리소스를 얻어오거나 POST를 통해 업데이트를 실시한다.

한 가지 더 예를 들어, DNS는 TCP/UDP 모두를 활용하는 Layer 7 프로토콜이다. 기본적으로 DNS는 UDP를 사용하지만 전달해야 하는 패킷의 크기가 달라지면 말이 달라진다. UDP는 패킷의 크기가 64B 를 초과할 수 없기 때문에 DNS를 로드밸런싱 중 패킷의 크기가 64B를 넘어버리는 경우 TCP를 사용한다. 그렇기에 DNS를 제대로 로드밸런싱하기 위해서는 TCP 기반의 L7 Virtual Server와 UDP 기반의 L7 Virtual Server 모두 생성해야 한다.

Layer 4 프로토콜과 Layer 4 프로토콜 Profile 설정을 끝마치면 Layer 7 프로토콜 Profile 선택을 통해 원하는 Layer 7 프로토콜 헤더를 활용할 수 있다.

image

F5 Networks의 L7 Virtual Server의 HTTP Profile

HTTP Profile 내에 HTTP 헤더를 활용한 여러 기능들

Fallback Host : Pool Member가 모두 Health Check Down일 경우 302 Response Code를 이용해 다른 URL로 이동시킨다.

Request Header Insert : HTTP Header 사용자가 원하는 사용자 정의 헤더를 집어 넣을 수 있다.

Insert X-Forward-For : Source IP NAT 시 사용자의 IP를 헤더에 담아 전달하는 기능.

또는 HTTP 헤더를 통해 특정 Pool Member로만 로드밸런싱 실시하는 기능 등 여러 기능들이 존재한다.

정리하자면, L7 로드밸런싱은 Layer 4 프로토콜과 Layer 4 프로토콜 Profile을 활용할 수 있을 뿐만 아니라, Layer 7 프로토콜 Profile을 통해 Layer 7 프로토콜 헤더를 읽고 활용할 수 있음을 의미한다.

L4 / L7 Load Balancing 에 대해 놓치기 쉬운 두 가지

1. L2 스위치는 이더넷 스위칭, L3 스위치는 IP 라우팅, L4 스위치는 서버 로드밸런싱을 한다는데 각자 자신이 속한 계층에서만 활용 가능한 것 아닌가?

그렇지 않다. OSI 7 Layer를 생각하면 데이터가 사용자에게 도달하기 위해서는 L1 부터 L7까지 순차적으로 올라가야 하며, 사용자가 데이터를 다른이에게 전달하기 위해서는 L7부터 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 스위치도 IP Header를 이해할 수 있어서 라우터처럼 활용할 수 있고, Ethernet Frame Header를 이해할 수 있기에 L2 스위치처럼 사용할 수 있다.

그리고 라우터(L3 스위치) 또한 Ethernet Frame Header를 이해할 수 있기 때문에 L2 스위치처럼 사용할 수 있다.

그러나 L4 스위치나 L3 스위치는 상위 레벨 헤더 분석을 할 수 있는 만큼 고가의 장비여서 하위 레벨의 역할에는 사용하지 않는다.

그렇게 사용하는 것은 낭비기 때문에 할 수는 있으나 하지 않는 것이다.

2. L4 Virtual Server는 TCP/UDP만을 다루는 로드밸런서이고, L7 Virtual Server는 주로 HTTP/HTTPS만을 다루는 로드밸런서 아닌가?

반은 맞고, 반은 틀린 말이다.

1번에서 언급했던 것처럼 상위 레벨의 역할을 수행하는 스위치는 하위 역할의 프로토콜을 모두 이해해야 한다.
HTTP 헤더를 분석할 수 있는 L7 Virtual Server는 로드밸런싱을 위해 하위 레벨인 TCP를 반드시 이해해야 하며 TCP Header를 분석할 줄 알아야 한다.

image

그렇다면 왜 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를 사용하면 될 것이다.

🕋 Backend — Previous
대용량 데이터 처리
Next — 🕋 Backend
대용량 세션을 위한 로드밸런서