[JSP] 서블릿, 서블릿 컨테이너 (feat.톰캣)

🧐 들어가기전

 

최근에 k6로 부하 테스트를 진행하면서, 요청이 몰릴 때 톰캣이 밀리며 응답 속도가 느려지는 현상을 확인할 수 있었다.  현상 자체는 이해가 갔지만, 정작 '톰캣이 밀린다'는 게 정확히 어떤 구조적인 이유에서 비롯된 건지는 잘 모르겠다는 생각이 들었다. 톰캣이 뭔가 처리를 못하고 대기열이 쌓이는 건 알겠는데, 그 안에서 서블릿은 어떤 역할을 하고, 서블릿 컨테이너는 어디까지 책임지는지 등 기본적인 개념이 모호하게 느껴졌다. 그래서 이번 기회에 톰캣의 동작 원리를 중심으로, 그 핵심 구성 요소인 서블릿과 서블릿 컨테이너에 대해 제대로 정리해보려고 한다.

---

🔸Servlet(서블릿)

1️⃣ 서블릿이란?

자바 기반의 웹 요청 처리용 서버 사이드 컴포넌트로,
HTTP 요청을 받아 처리하고, 그 결과를 HTTP 응답으로 되돌려주는 역할을 한다.

웹 애플리케이션을 개발하다 보면, 클라이언트의 요청을 받아 처리한 뒤, 그 결과를 다시 응답으로 되돌려주는 구조를 자주 보게 된다. 자바 진영에서는 이 역할을 서블릿(Servlet)이 담당한다.

 

우리가 흔히 사용하는 API 요청, 예를 들어 GET이나 POST 요청을 생각해보자.

• GET 요청은 서버로부터 정보를 조회하는 데 사용되고,
• POST 요청은 새로운 데이터를 전송하거나 생성할 때 주로 사용된다.

두 요청 모두 조회하고자 하는 값이나, 성공했다는 값을 응답으로 받는다. 즉 요청이 있으면 응답도 있다.

클라이언트가 어떤 요청을 보내면, 그 요청을 분석하고 처리한 뒤, 그에 맞는 응답을 다시 클라이언트에게 전달해주는 것이 바로 서블릿의 역할이다. 

---

2️⃣ 서블릿의 특징

• 요청에 대한 응답은 HTML 등 웹 문서 형식으로 생성해 반환한다.
• Java Thread를 이용해 멀티스레드 방식으로 동작하며, 동시에 여러 요청을 처리할 수 있다.
• MVC 패턴에서 Controller 역할을 수행한다.
• 서블릿 컨테이너에서 실행되며, 요청 수명주기 전반을 관리받는다.
• UDP보다 신뢰성은 높지만, 상대적으로 처리 속도는 느리다 (TCP 기반이기 때문)

서블릿은 단순한 HTTP 처리기를 넘어서, 웹 서버와 클라이언트 사이의 모든 흐름을 담당하는 핵심 컴포넌트다.
스프링 부트를 쓰든, JSP를 쓰든, 결국 그 아래에서 요청을 받아 응답을 보내는 일은 서블릿이 하고 있다.

---

3️⃣ 서블릿의 동작 과정

Servlet 동작과정

 

1. 클라이언트 요청 (HTTP Request)
2. 서블릿 컨테이너 동작 시작
3. init() 호출 - 초기화
4. service() → doGet() / doPost()
5. 응답 반환 (HTTP Response)
6. destroy()

🔹1. 클라이언트 요청 (HTTP Request)

사용자가 웹 브라우저나 앱에서 특정 URL로 요청을 보낸다.

이 요청은 HTTP 프로토콜을 통해 서버(WAS, Web Application Server)로 전달된다.

 

🔹2. 서블릿 컨테이너 동작 시작

WAS 내부의 서블릿 컨테이너는 이 요청을 감지하고, 다음 과정을 자동으로 수행한다.

요청 및 응답에 사용되는 객체는 HttpServletRequest, HttpServletResponse이다.
컨테이너가 요청마다 이 객체들을 자동으로 생성해서 서블릿에 전달한다.

 

1. web.xml 확인
   요청된 URL이 어떤 서블릿과 매핑되어 있는지 확인한다.
   최근에는 애노테이션(@WebServlet)으로 매핑하는 경우가 많지만, 전통적인 방식은 web.xml을 이용
   
   
2. 서블릿 클래스 로딩 및 실행
   해당 요청에 대응하는 서블릿 클래스가 처음 요청될 경우, 컨테이너는 해당 클래스를 메모리를 로딩하고, 서블릿 객체를 단 한 번만 생성

 

🔹3. init() 호출 (초기화)

서블릿이 처음 생성될 때, 컨테이너는 한 번만 init() 메서드를 호출하여 서블릿을 초기화한다.

 

🔹4. 요청 처리: service() → doGet() / doPost()

컨테이너는 해당 서블릿의 service() 메서드를 호출한다.
이 메서드는 요청의 HTTP 메서드(GET, POST 등)를 판별하여, 그에 맞는 doGet() 또는 doPost() 같은 메서드를 호출한다.

• GET 요청 → doGet() 호출
• POST 요청 → doPost() 호출

각 메서드 내부에서 비즈니스 로직을 처리하고, 응답을 HttpServletResponse 객체에 보내서 클라이언트에 전달한다.

 

🔹5. 응답 반환 (HTTP Response)

HttpServletResponse객체를 통한 응답

요청에 대한 처리가 완료되면, 결과는 HTTP 응답 형태로 클라이언트에 반환한다.

 

🔹6. destroy() 호출 (종료 시)

서블릿이 더 이상 필요 없어지거나, 서버가 종료될 때, 컨테이너는 destroy() 메서드를 호출한다.

HttpServletRequest, HttpServletResponse 두 객체 소멸

---

🔸Servlet Container(서블릿 컨테이너)

1️⃣ 서블릿 컨테이너란?

서블릿을 관리해주는 컨테이너

서블릿 컨테이너는 자바 웹 애플리케이션에서 서블릿 기반 요청을 처리하는 핵심 엔진이다. HTTP 요청을 받고, 적절한 서블릿으로 연결하고, 응답을 반환하기까지의 전 과정을 담당한다.

---

2️⃣ 서블릿 컨테이너의 역할

🔹1. 웹서버와의 통신 지원

클라이언트 요청을 받아들여 HTTP 프로토콜을 해석하고 처리할 수 있도록 준비

서블릿 컨테이너는 웹서버와 통합되거나 내장되어, 클라이언트로부터 HTTP 요청을 수신한다.

일반적으로는 Apache, Nginx 같은 웹서버가 요청을 받아 서블릿 컨테이너에 전달하거나, Tomcat과 같이 웹서버와 컨테이너가 통합된 형태도 존재한다.

 

기본적으로 네트워크 통신을 위해서는 개발자가 직접 소켓을 생성하고, listen(), accept() 등을 구현해야 하지만, 서블릿 컨테이너는 이러한 저수준 네트워크 처리 과정을 내부적으로 자동화한다. 즉, 개발자는 복잡한 네트워크 설정이나 HTTP 프로토콜 처리를 신경 쓸 필요 없이, 서블릿의 비즈니스 로직 구현에만 집중할 수 있게 된다.

🔹2. 서블릿 객체 생성 및 생명주기 관리

서블릿의 생명주기

서블릿 컨테이너는 서블릿 클래스를 로드하고, 해당 객체의 생명주기 메서드 (init(), service(), destroy())를 관리한다.

• 요청이 처음 오면 객체를 생성하고 init() 호출
  • 클라이언트 요청이 들어오면 서블릿 컨테이너는 해당 서블릿 클래스가 메모리에 로드되어 있는지 확인한다.
  • 서블릿이 아직 생성되지 않았다면, 컨테이너는 서블릿 객체를 생성하고, init() 메서드를 단 한 번 호출하여 초기화 작업을 수행한다.
  • init()은 서블릿의 초기 설정, 공통 리소스 초기화 등에 활용되며, 한 번만 호출됩니다.
• 요청마다 service() 메서드 실행
  • init()이 완료된 이후부터 클라이언트 요청이 들어올 때마다, 컨테이너는 service() 메서드를 호출한다.
  • 이 메서드는 요청 방식에 따라 자동으로 doGet(), doPost() 등의 메서드로 분기 처리한다.
  • 컨테이너는 이때 요청과 응답 객체(HttpServletRequest, HttpServletResponse)도 함께 전달한다.
• 서버 종료 시 destroy() 호출
  • 서버가 종료되거나, 해당 서블릿이 변경되어 다시 로딩될 경우 컨테이너는 서블릿을 제거(destroy)한다.
  • 이때 destroy() 메서드를 단 한 번 호출하여 정리 작업을 수행한다.
  • destroy()는 보통 리소스 해제, 연결 종료, 로그 처리 등에 사용된다.

🔹3. 멀티스레드 처리

멀티스레드 처리

서블릿 컨테이너는 서블릿을 생성한 이후, 하나의 서블릿 인스턴스를 여러 요청이 동시에 사용할 수 있도록 멀티스레드 방식으로 처리한다. 각 HTTP 요청마다 별도의 스레드를 생성하여 service() 메서드를 호출함으로써, 동시 접속 처리와 성능 향상을 가능하게 한다.

 

과거에는 웹서버가 동적인 콘텐츠를 처리하기 위해 CGI(Common Gateway Interface)라는 방식을 사용했다.
CGI는 웹서버와 외부 프로그램 간의 데이터 통신을 위한 표준 규격으로, C나 Perl로 작성된 프로그램이 대표적이다.

하지만 이 CGI 방식은 요청마다 별도의 프로세스를 생성하여 처리하는 구조였기 때문에, 다음과 같은 중대한 성능 문제가 있었다.

• 요청마다 새로운 프로세스가 생성되고, 작업 후에는 종료되어야 함
• 이 과정에서 메모리와 CPU 자원 소모가 큼
• 동시 요청이 많아지면 서버 과부하로 이어짐

서블릿 컨테이너는 이러한 CGI 방식의 비효율을 멀티스레드 기반 요청 처리 방식으로 해결하였다.

• 하나의 서블릿 인스턴스를 생성
• 들어오는 각 요청마다 새로운 스레드를 생성해 service() 메서드를 실행

🔹4. 보안 관리

서블릿 컨테이너는 기본적인 웹 애플리케이션 보안 기능을 제공한다.

• 인증(Authentication)과 인가(Authorization) 처리
• HTTPS 지원
• URL 접근 제어
• 세션 쿠키 관리

이를 통해 어플리케이션 레벨 보안 로직 없이도 안정적인 보안 환경을 구현할 수 있다.

---

🔸 톰캣 (Tomcat)

톰캣은 대표적으로 서블릿 컨테이너의 종류 중 하나이다.

따라서 위에서 살펴본 것과 같이 클라이언트의 요청이 들어오면 요청마다 스레드를 할당하여 서블릿의 service() 메서드를 실행한다. 

▶️ 톰캣이 쓰레드를 할당하는 구조

과거에는 클라이언트의 요청이 들어올 때마다 새로운 스레드를 생성하여 서블릿을 실행하고, 요청이 끝나면 스레드를 소멸하는 방식을 사용하였다. 하지만 이런 방식은 다음과 같은 단점을 가지고 있다.

• 스레드 생성과 소멸에는 비용이 큼 (CPU, JVM, OS 리소스 소모)
• 매 요청마다 스레드를 새로 만들면 자원 낭비가 심함
• 동시에 많은 요청이 들어올 경우, 스레드 수가 폭증해 시스템이 쉽게 과부하 상태에 빠질 수 있음

위와 같은 문제를 해결하기 위해 Tomcat은 쓰레드 풀을 사용한다.

 

🔹톰캣 쓰레드풀의 동작원리

쓰레드풀

요청 ▶ 작업 큐 ▶ idle 스레드 처리
      │         ▲
      ▼         │
  큐 가득차면 → 스레드 추가 생성 (max size까지)
                      │
     max + queue 한계 초과 → 요청 거부

1. 요청 시작: 초기 스레드 생성
   • 첫 요청이 들어오면, 스레드 풀은 설정된 core size만큼의 스레드를 미리 생성한다.
2. 작업 큐에 요청 저장
   • 유저 요청(HTTP 요청, 소켓 연결)은 먼저 작업 큐에 저장된다.
3. 유휴 스레드가 작업을 처리
   • core size 스레드 중 idle(유휴) 상태인 스레드가 있다면, 작업 큐에서 작업을 꺼내 해당 스레드에 할당하여 요청을 처리한다.
4. 유휴 스레드 없음 → 큐에서 대기
   • 모든 core 스레드가 작업 중이면, 새로 들어온 요청은 작업 큐에서 대기한다.
5. 작업 큐가 가득 차면 스레드 추가 생성
   • 작업 큐가 가득 차면, 스레드 풀은 maximum pool size까지 스레드를 추가 생성하여 요청을 처리하려 시도한다.
6. 최대 스레드 + 큐 초과 → 요청 거부
   • 최대 스레드 수에 도달했고 작업 큐도 가득 찬 상태라면, 추가 요청은 거부되고 클라이언트는 connection refused 또는 503 Service Unavailable 오류를 받게 된다.
7. 작업 완료 후 → 유휴 상태로 전환
   • 작업을 마친 스레드는 다시 유휴 상태로 돌아가며, 다음 요청을 대기한다.
8. 불필요한 스레드 제거
   • 작업 큐가 비어 있고, core size 이상으로 생성된 스레드가 있다면, 일정 시간이 지나면 해당 스레드를 제거한다.

스레드 풀은 적절한 스레드 수와 큐를 관리하며, 요청을 효율적으로 분산 처리하다가 리소스 한계를 넘으면 요청을 거부하여 서버를 보호한다.

 

🔹Server.xml

그렇다면 초기의 톰캣의 스레드 수와, 최대 스레드 수는 어디서 정의할까?

$TOMCAT_HOME/conf/server.xml

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443"
           maxThreads="200"
           minSpareThreads="10"
           acceptCount="100" />

 

• 초기 생성되는 스레드 수 → minSpareThreads
• 최대 스레드 수 (스레드 풀의 max size) → maxThreads
• 대기 큐 크기 → acceptCount

위와 같이 Server.xml을 통해서 Tomcat을 설정한다.

---

🎯 요청 부하 → 톰캣이 밀리는 이유?

이제, 클라이언트의 요청이 들어왔을 때 톰캣이 어떻게 쓰레드를 할당하고 서블릿을 처리하는지에 대한 구조를 이해하였으므로, 부하테스트를 할 때 톰캣이 밀리는 이유에 대해 이해할 수 있다.

 

다음은 클라이언트 요청이 많아졌을 때, 톰캣이 밀리는 과정이다.

 

1. 초기 상태

• 톰캣은 minSpareThreads만큼의 유휴 스레드를 미리 준비한다.

2. 요청이 증가

• 유휴 스레드가 부족해지면 톰캣은 maxThreads까지 스레드를 점진적으로 생성하며 요청을 처리한다.

3. 정해진 maxThreads를 초과한 요청 발생

• 동시에 요청이 maxThreads(예: 200)를 넘으면, 톰캣은 더 이상 스레드를 생성하지 않는다.
• 처리하지 못한 요청은 acceptCount(예: 100) 만큼 대기 큐에 일시적으로 저장된다.

4. 큐까지 가득 차면?

• maxThreads와 acceptCount까지 모두 초과되면 톰캣은 더 이상 요청을 받을 수 없다.
• 추가 요청에 대해 "connection refused", "503 Service Unavailable", 혹은 타임아웃 발생

즉 톰캣의 요청 처리 한계를 초과하여 대기 큐가 가득 차고 새로운 요청이 처리되지 못하는 상태가 되며 톰캣이 밀리는 것이다.

 

💡해결 방법
- maxThreads, acceptCount 값을 서비스 규모에 맞게 조정
- 비동기 처리, Non-blocking I/O 도입
- 요청 처리 시간을 줄이는 구조 개선 (예: DB 튜닝, 캐싱)
- 스케일 아웃 -> 여러 톰캣 인스턴스로 부하 분산

 

 

---

📙 출처

https://mangkyu.tistory.com/14

https://velog.io/@jihoson94/Servlet-Container-%EC%A0%95%EB%A6%AC