WAS의 서블릿 객체를 호출하는 쓰레드

최지환·2022년 7월 27일

스프링

목록 보기

7/12

단일 요청이 들어온 경우를 생각해보자.

쓰레드는 요청이 들어오기전에는 휴식 상태로 대기하고 있다. 이후 요청이 들어오면 휴식 상태에 있던 쓰레드가 클라이언트로 부터 받은 요청이 할당 되어 서블릿 객체를 호출하고, 로직을 실행한다.

이후 요청을 처리한 응답을 반환한다.

그럼 클라이언트로 부터 다음과 같이 다중 요청을 받을 경우 쓰레드를 하나만 사용한다면 어떻게 될까?

일반적으로 단일 요청을 처리하는 경우보다 다중 요청을 처리하는 경우가 많을 것이다.

위의 그림과 같이 클라이언트로 부터 요청 A 가 들어온 경우, 쓰레드에 요청 A가 할당 된다. 만약 쓰레드가 하나 밖에 없다면, 다른 클라이언트로 부터 다음 요청 B가 들어와도 이를 처리 할 수 있는 쓰레드가 없기 때문에.

처리가 지연 될 수 밖에 없다.

따라서 위의 그림 처럼 요청B는 요청A가 처리 될 때 까지 기다렸다가. 실행이 된다.

만약 위의 상태에서 요청C, 요청 D, 요청 E … 등 수많은 다른 요청이 들어온다면 서버의 속도가 매우 느릴 것이다.

💡 **쓰레드 하나가 하나의 요청**을 처리 할 수 밖에 없기 때문에, 당연하게도 여러 요청이 들어오면 이를 처리하기는 쉽지가 않다.

만약 쓰레드가 요청 A를 처리하던 중, 요청B에 timeout이 발생하면 요청 B에 대한 처리가 안된다.

최악의 상황에는 요청A, 요청 B 둘다 timeout이 발생할 수도 있다.

그렇기 때문에 다음과 같은 방법으로 다중 요청을 처리 한다.

새로운 요청이 들어올 때마다 요청을 처리하는 신규 쓰레드를 만들어 다중 요청을 처리 할 수 있도록 한다.

장점
- 동시 요청 처리 가능
- 리소스(cpu, 메모리)가 허용할 때 까지 처리 가능
- 하나의 쓰레드가 지연 되어도, 나머지 쓰레드는 작동 가능
단점
- 고객이 요청할 때마다 쓰레드를 생성하면 응답 속도가 느려짐
- 컨텍스트 스위칭 비용이 발생
  → 어떤 하나의 프로세스를 실행하고 있는 상태에서 인터럽트 요청에 의해 다음 우선 순위의 프로세스가 실행되어야 할 때 기존의 프로세스의 상태 또는 레지스터 값(Context)을 저장하고 CPU가 다음 프로세스를 수행하도록 새로운 프로세스의 상태 또는 레지스터 값(Context)를 교체하는 작업
- 쓰레드 생성에 제한이 없다.
  - 고객의 요청이 너무 많으면 CPU, 메모리의 임계치를 넘어갈 수 있다. 이 경우 서버가 죽는다.

다중 요청 - 요청 마다 쓰레드 생성 의 단점은 운영중인 서비스에 치명적이다. 서버가 한번 죽으면 이를 복구하는데에도 시간이 들어가기 때문이다. 그래서 다음과 같은 방법(쓰레드 풀)으로 이런 문제를 해결 하였다.

쓰레드 풀 방식은 풀안에 미리 쓰레드 여럿 만들어두고, 미리 만들어둔 쓰레드들로 요청을 처리를한다.
→ 요청이 들어올 때마다 쓰레드를 만들고 삭제하지 않아도 됨.

특징
- 필요한 쓰레드들을 쓰레드 풀에 보관하고 관리
- 쓰레드 풀에 생성가능한 최대 쓰레드 갯수를 관리, 톰캣은 최대 기본으로 200개(개발자가 유동적으로 변경 가능)
사용
- 요청이 들어와 쓰레드가 필요하면, 쓰레드 풀 안에 있는 미리 생성해둔 쓰레드를 꺼내서 사용한다.
- 사용을 종료하면 쓰레드 풀에 해당 쓰레드를 반납
- 모든 쓰레드가 이미 사용중이라 쓰레드 풀에 쓰레드가 없으면
  - 기다리는 요청은 서버에서 거절하거나, 특정 갯수의 요청을 대기하도록 설정할 수 있음(아래 그림 참고)
장점
- 쓰레드가 미리 생성 되어있기 댸문에, 쓰레드의 생성과 종료에 대한 비용이 절약되고, 응답 시간이 빠름
- 너무 많은 요청이 들어와도 서버가 죽지 않으며 안전하게 처리 가능