스프링 MVC - 웹 구조, 서블릿

웹 시스템의 구성

1. WAS - DB

- 웹 서버를 두지 않고 WAS가 웹 서버의 역할까지 다 한다.

 

단점

• WAS가 정적 리소스, 동적 리소스 모두 처리하므로 큰 부담이 된다.
• 정적 리소스 생성이 코스트가 큰 동적 어플리케이션 실행에 방해를 줄 수 있다.
• 만약 WAS가 고장 나면 오류 화면을 노출시킬 수 없다.

2. Web Server - WAS - DB

- 앞에서 정적인 처리는 웹 서버가, 동적인 처리가 필요하면 WAS에게 위임

- WAS는 중요한 어플리케이션 로직을 처리

 

장점

• 효율적인 리소스 관리가 가능 - 정적인 요청이 많으면 웹 서버를 증설, 동적인 요청이 많으면 WAS를 증설
• 정적 리소스를 제공하는 웹 서버는 잘 다운되지 않음. WAS는 곧잘 다운됨
• 따라서 WAS가 처리를 하지 못하는 상황이 되어도, 웹 서버에서 오류 메시지를 띄울 수 있음

서블릿

HTML에서 Form 데이터(userName, ID)를 post 전송한다면 http 요청 메시지가 생성될 것이다.

그렇다면 서버에서는 어떤 처리를 해야 할까?

 

- WAS를 사용하지 않는다면..

• 서버 TCP/IP 연결 대기, 소켓 연결
• HTTP 요청 메시지 파싱 해서 데이터 읽기
  • POST 방식, /save URL 인지
  • Content-Type 확인
  • HTTP 바디 메시지 파싱, form에서 전달한 username과 ID를 사용할 수 있게 파싱
• 저장 프로세스 실행
• 비즈니스 로직 실행 - 데이터베이스에 데이터 저장
• HTTP 응답 메시지 생성
  • HTTP 시작 라인 생성
  • Header 생성
  • 메시지 바디에 응답 값 입력
• TCP/IP에 응답 전달, 소켓 종료

를 직접 구현해서 처리해야 한다.

 

- 하지만 서블릿을 지원하는 WAS를 사용한다면?

저 많은 할 일 중 연결, HTTP 요청 메시지 파싱, HTTP 응답 메시지 생성, 전달은 할 필요가 없고 단지

비즈니스 로직 코드만 작성하면 된다.

 

1. 서블릿 클래스

서블릿은 HttpServlet을 상속받으며, 파라미터로 request 객체와 response 객체가 필요하다.

따라서 서블릿 내에서 비즈니스 로직을 진행할 때 http 요청 시 받은 데이터(request)를 접근할 수 있고, 결과를 response객체에 저장해서 반환하면 된다.

 

2. 서블릿의 요청 흐름

• HTTP 요청 시 WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체를 호출한다.
• 개발자는 Request 객체에서 다양한 정보를 get 해서 사용한다.
• Response 객체에 응답 정보를 set 해서 반환한다.
• WAS는 반환된 Response 객체를 토대로 HTTP 응답 메시지를 생성한다. 

 

3. 서블릿 컨테이너

• 톰캣처럼 서블릿을 지원하는 WAS는 서블릿 컨테이너를 갖고 있다.
• 서블릿 컨테이너는 스프링 컨테이너처럼 서블릿 객체를 싱글톤으로 관리한다.
• 최초 로딩 시점에 서블릿 컨테이너에 서블릿 객체들을 생성해두고, 요청 시 재활용한다.
• 따라서 같은 역할을 하는 요청은 모두 같은 서블릿 객체를 통해 처리된다.
• 싱글톤이므로 공유 변수의 사용을 조심해야 한다.
• 또한, 동시 요청을 위한 멀티 쓰레드 처리를 지원한다.

---

4. 동시 요청 - 멀티 쓰레드

 

웹 브라우저의 요청이 WAS와 연결되면, 누가 서블릿 객체를 호출해서 실행할까?

-> 어플리케이션 코드를 하나하나 실행하는 것은 쓰레드이다.

 

따라서, 동시 요청이 들어올 경우 쓰레드를 생성해서 서블릿 객체에 접근한다.

요청마다 쓰레드를 생성하면 어떻게 될까

 

장점

• 동시 요청 처리 가능
• 쓰레드 하나가 죽어도, 다른 쓰레드에 영향 x
• 리소스가 허용할 때까지 처리 가능

단점

• 매번 쓰레드를 생성해야 하므로 생성 비용이 든다.
• 쓰레드는 컨텍스트 스위칭 비용이 든다.
• 쓰레드 생성에 개수 제한이 없으므로, 계속 생성하다 보면 서버 자원의 최대치를 넘어서 죽을 수 있다.

5. 쓰레드 풀

따라서 위의 단점을 막기 위해 쓰레드 풀을 사용한다.

쓰레드 풀에 미리 쓰레드를 지정한 개수만큼 생성해두고, 요청이 들어올 때마다 꺼내서 쓰고 다시 풀에 반환한다.

그렇게 되면, 매번 생성/파괴 비용이 줄어들고, 개수 제한이 있으므로 자원의 최대치를 넘길 일이 없다.

 

6. 쓰레드 풀의 적정 숫자

너무 많이 생성한다면? 응답 가능한 쓰레드의 여분이 많으므로 많은 요청에도 빠르게 응답, 하지만 서버는 위험하다

너무 적게 생성한다면? 응답 가능한 쓰레드가 몇 개 없으므로 많은 요청에 느린 응답, 하지만 서버는 여유롭다.

 

- WAS가 멀티 쓰레드 기능을 지원하는 것은 개발자 입장에서 매우 편하다.

- 싱글 쓰레드 환경처럼 편리하게 소스 코드를 개발하면 되기 때문이다.