톰캣 VS 네티 (톰캣 편)

부하 테스트를 진행하면서 대용량의 요청이 발생할 때 서버의 CPU 사용률이 일정 수준이상을 넘지 못하고 응답이 지연됨과 동시에 Waiting 상태의 스레드가 매우 많은 것을 확인할 수 있었다. 이는 Spring MVC와 톰캣이 Blocking 모델을 기반으로 하기 때문에 발생하는 문제이다. 또한 최근 MSA에 대해 공부하던 중 Spring Cloud에서는 서블릿 컨테이너인 Tomcat이 아닌  Netty를 사용한다는 것을 알게 되었다. 이에 Non-Blocking 모델을 기반으로하는 Netty 학습에 대한 필요성을 느꼈고 이와 동시에 Tomcat에 대해서도 조금 더 자세하게 알아보고자 했다.

 

 

---

 

☑️ 톰캣

먼저 톰캣에 대해 자세하게 알아보자. 톰캣은 Spring에 기본적으로 내장되어 있는 서블릿 컨테이너로, 일반적으로 MVC와 함께 Blocking I/O 방식으로 작동한다. 그런데 톰캣에 대해 공부하던 중, 많은 블로그에서 `톰캣 9 버전 이후로는 Non-Blocking 모델을 사용할 수 있다` 라는 글을 봤고, 이에 대해 자세하게 알아보고자 했다.

 

 

대략적인 톰캣의 동작 방식은 `클라이언트의 요청이 들어오면 톰캣은 스레드 풀에서 하나의 스레드를 할당한다.` 부터 시작할 것이다. 하지만 조금 더 자세하게 알아보면 요청을 스레드에 할당하는 단계 이전의 과정에 대해 알 수 있다. 이러한 과정 즉, 데이터 패킷을 `HttpServletRequest` 로 변환하여 서블릿 객체에 전달하는 과정을 담당하는 것이 Connecter이며, 이는 세가지 버전으로 나뉘며 각 버전 별로 4가지(BIO, NIO, NIO2, APR)의 동작 방식을 설정할 수 있다.

 

Tomcat Connector

1. HTTP/1.1 Connector

2. HTTP/2 Connector

3. AJP Connector (with Apache HTTP web server) : 특수 Protocol처리

 

그 중 대표적인 동작 방식인 BIO(Blocking I/O)와 NIO(Non-Blocking I/O)에 대해 알아보자. 참고로 NIO는 New I/O의 줄임말이다. NIO API 중 File API와 같은 일부 API는 Blocking 방식으로 작동하기 때문에 이를 NIO를 Non-Blocking I/O라고 해석한다면 오해의 소지가 생길 수 있다.

 

➖ BIO Connecter

BIO Connecter는 아래와 같이 동작하며 이는 커넥션이 수립되는 순간부터 처리가 완료되는 순간까지 모든 과정을 Blocking으로 처리하게 된다.

 

동작 과정

 

• 클라이언트가 서버에 연결을 요청하면, Tomcat의 Acceptor Thread가 서버소켓을 통해 연결을 수락하고 새 Socket을 생성한다.
• 연결된 Socket을 처리하기 위해 스레드 풀에서 스레드 하나를 할당하거나 새 스레드를 생성한다.
• 스레드는 소켓의 InputStream을 통해 요청 데이터를 읽고 서블릿 컨테이너로 전달한다.
  
  • OS는 요청 데이터를 DMA를 이용하여 커널 버퍼에 복사한다.
  • 이후에 JVM 내부 버퍼로 커널 버퍼의 데이터를 복사하고 이를 파싱하여 서블릿 컨테이너로 전달한다.
• 서블릿이 요청을 처리하고 응답 데이터를 생성하면, 스레드는 응답 데이터를 클라이언트로 전송힌다.
• 요청 처리가 완료되면, 스레드는 스레드 풀로 반횐된다.

 

 

 

➖ NIO Connecter

 

동작 과정

 

1. 클라이언트가 연결을 요청하면, Tomcat의 Acceptor Thread가 ServerSocketChannel을 통해 연결을 수락하고 SocketChannel을 생성한다.

2. 생성된 SocketChannel은 Poller Thread에 등록된다.

3. Poller Thread는 생성된 SocketChannel을 Selector에 등록한다.

4. SocketChannel은 읽기/쓰기 작업이 준비될 때 이벤트를 발생시킨다.

5. 이벤트 리스너인 Selector는 감지된 I/O 이벤트(데이터 읽기 준비 완료)를 Poller Thread에 전달한다.

6. Poller Thread는 해당 작업을 Worker Thread에 작업을 위임한다.

 

7. Worker Thread는 요청 데이터를 읽고 서블릿 컨테이너로 전달한다.

    - 이 과정에서 Worker Thread는 ByteBuffer를 사용한다.

    - ByteBuffer는 커널 버퍼의 데이터를 복사하는 것이 아니라 직접 참조하며, 해당 데이터를 파싱하여 서블릿 컨테이너롤 전달한다.

8. 서블릿이 응답 데이터를 생성하면 Poller Thread가 데이터를 클라이언트로 전송한다.

 

 

 

1.  

 

 

위 동작 과정에서 굵게 표시한 글이 BIO와 NIO의 차이점이다. 간단하게 설명하자면 BIO의 Acceptor에 위 그림과 같이 Poller, Selector가 추가되고 기존 단방향 입출력을 지원하던 Stream이 양방향 입출력 Channel로 변경되었으며 Buffer가 추가된 형태라고 볼 수 있다.

혼동될 수 있는 부분을 짚어보자면 Acceptor Thread와 Poller Thread는 별개의 전용 스레드이며 Worker Thread는 스레드 풀에서 관리되는 스레드를 의미한다.

 

 

 

이렇게만 들으면 이게 왜 Non-Blocking 모델인지 의문이 생길 수 있다.

 

그림에는 나와 있지 않은 Selector가 여러 Channel을 병렬적으로 관리하고 여러 Channel 중 읽기 준비가 완료된 Channel을 Poller Thread에 전달(4, 5 번 과정)한다. 이를 BIO에서 데이터 읽기 준비와 같은 기존 모든 과정을 Blocking 하게 동기적으로 실행해야됐던 것과 비교해보면 비동기 Non-Blocking으로 작동한다는 것을 알 수 있다. 즉, Selector가 이벤트 리스너이자 멀티플렉서 역할을 하는 것이다.

 

 

 

 

또한 ByteBuffer가 왜 추가되어 얻을 수 있는 이점에 대해 의문이 생길 수 있다.

 

 

출처: https://mark-kim.blog/understanding-non-blocking-io-and-nio/

 

 

Bio 커넥터에서는 네트워크 인터페이스를 통해 수신한 데이터를 커널 버퍼에 저장한 후, 해당 데이터를 JVM 내부 버퍼에 복사하여 사용했다. 이러한 경우 내부 버퍼로 복사할 때 CPU가 사용되고, 이후 해당 데이터를 정리하기 위해 CG를 진행할 때도 CPU가 사용될 뿐더러, 복사가 진행되는 동안 I/O를 요청한 Thread는 Blocking 상태에 들어가게 된다.

 

위와 같은 세가지 오버헤드를 제거하기 위해서 추가된 것이 ByteBuffer이다. ByteBuffer는 커널 버퍼를 직접 참조한다. 그렇기 때문에 추후 CG를 할 필요가 없어지며, 디스크 혹은 소켓에서 커널 버퍼로 데이터를 가져오는 작업은 DMA가 처리하기 때문에 CPU가 추가적으로 사용될 필요도 없어진다. 또한 복사를 하지 않기 때문에 Thread가 Blocking 상태에 들어갈 일도 없어지게 된다.

 

 

ByteBuffer의 구조

ByteBuffer는 내부에 byte 배열로 구성되어 있으며 버퍼형태의 네 가지 포인터를 가지고 있는 클래스이다.

 

○ position
    - 읽기 또는 쓰기가 작업 중인 위치를 나타낸다.
    - 버퍼 생성시 0으로 초기화되며, 데이터를 입력하거나 읽으면 자동으로 증가한다.
    - limit와 capacity보다 작거나 같다.
○ limit
    - 읽고 쓸 수 있는 버퍼 공간의 최대치를 나타낸다.
    - 이 값은 capacity보다 크게 설정할 수 없다.
○ capacity
    - 버퍼에 저장할 수 있는 데이터의 최대 크기로 한 번 정하면 변경이 불가하다.
○ mark
    - 사용자가 편의상 마음대로 지정할 수 있는 포인터이다.
    - 특별히 특정 위치를 기억하고 있다가 다음에 되돌아가야할 때 사용된다.

 

 

출처: https://mark-kim.blog/understanding-non-blocking-io-and-nio/

 

 

 

 

 

 

위에서 말한 NIO Connecter가 바로 `톰캣9 버전부터는 Non-Blocking 모델을 제공한다.` 라는 말을 하는 이유이다. 이는 우리가 원하는 애플리케이션 레벨에서의 Non-Blocking이 아니며 오해의 소지가 다분하기 때문에 내부 구조와 동작과정을 알아둘 필요가 있다.

 

 

 

NIO 커넥터의 전체적인 동작 과정

 

출처: https://mark-kim.blog/understanding-non-blocking-io-and-nio/

 

 

 

 

 

➖ 톰캣이 완전한 Non-Blocking이 불가능한 이유

 

이렇듯 커넥터에서 Non-Blocking 모델을 사용함에도 불구하고 톰캣은 전체적으로 Blocking 모델을 따르기 때문에 완전한 Non-Blocking이 불가능하며 Thread Per Request의 형태의 띈다. 또한  그 이유를 조금 더 자세하게 말하자면 아래와 같다.

 

 

1. 톰캣은 서블릿 API를 사용하고, 해당 API(`HttpServletRequest`, `HttpServletResponse`)가 Blocking 모델을 기반으로 설계되었기 때문이다. 스프링에서 사용하는 디스페처 서블릿 또한 해당 API에 의존한다.

 

2. 톰캣에서는 요청이 서블릿으로 전달되기 전에 동기적으로 작동하는 필터와 인터셉터 존재한다.

 

 

Thread Per Request는 대용량의 요청이 들어올 경우 한번에 Thread의 수만큼의 요청만 받아들이며 I/O 작업에 들어갈 경우 해당 Thread가 Waiting 상태로 대기하게 된다는 한계가 있다. 이로 인해 CPU의 성능을 온전하게 사용하지 못하게 된다.

이러한 병목을 완화하기 위해 Thread 수를 늘릴 수는 있지만 Context Switching 오버헤드를 발생시킨다.

 

 

 

---

 

 

☑️ 결론

 

톰캣과 네티에 대한 내용은 하나의 글에 모두 담아내려고 했지만 생각보다 내용이 길어졌다. 사실 여기까지의 글은 결국 톰캣은 Blocking하게 동작한다는 것을 말하고자 함이었다. 다음 글에서 Netty에 대해 자세하게 알아보자.