Spring Boot
서블릿(Servlet) 이란?
작은별._.
2024. 1. 1. 11:24
728x90
서블릿은 웹 서버를 구현할 때 필요한 TCP/IP 연결, HTTP 메시지 파싱, HTML 생성 등의 역할을 대신해주어 개발자가 비즈니스 로직에만 집중할 수 있도록 해줍니다. 서블릿은 아래와 같이 생겼습니다.
- urlPatterns(/hello)의 URL이 호출되면 서블릿 코드가 실행됩니다.
- HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServetRequest
- 서블릿이 개발자를 위해 HTTP 요청 메시지를 직접 파싱하여 HttpServletRequest 객체에 담아서 제공
- HTTP 응답 정보를 편리하게 사용할 수 있는 HttpServetResponse
- 개발자가 설정한 스펙에 맞게 서블릿이 HTTP 응답 메시지 직접 구성하여 HttpServletResponse 객체에 담아서 제공
서블릿은 HTTP 요청을 처리하고 응답을 생성하는 Java 클래스의 형태입니다. 개발자는 서블릿을 사용하여 요청을 처리하고 데이터를 생성하여 응답으로 보낼 수 있습니다.
서블릿 컨테이너
서블릿을 지원하는 WAS(Web Application Server) 안에는 서블릿 컨테이너(Servlet Container) 라는 것이 있습니다. (보통 tomcat처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고도 합니다.) 서블릿 컨테이너는 서블릿 객체를 자동으로 생성하고, 초기화하고, 호출하고, 종료시키는 역할을 합니다. 즉, 서블릿의 전반적인 생명주기를 관리합니다.
역할 및 동작 과정
- WAS의 Servlet Container가 servlet 객체를 생성
- Spring Boot 로딩 시점에 생성되거나, 최초 요청 시점에 생성 (서블릿 생성 시점 옵션 설정)
- 클라이언트가 해당 servlet을 사용하는 http 요청을 하면, Servlet Container에서 request,response 객체 생성
- 이때, 쓰레드가 Servlet 객체 호출하고 request,response 객체를 Servlet 객체에 넘겨줌.
- request 객체를 활용해 Servlet의 비즈니스 로직 실행.
- 응답 결과를 response 객체에 담은 후, Servlet Container에 전달
- Servlet Container가 http 응답 메시지 생성 후 클라이언트에게 전달
특징
- 서블릿 객체는 싱글톤으로 관리가 됩니다.
- 어떤 요청이 올 때마다 계속 객체를 생성하는 것은 비효율적입니다. 따라서, 최초 로딩 시점에 서블릿 객체를 미리 만들고 재활용합니다.
- 모든 요청은 동일한 서블릿 객체 인스턴스에 접근합니다.
- 공유 변수를 사용할 때는 매우 주의해야 합니다.
- 서블릿 컨테이너가 종료될 때 함께 종료됩니다.
- 동시 요청을 위한 멀티 쓰레드 처리를 지원해 줍니다.
- 서블릿 객체를 호출하는 주체는 Thread입니다.
- tomcat은 default로 최대 200개의 Thread를 Thread Pool에 생성하여 관리합니다. (개수 변경 가능)
- 멀티 레드에 대한 부분을 WAS가 처리해주기 때문에, 개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 됩니다. 즉, 마치 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드를 개발하면 됩니다.
- 단, 멀티 쓰레드 환경이므로, 싱글톤 객체(서블릿, 스프링 bean)는 주의해서 사용해야 합니다.
참고
Thread Pool: 요청마다 Thread를 생성하는 것의 단점을 보안하기 위해 필요한 Thread를 보관하고 관리하는 곳
Thread가 필요하면, 이미 생성되어 있는 Thread를 Thread Pool에서 꺼내 사용합니다. 사용을 종료한 후, Thread Pool에 해당 Thread를 반납합니다. 만약, Thread Pool에 생성된 모든 Thread 들이 모두 사용 중이라면, Thread를 요청할 때 이 요청을 거절하거나, 특정 숫자만큼만 대기하도록 설정할 수 있습니다.
장점
Thread Pool을 이용하면, Thread가 미리 생성되어 있으므로 Thread를 생성하고 종료하는 비용(CPU)이 절약되고, 응답 시간도 빠릅니다.
실무 성능 튜닝 팁
WAS의 주용 튜닝 포인트는 최대 쓰레드(max thread) 수입니다. 만약, 이 값이 너무 낮게 설정되어 있으면, 동시 요청이 많을 경우 서버 리소스는 여유롭지만 (CPU 사용량 등), 클라이언트는 금방 응답에 지연이 발생할 것입니다. 반대로, 이 값이 너무 높게 설정되어 있다면, 동시 요청이 많을 경우 CPU, 메모리 리소스 임계점 초과로 서버가 다운될 것입니다.
그럼, Thread Pool의 적정 숫자는 어떻게 찾을 수 있을까요?
애플리케이션 로직의 복잡도, CPU, 메모리, IO 리소스 상황에 따라 모두 다르지만, 최대한 실제 서비스와 유사하게 성능 테스트를 시도함으로써 적정 숫자를 결정할 수 있습니다. (tool: Apache ab, 제이미터, nGrinder)
더해서, Spring의 Mult-Thread 관련 참고하면 좋은 포스팅을 첨부합니다!
https://jeong-pro.tistory.com/204
[참고자료]
김영한, " 스프링 MVC 1편", 인프런
728x90
반응형