서블릿 기반 스프링 MVC를 사용해 개발을 진행하고 있다면 서블릿 컨테이너이자 WAS(Web Application Server)로 대부분의 개발자들이 Tomcat을 선택할 것이다.
오늘은 많은 개발자들이 사용하고 있는 Tomcat에 대해 정리해보고자 한다.
필자가 공식문서에서 참고한 Tomcat 문서의 버전은 10.1.24이다.
Architecture
전반적인 Tomcat 아키텍쳐와 그 구성요소를 살펴보겠다.
크게 Server, Service, Engine, Host, Connector, Context로 구성된다.
Tomcat은 Servlet 사양의 빠르고 효율적인 구현을 목표로 설계되었다.
Server
Tomcat 환경에서 Server는 전체 컨테이너를 의미한다. 즉 Server는 전체 Catalina 서블릿 컨테이너를 나타낸다.
Tomcat은 개발자가 거의 커스터마이징하지 않는 Server 인터페이스의 기본 구현을 제공한다.
참고로 Tomcat 서블릿 컨테이너를 Catalina라고 부른다.
Service
Service는 Server 내부에 존재하며 하나 이상의 Connector를 하나의 Engine에 연결하는 중간 구성 요소다.
단일 구성 엔진과 하나 이상의 커넥터 구성 요소의 조합을 서비스라고 이해하면 된다.
Service 요소는 기본 구현이 간단하고 충분하므로 개발자가 거의 커스터마이징하지 않는다.
Engine과 Connector는 1:N 관계인 것을 알 수 있다.
Engine
Engine는 특정 service에 대한 요청 처리 파이프라인을 나타낸다.
Service는 여러 Connector를 가질 수 있으므로, Engine은 이들 Connector로부터 모든 요청을 받아 처리하고, 응답을 적절한 Connector에 다시 전달하여 클라이언트로 전송한다.
Engine 인터페이스도 커스텀 Engine을 제공하기 위해 구현될 수 있지만, 이는 흔한 상황은 아니다.
Engine은 특정 Catalina Service와 관련된 전체 요청 처리를 나타낸다.
하나의 Engine는 반드시 Service 내부에 중첩되어야 하며, 해당 Service와 관련된 모든 Connector 다음에 위치해야 한다.
Engine은 Logging, Access Logs, Lifecycle Listeners, Request Filters와 같은 특별한 기능을 가지고 있다.
Host
Host는 가상 호스트를 나타내며, 이는 서버의 네트워크 이름(예: "www.mycompany.com")을 Tomcat이 실행되는 특정 서버와 연결하는 것이다.
Engine은 여러 Host를 포함할 수 있으며, Host 요소는 yourcompany.com 및 abc.yourcompany.com과 같은 네트워크 별칭도 지원한다.
클라이언트가 네트워크 이름을 사용하여 Tomcat 서버에 연결할 수 있으려면, 이 이름이 속한 인터넷 도메인을 관리하는 DNS 서버에 등록해야 한다.
표준 Host 구현이 상당한 추가 기능을 제공하므로 개발자가 커스텀 Host를 만들지 않아도 된다.
HOST는 Logging, Access Logs, 자동 애플리케이션 배포, 호스트 이름 별칭, 라이프 사이클 리스너, 요청 필터, SSO(Single Sign ON), 사용자 웹 애플리케이션과 같은 특별한 기능을 제공한다.
Connector
Connector는 클라이언트와의 통신을 처리한다.
Tomcat에는 여러 Connector가 있다.
여기에는 대부분의 HTTP 트래픽에 사용되는 HTTP Connector와 Tomcat을 Apache HTTPD 서버와 같은 웹 서버에 연결할 때 사용되는 AJP 프로토콜을 구현하는 AJP Connector가 포함된다.
커스터마이징된 Connector를 만드는 것은 어려우므로 제공하는 구현체를 사용하면 된다.
커넥터는 추후에 더 자세한 내용으로 보충할 예정이다.
Context
Context는 웹 애플리케이션을 나타내며, 하나의 Host는 고유한 경로를 가진 여러 Context를 포함할 수 있다.
Context 인터페이스를 사용해 커스텀 Context를 구현할 수 있지만, StandardContext가 상당한 추가 기능을 제공하기 때문에 커스텀 구현체를 우리가 작성할 이유는 없다.
HTTP 요청을 처리하는 웹 애플리케이션은 Request URI의 가장 긴 prefix를 각 정의된 Context의 컨텍스트 경로와 일치시켜 Catalina(서블릿 컨테이너)에 의해 선택된다.
선택된 Context는 웹 애플리케이션 배포에 정의된 서블릿 매핑에 따라 들어오는 요청을 처리할 적절한 서블릿을 선택한다.
일단 이 정도로 아키텍쳐의 핵심 구성 요소는 살펴볼 수 있었다.
슬쩍 공식 문서를 구경해봤는데 최근에 자바 21에서 등장한 Virtual Thread도 지원하는 Executor도 등장한 것을 확인할 수 있었다.
사실 아키텍쳐를 가볍게 정리했지만.. 구조만 가볍게 살펴본 것이고 진짜 중요한 Connector는 별도의 게시글에서 정리해보겠다.
Tomcat 아키텍쳐를 간단하게 정리한 이미지를 첨부하면서 마치겠다.
참고 자료
https://tomcat.apache.org/tomcat-10.1-doc/architecture/overview.html
https://howtodoinjava.com/tomcat/tomcats-architecture-and-server-xml-configuration-tutorial/
댓글