[Spring] 스프링 MVC : 스레드란? 서버에서의 스레드 사용방식, 스레드 풀(Thread pool)

[3] 동시 요청 - 멀티 쓰레드

클라이언트의 요청→ WAS가 응답 → TCP/IP 연결 → 서블릿을 호출.

이 서블릿 객체를 누가 호출하는가? 쓰레드

 

쓰레드

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

 

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

• WAS내에 쓰레드가 1개만 있다고 가정

• 요청이 오면 쓰레드 연결 및 서블릿 호출

• 서블릿 응답

• 응답을 수행한 뒤 쓰레드는 휴식

 

다중 요청 - 쓰레드 하나 사용

• 쓰레드는 하나인데 요청이 여러개 들어오는 경우, 먼저 들어온 요청을 처리하기 위해 하나 있는 쓰레드가 할당되어 서블릿 코드를 실행
• 1번 요청 처리가 잘 수행되면, 순차적으로 2번 요청에 대한 응답이 수행하면 됨
• BUT, 1번 요청을 처리하는 과정에서 서블릿 코드 내부의 이유로 지연 발생

• 지연 발생 중에 2번 요청이 들어오면, 쓰레드가 1개뿐이므로 요청2는 대기

• 문제 발생) 지연이 길어지면 1번에 대한 연결과 2번 요청에 대한 연결 모두 죽어버림
  • 2번 요청에 대한 수행 자체가 불가
• 이를 해결하기 위한 가장 단순한 방법 ⇒ 요청마다 쓰레드 하나를 생성해서 처리

 

요청마다 쓰레드 생성

• 쓰레드를 하나 더 생성하고 동일한 서블릿을 호출해 2번 요청을 처리
  • 다른 쓰레드는 지연 중인 쓰레드와 별개로 코드를 실행한 뒤 응답을 수행
  • 쓰레드를 생성해서 요청을 수행하고 실행이 종료되면, 스레드는 해제하는 방식

장단점

• 장점
  • 동시 요청을 처리할 수 있음
  • 리소스(CPU, 메모리)가 허용할 때 까지 처리가능
  • 하나의 쓰레드가 지연 되어도, 나머지 쓰레드는 정상 동작함
• 단점
  • 쓰레드는 생성 비용은 매우 비쌈
    • 고객의 요청이 올 때 마다 쓰레드를 생성하면, 응답 속도가 늦어짐
  • 쓰레드는 컨텍스트 스위칭 비용이 발생
    • 코어 하나가 실제로 스레드를 동시에 수행하는 것이 아님. 스레드끼리 전환할 때 발생하는 비용 ⇒ context swtich
  • 쓰레드 생성에 제한 X
    • 고객 요청이 너무 많이 오면(치킨 디도스 같은), CPU, 메모리 임계점을 넘어서 서버가 죽을 수 있음

이를 방지하기 위해 내부에 Thread Pool이 존재

쓰레드 풀

• 쓰레드가 필요할 때마다 쓰레드 풀에 요청하여, 이미 생성되어 있는 쓰레드를 받아 사용
• 쓰레드 사용을 종료하면 쓰레드 해제가 아닌 쓰레드 풀에 사용한 쓰레드를 반납

• 기존 쓰레드가 모두 사용 중이라 쓰레드 풀에 쓰레드가 없다면, 요청을 거절하거나 특정 숫자만큼 대기하도록 설정할 수 있음

 

요청마다 쓰레드 생성의 단점 보완

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

실무 팁

• WAS의 주요 튜닝 포인트는 최대 쓰레드(max thread) 수이다

• 이 값을 너무 낮게 설정하면?
  • 동시 요청이 많으면, 서버 리소스는 여유롭지만, 클라이언트는 금방 응답 지연
    
    • 최대 쓰레드 수를 10으로 설정한다면, 동시에 100개의 요청이 오는 경우 10개 요청만 처리하고 90개 요청은 대기 or 거절
• WAS는 살아있을지 몰라도 요청이 밀리면서 서비스에는 장애 발생
  • CPU의 5%만 사용한다면 매우 비효율
  • 못해도 CPU 사용율은 50%를 넘겨야 개발자가 어느정도 제대로 세팅했다고 볼 수 있음
• 이 값을 너무 높게 설정하면?
  • 동시 요청이 많으면, CPU, 메모리 리소스 임계점 초과로 서버 다운
• 장애 발생시?
  • 클라우드면 일단 서버부터 늘리고, 이후에 튜닝
  • 클라우드가 아니면 열심히 튜닝

 

쓰레드 풀의 적정 숫자

• 어떻게 찾는가?
• 애플리케이션 로직의 복잡도, CPU, 메모리, IO 리소스 상황에 따라 모두 다름
• 중요한 것은 성능 테스트
  • 최대한 실제 서비스와 유사한 환경에서 성능 테스트 시도
  • 툴: 아파치 ab, 제이미터, nGrinder(오픈소스) 등을 이용

 

WAS의 멀티 쓰레드 지원

• 개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 됨 (비즈니스 로직만) ⇒ 스레드 관련은 WAS가 처리!
• 개발자는 마치 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드를 개발
• 멀티 쓰레드 환경이므로 **싱글톤 객체(서블릿, 스프링 빈)**는 주의해서 사용

 

이 포스트는 인프런 김영한 강사님의 강좌 <스프링 mvc> 를 기반으로 작성되었습니다.