🐶 코기의 Servlet vs Spring

[10분 테코톡] 🐶 코기의 Servlet vs Spring 를 듣고 정리.

서블릿이란

처음 웹 서버는 클라이언트 요청에 대해서 정적인 페이지로만 응답할 수 있었다. 그래서 웹서버에 프로그램을 붙여서 동적인 페이지를 생성하기 시작했다. 바로 이 서블릿도 동적인 페이지를 생성하기 위해 웹 서버에 붙이는 프로그램중 하나이다.

서블릿을 사용하면 어떤 실질적인 이점이 존재할까?

서블릿으로 요청을 처리할 떄 사용할 수 있는 HttpServletRequest가 제공해주는 편의 메소드의 일부이다. 텍스트 형태의 http 요청을 직접 파싱하기 보다는 HttpServletRequest의 메소드를 호출하는것이 훨씬 편하다.

뿐만 아니라 서블릿이 요구하는 구현 규칙을 지켜주면서 정의해준다면 http 요청 정보를 쉽게 사용할 수 있고, 처리 결과를 쉽게 응답으로 변환할 수 있다.

즉 서블릿을 이용해 웹 요청을 다룬다면 개발자들은 파싱보다는 실제 서비스, 비지니스 처리 로직에 좀더 집중할 수 있게 해준다.

서블릿 인터페이스는 세 가지 메소드를 구현할 것을 규제하고 있다. 서블릿은 실제로 이렇게 생겼다. 생성자, 소멸자 그리고 서비스(요청을 처리할 때 호출되는 메소드이다)

이중 서비스 메소드의 로직을 축약한 코드이다. 간략히 생각하여 Http메소드에 맞는 맵핑된 로직 메소드를 호출한다고 생각하면 된다.

서블릿 컨테이너와 서블릿이 호출되는 과정

서블릿 컨테이너: 서블릿을 담고 관리하는 바구니, 싱글톤 컨테이너 역할. 서블릿의 생명주기를 관리하는 객체

사용자 요청이 들어오면 서블릿 컨테이너는 먼저, HttpServletRequest와 HttpServletResponse를 만들게 된다.

이후 서블릿 컨테이너는 해당 요청과 매핑된 서블릿을 찾게 된다. 서블릿 컨테이너가 어떤 서블릿이 어떤 요청과 매핑되어있는 지는 web.xml 설정파일로 개발자가 지정해줘야한다.

설정파일을 서블릿 컨테이너가 읽어서 이 요청이 어떤 서블릿이 필요한지를 알게 되면 그 서블릿 인스턴스가 컨테이너에 존재하는지 확인한다. 만약에 그 인스턴스가 컨테이너에 존재한다면 그 인스턴스를 그대로 사용하는 것이고 없다면 생성해서 가져가 사용하는 것이다. (생성한다면 앞서 본 서블릿의 init 이 호출!)

서블릿 컨테이너에 스레드를 생성하고 앞서 미리 만든 HttpServletRequest, HttpServletResponse를 인자로 맵핑한 서블릿 인스턴스의 서비스 메소드를 호출한다.

이후 Response를 클라이언트에게 반환하고, HttpServletRequest객체와 HttpServletResponse객체를 소멸시키고 끝나게 된다.

→ 서블릿 인스턴스는 소멸되지 않는다. 서블릿 객체는 싱글톤 패턴이므로 다음 요청이 들어오면 다시 임무를 수행하게 된다

→그렇다면 한 요청을 처리하는 도중에 다른 요청이 동시에 들어온다면? 이때는 멀티스레딩으로 요청을 처리하게 된다 아래 그림처럼 여러 스레드가 생성이되고 스레드당 다른 서블릿이 처리할 수도, 반대로 여러 스레드에서 한 서블릿의 여러 요청을 동시에 처리할 수도 있을 것이다.

하지만, 멀티스레드 사용은 유의해야한다. 스레드 생성 자체의 비용도 크고 다른 스레드로 전환하는 context switch의 오버헤드도 크다. 스레드 생성에 제한을 두지 않는다면, 하드웨어 용량을 초과하게 되면 서버 다운이 발생할 수도 있다.

즉 서블릿 컨테이너에는 비효율성이 존재한다. 요청당 서블릿을 정해주는 곳이 비효율적인데, 관리 측면에서는 멀티스레딩의 어려움, 개발 측면에서는 핸들러의 공통 로직이 매번 중복된다는 단점이 있다.

핸들러의 공통 로직이 매번 중복? 무슨뜻인가

이런 느낌이다. 1, 3이 매번 중복된다. 이러기보다는

이런 구조가 훨씬 나을 것이다. 이러한 패턴이 존재하며 명칭은 프론트 컨트롤러 패턴이다. 즉 앞단에 공통되는 로직을 처리하게 하는 패턴이다.

스프링 mvc가 바로 이 프론트 컨트롤러 패턴을 사용한다. 모든 요청을 받아 공통처리를 하는 전면 컨트롤러 Dispatcher Servlet을 앞단에 둔다.

비교하자면 이전에 서블릿을 개별적으로 다뤘던 때는 요청마다 매반 서블릿을 정의하고, 요청을 수행할때마다 매번 스레드를 생성했다. 하지만 스프링의 front controller pattern은 하나의 서블릿만을 정의하고 이 서블릿이 모든 요청을 수행하게끔 한다.

Dispatcher 서블릿의 웹 요청 처리 과정

디스패쳐 서블릿이 모든 요청을 받는다.

핸들러 맵핑이 요청에 맞는 컨트롤러를 찾아 반환한다.

핸들러어댑터는 그 컨트롤러의 메소드를 호출에서 처리로직을 수행한다.

처리 결과를 Model And View 객체로 변환해서 디스패처 서블릿에 넘겨준다

다시 디스패쳐 서블릿은 뷰 리졸버를 이용해서 뷰를 찾거나 생성한다.

그렇게 얻은 뷰에 모델로 들어왔던 데이터를 넣어서 응답결과 생성을 요청해서 우리가 볼수 있는 JSP나 Thymeleaf같은 데이터를 담은 출력파일로 응답을 한다.

→ 역할을 분담하면서 더 개발자의 일이 늘어난 것이 아니냐?

아니다. 우리가 해야할 것은 처리 핸들러 맵핑된 처리로직뿐이다. 오히려 진짜 집중해야할 곳에 집중할 수 있다.

디스패쳐 서블릿이 스프링 컨테이너로부터 DI를 받아서 사용하고 동작을 하게 된다.

스프링 컨테이너는 프로그램이 동작하는동한 사용되는 자바 객체들을 프레임워크가 대신 관리하고 보관한다.

서블릿 웹 어플리케이션 컨텍스트는 웹 요청 관련 객체들이 담겨있고 루트 웹 어플리케이션 컨텍스트에는 웹 요청처리 관련 빈 외에 컴포넌트들 즉 서비스 레포지토리 관련 객체들이 관리된다. 컨테이너가 개발에 필요한 부분이나 디스패쳐 서블릿이 요청을 처리할 때 필요한 부분은 알아서 주입하게 된다.

한마디로 서블릿 설정 파일만 잘 작성하면 설정대로 생성된 객체가 스프링 컨테이너에서 관리되고 필요한 부분에서 주입되어 디스패쳐 서블릿이 알아서 사용할 수 있게 된다.

더 공부해볼 키워드

• 웹 서버와 웹 어플리케이션 서버
• WAS가 멀티 스레드를 관리하는 방식
• 스프링 설정 파일과 서블릿 설정 팡리
• 스프링 컨테이너에 빈을 등록하는 방법/ 컨테이너가 주입 위치를 찾는 방법
• 디폴트 서블릿
• 스프링과 스프링 부트