웹 애플리케이션 이해
인프런 - 김영한 님의 스프링 MVC 1편을 듣고 강의 내용을 개인 공부 목적으로 요약정리한 포스트입니다.
출처
HTTP에 관한 기반 지식 필요
● 웹 서버, 웹 애플리케이션 서버(WAS) ●
웹에서는 모든 것이 HTTP를 통하여 이루어진다.
HTTP 메시지에 모든 것을 전송할 수 있다.
HTML, TEXT
IMAGE, 음성, 영상, 파일
JSON, XML (API)
심지어 서버간 데이터를 주고받을 때도 대부분 HTTP를 사용한다.
웹 서버(Web Server)란
HTTP를 기반으로 동작하는 서버이다.
정적 리소스, 기타 부가 기능을 제공한다.
정적 리소스란, 정적 HTML, CSS, JS, 이미지, 영상과 같은 정적 데이터들을 말한다.
대표적 웹 서버로는 NGINX, APACHE가 있다.
웹 애플리케이션 서버(WAS - Web Application Server)란
웹 서버와 마찬가지로 HTTP으로 동작
웹 서버 기능을 대부분 포함 + (정적 리소스 제공 기능)
프로그램 코드를 실행하여 애플리케이션 로직을 수행한다
- 동적 HTML 생성, HTTP API(혹은 REST API, JSON)
- 서블릿, JSP, 스프링 MVC ->이 WAS에서 동작한다.
대표적인 WAS 서버 예로는 톰캣(Tomcat), Jetty, Undertow 이 있다.
웹 서버, 웹 애플리케이션 서버(WAS)의 차이
웹 서버와 웹 애플리케이션 서버 (WAS) 용어의 경계가 모호함.
WAS는 애플리케이션 코드를 실행하는데 더 특화되어있다.
웹 서버 - 정적 리소스(파일), WAS는 애플리케이션 로직을 실행하는 서버다.
웹 시스템 구성 - WAS, DB의 경우
WAS는 정적 리소스, 애플리케이션 로직을 모두 제공하므로, WAS와 DB만으로 시스템 구성이 가능하다.
하지만 이렇게 하면 WAS가 너무 많은 역할을 담당하게 되어 서버 과부하가 우려된다.
가장 비싼 애플리케이션 로직이 값이 싼 정적 리소스 제공 때문에 수행이 어려울 수 있다.
WAS 장애시 오류 화면 노출도 불가능하다.
웹 시스템 구성 - WEB, WAS, DB의 경우
정적 리소스를 처리하는 웹 서버를 따로 둔 경우,
정적 리소스는 웹 서버가 처리하고, 애플리케이션 로직 같은 동적 처리가 필요하면 WAS에 요청을 보낸다.
WAS는 중요한 애플리케이션 로직 처리만 전담.
정적 리소스가 많이 사용되면 Web서버를 증설하거나 애플리케이션 리소스가 많이 사용되면 WAS를 증설하는 식으로 효율적인 리소스 관리도 가능하다.
정적 리소스만 제공하는 웹 서버는 잘 죽지 않는다. WAS에서 오류가 나더라도 WEB 서버에서 오류 화면을 노출시킬 수 있다.
● 서블릿 ●
서버에서 처리해야 하는 업무
만약 클라이언트가 하나의 HTML Form데이터를 post 메서드로 전송하면, 웹 브라우저에서 HTTP 메시지를 생성한다.
그러면 서버는
이 많은 일들을 처리해야 하는데, 사실상 저 곳에서 의미 있는 비즈니스 로직은 저 초록색 부분뿐이다.
서블릿을 지원하는 WAS에서 서블릿은 저 비즈니스 로직을 제외한 소켓 연결, HTTP 요청 파싱, HTTP 응답 메시지 생성 등등을 처리해준다.
서블릿 코드의 모습
서블릿의 HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest, HTTP 응답 정보를 편리하게 사용할 수 있는 HttpServletResponse. 이것을 잘 사용하기 위해서는 HTTP의 스펙을 잘 이해하고 있어야 한다.(복습할 것!)
HTTP 요청, 응답 흐름
웹 브라우저에서 HTTP 요청 메시지 -> WAS에서 request, response 객체 생성 -> 서블릿 컨테이너에서 request, response의 정보로 비즈니스 로직 실행, response 반환 -> WAS에서 response 객체의 내용으로 HTTP 응답 정보 생성
서블릿 컨테이너
서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함. 대표적으로 톰캣
서블릿 객체의 생명주기 관리.
서블릿 객체는 싱글톤으로 관리.
-> 싱글톤이란, 하나의 객체만 만들어 공유하여 재활용하는 것. 왜? 요청이 올 때마다 계속 객체를 생성하는 것은 비효율적이다. 동일한 객체에 인스턴스로 접근하여 사용한다.
따라서, 공유 변수 사용에 주의하여야 함
JSP(자바 서버 페이지)도 서블릿으로 변환되어서 사용된다
동시 요청을 위한 멀티 스레드 처리 지원
● 동시 요청 - 멀티 쓰레드 ●
서블렛 객체를 호출하는 것은 WAS의 쓰레드.
쓰레드
쓰레드란?https://ko.wikipedia.org/wiki/%EC%8A%A4%EB%A0%88%EB%93%9C_(%EC%BB%B4%ED%93%A8%ED%8C%85)
쓰레드는 한번에 하나의 코드 라인만 수행할 수 있다.
쓰레드는 생성 비용이 매우 비싸다. (만일 다중 요청이 있을 때, 요청이 올 때마다 쓰레드를 생성하면 응답 속도가 늦어진다.)
쓰레드는 컨텍스트 스위칭 비용이 발생한다.
따라서 WAS에서 요청이 올 때마다 쓰레드를 생성하여 사용한다면, 리소스(CPU, 메모리)가 허용할 때 까지는 처리가능하지만, 임계점을 넘으면 서버가 죽을 수 있다.
쓰레드 풀
요청마다 쓰레드를 생성하여 사용하는 것의 단점을 보완한 것.
필요한 쓰레드를 미리 생성하여 쓰레드 풀에 보관하여 관리한다.
쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다.
장점-> 쓰레드가 미리 생성되어 있으므로, 쓰레드를 생성하고 종료하는 비용(CPU)이 절약되고, 응답 시간이 빠르다.
생성 가능한 쓰레드의 최대치가 있으므로 많은 요청이 들어와도 기존 요청을 안전하게 처리한다.
WAS의 멀티 쓰레드 지원
WAS가 멀티 쓰레드를 지원하므로 개발자는 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드 개발
단, 멀티 쓰레드 환경임을 유의하여 싱글톤 객체(서블릿, 스프링 빈)를 주의해서 사용하여야 함.
● HTML, HTTP API, CSR, SSR ●
서버에서
정적 리소스를 요청받으면 고정된 HTML 파일, CSS, JS, 이미지, 영상 등을 제공
동적으로 생성되는 HTML 페이지를 요청받으면 WAS에서 DB 조회 등을 거쳐 동적으로 HTML을 JSP 혹은 타임리프 등으로 생성하여 제공할 수 있음
HTTP API는 HTML이 아니라 데이터를 전달하는데 주로 JSON의 형식을 사용한다.
HTTP API는 다양한 시스템 연동이 가능하다. (앱 클라이언트, 웹 브라우저, 웹 클라이언트(React, Vue.js), 서버 to 서버(예를 들면, 주문 서버 -> 결제 서버, 기업 간 데이터 통신)
SSR - 서버 사이드 렌더링
서버에서 최종 HTML을 생성해서 클라이언트에 전달.
주로 정적인 복잡하지 않은 화면에 사용
JSP, 타임리프 -> 공부해두기
CSR - 클라이언트 사이드 렌더링
HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성하여 적용
주로 복잡하고 동적인 화면에 사용, 웹 환경을 마치 앱처럼 필요한 부분 부분 변경할 수 있음.
ex) 구글 지도, Gmail, 구글 캘린더
React, Vue.js
● 자바 백엔드 웹 기술 역사 ●
과거 기술
서블릿 -1997
JSP - 1999
서블릿, JSP 조합 MVC 패턴 사용
다양한 MVC 프레임 워크 - 2000년 초 ~ 2010년 초
현재 사용 기술
애노테이션 기반의 스프링 MVC 등장
스프링 부트 등장 - 스프링 부트는 서버를 내장
과거에는 서버에 톰캣 같은 WAS를 직접 설치하고, 소스는 War파일(https://ko.wikipedia.org/wiki/WAR_(%ED%8C%8C%EC%9D%BC_%ED%8F%AC%EB%A7%B7))을 만들어서 설치한 WAS에 배포
->스프링 부트는 빌드 결과(Jar)에 WAS 서버 포함 -> 빌드 배포 단순화
최신 기술
스프링 웹 플럭스
자바 뷰 템플릿 역사 - HTML을 편리하게 생성하는 뷰 기능
- JSP
- 프리마커(Freemarker), Velocity(벨로시티)
- 타임리프(Thymeleaf)
- 내추럴 템플릿 (HTML의 모양을 유지하면서 뷰 템플릿 적용 가능)
- 스프링 MVC와 강력한 기능 통합