*김영한님의 스프링 MVC 강의를 기반으로 작성하였습니다.
웹 서버, 웹 애플리케이션 서버
HTTP: HTTP 메세지에 다양한 데이터를 담아 주고받는다.
웹 서버: 정적 리소스 담당. apache, Nginx 등.
웹 애플리케이션 서버(WAS): 동적, 정적 리소스 처리 가능. 하지만 애플리케이션 로직에 모든 것을 위임하면 안되기에
웹 서버에게 기본적으로 처리 가능한 것은 처리하게 시키고, 동적 리소스 같은 WAS에서 수행해야하는 일은 위임 로직으로 WAS에게 전달.
(애플리케이션 로직은 가장 비싼 요소이다. 가장 중요한 애플리케이션 로직만 전담할 수 있다) ex) tomcat
정적 리소스가 많이 쓰이면 Web 서버 증설하고,
애플리케이션 리소스가 많이 쓰이면 WAS 증설 하는 것으로 효율적으로 리소스 관리 가능.
서블릿
HTTP 메세지를 주고 받을 때, request를 수신하고 의미 있는 정보를 추출하는 선작업과, 로직 실행 뒤
적절한 response 메세지를 생성하여 전달하는 과정을 자동화하여 처리해주는 것이 서블릿.
was에서 받은 request 요청 메세지를 기반으로 새롭게 request, response 객체를 생성하고 서블릿 객체 (helloServlet) 에 파라미터로 전달.
리턴으로 response(servlet 메소드 수행 중 적절한 리턴 정보를 response에 담아놓음) 를 주면, 이것을 기반으로 적절한 response 메세지 생성 후 전달한다.
위 과정을 편하게 사용하게 돕는 것이 서블릿 컨테이너. 서블릿 객체 생성, 호출, 관리를 돕는다.
톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함
서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리 서블릿 객체는 싱글톤으로 관리
고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근
공유 변수 사용 주의
JSP도 서블릿으로 변환 되어서 사용
서블릿 컨테이너 종료시 함께 종료
동시 요청을 위한 멀티 쓰레드 처리 지원 : WAS의 특징. 개발자가 멀티 스레드 관련을 실경쓰지 않아도 WAS가 알아서 처리해준다.
프로세스: 프로그램을 실행
쓰레드: 프러세스 내에서 여러 작업을 수행
쓰레드가 서블릿 객체를 호출한다.
쓰레드는 한번에 하나의 코드 라인만 수행한다.
동시 처리가 필요할 경우, 쓰레드를 추가로 생성한다.
단일 쓰레드에서 만약 요청이 지연되면, 다른 요청이 스레드를 받기 위해 대기하고, 만약 계속해서 지연된다면 둘다 타임 아웃으로 반려된다.
새롭게 쓰레드를 생성하면,
이러한 행위를 WAS가 알아서 해준다.
쓰레드는 생성도 비싸고, 매우 중요한 자원인 CPU를 잡아먹는다.
컨텍스트 스위칭: CPU에 올라가는 자원을 변경하는 것. 쓰레드가 많아지면 계속해서 자원을 갈아끼게되고, 이 비용이 발생하게 된다.
또한 너무 많은 요청이 밀려있다면, 쓰레드가 무한히 생성되어 계속해서 CPU에 들어오려한다(리소스를 너무 차지함). -> 서버 다운으로 이어진다.
문제를 해결하는 방안: 쓰레드 풀
쓰레드 풀에 생성된 쓰레드만 계속해서 활용한다. (한계점을 두는 것)
쓰레드 풀에 잔여 쓰레드 존재 시, 여기서 가져오고, 다쓰고 다시 쓰레드 풀에 반납.
쓰레드를 생성하고, 없애는 것이 아닌, 쓰레드 풀에 미리 일정 개수를 만들어 놓고 계속해서 활용하는 것.
만약 제한 개수를 넘는 쓰레드 요청이 들어오면 대기 or 거절(당장 필요하지 않거나 우선순위가 낮은 것. 나중에 여유 될떄 다시 요청들어오면 그때 수신)
만약 max thread 가 낮다면? cpu 사용률이 낮아짐
AWS에서 cpu 사용률 10% 개짜리 5개를 생성 -> 그냥 1개의 50% 짜리 인스턴스랑 동일한 성능 -> 비용낭비!
적절한 쓰레드 풀의 수는 결국 성능 테스트를 통해 찾아야한다.
[HTML, HTTP API, CSR, SSR]
정적 리소스: 이미 생성된 파일을 반환
그때그때 동적으로 웹 페이지를 생성해서 보낸다.
HTTP API: html이 아닌 데이터를 전달한다.
html 렌더링할 때 쓰이는 것이 아니다.
HTTP API 가 어디서 사용되는가?
html을 보여주는 곳을 제외한 모든 곳에서 사용한다.
서버 개발자가 고려해야하는 사항.
- 정적 페이지
-동적 페이지
- HTTP API
자바 스크립트에서 inner html등으로 동적으로 페이지를 바뀌게 클라이언트 쪽에서 처리
서버 사이드 렌더링: 결국 서버가 보내는 이미지의 연속 (느리게 보면 깜빡깜빡거리는 느낌)
클라이언트 사이드 렌더링: 자체적으로 동적으로 생성 ( 부드럽게 자체적으로)
스프링 부트
-서버를 내장하고 있다.
-빌드 결과 (Jar, War) 에 WAS 서버 포함 -> 빌드 배포 단순화
NodeJS 처럼 비동기 non-blocking 으로 쓰레드 각각을 고효율로 사용가능하지만 아직 완전 x
자바 뷰 템플릿
뷰: HTML을 편리하게 생성.
'Spring boot' 카테고리의 다른 글
스프링 시큐리티 정리 (0) | 2023.04.07 |
---|---|
[스프링 MVC] Part2 (서블릿) (1) | 2023.03.14 |
[JPA] Part 6 (객체지향 쿼리 언어 pt.2) (0) | 2023.03.13 |
[JPA] Part 5 (객채지향 쿼리 언어 pt.1) (0) | 2023.03.13 |
[JPA] Part 4 (값 타입) (0) | 2023.03.10 |