운영중인 서비스는 L4로 이중화가 되어있다. 서버에서 다른 작업을 하면서 알게 된 사실인데, A서버에서 IIS를 내리면 A서버에 연결 중이던 클라이언트들은 L4가 있음에도 불구하고 더 이상 통신을 할 수 없고, 클라이언트가 접속을 완전히 끊어진 뒤에 다시 연결하면 정상운영 중인 B서버로 연결이 옮겨갔다. 새로 접속을 했을 때, B서버로 연결이 된 걸보면 헬스 체크와 로드 밸런싱 기능이 정상작동 중이라는 얘기인데.. 이해할 수가 없었다. 그래서 L4에 대해 좀 더 자세히 알아보기로 했다.
1. L4 스위치 란
L4(Layer 4)는 OSI 7계층 모델의 전송계층(Transport Layer)을 의미하며, 주로 L4 스위치(로드밸런서)를 지칭한다.
주로 TCP 및 UDP(4계층 통신) 헤더 정보(IP 주소, 포트 번호)를 기반으로 패킷을 분석하여, 여러 서버로 트래픽을 분산하는 로드밸런싱(부하 분산)을 의미하며, 이 과정에서 세션 테이블을 통해 연결 상태를 유지하고, 가상 IP(VIP)를 실제 서버 IP(RIP)로 변환하여 효율적인 서비스 제공을 목표로 한다.
2. L4 스위치 작동원리
그림과 같이 복수의 트래픽이 발생했을 때, 트래픽이 특정 서버에 몰리지 않도록 L4가 로드 밸런서의 역할을 해준다. L4에서 설정한 알고리즘(Round-robin, Least-connection 등)에 맞게 각 서버로 트래픽이 전달된다.
만약 트래픽이 더 많이 늘어난다면 어떻게 될까?
트래픽이 계속 늘어나더라도 클라이언트는 LOAD BALANCER인 L4스위치 만 바라보기 있기 때문에 필요한 만큼 서버를 추가해 서버를 수평적으로 Scale-out할 수 있다. 반대로 트래픽이 낮아졌을 때 서버를 제거하는 것도 용이하다.
L4스위치는 하나의 공인IP와 사설 IP를 가지며 모든 클라이언트의 요청이 이 주소로 들어온다.
클라이언트는 서버들의 주소를 알 필요가 없고, 오직 LB인 L4 스위치의 공인 IP주소만 알면 된다. 또한 서버들은 이제 모든 클라이언트의 요청을 L4스위치 가 처리해주기 때문에 L4스위치와 사설IP로 통신을 주고받게 된다. 서버의 IP가 클라이언트에 노출되지 않기 때문에 자연스레 악의적인 공격들에서 안전할 수 있게 된다.
(*TCP는 IP와 PORT를 사용해 연결하기 때문에 클라이언트-L4, L4-서버 모두 IP와 PORT주소를 함께 알아야한다.)
3. 클라이언트와 서버의 연결
TCP 통신에서 연결이 성립되는 과정은 3-Way Handshake라고 불린다. 이는 클라이언트와 서버가 서로의 연결 가능 여부를 확인하고, 데이터 전송을 위한 초기 시퀀스 번호를 교환하는 절차다. 클라이언트와 서버 사이에 L4스위치가 있는 경우, L4스위치는 전달자로서의 역할만 수행하고 아래와 같은 과정을 거친다.
1. 서버는 먼저 TCB(Transmission Control Block)를 생성한다.
이 TCB는 연결 상태와 시퀀스 번호 등의 정보를 담고 있으며, 서버가 클라이언트의 요청을 받을 준비를 마치면 상태를 LISTEN으로 변경한다.
2. 클라이언트가 연결 요청 전송(SYN-SENT 상태)
클라이언트 역시 TCB를 생성하고 서버에 연결을 시도한다.
이때 TCP 헤더의 SYN 비트를 1로 설정한 SYN 패킷을 전송하며, 임의의 시퀀스 번호 seq = x를 생성한다.
SYN 패킷을 보낸 후, 클라이언트는 상태를 SYN-SENT로 전환한다.
*SYN패킷은 데이터는 포함하지 않지만 시퀸스 번호를 소비한다. 즉, 다음에 전송되는 데이터의 시퀸스는 x+1이 된다.
3. 서버 응답(SYN-ACK or RST)
서버는 클라이언트의 SYN 요청을 수신하면 다음 두 가지 중 하나로 응답한다.
[연결 수락]
서버가 연결을 허용할 경우, SYN=1과 ACK=1이 설정된 SYN-ACK 패킷을 보낸다.
이때 서버도 자신의 시퀀스 번호 seq = y를 생성하고, 클라이언트의 요청을 확인하기 위해 ACK 번호를 x + 1로 설정한다.
서버는 이 응답을 보낸 뒤 상태를 SYN-RCVD로 변경한다.
* SYN-ACK 패킷도 데이터는 없지만 시퀸스 번호를 소비하므로 다음은 y+1이 된다.
[연결 거절]
만약 서버가 연결을 거부한다면, RST (Reset) 패킷을 전송하여 연결을 초기화한다.
4. 클라이언트의 최종 확인(ACK 전송)
클라이언트는 서버로부터 SYN-ACK를 받으면 마지막으로 ACK 패킷을 보낸다.
이 패킷에는 다음과 같은 정보가 담긴다:
- SYN = 0, ACK = 1
- seq = x + 1
- ack = y + 1
이로써 클라이언트는 서버의 SYN을 정상적으로 수신했음을 알리고, 상태를 ESTABLISHED로 변경한다.
이 시점부터 양측은 TCP연결이 성립된 것이며, 데이터 송수신이 가능한 상태가 되고, 연결된 TCP는 세션 테이블을 유지하게 된다.
이 세션 테이블은 두 가지 역할을 한다.
- 세션 유지
- 클라이언트 IP 및 포트, 서버 IP 및 포트, 프로토콜(TCP/UDP) 정보 저장
- Handshake가 완료된 연결은 동일한 서버로 트래픽이 유지되도록 관리
- 헬스체크
- L4가 서버에 SYN을 보내면 SYN-ACK가 정상적으로 오는지 확인하여 서버가 응답가능한 상태인지 확인 가능
4. 헬스체크를 하지 못했던 원인
위에서 L4는 서버에 SYN을 보냈을 때, SYN-ACK가 정상적으로 온 경우, 서버가 정상인 상태로 판단한다고 했다. 하지만 L4의 경우 TCP 포트 수준에서만 서버의 정상/비정상을 판단하기 때문에 포트는 열려있고, IIS의 어플리케이션이 죽은 경우를 정상으로 판단하게 되었던 것이다.
또한 L4의 Sticky Session(같은 사용자의 여러 요청이 항상 같은 서버로 가도록 유지하는 정책)에 맞물려 정상적으로 사용하다가 IIS만 다운된 서버에 접속된 사용자들은 접속을 완전히 재연결 하기 이전까지 IIS가 다운된 서버로 계속 연결이 되었었다.
이 경우 TCP통신이 어플리케이션 계층을 판단할 수 없기 때문에 L4에서 L7 Health Check를 사용하여 HTTP응답을 받아 서버상태를 판단해야만 한다.
결론적으로 IIS 장애유무로 서버를 이중화(혹은 다중화)하려고 한다면 L7 로드밸런싱 설정이 필요하다.