서블릿 기본 지식

위와 같은 HTML Form이 있고, 전송하면 해당 데이터를 통해 POST 요청 메시지가 만들어지고 회원가입이 되는 것이 있다고 하자.

서버에서는 어떤 일을 처리해야 할까?

연결하고, HTTP 메시지를 읽고 분석하고, 비즈니스 로직을 실행한 후 응답 메시지를 생성해 보내고 종료한다.

여기서 그때마다의 비즈니스 로직은 일부분이고 HTTP 메시지를 파싱하고 분석하는 그런 나머지 부분은 어떤 비즈니스 로직을 개발하든 공통적으로 처리해야되는 동작이다.

그래서 서블릿이 등장한다.

서블릿을 지원하는 WAS가 비즈니스 로직을 제외하고 모든 역할을 해준다.

서블릿

• urlPatterns(/hello)의 URL이 호출되면 서블릿 코드가 실행.
• HTTP 요청을 편리하게 사용할 수 있는 HttpServletRequest
  • 이 객체를 이용해 사용자 이름을 가져오는 등의 역할을 할 수 있다.
• HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse
• 개발자는 HTTP 스펙을 매우 편리하게 사용할 수 있다.

서블릿 작동 흐름

• HTTP 요청 시
  • WAS는 Request, Response 객체를 새로 만들어 서블릿 객체 호출
  • 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내 사용
  • 개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력
  • WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성

서블릿 컨테이너

톰캣과 같이 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 한다.

• 서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리
• 서블릿 객체는 싱글톤으로 관리한다. (Request, Response 객체 아님)
  • 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율적이다.
  • 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용한다.
  • 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근한다.
  • 따라서 공유 변수의 사용에 주의해야 한다.
  • 서블릿 컨테이너 종료 시 함께 종료된다.
• JSP도 서블릿으로 변환되어 사용된다.
• ★동시 요청을 위한 멀티 쓰레드 처리를 지원한다.

멀티쓰레드

클라이언트가 요청을 하면 TCP/IP 연결이 된다. 여기서 서블릿 객체를 호출하고 작업을 처리하게 된다.

서블릿 객체를 누가 호출하나?

쓰레드가 호출한다.

• 애플리케이션 코드를 하나하나 순차적으로 실행하는 것이 쓰레드
• 자바 메인 메서드를 처음 실행하면 main 이라는 이름의 쓰레드가 실행
• 쓰레드가 없다면 자바 애플리케이션 실행이 불가능
• 쓰레드는 한번에 하나의 코드 라인만 수행한다.
• 동시 처리가 필요하면 쓰레드를 추가로 생성한다.

단일 요청 - 쓰레드 하나 사용

요청이 오면 쓰레드를 할당하고 이 쓰레드가 서블릿을 호출하고 서블릿이 응답처리를 한 후 사용된 쓰레드는 다시 휴식하게 된다.

다중 요청

요청1에서 쓰레드를 사용하는데 처리에 지연이 발생했다. 이 때 요청2가 들어온다면 쓰레드를 사용하지 못한다. 이러면 둘 다 지연이 발생하고 오류가 발생할 수 있다.

해결?

요청마다 쓰레드를 생성하면 된다.

요청1의 처리가 지연이 되어도 요청2의 쓰레드가 따로 생성되었기 때문에 그 쓰레드는 정상적으로 서블릿 객체를 호출하고 처리할 수 있다.

• 장점
  • 동시 요청을 처리할 수 있다.
  • 리소스(CPU, 메모리)가 허용될 때 까지 처리 가능.
  • 하나의 쓰레드가 지연 되어도 나머지 쓰레드는 정상 동작한다.
• 단점
  • 쓰레드의 생성비용이 매우 비싸다. (CPU 등)
    • 고객의 요청이 올 때 마다 쓰레드를 생성하면 쓰레드의 생성 시간만큼 응답 속도가 늦어진다.
  • 쓰레드는 컨텍스트 스위칭 비용이 발생한다.
    • CPU 코어가 하나라면 2개의 쓰레드를 처리할 때 동시 수행하는 것이 아닌 순차적으로 수행하게 된다. 너무 빨라서 동시처리로 보이는 것이다.
    • 이렇게 수행하는 과정에서 스위칭하는데 비용이 발생한다.
  • 쓰레드 생성에 제한이 없다.
    • 고객 요청이 너무 많이 오면 CPU, 메모리 임계점을 넘어 서버가 죽을 수 있다.

쓰레드 풀

각 요청마다 쓰레드를 생성하는 것에 대한 문제를 해결하기 위해 WAS는 쓰레드 풀을 사용한다.

내부에 쓰레드 풀을 만들어놓고 요청이 오면 쓰레드 풀에 있는 쓰레드를 사용하게 된다. 쓰레드의 사용이 끝나면 다시 쓰레드 풀에 넣는다.

쓰레드를 계속 죽이고 다시 생성하는 것이 아니기때문에 쓰레드의 생성 시간을 아낄 수 있다.

서버의 한계때문에 지정해놓은 쓰레드 풀의 모든 쓰레드가 사용 중이라면 요청을 대기시키거나 요청이 너무 많다면 거절할 수 있다.

• 특징
  • 필요한 쓰레드를 쓰레드 풀에 보관하고 관리한다.
  • 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다. 톰캣은 최대 200개가 기본설정이다. (변경 가능)
• 사용
  • 쓰레드가 필요하면, 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내 사용한다.
  • 사용을 종료하면 쓰레드 풀에 해당 쓰레드를 반납한다.
  • 최대 쓰레드가 모두 사용중이어서 쓰레드 풀에 쓰레드가 없다면
    • 기다리는 요청은 거절하거나 특정 숫자만큼만 대기하도록 처리.
• 장점
  • 쓰레드가 미리 생성되어 있으므로 쓰레드를 생성하고 종료하는 비용(CPU)이 절약되고 응답시간이 빠르다.
  • 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있다.

실무 팁

• WAS의 주요 튜닝 포인트는 최대 쓰레드(max thread) 수 이다.
• 이 값을 너무 낮게 설정하면?
  • 동시 요청이 많으면 서버 리소스는 여유롭지만 클라이언트 입장에서는 금방 응답이 지연된다.
• 이 값을 너무 높게 설정하면?
  • 동시 요청이 많으면 CPU, 메모리 리소스 임계점 초과로 서버가 다운된다.
• 장애 발생 시?
  • 클라우드라면 일단 서버부터 늘리고 이후 튜닝한다.
  • 클라우드가 아니면 열심히 튜닝한다.

그래서 쓰레드 풀의 적정 숫자를 어떻게 찾나?

• 애플리케이션 로직의 복잡도(DB를 몇 번 호출하는 지 등), CPU, 메모리, IO 리소스 상황에 따라 모두 다르다.
• 성능 테스트 (트래픽이 큰 서비스라면)
  • 최대한 실제 서비스와 유사하게 성능 테스트를 시도한다.
  • 툴 : 아파치 ab, 제이미터, nGrinder

WAS의 멀티 쓰레드 지원의 핵심

• 멀티 쓰레드에 대한 부분은 WAS가 처리
• 개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 됨. (직접하려면 매우 힘듦)
• 개발자는 마치 싱글 쓰레드 프로그래밍을 하듯 편리하게 소스코드를 개발.
• 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용.