스프링 MVC 1편 - [1] 웹 서버, 웹 애플리케이션 서버

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

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

아래 내용은 인프런 김영한님의 스프링 MVC 1편 강의를 듣고 정리한 내용입니다.

 

[1] 웹 서버(Web Server) vs 웹 애플리케이션 서버(WAS)
공통점

① HTTP 기반으로 동작

② 정적 리소스 제공
차이점
① 웹 서버 : 정적파일 위주
② 웹 애플리케이션 서버 : 애플리케이션 코드 실행하는 데 더 특화

웹 시스템 구성
① WAS + DB
WAS가 정적+애플리케이션 로직 모두 수행가능하지만, 그런 식으로 사용하진 않는다.
WAS+DB 조합이 잘 안 쓰이는 이유
1] WAS가 너무 많은 역할을 담당
2] 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행 어려울 수 있음
3] WAS 장애시 오류 화면 노출 불가능

② 웹 서버 + WAS + DB
정적 리소스는 웹 서버, 애플리케이션 로직은 WAS가 처리
장점
1] 효율적 리소스 관리 
=> 정적 리소스, 애플리케이션 리소스 중 많이 사용되는 서버 각자 증설 가능
2] WAS, DB 장애 시 웹 서버가 오류 화면 제공
=> 개발자가 직접 애플리케이션 로직을 손대는 WAS 서버는 잘 죽는데, 웹 서버로 오류 화면 노출 가능

[2] 서블릿(Servlet)
웹 애플리케이션 서버를 직접 구현하려면 서버 TCP/IP 대기·소켓 연결, 파싱, POST /URL 인지, HTTP 응답메시지 생성 등 할 게 많으나 서블릿이 비즈니스 로직을 제외한 나머지 기능을 다 제공해 줌!

HTTP 요청 정보 =  HttpServletRequest
HTTP 응답 정보 = HttpServletResponse <제공!

HTTP 요청 응답 흐름
HTTP 요청시
① WAS는 Request, Response 객체를 새로 만들어 서블릿 객체 호출
② 개발자는 Request 객체에서 요청 정보 꺼내서 사용
     개발자는 Response 객체에서 응답 정보 꺼내서 사용
③ WAS는 Response 객체에 담긴 내용으로 HTTP 응답 정보 생성

서블릿 컨테이너
서블릿 객체를 생성, 호출, 종료하는 생명주기 관리
=> 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라 부름
서블릿 객체는 객체를 만들어두고 공유하는 싱글톤으로 관리
=> 공유변수 사용주의!
JSP도 서블릿으로 변환돼 사용
서블릿의 주요기능 : 동시 요청을 위한 멀티 쓰레드 처리 지원함

[3] 동시요청 - 멀티 쓰레드
쓰레드 : 애플리케이션 코드를 하나하나 순차적으로 실행하는 것
1] 단일 요청 - 쓰레드 하나 -> 잘돌아감
2] 다중 요청 - 쓰레드 하나 ->  X 새로운 요청으로 전환되는 과정에서 실행이 지연되면 time out error 발생
3] 요청마다 쓰레드 생성
  장점 : 동시요청 가능
  단점 : 쓰레드 생성 비용 비쌈. 
            쓰레드 컨텍스트 스위칭 비용 발생 CPU가 하나일 때 각 쓰레드 하나씩 옮겨가면 비용 발생
            생성 제한이 없어서 너무 많은 요청이 들어오면 서버 터짐

4] 쓰레드풀
  필요한 쓰레드를 쓰레드풀에 보관하고 관리. 톰캣은 최대 200개가 디폴트
  쓰레드가 필요하면 풀에서 꺼내 쓰고 다 쓰면 반납함. 모두 사용 중이면 대기하거나 거절 가능.

장점 : 쓰레드를 미리 생성해놔 생성 종료하는 자원을 아낄 수 있음(응답시간 빨라짐)
  
실무에선? 

주요 튜닝 포인트는 최대 쓰레드 수. < 적정 숫자는 그때 그때 다르다.
쓰레드 수가 너무 적으면 CPU 낭비 심하고, 너무 많으면 CPU·메모리 리소스 임계점 초과로 서버 다운
=> 장애 발생하면
클라우드면 서버 늘리고 이후 튜닝
클라우드 아니면 열심히 튜닝...

그런데 WAS가 멀티 쓰레드를 지원하므로 개발자는 관련 코드 신경 안 써도 됨. 하지만, 싱글톤 객체이므로 '멤버 변수 공유'를 주의해서 사용해야 함.

[4] HTML, HTTP API, CSR, SSR

HTML
정적 리소스 : 고정된 HTML 파일, CSS, JS, 이미지, 영상 등 제공 [웹 서버]
HTML 페이지 : 동적으로 필요한 HTML 파일을 생성해 전달 [WAS]

HTTP API
HTML이 아닌 데이터 전달, 주로 JSON 형식 사용한다. 그래서 UI 화면이 필요하면 클라이언트가 별도로 처리해야 함.
HTML을 보여주는 곳을 제외한 모든 프로세스에서 사용됨
=> 웹 클라이언트 to 서버, 앱 클라이언트 to 서, HTTP API - 서버 to 서버

서버사이드 렌더링(SSR)
서버에서 동적으로 HTML을 생성해서 뿌림 -> 주로 정적 화면 사용
관련 기술 : JSP, 타임리프 -> 웹 백엔드 개발자 영역

클라이언트 사이드 렌더링(CSR)
HTML 결과를 자바스크립트 사용해 웹브라우저에서 동적으로 생성해 적용
ex) 구글 지도 등
관련 기술 : React, Vue.js -> 웹 프론트 개발자 영역
1. HTML 요청 
    => 응답 :  HTML 내용 X, 자바스크립트 링크
2. 자바스크립트 요청
    =>응답 : 자바스크립트 클라이언트 로직, HTML 렌더링 코드
3. HTTP API - 데이터 요청
    =>응답 : JSON 

ㅁ 영한님 : 백엔드는 서버 사이드 렌더링 기술에 집중하자!

[5] 자바 백엔드 웹 기술 역사
자바 웹 기술 역사 

과거
1. 서블릿 1997
2. JSP 1999
3. 서블릿 + JSP + MVC 패턴 사용 
4. MVC 프레임워크 난립 2000년~2010년 초
-> 스트럿츠, 웹워크, 스프링 MVC

현대
1. 애노테이션 기반 스프링 MVC
2. 스프링 부트 => 배포의 단순화

최신기술
1. Web Servlet - Spring MVC
2. Web Reactive - Spring WebFlux

    =>웹플럭스는 : 함수형, 비동기 넌 블러킹 처리, but 난이도 높고 관계형 DB 지원 부족으로 아직 거의 쓰이지 않음.

자바 뷰 템플릿 역사
JSP -> 프리마커, 벨로시티 -> 타임리프[사실상 대세]