Servlet

• 앞서 Web server에 대해 공부할 때

• 그런데 비즈니스 로직을 제외한 나머지 기능을 모든 res마다 구현하는 것은 미친짓이라고 하였다. 그리고 개발자가 이를 생략할 수 있도록 도와준 것이 바로 Servlet이라 하였다.

• 보면 위가 서블릿 코드인데 비즈니스로직을 제외한 나머지 코드가 한개도 없다.
  바로 HttpServlet을 extends 해왔는데 이게 @WebServlet 어노테이션과 함께 나머지 불필요한 일련의 과정을 생략할 수 있도록 도와주는 것이다.

• 그래서 urlPatterns의 URL이 호출되면 해당 서블릿 코드가 실행되고
  HTTP req 정보를 편리하게 사용할 수 있는 HttpServletRequest,
  HTTP res 정보를 편리하게 사용할 수 있는 HttpServletResponse,
  그리고 이것들로 인하여 개발자는 HTTP 스펙을 매우 편리하게 사용할 수 있다.

• 그럼이제 서블릿 컨테이너에 대해 더 자세히 알아보자.

Servlet Container

• servlet을 지원하는 WAS 안에는 Servlet container라는게 있는데
  이 Servlet container가 servlet 객체를 자동으로 생성, 호출해준다.
  또한 WAS가 내려갈 때 같이 종료하며 생명주기 관리도 해준다.

• 톰캣처럼 Servlet을 지원하는 WAS를 Servlet container라고 한다.

• ServletContainer는 Servlet객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리한다.

• Servlet객체는 싱글톤으로 관리된다.

  • 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율
  • 최초 로딩 시점에 Servlet 객체를 미리 만들어두고 사용
  • 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근
  • 공유 변수 사용 주의 (항상 싱글톤으로 사용할 땐 이를 주의해야한다!)
  • Servlet Container 종료시 함께 종료

• JSP도 Servlet으로 변환되어서 사용

• 동시 요청을 위한 멀티 쓰레드 처리 지원 -> 따로 개발자가 신경쓰지 않아도 WAS가 다 알아서 해줌

동시 요청 - Multi Thread

1. 사용자가 req를 함
2. 우선 TCP/IP 연결을 하고 연결이 되면 Thread를 할당을 하고
3. Thread가 Servlet을 호출한다.
4. 그럼 Servlet이 일련의 로직을 실행 후 응답을 하여 사용자에게 간다.

Thread

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

• 그럼 만약 쓰레드가 하나인 상황을 가정해보자. 사용자 1이 req를 보냈고 이게 DB이든 로직이든 어떠한 일련의 문제로 굉장히 처리가 지연되고 있다고 가정할 때 사용자 2가 요청을 보내면 쓰레드가 1개밖에 없기 때문에 굉장히 요청이 지연된다. 그리고 나면 나중에 timeout이 나서 둘다 오류를 받을 것이다.
  그럼 이 상황을 해결할 방법이 없을까?

• 답은 굉장히 단순하다 그냥 Thread를 하나 생성하면 된다.
  그래서 req마다 그냥 Thread를 생성하면 된다. -> 그런데 딱 봐도 뭔가 단점이 있을 것 같지 않은가?

• 장점

  • 동시에 요청을 처리할 수 있다.
  • 리소스(CPU, memory)가 허용할 때 까지 처리가능하다.
  • 하나의 쓰레드가 지연되어도 나머지 쓰레드가 동작한다.

• 단점

  • 쓰레드 생성비용이 매우 비싸다.
    • 고객의 요청이 올 때 마다 쓰레드를 생성하면, 응답 속도가 늦어진다.
  • 쓰레드는 컨텍스트 스위칭 비용이 발생한다.
    • CPU의 코어의 수만큼 Thread를 생성할 수 있다.
      그래서 해당 Thread를 다른 task로 전환할 때 비용이 바로 context-switching 비용이라한다.
  • 쓰레드 생성에 제한이 없다.
    • 고객요청이 너무 많으면 CPU, 메모리 임계점을 넘어서 서버가 죽을 수 있다.

Thread Pool

• 서버의 cpu에 코어 수에 맞춰 미리 Thread를 생성해두고 한 곳에 모아두면 그게 Thread pool이고 무한정 생성하는 것이 아닌 서버가 버틸 수 있는 적정량을 생성해두고 multi thread로 동작한다.

• 그럼 Thead pool에 THread가 0개 되면 어떻게 될까?
  대기와 거절을 할 수 있다. 우리가 티켓팅할 때 보는 대기열이다.

• 특징

  • 필요한 쓰레드를 쓰레드 풀에 보관하고 관리한다.
  • 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다. 톰켓의 default thread개수는 최대 200개 기본 설정

• 사용

  • 쓰레드가 필요하면, 이미 생성되어있는 쓰레드를 쓰레드 풀에서 꺼내서 사용한다.
  • 사용을 종료하면 쓰레드 풀에 해당 쓰레드를 반납한다.
  • 최대 쓰레드가 모두 사용중이어서 쓰레드 풀에 쓰레드가 없다면?
    • 기다리는 요청은 거절하거나 특정 숫자만큼만 대기하도록 설정할 수 있다.

• 장점

  • 쓰레드가 미리 생성되어 있으므로, 쓰레드를 생성하고 종료하는 비용(CPU)이 절약되고, 응답 시간이 빠르다.
  • 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있다.

실무 팁

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

Thread pool의 적정 숫자

• 앞서 cpu가 너무 놀아서도 안되고 너무 바빠서도 안 된다고 하였다. 그럼 Thread pool의 적정 숫자는 어떻게 찾을까?

• 어플리케이션 로직의 복잡도, CPU, memory, IO 리소스 상황에 따라 모두 다르다.

• 성능테스트

  • 최대한 실제 서비스와 유사하게 성능테스트를 시도한다.
  • Tool: Apache ab, 제이미터, nGrinder(네이버꺼)

결론

• 멀리도 돌아왔는데 그래서 결국
  WAS는 멀티 쓰레드를 지원해준다. -> 개발자가 멀티쓰레드 관련 코드를 신경쓰지 않아도 된다.
• 마치 싱글 쓰레드 프로그래밍하듯 편리하게 소스코드를 개발할 수 있다.
• 다만 멀티 쓰레드 환경이므로 싱글톤 객체(servlet, spring bean)은 주의해서 사용해야한다.
  공유변수 이런거