이 글은 김영한 님의 스프링 MVC 1편 수강 후 정리한 글입니다.
(https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1/dashboard)
웹 서버, 웹 애플리케이션 서버
웹 (서버, 인터넷, 클라이언트)는 HTTP(하이퍼텍스트 전송 프로토콜) 기반으로 통신한다.
즉, HTTP 메시지에 아래와 같이 거의 모든 형태의 데이터를 담아서 전송한다.
• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML (API)
서버 간에 데이터를 주고받을 때도 대부분 HTTP를 사용하며 지금은 바야흐로 HTTP 시대라고 할 수 있겠다!
1. 웹 서버
먼저 웹 서버는 HTTP 기반으로 동작하며, 정적 리소스를 제공하고 그 외 기타 기능들을 제공한다.
• 정적(파일) : HTML, CSS, JS, 이미지, 영상
ex) NGINX, APACHE
※ 정적 리소스 제공 : 브라우저나 클라이언트 쪽에서 HTTP 요청이 들어왔을 때 서버에 존재하는 해당 정적 리소스를 HTTP 응답으로 보내주는 것이다. (모든 사용자에게 동일한 파일 제공)
2. 웹 애플리케이션 서버 (WAS)
웹 애플리케이션 서버 또한 HTTP 기반으로 동작하며, 앞서 언급한 웹 서버의 기능(정적 리소스 제공 등)을 제공한다.
또한 웹 서버와 다르게 프로그램 코드를 실행하여 애플리케이션 로직을 수행할 수 있다. 그렇기 때문에 사용자 별로 다른 화면을 제공할 수 있다는 장점이 있다.
• 동적 HTML, HTTP API(JSON)
• 서블릿, JSP, 스프링 MVC
ex) Tomcat, Jetty, Undertow
3. 웹 서버 vs 웹 애플리케이션 서버
위에서 말했듯이 웹 서버는 정적 리소스 파일을 제공하지만, WAS는 애플리케이션 로직 또한 실행할 수 있다.
하지만 사실은 둘의 용어도, 경계도 상당히 모호하다고 한다.
웹 서버도 프로그램을 실행하는 기능을 포함하기도 하고, WAS도 웹 서버의 기능을 제공하기 때문이다.
자바에서는 서블릿 컨테이너 기능을 제공하면 WAS로 보긴 하는데, 서블릿 없이 자바코드를 실행하는 서버 프레임워크도 존재한다...
애매하긴 하지만 정리하자면 WAS는 애플리케이션 코드를 실행하는데 더 특화되어 있다고 보면 되겠다.
4. 웹 시스템 구성 - WAS, DB
WAS와 DB 만으로 웹 시스템 구성이 가능하다.
WAS는 정적 리소스, 애플리케이션 로직 모두 제공 가능하기 때문이다.
하지만 이렇게 되면 WAS가 너무 많은 기능을 담당하게 되어 과부화가 발생할 수 있다.
값 비싼 애플리케이션 로직이 값 싼 정적 리소스 때문에 수행이 어려워지는 경우가 생길 수 있다는 것이다.
심지어 WAS는 장애 발생 시 오류 화면도 노출시킬 수 없다.
※ API를 통해 단순히 화면없이 데이터 전달만 할 거라면 위와 같이 WAS와 DB 만으로 구성하기도 한다.
5. 웹 시스템 구성 - WEB, WAS, DB
위와 같은 문제를 방지하기 위해 보통 일반적으로 웹 시스템을 WEB, WAS, DB를 사용하여 구성한다.
웹 서버는 정적 리소스를 처리하며, 애플리케이션 로직과 같은 동적인 처리가 필요하게 될 때는 WAS에 요청을 위임한다.
WAS는 값 비싸고 중요한 애플리케이션 로직 처리를 전담한다.
위와 같은 웹 시스템 구성은 효율적인 리소스 관리가 가능하다는 장점이 있다.
정적 리소스가 많이 사용되면 웹 서버를, 애플리케이션 로직이 많이 사용되면 WAS를 증설함으로써 효율적인 관리를 가능하게 한다.
또 다른 장점으로는 WAS, DB에서 장애 발생 시에 WEB 서버가 오류 화면을 제공해 줄 수 있다는 점도 있다.
WAS는 오류가 잘 발생하는 편이지만, 정적 리소스만을 담당하는 WEB은 쉽게 다운되지 않는다.
서블릿
서블릿이란 자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램 혹은 그 사양을 말한다.
클라이언트의 요청에 대해 동적으로 작동하는 웹 애플리케이션 컴포넌트이며, MVC 패턴에서 Controller로 사용된다.
웹 애플리케이션을 개발할 때 실질적인 비즈니스 로직만을 개발하고 싶지만, 그 외에도 파싱이나 응답 전달 등 더 많은 기능을 사용해야 한다.
의미있는의미 있는 비즈니스 로직만을 집중해서 개발해도 바쁜데 그 외 기능들도 직접 구현해야 한다면 상당히 시간 낭비일 것이다. 그렇기 때문에 우리는 서블릿을 지원하는 WAS를 사용하여 의미 있는 비즈니스 로직만을 구현하도록 해야 한다.
1. 특징
@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {
@Override
protected void service(HttpServletRequest request, HttpServletResponse response){
//애플리케이션 로직
}
}
위의 코드는 서블릿의 예시 코드이다. urlPatterns의 "/hello"가 호출되면 서블릿 코드가 실행된다.
HttpServlet을 상속하여 서블릿을 이용할 수 있다.
HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest와 HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse가 존재한다.
개발자가 HTTP 스펙을 매우 편리하게 이용할 수 있도록 한다.
2. 서블릿 HTTP 요청 / 응답
HTTP 요청이 WAS에 들어오면 Request, Response 객체를 새로 만들어 서블릿 객체를 호출한다.
개발자는 Request 객체에서 HTTP 요청 정보를 꺼내 사용하고, Response 객체에 HTTP 응답 정보를 편리하게 입력한다.
마지막으로 WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성해준다.
3. 서블릿 컨테이너
서블릿을 지원하는 WAS를 서블릿 컨테이너라고 한다. ex) Tomcat
서블릿 컨테이너는 서블릿 객체의 생명주기를 관리한다. (생성, 초기화, 호출, 종료)
서블릿 객체는 싱글톤으로 관리되는데, 최초 로딩 시에 서블릿 객체를 미리 만들어두고 이를 재활용한다. (공유 변수 사용 주의)
요청이 올 때마다 계속 객체를 생성하는 것은 비효율적이기 때문이다.
서블릿 객체는 서블릿 컨테이너 종료 시 함께 종료된다.
동시 요청을 위한 멀티 쓰레드 처리를 지원한다.
동시 요청 - 멀티 쓰레드
1. 쓰레드
애플리케이션 코드를 하나하나 순차적으로 실행하는 것이다.
쓰레드가 없다면 자바 애플리케이션의 실행이 불가능해진다.
쓰레드는 한 번에 하나의 코드 라인만을 수행하기 때문에 동시 요청이 들어와서 동시 처리가 필요할 때는 쓰레드를 추가로 생성한다.
2. 요청마다 쓰레드 생성
장점
- 위의 그림처럼 동시 요청을 처리할 수 있다.
- 리소스(CPU, 메모리)가 허용하는 범위까지 계속해서 처리할 수 있다.
- 위의 그림처럼 하나의 쓰레드가 지연되더라도, 나머지 쓰레드는 정상 작동한다.
단점
- 쓰레드의 생성 비용은 매우 비싸다. 그렇기 때문에 요청이 들어올 때마다 쓰레드를 생성하면, 응답 속도가 늦어진다.
- 쓰레드는 컨텍스트 스위치 비용이 발생한다.
- 쓰레드 생성에 제한이 없다. 요청이 너무 많이 들어오게 되면 서버가 다운될 수 있다.
3. 쓰레드 풀
요청마다 쓰레드를 생성하는 방법의 단점을 보완하기 위해서 쓰레드 풀을 사용한다.
필요한 쓰레드를 쓰레드 풀에 보관하고 관리한다.
쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다.
사용
쓰레드가 필요하면, 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내서 사용한다.
쓰레드의 사용이 끝나면 쓰레드 풀에 해당 쓰레드를 반납한다.
만약 쓰레드가 모두 사용중이어서 쓰레드 풀에 사용 가능한 쓰레드가 없다면?
-> 요청을 모두 거절하거나 특정 숫자만큼만 대기하도록 설정할 수 있다.
장점
쓰레드가 미리 생성되어 있어서 쓰레드를 생성하고 종료하는 비용(CPU)이 절약되고, 응답 시간이 빠르다.
생성 가능한 쓰레드의 수에 한계가 있기 때문에 너무 많은 요청이 들어오더라도 기존 요청은 안전하게 처리할 수 있다.
4. 최대 쓰레드 수
최대 쓰레드 수는 WAS의 주요 튜닝 포인트이다.
최대 쓰레드 수가 너무 낮으면 서버 리소스는 여유로운 반면 클라이언트 측에선 응답 지연이 된다.
최대 쓰레드 수가 너무 높으면 CPU, 메모리 리소스 임계점 초과로 서버가 다운된다.
장애가 발생했을 때 클라우드라면 서버를 증설한 후 튜닝을 진행하고, 클라우드가 아니라면 바로 튜닝을 진행한다.
적절한 쓰레드 수는 애플리케이션 로직의 복잡도, CPU, 메모리, IO 리소스 상황에 따라 모두 다르기 때문에 대략적으로 감에 의존한다.
그렇기 때문에 성능 테스트가 중요하다. 아파치 ab, 제이미터, nGrinder 등의 툴을 사용하여 최대한 실제 서비스와 유사하게 성능 테스트를 시도한다.
5. WAS의 멀티 쓰레드 지원
멀티 쓰레드에 대한 부분은 WAS가 처리해주기에 개발자는 멀티 쓰레드 관련 코드는 신경쓰지 않고 마치 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드를 개발하면 된다.
멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)를 사용할 때 공유 변수에 주의해야 한다.
HTML, HTTP API, CSR, SSR
1. 정적 리소스
고정된 HTML 파일, CSS, JS, 이미지, 영상 등을 제공하며, 주로 웹 브라우저에서 요청한다.
2. HTML 페이지
WAS가 JSP, 타임리프 등을 사용하여 동적으로 필요한 HTML 페이지를 생성해서 전달한다.
웹 브라우저는 HTML 페이지를 해석하여 클라이언트에게 보여준다.
3. HTTP API
HTML 페이지를 전달하는 것이 아니라 데이터를 전달한다. 주로 JSON 형태로 데이터를 통신한다.
데이터만 주고받는 형식이기 때문에 앱, 웹 클라이언트, 서버 등 다양한 시스템에서 호출할 수 있다.
4. SSR (Server-Side Rendering)
서버에서 최종 HTML 파일을 생성하여 클라이언트에 전달한다.
주로 정적인 화면에 사용하며, JSP나 타임리프 등을 사용한다. -> 백엔드 개발자
※ SSR을 사용하더라도 자바스크립트를 사용해서 화면 일부를 동적으로 변경 가능
5. CSR (Client-Side Rendering)
HTML 결과를 JS를 활용하여 웹 브라우저에서 동적으로 생성하여 적용한다.
주로 동적인 화면에 사용하며, 웹 환경도 마치 앱 화면처럼 필요한 부분을 변경할 수 있다.
React, Vue.js 등을 사용한다. -> 웹 프런트엔드 개발자
※ React, Vue.js에 대해 CSR + SSR를 동시에 지원하는 웹 프레임워크도 존재한다.
6. 백엔드 개발자 입장에서 UI 기술
서버 사이드 렌더링 기술 - JSP, 타임리프에 대한 학습은 필수이다.
백엔드 개발자는 서버, DB, 인프라 등등 수많은 백엔드 기술을 공부해야 하기에, 웹 프론트엔드 기술 학습은 옵션이다.
FE도 숙련된 개발자가 되기 위해선 많은 시간이 필요하므로, FE 개발자에게...
자바 백엔드 웹 기술 역사
1. 과거 기술
서블릿 - 1997 : HTML 생성이 어려움
JSP - 1999 : HTML 생성은 편리하지만, 비즈니스 로직까지 너무 많은 역할 담당
서블릿, JSP 조합 MVC 패턴 사용 : 모델, 뷰 컨트롤러로 역할을 나누어 개발
MVC 프레임워크 춘추 전국 시대 - 2000년 초 ~ 2010년 초 : MVC 패턴 자동화, 복잡한 웹 기술을 편리하게 사용할 수 있는 다양한 기능 지원 ex) 스트럿츠, 웹워크, 스프링 MVC(과거 버전)
2. 현재 사용 기술
애노테이션 기반의 Spring MVC 등장 : 춘추 전국 시대 마무리
스프링 부트의 등장 : 서버를 내장, 빌드 결과에 WAS 서버를 포함 -> 빌드 배포의 단순화
3. 최신 기술 - 스프링 웹 기술의 분화
Web Servlet - Spring MVC : 서블릿 기반으로 동작, 멀티 쓰레드
Web Reactive - Spring WebFlux
- 비동기 넌 블러킹 처리
- 최소 쓰레드로 최대 성능 - 쓰레드 컨텍스트 스위칭 비용 효율화
- 함수형 스타일로 개발 - 동시처리 코드 효율화
- 서블릿 기술 사용 X
하지만 기술적 난이도가 매우 높고, RDB에 대한 지원도 부족하며, 일반 MVC 쓰레드의 경우에도 충분히 빠르기에 실무에서 아직 많이 사용되지는 않는다.
4. HTML을 편리하게 생성하는 뷰 기능
JSP : 속도 느림, 기능 부족
프리마커(Freemarker), Velocity(벨로시티) : 속도 문제 해결, 다양한 기능
타임리프(Thymeleaf)
- 내추럴 템플릿: HTML의 모양을 유지하면서 뷰 템플릿 적용 가능
- 스프링 MVC와 강력한 기능 통합
- 최선의 선택이나 성능은 프리마커, 벨로시티가 더 빠름
'개발 > 스프링 MVC' 카테고리의 다른 글
(스프링 MVC 1편) 3. 서블릿, JSP, MVC 패턴 (0) | 2023.03.18 |
---|---|
(스프링 MVC 1편) 2. 서블릿 (0) | 2023.03.10 |