[L4 Swtich] 서비스 그룹 관리 및 장애 사례

 

1. L4 스위치 서비스 그룹 및 실제 서버 관리

 L4 스위치는 서비스 트래픽의 로드 밸런싱 역할을 수행하며, 서비스 그룹에 속한 실제 서버의 상태를 주기적으로 감시하여 정상적인 서버로 트래픽을 분배한다. 이러한 서버 상태 감시를 헬스 체크(Health Check)라 하며, 주로 다음과 같은 방법들이 사용된다.

 

- ICMP 기반 헬스 체크

방법	ping을 통해 서비스 그룹 내 서버의 연결성을 확인함.
특징	네트워크 레이어 수준의 단순 연결 상태를 체크함.

 

- TCP 포트 기반 헬스 체크

방법	- 3-way 핸드셰이킹 과정을 통해 서버의 서비스 포트를 확인.   1. L4 스위치가 서버에 SYN 패킷 전송.   2. 서버가 SYN-ACK 응답을 보내면 연결 정상으로 판단.   3. 이후 FIN 패킷을 전송해 세션 종료.
특징	TCP 포트를 통해 애플리케이션 연결성을 간단히 확인.

- 스크립트(Content) 기반 헬스 체크

방법	- L7 콘텐츠 요청을 통해 서버 및 데이터베이스 연결성을 점검.   · L4 스위치가 서버에 GET /index.html HTTP/1.1 요청 전송.   · 서버는 데이터베이스에서 index.html 파일 존재 여부를 확인한 후, HTTP/1.1 200 OK 응답을 반환.   · L4 스위치는 응답을 확인 후 헬스 체크 세션 종료.
특징	- 단순한 네트워크/포트 체크를 넘어 데이터베이스 연결 상태까지 확인 가능.
장점	- 서비스 상태를 보다 완벽하게 검사할 수 있음.

 

- WAF(Web Application Firewall)와의 관계

 

• 서버와 데이터베이스 간 문제가 발생하면, 웹 서버는 400번대 또는 500번대 에러 코드를 반환한다..
• WAF가 이를 감지하여 자체 장애 메시지를 사용자 브라우저에 표시한다.

- L4 스위치의 기능 확장

 L4 스위치는 단순히 L4 헤더(소켓 정보: 소스 IP, 목적지 IP, 소스 포트, 목적지 포트)만 처리하는 것이 아니라, L7 헤더 및 데이터까지 다룰 수 있다. 

• 특정 URL 리다이렉션 및 필터링
• QoS 기반 트래픽 관리
• TCP/UDP 포트 및 L7 프로토콜을 활용한 정책 적용

 

2. L4 스위치 장애 사례

 L4 스위치의 장애 상황을 분석하고 해결 방안을 살펴보자. L4 스위치의 구성 및 서버 간의 통신 방식에 따른 다양한 장애 사례를 다루고, 각 상황에서의 적절한 장애 처리 방법을 제시한다.

 

(1) L4 스위치 구성 장애

L4 스위치는 물리적인 포트 수에 제한이 있기 때문에, 포트 수를 확장하기 위해 하단에 L2 스위치를 추가해 구성하는 경우가 있다.

 

 초창기의 L4 스위치는 물리적 포트 수가 부족하여 L2 스위치를 추가하는 방식이 일반적이었다. 예를 들어, 특정 시스템이 L4 스위치를 통해 데이터베이스 서버로 접속하는 상황에서, L4 스위치가 로드 밸런싱을 진행하면서 세션을 연결한다. 그러나 L2 스위치가 데이터를 직접 포워딩하면, 응답 패킷의 소스 IP가 실제 서버의 IP로 설정되어 클라이언트가 이를 인식하지 못하고 패킷을 폐기하게 된다. 이를 해결하려면, 서버를 L4 스위치에 직접 연결하여 L4 프로세싱을 거치도록 구성해야한다.

 

(2) L4 스위치 서버 구성 장애

 예를 들어, 서버에 추가한 새로운 관리 IP가 서비스 IP와 동일한 서브넷을 사용하면, 디폴트 게이트웨이가 변경되어 응답 패킷이 L4 스위치를 경유하지 않고 백본을 통해 직접 전송될 수 있다. 이 경우, 서버에서 세션이 제대로 설정되지 않으며 서비스가 정상적으로 이루어지지 않는다.

 

이 문제를 해결하려면, 서버의 IP 설정 시 서비스 IP와 관리 IP가 다른 서브넷에 위치하도록 설정하거나, 서브넷 내에서 32비트 호스트 라우팅을 추가하여 네트워크 경로를 명확히 해야 한다.

 

(3) 비대칭 경로로 인한 L4 서비스 장애

 비대칭 경로 문제로 인한 서비스 장애도 발생할 수 있다. 클라이언트와 서버 간의 TCP 세션이 아직 완전히 설정되지 않은 상태에서 응답 패킷이 방화벽 등에서 차단되거나, L4 스위치를 거치지 않고 응답이 전달되지 않는 경우가 이에 해당한다. 이 경우, L4 스위치의 세션 테이블에는 세션 정보가 기록되지만, 클라이언트는 응답 패킷을 받을 수 없어 세션 연결이 실패한다.

 

이 문제는 서버의 상태를 netstat -an 명령어로 확인하여 해결할 수 있으며, 세션 상태가 ESTABLISHED로 표시된다면 서버와의 연결은 정상적이지만, 경로 상에서 문제가 발생한 것임을 확인할 수 있다.

 

(4) L4 헬스 체크 방식의 고려

 L4 스위치가 서버의 상태를 확인하는 방법으로 ICMP를 사용하는 경우가 많다. 그러나 이는 서버의 TCP 서비스 포트가 리스닝 상태인지 확인하지 못하기 때문에, 서비스가 실제로 정상 작동하지 않는 경우에도 L4 스위치가 서버로 트래픽을 전달할 수 있다. 이때는 서버의 서비스 포트가 정상인지 직접 확인하는 방법이 필요하다.

권장하는 헬스 체크 방법

- TCP 포트를 통해 직접 확인하거나 애플리케이션의 특정 포트나 스크립트를 통해 헬스 체크를 구현하여, 서버 상태에 맞는 응답을 받을 수 있도록 하는 방법이 있음.

 

- 장애 처리 시 서비스 이해의 중요성

L4 스위치의 설정과 장애 처리는 서비스의 특성을 잘 이해하는 것이 매우 중요하다. 서비스 간의 연관 관계를 파악하지 않으면, 장애 상황을 정확히 진단하고 처리하는 데 어려움을 겪을 수 있다. 또한, TCP 및 세션 지속성에 대한 이해가 부족하다면, L4 스위치의 장애 처리가 어려울 수 있다.

 

세션의 지속성이 중요한 경우, 로드 밸런싱 메서드에서 해시 방식을 사용하는 것보다는, 세션 테이블에서 세션 상태를 관리하여 클라이언트와 서버 간의 연결을 지속하는 것이 효율적이다.