김영한님의 스프링 MVC 1편 강의를 듣고 정리한 내용입니다.
웹 서버, 웹 애플리케이션 서버
- 웹 서버
- 웹 애플리케이션 서버
- HTTP 기반 동작
- 애플리케이션 로직(동적)에 특화
웹 시스템 구성
- was, db 만으로 시스템 구성 가능
- was가 너무 많은 역할을 하면 서버 과부하의 우려가 있다
- 정적 리소스는 웹 서버가 처리
- 웹 서버는 잘 안 죽고 WAS는 잘 죽는다.
서블릿
- 비즈니스 로직을 제외하고 서버에서 처리해야 하는 업무를 전부 지원
- HTTP request가 들어오면
- WAS가 Request, Response 객체 만들어서 서블릿 객체 호출
HttpServletRequest
로 Request 객체에 담긴 요청 정보 사용
HttpServletResponse
로 Response 객체에 응답 정보 제공
- WAS가 Response 객체에 담긴 내용을 바탕으로 HTTP 응답 정보 생성
- 서블릿 컨테이너는 서블릿을 자동으로 생성, 호출, 관리한다.
- 서블릿 객체는 싱글톤으로 관리 -> 모든 요청은 동일한 서블릿 객체 인스턴스에 접근
- 공유 변수 사용 주의
- 동시 요청을 위한 멀티 쓰레드 처리 지원 => 핵심!
동시 요청 - 멀티 쓰레드
서블릿은 누가 호출하지?? -> 쓰레드가 호출!
- 애플리케이션 코드를 실행하는 것이 쓰레드
- 자바에서 메인 메서드를
main
쓰레드가 실행한다.
- 요청마다 쓰레드를 생성하면
- 동시 요청 처리가 가능하고 하나가 지연돼도 나머지는 정상 동작한다.
- 생성 비용 비싸고 컨텍스트 스위칭 비용이 발생, 생성 제한이 없어서 서버 죽을 수 있다.
쓰레드 풀
- 미리 쓰레드를 여러개 만들어놓고 요청이 들어올 때 놀고 있는 쓰레드를 사용하고 사용이 끝나면 반납
- 노는 쓰레드가 없으면 쓰레드 대기 또는 요청 거절
- 생성 가능한 쓰레드의 최대치를 관리(톰캣 기본 최대 200개)
실무 팁❗️
WAS 주요 튜닝 포인트는 최대 쓰레드 수
- 너무 적으면 서버 리소스는 여유롭지만 클라이언트 응답 지연이 자주 일어나고
- 너무 높으면 CPU, 메모리 리소스 임계점 초과해서 서버가 다운된다.
서버 리소스가 여유로우면 좋은거 아니야?
CPU 적어도 50%는 사용해야 하는 상황에서 5%, 10%만 사용하는건 설정을 잘못한 것 = 개발자는 부끄러워해라.
장애 발생시
- 클라우드는 서버 늘리고 이후에 튜닝
- 온프레미스는 열심히 튜닝 ^^
적정 숫자는 상황에 따라 전부 다르다. 실무에서는 성능 테스트 해보는 것이 제일 좋다.
HTML, HTTP API, CSR, SSR
- 백엔드에서 어떻게 제공할건지 고민할 부분
- 정적 리소스
- 동적 html 페이지
- HTTP API
- html이 아니라 데이터(주로 json 방식)를 전달하고 클라이언트가 처리
- SSR, 서버 사이드 렌더링
- 서버에서 html 생성에서 전달
- 복잡하지 않고 정적 페이지에 굿
- JSP, 타임리프
- CSR, 클라이언트 사이드 렌더링
- 자바스트립트로 동적으로 html 생성
- 복잡하고 동적인 페이지에 굿
- React, Vue.js
자바 백엔드 웹 기술의 역사
(과거 기술)
서블릿 -> JSP -> 두 개 조합한 MVC 패턴 -> MVC 프레임워크(스트럿츠, 초기 스프링 MVC) -> ...
(현재 사용 기술)
... -> 애노테이션 기반의 스프링 MVC -> 스프링 부트(내장 서버)
- 웹 서블릿 - 스프링 MVC
- 웹 리액티브 - 스프링 WebFlux
스프링 WebFlux❓
- 비동기 넌 블러킹 처리로 최소 쓰레드로 최대의 성능을 낸다. => 일반 MVC 쓰레도 모델도 충분히 빠름
- 함수형 스타일로 개발해서 동시 처리가 효율적이다.
- 서블릿 사용 X
- 러닝커브가 크고 RDB 지원이 아직 부족하다. NoSQL은 잘 쓸 수 있다.