Tomcat과 TCP Backlog

"부하 테스트 중 TCP 커넥션 유실 문제 발생"에서 다룬 바와 같이 부하 테스트 중에 TCP 커넥션에 대한 이슈가 있었습니다. 핵심적인 원인은 TCP Backlog Queue(accept queue, 대기열) 크기를 조정해주지 않았던 것입니다. 그리고 TCP Backlog Queue 크기를 조정하는 과정에서 Spring Boot 내장 Tomcat의 max-connections와 accept-count 설정에 대한 혼동이 있었습니다.

그래서 TCP Backlog와 accep-count의 관계에 대해서도 간략하게 살펴보았습니다. 이번 포스팅에서는 그 관계를 코드 레벨에서 더 분석해보고자 합니다.

NIO Connector란

먼저 Spring Boot 내장 Tomcat이 핸들링하는 NIO Connector에 대해 살펴보겠습니다.

Tomcat은 클라이언트의 요청을 처리하기 위해 여러 종류의 Connector를 제공합니다. 그 중 기본 설정인 NIO Connector는 Java의 Non-blocking I/O (NIO) 기반으로 동작하며, 다음과 같은 구조로 처리됩니다.

1. Acceptor Thread
   클라이언트의 연결 요청을 수락합니다. 이 때 커널의 TCP Backlog Queue에 대기 중인 연결을 accept()로 가져옵니다.

2. Poller Thread
   연결된 소켓 채널에서 데이터가 들어오는지(혹은 I/O 이벤트가 발생하는지) 감시합니다. NIO의 Selector를 사용해 non-blocking 방식으로 감시합니다.

3. Worker Thread
   실제로 요청을 처리하고 응답을 생성하는 역할을 합니다. 연결된 소켓 채널에서 I/O 이벤트가 발생하면 Poller에 의해 워커 쓰레드로 전달됩니다.

Connector.startInternal()

내장 Tomcat은 NIO Connector를 org.apache.catalina.connector.Connector의 위치에서 사용하고 있습니다. 그리고 Connector라는 클래스 안에는 startInternal()이라는 메서드가 있습니다. 이 메서드는 Spring 애플리케이션을 실행할 때 호출이 됩니다.

그러면 Connector.startInternal()이 호출되면 어떤 일이 발생할까요? 실제로 아래와 같은 순서로 각각의 메서드가 호출이 되는데, 저희는 NioEndpoint.start()의 내부 동작을 파헤쳐 보겠습니다.

Connector.startInternal()
	└── ProtocolHandler.start()
		└── Http11NioProtocol.start()
			└── NioEndpoint.start()

NioEndpoint.start()

NioEndpoint.start()은 다음 두 가지 동작으로 나뉩니다.

1. bindWithCleanup(): socket binding을 실행합니다.
2. startInternal(): Poller Thread와 Acceptor Thread를 실행합니다.

bindWithCleanup()

첫 번째로 bindWithCleanup()을 실행함으로써 웹 서버를 TCP listening 상태로 만드는 과정이 진행됩니다. 이 과정에서 ServerSocketChannel.bind()가 호출이 되는데, 인수 값으로 accept-count가 들어갑니다.

대입한 accept-count는 내부적으로 backlog라는 변수명으로 활용됩니다. 이 backlog 값이 TCP Backlog와 직접적으로 연관된 부분입니다.

ServerSocketChannel.bind()에서 한 단계 더 들어가면 unixBind()가 나오는데, 이곳에서 Java 표준 라이브러리가 제공하는 listen() 메서드를 통해 소켓 작업을 처리하게 됩니다. 실제로는 JNI(Java Native Interface)를 통해 C/C++로 구현된 메서드를 호출합니다. 여기서의 listen() 메서드의 역할은 소켓을 리스닝 모드로 전환하며, 지정된 backlog로 대기열 크기를 설정하는 것입니다.

기본적으로는 모든 프로세스가 OS에서 설정된 TCP Backlog Queue 크기에 종속되지만, 각 프로세스마다 사용할 수 있는 대기열 크기를 논리적으로 제한할 수 있습니다. 따라서 Tomcat 서버는 listen() 과정에서 지정된 accept-count만큼 TCP Backlog Queue, 즉 accept queue를 사용하도록 설정하게 됩니다.

startInternal()

다음으로 NioEndpoint.start()의 두 번째 동작인 startInternal()을 살펴보겠습니다. 이 메서드에서는 아래와 같은 3가지의 중요한 동작이 실행됩니다.

1. initializeConnectionLatch(): max-connections 값을 설정합니다.
2. pollerThread.start(): Poller Thread를 실행합니다.
3. startAcceptorThread(): Acceptor Thread를 실행합니다.

initializeConnectionLatch()의 역할은 단순합니다. max-connections 설정값을 적용하는 것입니다. max-connections 값은 Tomcat이 동시에 처리 가능한 최대 커넥션의 개수를 의미합니다. 이 값을 설정할 때는 LimitLatch를 활용하는데, 잠시 후에 이것이 어떻게 활용되는지 알아보겠습니다.

그리고 나머지 pollerThread.start()와 startAcceptorThread()는 보이는 그대로 Poller Thread와 Acceptor Thread를 실행하는 것입니다. 저희는 여기서 Tomcat과 TCP Backlog의 관계를 분석하고 있으므로 Acceptor Thread 자체가 어떤 일을 수행하는지 살펴보겠습니다.

Acceptor.run()

앞서 언급했듯이 Acceptor는 클라이언트의 연결 요청을 수락하는 역할을 합니다. 그리고 Acceptor는 Runnable 구현체이기 때문에 run() 메서드 안에 있는 내용이 전부입니다. 그 내용 중에는 아래와 같은 코드가 포함돼 있습니다.

위 코드에서 countUpOrAwaitConnection()과 serverSocketAccept()가 중요합니다. 첫 번째로 countUpOrAwaitConnection()은 클라이언트의 연결 요청이 max-connections 값을 초과하지 않는지 체크합니다. 내부적으로는 initializeConnectionLatch()에서 등장했던 LimitLatch를 사용합니다. 이는 동시에 활성화될 수 있는 작업이나 연결의 최대 개수를 제한하는 동기화 메커니즘을 제공하는 것입니다. 마치 정해진 수만큼만 출입을 허용하는 문의 빗장(Latch)과 같은 역할을 한다고 이해하시면 됩니다.

그래서 LimitLatch.countUpOrAwait()를 호출하고, 만약 현재 카운터 값이 설정된 한계값(여기서는 max-connections)보다 작으면 카운터를 1 증가시키고, 이미 한계값에 도달했다면 해당 스레드는 다른 스레드가 작업을 완료하고 카운터를 감소시킬 때까지 대기 상태에 들어갑니다. 즉, Acceptor 쓰레드가 대기 상태에 있는 것입니다.

그리고 두 번째는 serverSocketAccept()인데, Acceptor 쓰레드의 주요 작업이라고 볼 수 있습니다. 이 메서드를 더 깊이 들어가 보면 아래와 같이 ServerSocketChannel.accept()를 찾을 수 있습니다. 이 안에서는 실제 소켓 처리 작업을 실행하는 메서드(implAccept)가 호출되고, 이 역시 JNI를 통해 C/C++로 구현된 메서드를 호출합니다. 즉, accept queue에서 대기하고 있는 TCP 커넥션을 가져오는 작업을 진행하는 것입니다.

만약 accept queue에 대기 중인 커넥션이 가득 차 있다면 새로운 클라이언트의 ACK 요청이 accept-quque에 쌓이지 못하고 커널 레벨에서 드롭될 수 있습니다 (SYN 요청도 드롭. TCP Backlog Queue 사이즈에 동일하게 영향을 받음)

그래서 Acceptor가 accept()를 빨리 호출해서 커넥션을 accept-queue에서 빨리 꺼내야 하겠지만, 이미 max-connections만큼의 커넥션을 유지하고 있다면 Accpetor는 countUpOrAwaitConnection()의 내부 로직에 따라 accept()를 호출하지 못하고 대기 상태에 있을 것입니다. 따라서 accept-count를 무작정 늘리는 것은 연결 자체를 많이 수신할 수는 있지만, Worker 쓰레드가 바쁜 상태라면 작업 처리량을 늘리지는 못할 것입니다.

마치며

지금까지 Tomcat의 NIO Connector가 어떻게 동작하는지, 그리고 TCP Backlog와 accept-count, max-connections 설정값이 각각 어떤 의미를 가지며 실제 코드 흐름에서 어떻게 사용되는지를 살펴보았습니다.

결론적으로,

• accept-count는 OS의 TCP Backlog Queue 크기를 논리적으로 제한하며,
• max-connections는 동시에 처리 가능한 연결 수를 제한하는 역할을 합니다.
• 그리고 이 두 설정값은 Tomcat의 Acceptor 쓰레드에서 커넥션을 수락하는 데 직접적인 영향을 줍니다.

서버가 고부하 상황에서 연결 유실 없이 안정적으로 작동하기 위해서는 단순히 트래픽만 고려하는 것이 아니라, 커넥션 처리 흐름과 큐의 작동 방식을 충분히 이해하고, 이를 기반으로 적절한 튜닝을 수행해야 합니다.

이 글이 Tomcat의 커넥션 처리 흐름을 이해하는 데 조금이나마 도움이 되었기를 바랍니다.