L4 웹 방화벽에 의한 성능 저하 사례

해당 내용은 '실무로 배우는 시스템 성능 최적화'의 내용중 일부를 발췌한 내용입니다. 웹 방화벽에 의한 성능 저하 사례로 방화벽으로 인해 이러한 문제가 발생할 수 있구나 정도로 인지하고 있다면 비슷한 이슈가 발생했을 때 보다 빠르게 대응을 할 수 있을 거라 생각되어 남겨 봅니다.

현상

전국에서 사용하는 시스템으로, 특정 지역의 윈도우7 사용자만 화면 응답시간이 급격히 느려져 1분 이상 소요되는 현상이 발생했다. 그러나 항상 느린 것은 아니고 동일한 화면도 느릴 때와 빠를 때가 있는데 대부분은 느렸다.

접근 방법

현상을 정확히 확인하기 위해 해당 기관을 방문해 직접 화면을 사용하면서 네트워크 패킷을 수집해서 분석했다. 화면이 느릴 때는 HTTP 요청에서 TCP 재전송이 발생하면서 지연되는데, 결국은 서버로부터 HTTP 요청에 대한 ACK를 받지 못하고 타임아웃인 1분에 걸려서 해당 TCP 세션을 강제로 끊고 새로운 TCP 세션을 맺어 HTTP 요청을 보내어 응답을 받음으로써 1분 이상 소요됐다.

그런데 이상한 것은 아파치 웹 서버의 Keepalive 타임아웃이 5 초인데 사용자단 브라우저 TCP 세션은 5초가 이상 지나도 계속 ESTABLISH 상태를 유지하고 있고, 느릴 때는 5초 이상 경과된 TCP 세션을 사용하고 있었다. 그러나 웹 서버에서는 Keepalive 5초가 경과해서 해당 TCP 세션을 끊기 위해 FIN을 보냈음에도 클라이언트로부터 FIN을 받지 못하고 있는 TIME_WAIT 상태였다.

따라서 클라이언트와 웹 서버 사이 어디에선가 웹 서버가 보낸 TCP 세션 종료 신호인 FIN 패킷을 삼키고 있는 것으로 판단했다. 이런 현상이 특정 기관 사용자에게서만 발생하고 있어 해당 기관 내부 네트워크 이상으로 판단했다. 그러나 웹 서비스의 대표 IP인 L4의 가상 IP 대신 실제 서버 IP를 사용해 테스트를 진행하면 웹 서버 2대 모두로부터 정상적으로 클라이언트가 FIN 패킷을 받았다. 이에 L4 가상 IP 사용과 실 서버 IP 사용 시 발생하는 차이가 웹 방화벽 경유로 기인했음을 확인하고 L4 가상 IP를 사용하더라도 웹 방화벽을 경유하지 않도록 네트워크 설정을 수정해 다시 테스트를 진행한 결과, 웹 서버가 보낸 FIN 패킷을 클라이언트가 정상적으로 받는 것이 확인됐으며, 화면 응답시간도 정상이었다.

원인

웹 서버는 Keepalive 5초가 경과한 TCP 세션을 끊고 있으나 FIN 패킷이 클라이언트에 전달되지 않아 클라이언트는 웹 서버가 close한 세션을 살아있다고 생각하고 해당 TCP 세션으로 HTTP 요청을 전송함으로써 이상을 감지하기까지 오래 걸려 화면 지연이 발생했다. 웹 방화벽에서 웹 서버가 보낸 FIN 패킷을 삼킨 것으로 테스트에서 확인했다.