스프링 MVC (1) 웹 애플리케이션 이해

 

1. 웹 서버, 웹 애플리케이션 서버 

 

 1.1 웹 - HTTP 기반 

 - HTTP 메시지를 통해 많은 것을 전송 (HTML,음성,영상,파일,JSON 등등)

 - 거의 모든 형태의 데이터를 전송할 수 있음 

 - 서버 간 데이터를 주고 받을 때에도 HTTP를 사용한다.

 

 1.2 웹 서버 VS 웹 애플리케이션 서버 

 

  웹 서버:  - HTTP 기반으로 동작, 정적 리소스 제공, 기타 부가기능 

                - 정적 리소스란 HTML,CSS,JS,이미지 영상 등 

                -  대표적인 웹 서버는 APACHE이다.

 

  웹 애플리케이션 서버:  - HTTP 기반 동작, 웹서버 기능 포함 

                                       -  프로그램 코드를 실행해서 애플리케이션 로직 수행 

                                          (동적 HTML, HTTP API(JSON), 서블릿,JSP, 스프링 MVC)

                                        - 톰캣이 대표적인 웹 애플리케이션 서버  

    

출처:  스프링 MVC (김영한 - 인프런)

   - 정적 혹은 동적 애플리케이션 로직을 실행한다는 차이점이 있지만, 둘 사이 경계는 모호하다.

   - 웹 서버도 프로그램을 실행하는 기능 포함하기도 하고, WAS는 WEB 기능도 함 

   - 자바에서는 서블릿 컨테이너 기능을 제공하면 WAS이다. (WAS가 애플리케이션 코드 실행 특화) 

   

1.3 웹 시스템 구성 

 

 - WAS와 DB만으로 시스템 구성 가능하다! WAS는 정적,동적 리소스 모두 제공 가능하다

 - 이럴 경우 WAS가 너무 많은 역할을 담당하고, 서버 과부화 우려가 있다.

 - 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있다.

 - WAS 장애시 오류 화면을 출력할 수도 없다.

 - 이를 개선하기 위해 WEB와 WAS DB를 이용하여 웹 시스템을 구성한다. 

 - 정적 리소스는 웹서버가 처리하고, WAS는 애플리케이션 로직만 담당 

 - WAS,DB 장애시 WEB서버가 오류 화면 제공 (WEB는 잘 안죽음) 

 

* WEB,WAS 분리해두면 효율적 리소스 관리가 가능해짐  

   - 정적리소스 많으면  정적 Web서버 증설 <-> 애플리케이션 리소스가 많이 사용되면 WAS 증설 

 

* API 서버만 서로 소통하는 경우 WAS 서버만 구축해도 상관없기도 하다 

 

2. 서블릿 

 

- HTML From 데이터 전송으로 서버가 HTTP 메시지를 받았다고 해보자 

출처:&nbsp; 스프링 MVC (김영한 - 인프런)

 

- 이때 웹 애플리케이션 서버를 직접 구현해야한다면, 처리해야하는 일이 너무 많다.

-  소켓 열어서 대시 -> 파싱해서 바디 읽고 -> 비지니스 로직 실행 -> 응답 메시지 생성 -> TCP/IP 응답, 소켓 종료

-  의미있는 비지니스 로직을 실행하기까지 준비단계가 너무 많다.

-  서블릿을 지원하는 WAS를 사용하면, 비지니스 로직 외 나머지 과정을 WAS가 다 해준다.

 - 또한 HTTP 스펙을 매우 편리하게 사용할 수 있다.

 

출처: 스프링 MVC (김영한) - 인프런

 

@WebServlet(urlPatterns ="/hello")
public class HelloServlet extends HttpServlet {

   @Override 
   Protected void service(HttpServletRequest request, HttpServletResponse response){
     //로직 
   }
}

 - URL이 호출되면 서블릿 코드 실행

 - HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest

 - HTTP 응답 정보를 편리하게 사용할 수 있는 HttpServletResponse 

   HTTP 스펙을 매우 편리하게 사용 가능하다! 

 

출처:&nbsp; 스프링 MVC (김영한 - 인프런)

   - HTTP 요청시 -> WAS Request,Response 객체를 (요청메시지 기반으로 생성) 새로 만들어서 서블릿 객체 호출 

     -> 애플리케이션 로직을 처리하면서 Request,Response 편리하게 사용

     -> WAS가 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성 

 

2.1 서블릿 컨테이너 

출처:&nbsp; 스프링 MVC (김영한 - 인프런)

 

- 톰캣과 같이 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함

- 서블릿 컨테이너는 서블릿 객체 생성,초기화,호출,종료 등 모든 생명주기 관리함 

- 서블릿 객체는 싱글톤으로 관리된다. 

   > 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율 

   > 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용 

   > 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근 

   > 공유 변수 사용 주의 

   > 서블릿 컨테이너 종료시 함께 종료 

- JSP도 서블릿으로 변환 되어서 사용된다.

- 동시 요청을 위한 멀티 쓰레드 지원 된다.

 

 

3.  멀티 쓰레드

 

- WAS는 내부적으로 멀티 쓰레드를 통해 클라이언트 요청을 처리한다.

- 웹 개발시 멀티 쓰레드 관련 코드를 신경쓰지 않아도 된다!

- 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링빈)은 주의해서 사용하자

 

3.1 요청 마다 쓰레드 생성 

출처: 스프링 MVC (인프런) -김영한

- 크게 클라이언트 요청 -> WAS와 연결 -> 쓰레드 -> 서블릿 호출 -> 로직 실행 후 응답 흐름이다.

- 결국 HTTP도 TCP/IP 방식으로 요청당 1개의 쓰레드가 배정되어 요청을 처리한다.

 

> 장점 :  - 동시 요청 처리

              - 리소스 허용시 까지 처리 가능

              - 하나의 쓰레드가 지연 되어도, 나머지 쓰레드 정상 가동

> 단점 : - 쓰레드 생성비용이 비싸다 (요청마다 쓰레드 생성시 응답 속도 늦는다)

             - 컨텍스트 스위칭 비용이 발생한다.

             - 쓰레드 생성의 제한이 없어서 서버가 다운 될 수 있다.

 

3.2 쓰레드 풀 방식 

 

출처: 스프링 MVC (인프런) -김영한

- 쓰레드 풀을 사용하여 위의 단점을 해소할 수 있다.

- 필요한 쓰레드는 쓰레드 풀에 보관하고 관리 

- 생성 가능한 쓰레드의 최대치 관리 (톰캣 기준 최대 200개 기본설정(변경가능))

- 만일 최대 스레드가 모두 사용중이라면, 기다리는 요청은 거절하거나, 대기를 설정할 수 있다.

 

장점 : > 쓰레드 미리 생성되어 있어서 쓰레드 생성 및 종료 비용 절약, 응답 시간 빠름

          > 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청을 안전 하게 처리

 

* 쓰레드 풀 팁

- WAS의 주요 튜닝 포인트 최대 스레드 수 

   -> 너무 낮게 설정시 ( 서버 리소스가 여유로움에도 불구하고, 클라이언트 응답 지연)

   -> 너무 높게 설정 (리소스 임계점 초과로 서버 다운)

- 장애 발생시 

   -> 클라우드면 서버를 늘리고 -> 이후 튜닝

   -> 클라우드가 아니라면 열심히 튜닝하자 

 

* 적정 쓰레드의 숫자 

이는 애플리케이션 로직의 복잡도, CPU,IO 등등 여러 상황에 따라 모두 다르다 

최선의 방법은 성능 테스트를 열심히 해보는 것이다.

 

 

4. HTML,HTTP API,CSR,SSR

 

4.1 정적 리소스 

 

- 고정된 HTML, CSS,JS,이미지 영상등 제공

- 주로 웹 브라우저 

출처: 스프링 MVC (인프런) -김영한

 

4.2  HTML페이지 (동적)

 

- 동적으로 필요한 HTML 파일을 생성해서 전달

-  웹 브라우저: HTML 해석 

출처: 스프링 MVC (인프런) -김영한

4.3 HTTP API 

 

- HTML페이지 같은게 아닌 데이터 전달

- 주로 JSON형식 사용

- 다양한 시스템에서 호출

- HTTP 프로토콜 위에서 데이터 주고 받기

 

출처: 스프링 MVC (인프런) -김영한

- 웹 클라이언트 to 서버 : 서버에서 데이터 받으면, 웹브라우저에서 UI는 별도 처리

- 앱 클라이언트 to 서버 : 웹과 동일

- 서버 to 서버: 서버간 통신에서도 데이터를 주고받을 때 HTTP API사용

 

4.4 SSR,CSR

 

SSR (서버사이드 렌더링): - HTML 최종 결과를 서버에서 만들어서 웹브라우저에 전달

                                           - 주로 정적인 화면에 사용한다.

                                           - JSP,타임리프 등등

CSR(클라이언트 사이드 렌더링): - HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 

                                                        동적으로 생성해서 적용

                                                      - 주로 동적 화면에 사용, 웹 환경을 마치 앱 처럼 부분부분 변경 가능 

 

* CSR+SSR 동시에 지원하는 웹 프레임워크도 있고, SSR을 써도 자바 스크립트를 통해 일부 동적 변경 가능

 

 

참고자료: 스프링 MVC 인프런 김영한

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1/dashboard

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의