티스토리 뷰
WAS(Web Application Server) 와 Web Server
Web Server
- HTTP기반으로 동작
- 정적 리소스 제공
- NGINX,APACHE ..
WAS
- HTTP기반으로 동작
- 웹 서버 기능 + 프로그램 코드를 실행하여 애플리케이션 로직 수행 -> 사용자에 따른 동적 페이지 제공
- 동적 HTML, HTTP API, 서블릿, JSP, 스프링 MVC
- Tomcat ...
둘의 가장 큰 차이는 웹 서버는 정적 리소스를, WAS는 애플리케이션 로직을 제공하는 부분이다.
-> WAS는 애플리케이션 코드를 실행하는데 특화
웹 시스템의 구성
웹 시스템은 WAS, DB로 구성할 수 있다.
하지만, WAS가 부담하는 영역이 커지고(정적 리소스까지 제공해야 함), 장애 발생 때 대응이 어렵다. -> WAS가 전부를 담당
그렇기에 정적 리소스는 웹 서버가, 동적인 처리는 WAS가 담당하게 하는 것이 효율적인 방안이다.
서블릿, Servlet
서블릿은 서버에서 처리하는 업무 중 의미있는 비즈니스 로직에 집중할 수 있게 도와주는 방법
-> TCP/IP 연결하고, HTTP 요청 메시지 파싱하고... 로직을 기반으로 응답 메시지 만들어 클라이언트로 전달!
요청은 HttpServletRequest, 응답은 HttpResponseRequest 객체로 관리
서블릿 컨테이너 : 서블릿을 지원하는 WAS
서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리해준다. 이 객체는 싱글톤 객체이다.
-> 싱글톤 객체, 그렇기에 공유 변수 사용에 주의해야 한다. (싱글톤 객체는 컨테이너와 같이 태어나 같이 죽음)
동시 요청을 위한 멀티 쓰레드를 지원한다.
멀티 쓰레드 - 동시 요청 처리
서블릿 객체를 호출하는 녀석은 누구일까?
쓰레드 : 애플리케이션 코드를 하나하나 순차적으로 실행한다. 한 번에 하나의 코드 라인만 수행
쓰레드는 하나인데 동시 요청이 오기 시작한다면? -> 요청이 마비되기 시작한다. (하나의 자원에 동시 접근)
요청이 올 때마다 쓰레드를 생성하여 사용한다면
- 장점 : 동시 요청을 처리할 수있고, 리소스의 허용 범위까지 처리 가능하다.(쓰레드는 많으니까)
- 단점 : 쓰레드는 컨텍스트 스위칭 비용이 발생한다. -> cpu가 할당하는 쓰레드가 바뀔 때 발생하는 비용
- 쓰레드 생성에 제한이 없다. -> 고객 요청이 너무 많이 오면 (수강신청) 과부하가 와 서버가 죽을 수 있다.
새로운 방법 : 쓰레드 풀 (요청할 때마다 쓰레드 생성을 보완한)
미리 쓰레드 풀에 가용 가능한 쓰레드를 생성해두고 요청이 오면 쓰레드 풀에서 할당해주는 방식
사용이 종료되면 쓰레드 풀에 반납하고, 쓰레드 풀이 비어있다면 일정 대기 수준을 설정할 수 있다.
+) WAS의 주요 튜닝 포인트는 최대 스레드 수 -> 너무 낮으면 cpu가 놀고, 너무 높으면 서버 다운..
+) 적당한 개수는? -> 성능 테스트들 통해 트래픽을 확인하자 ( 아파치 ab, nGrinder .. )
멀티 쓰레드 관련 부분은 WAS가 처리한다. -> 우리는 멀티 쓰레드 관련 코드를 신경쓰지 않아도 된다.
주의해야 할 부분은 싱글톤 객체(서블릿, 스프링 빈)다.
HTTP API, SSR, CSR
HTTP API
- 다양한 시스템에서 호출하며, 데이터만 주고 받는다. (WAS처럼 페이지를 동적으로 만들어주는 것이 아님)
- 앱 클라이언트, 웹 클라이언트와 같은 UI 클라이언트와 데이터를 통신한다.
- 서버 또한 데이터를 주고 받는다. 주로 HTTP API는 JSON 형식이다.
백엔드 개발자의 서비스 제공 -> 정적 리소스 제공, 동적 HTML 페이지 제공, HTTP API 제공
SSR(Server Side Rendering, 서버 사이드 렌더링) - 백엔드
HTML 최종 결과를 서버에서 만들어서 웹 브라우저에 전달, 정적인 화면에 사용한다. -> JSP,Thymeleaf
CSR(Client Side Rendering, 클라이언트 사이드 렌더링) - 프론트엔드
HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용 -> React, Vue
+) 일단 SSR 기술이라도 확실하게 공부하자.
자바 웹 기술의 역사
과거
서블릿 - HTML 생성이 어려움 -> Java 코드로 짜야 하기에
JSP - HTML 생성은 편리, 하지만 비즈니스 로직까지 너무 많이 담당 (비즈니스 로직과 뷰가 한 코드에 존재)
서블릿, JSP 조합하여 MVC 패턴 사용
- 모델, 뷰, 컨트롤러로 역할을 나눈다. 화면은 뷰(JSP), 비즈니스 로직은 서블릿으로 분담
MVC 패턴이 MVC 프레임워크로
- MVC패턴의 자동화, 복잡한 웹 기술을 편리하게 사용 가능한 기능을 지원
현재 사용
애노테이션 기반의 스프링 MVC
- @Controller, MVC 기술의 통일
스프링 부트
- 내장 서버 -> 이전에는 서버에 WAS를 설치하고, 소스를 War 형태로 WAS에 배포한다.
최신 기술 - 스프링 웹 기술의 분화
Web Servlet - Spring MVC
Web Reactive - Spring WebFlux
- 비동기 넌 블러킹 처리, 최소 쓰레드로 최대 성능
- 함수형 개발로 동시처리 코드를 효율적으로, 서블릿 기술을 사용하지 않음
- 기술적 난이도가 높다.
자바 뷰 템플릿
JSP - 속도가 느리고 기능이 부족
Freemarker, Velocity - 속도와 기능적인 부분에서 개선
Thymeleaf
- 내추럴 템플릿 : HTML 모양을 유지하면서 뷰 템플릿을 적용 가능
- 스프링 MVC와의 기능 통합이 강력함
본 포스팅은 인프런 강의 김영한님의
[ 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 ] 을 수강하며 작성한 내용입니다.