스프링 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)
- 톰캣이 대표적인 웹 애플리케이션 서버
- 정적 혹은 동적 애플리케이션 로직을 실행한다는 차이점이 있지만, 둘 사이 경계는 모호하다.
- 웹 서버도 프로그램을 실행하는 기능 포함하기도 하고, 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 메시지를 받았다고 해보자
- 이때 웹 애플리케이션 서버를 직접 구현해야한다면, 처리해야하는 일이 너무 많다.
- 소켓 열어서 대시 -> 파싱해서 바디 읽고 -> 비지니스 로직 실행 -> 응답 메시지 생성 -> TCP/IP 응답, 소켓 종료
- 의미있는 비지니스 로직을 실행하기까지 준비단계가 너무 많다.
- 서블릿을 지원하는 WAS를 사용하면, 비지니스 로직 외 나머지 과정을 WAS가 다 해준다.
- 또한 HTTP 스펙을 매우 편리하게 사용할 수 있다.
@WebServlet(urlPatterns ="/hello")
public class HelloServlet extends HttpServlet {
@Override
Protected void service(HttpServletRequest request, HttpServletResponse response){
//로직
}
}- URL이 호출되면 서블릿 코드 실행
- HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest
- HTTP 응답 정보를 편리하게 사용할 수 있는 HttpServletResponse
HTTP 스펙을 매우 편리하게 사용 가능하다!
- HTTP 요청시 -> WAS Request,Response 객체를 (요청메시지 기반으로 생성) 새로 만들어서 서블릿 객체 호출
-> 애플리케이션 로직을 처리하면서 Request,Response 편리하게 사용
-> WAS가 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성
2.1 서블릿 컨테이너
- 톰캣과 같이 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함
- 서블릿 컨테이너는 서블릿 객체 생성,초기화,호출,종료 등 모든 생명주기 관리함
- 서블릿 객체는 싱글톤으로 관리된다.
> 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율
> 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용
> 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근
> 공유 변수 사용 주의
> 서블릿 컨테이너 종료시 함께 종료
- JSP도 서블릿으로 변환 되어서 사용된다.
- 동시 요청을 위한 멀티 쓰레드 지원 된다.
3. 멀티 쓰레드
- WAS는 내부적으로 멀티 쓰레드를 통해 클라이언트 요청을 처리한다.
- 웹 개발시 멀티 쓰레드 관련 코드를 신경쓰지 않아도 된다!
- 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링빈)은 주의해서 사용하자
3.1 요청 마다 쓰레드 생성
- 크게 클라이언트 요청 -> WAS와 연결 -> 쓰레드 -> 서블릿 호출 -> 로직 실행 후 응답 흐름이다.
- 결국 HTTP도 TCP/IP 방식으로 요청당 1개의 쓰레드가 배정되어 요청을 처리한다.
> 장점 : - 동시 요청 처리
- 리소스 허용시 까지 처리 가능
- 하나의 쓰레드가 지연 되어도, 나머지 쓰레드 정상 가동
> 단점 : - 쓰레드 생성비용이 비싸다 (요청마다 쓰레드 생성시 응답 속도 늦는다)
- 컨텍스트 스위칭 비용이 발생한다.
- 쓰레드 생성의 제한이 없어서 서버가 다운 될 수 있다.
3.2 쓰레드 풀 방식
- 쓰레드 풀을 사용하여 위의 단점을 해소할 수 있다.
- 필요한 쓰레드는 쓰레드 풀에 보관하고 관리
- 생성 가능한 쓰레드의 최대치 관리 (톰캣 기준 최대 200개 기본설정(변경가능))
- 만일 최대 스레드가 모두 사용중이라면, 기다리는 요청은 거절하거나, 대기를 설정할 수 있다.
장점 : > 쓰레드 미리 생성되어 있어서 쓰레드 생성 및 종료 비용 절약, 응답 시간 빠름
> 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청을 안전 하게 처리
* 쓰레드 풀 팁
- WAS의 주요 튜닝 포인트 최대 스레드 수
-> 너무 낮게 설정시 ( 서버 리소스가 여유로움에도 불구하고, 클라이언트 응답 지연)
-> 너무 높게 설정 (리소스 임계점 초과로 서버 다운)
- 장애 발생시
-> 클라우드면 서버를 늘리고 -> 이후 튜닝
-> 클라우드가 아니라면 열심히 튜닝하자
* 적정 쓰레드의 숫자
이는 애플리케이션 로직의 복잡도, CPU,IO 등등 여러 상황에 따라 모두 다르다
최선의 방법은 성능 테스트를 열심히 해보는 것이다.
4. HTML,HTTP API,CSR,SSR
4.1 정적 리소스
- 고정된 HTML, CSS,JS,이미지 영상등 제공
- 주로 웹 브라우저
4.2 HTML페이지 (동적)
- 동적으로 필요한 HTML 파일을 생성해서 전달
- 웹 브라우저: HTML 해석
4.3 HTTP API
- HTML페이지 같은게 아닌 데이터 전달
- 주로 JSON형식 사용
- 다양한 시스템에서 호출
- HTTP 프로토콜 위에서 데이터 주고 받기
- 웹 클라이언트 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편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의
웹 애플리케이션을 개발할 때 필요한 모든 웹 기술을 기초부터 이해하고, 완성할 수 있습니다. 스프링 MVC의 핵심 원리와 구조를 이해하고, 더 깊이있는 백엔드 개발자로 성장할 수 있습니다., 원
www.inflearn.com