[스프링 MVC 1편] - 1

스프링 MVC - 웹 애플리케이션의 이해

서버간 데이터를 주고 받을 때 대부분 HTTP를 사용한다. 때문에 선행 구조로 HTTP지식을 갖춰야한다. 웹 애플리케이션은 우선 웹서버, WAS 부터 시작한다.

웹 서버

HTTP 기반으로 동작
정적 리소스 제공, 기타 부가기능
정적 파일을 서빙.
Nginx, Apache

웹 애플리케이션 서버

정적 리소스를 제공하는 웹 서버 기능 포함
프로그램 코드를 싱행해 애플리케이션 로직을 수행해 동적 HTML, HTTP API 구성.
서블릿, JSP, 스프링 MVC
톰캣, Jetty, Undertow

차이

웹 서버는 정적 리소스 제공, WAS는 애플리케이션 로직에 따라 동적인 정보 제공
사실 둘의 용어 경계는 모호함
- 웹 서버도 프로그램을 실행하는 기능을 포함하기도 함.
- 웹 애플리케이션 서버도 웹 서버 기능을 제공함
자바는 서블릿 컨테이너 기능 제공하면 WAS 서블릿 없이 자바코드를 실행하는 서버 프레임워크도 존재하긴 함.
WAS는 애플리케이션 코드를 실행하는데 특화

웹 시스템 구성

WAS, DB 만으로 시스템 구성 가능
WAS는 정적 리소스, 애플리케이션 로직 모두 제공 가능.

WAS는 너무 많은 책임을 가진다

WAS가 너무 많은 역할을 담당, 서버 과부화 우려
가장 비싼 애플리케이션 로직(결제로직 등)이 정적 리소스 때문에 수행이 어려울 수 있음.
WAS 장애시 오류 화면 노출 불가능
WAS는 생각보다 잘 죽는다.

웹 시스템 구성 - WEB/WAS/DB

정적 리소스는 웹 서버가 처리
웹 서버는 애플리케이션 로직같은 동적인 처리가 필요하면 WAS에 요청을 위임
WAS는 중요한 애플리케이션 로직 처리 전담.
정적인 리소스로 프론트엔드를, 동적인 리소스는 백엔드에게 요청하는 방식으로 변모하는듯?

효율적인 리소스 관리
- 정적 리소스가 많이 사용되면 Web 서버 증설
- 애플리케이션 리소스가 많이 사용되면 WAS 증설
정적 리소스만 제공하는 웹 서버는 잘 죽지 않음.
애플리케이션 로직이 동작하는 WAS 서버는 잘 죽음.
WAS, DB 장애시 WEB 서버가 오류 화면 제공 가능

요새는 정적 리소스를 캐싱하는 CDN이 대두되기도 함.

서블릿

아래와 같은 POST 전송이 있다고 보자.

이에 따라 서버에서 처리해야 하는 업무는 다음과 같다.

결국 비즈니스 로직 실행이 중요한데 이를 제외한 작업을 수행하기에는 서버의 작업이 과도하게 많다. 이 작업들을 자동으로 수행해주는것이 서블릿이다.

예시 코드는 아래와 같다.

java

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {

  @Override
  protected void service(HttpServletRequest request, HttpServletResponse response) {
    // 애플리케이션 로직
  }

}

urlPatterns(/hello)의 URL이 호출되면 서블릿 코드가 실행.
HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest
HTTP 요청 정보를 편리하게 제공할 수 있는 HttpServletResponse
개발자는 HTTP 스펙을 매우 편리하게 사용
HTTP 요청 시
- WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출
- 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용
- 개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력
- WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성

서블릿 컨테이너

톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함
서블릿 컨테이너는 서블릿 객체를 생성/초기화/호출/종료 생명주기 관리
서블릿 객체는 싱글톤으로 관리
- 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율
- 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용
- 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근
- 공유 변수 사용 주의
- 서블릿 컨테이너 종료시 함께 종료
- 단 request,response는 매번 새로 생성됨 들어있는 정보가 다르므로.
JSP도 서블릿으로 변환 되어서 사용
중요! 동시 요청을 위한 멀티 쓰레드 처리 지원

동시 요청 - 멀티 쓰레드

백엔드 개발자의 꽃은 멀티 쓰레드이다. 개념을 흝어보자.

웹브라우저(클라이언트)에서 서버에 요청을 하면 서버는 응답을 뱉는다.
- 요청하면 TCP/IP 커넥션이 이루어지고 서블릿을 호출한다.
  - 그런데 이 서블릿은 누가 호출할까? -> 쓰레드가 호출한다.

쓰레드

애플리케이션 코드를 하나하나 순차적으로 실행하는 것은 쓰레드
자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행
쓰레드가 없다면 자바 애플리케이션 실행이 불가능
쓰레드는 한번에 하나의 코드 라인만 수행
동시 처리가 필요하면 쓰레드를 추가로 생성

단일 요청

쓰레드를 하나만 사용한다.

요청이 오면 TCP/IP 연결 후 서블릿객체를 요청하기 위해 쓰레드가 할당된다. 응답을 마치면 해당 쓰레드는 휴식 상태가 된다.

다중 요청

요청 1번이 오면 쓰레드가 서블릿 객체를 요청한다. 그런데 이때 처리가 지연이 된다면?
- 이때 요청 2번이 왔다. 그런데 쓰레드가 휴식 상태가 아니다. 이렇게 된다면?
  - 결국 둘다 죽는다.
위와 같은 문제로 인해 요청마다 신규 쓰레드를 생성해야한다.

쓰레드가 매번 생성되면 어떠한 장단점이 존재할까.

장점

동시 요청을 처리
리소스가 허용될 때 까지 처리
하나의 쓰레드가 지연되어도, 나머지 쓰레드는 정상 동작

단점

쓰레드 생성 비용은 비싸다.
- 고객이 요청할때 쓰레드를 매번 생성하면 응답 속도가 늦어짐
쓰레드는 컨텍스트 스위칭 비용이 발생
쓰레드 생성에 제한이 없다.
- 고객 요청이 너무 많이 오면, CPU, 메모리 임계점을 넘어 서버가 죽을 수 있다.

쓰레드 풀

요청 1번, 2번이 온다면 쓰레드 풀에 적재한다. 쓰레드 풀은 일종의 쓰레드들의 놀이터로 필요한 경우에만 쓰레드를 가져다 쓰는것이다. 응답이 마치면 쓰레드 풀에 반납한다.

특징

필요한 쓰레드를 쓰레드 풀에 보관하고 관리
쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리. 톰캣은 최대 200개 기본 설정(변경 가능)

사용

쓰레드가 필요하면, 이미 생성되어 있는 쓰레드를 풀에서 꺼내 사용
사용이 종료되면 풀에 반납
최대 쓰레드가 모두 사용중인 경우
- 기다리는 요청은 거절하나 특정 숫자만큼만 대기하도록 설정할 수 있다.

장점

쓰레드가 미리 생성됨. 생성 및 종료 비용 절약되고 응답 시간이 빠르다.
생성 가능한 쓰래드의 최대치 존재 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리 가능.

WAS의 주요 튜닝 포인트는 최대 쓰레드(max thread) 수이다.

최대 쓰레드를 너무 낮게 설정한 경우

10명만 사용하고 90명은 대기되거나 거절된다. WAS는 살아 있어도 서비스에는 차질이 있다.
동시 요청이 많으면, 서버 리소스는 여유롭지만 클라이언트는 금방 응답 지연

최대 쓰레드를 너무 높게 설정한 경우

동시 요청이 많으면 CPU, 메모리 리소스 임계점 초과로 서버가 다운될 수 있다.

쓰레드 풀의 적정 숫자

애플리케이션 로직의 복잡도, CPU, 메모리, IO 리소스 상황에 따라 모두 다름.
성능 테스트
- 최대한 실제 서비스와 유사하게 성능 테스트 시도
- 툴: 아파치 ab, 제이미터, nGrinder
- 트래픽이 적다면 상관없지만 많다면 성능 테스트는 필수이다.

핵심

결국 멀티 쓰레드에 관한 부분은 WAS가 지원한다.
개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 된다.
개발자는 마치 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드를 개발
멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)은 주의해서 사용해야 한다.

정적 리소스

HTML 웹 페이지

고정된 HTML 파일, CSS, JS, 이미지, 영상 등을 제공
주로 웹 브라우저
동적으로 필요한 HTML 파일을 생성해서 전달할 수도 있다.

HTTP API

HTML이 아니라 데이터를 전달
주로 JSON 형식 사용
다양한 시스템에서 호출
- 앱 클라이언트(아이폰, 안드로이드, PC 앱)
- React, Vue.js 같은 웹 클라이언트
- 웹 브라우저에서 자바스크립트(ajax 등)을 통한 HTTP API 호출
데이터만 주고 받음, UI 화면이 필요하면 클라이언트가 별도 처리

이 과정에서 서비스 제공을 위해 정적 리소스 제공, 동적으로 제공되는 HTML 페이지 제공, HTTP API 제공 방법을 백엔드 개발자는 항상 고민해야한다.

렌더링 방식

SSR 서버 사이드 렌더링

HTML 최종 결과를 서버에서 만들어 웹 브라우저에 전달
주로 정적인 화면에 사용
관련 기술 : JSP, 타임리프 -> 백엔드 개발자

CSR 클라이언트 사이드 렌더링

HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용
주로 동적인 화면에 사용, 웹 환경을 마치 앱 처럼 필요한 부분부분 변경할 수 있음.
구글 어스, Gmail 등
관련 기술 : React, Vue.js -> 웹 프론트엔드 개발자

참고

React, Vue.js를 CSR + SSR 동시에 지원하는 웹 프레임워크도 있음.
SSR을 사용하더라도, 자바스크립트를 사용해서 화면 일부를 동적으로 변경 가능.

서버사이드 렌더링(SSR)

서버에서 최종 HTML을 생성해서 클라이언트에 전달

클라이언트 사이드 렌더링(CSR)

그래서 어디까지 배워야하나

백엔드 개발자 입장에서 UI 기술

백엔드 - 서버 사이드 렌더링 기술

JSP, 타임리프
화면이 정적이고 복잡하지 않을 때 사용
백엔드 갭라자는 서버 사이드 렌더링 기술 학습 필수

웹 프론트엔드 - 클라이언트 사이드 렌더링 기술

React, Vue.js
복잡하고 동적인 UI 사용
웹 프론트엔드 개발자의 전문 분야

선택과 집중

백엔드 개발자의 웹 프론트엔드 기술 학습은 옵션.
백엔드 개발자는 서버, DB, 인프라 등 수 많은 백엔드 기술을 고웁해야 한다.
웹 프론트엔드도 깊이있게 잘 하려면 숙련에 오랜 시간 필요.

자바 웹 기술의 역사

과거 ...

1997 : 서블릿
- HTML 생성이 어려움...
1999 : JSP
- HTML 생성은 편리하지만, 비즈니스 로직까지 너무 많은 역할 담당...
서블릿, JSP 조합 MVC 패턴 사용
- 모델, 뷰 컨트롤러로 역할을 나누어 개발
2000년 초 ~ 2010년 초 : MVC 프레임워크 춘추 전국 시대
- MVC 패턴 자동화, 복잡한 웹 기술을 편리하게 사용할 수 있는 다양한 기능 지원
- 스트럿츠, 웹 워크, 스프링 MVC(과거 버전)

현재

애노테이션 기반의 스프링 MVC 등장
- @Controller
- MVC 프레임워크의 춘추 전국 시대 마무리
스프링 부트의 등장
- 스프링 부트는 서버를 내장
- 과거에는 서버에 WAS를 직접 설치하고, 소스는 War파일을 만들어서 설치한 WAS에 배포
- 스프링 부트는 빌드 결과(Jar)에 WAS 서버 포함 -> 빌드 배포 단순화

최신 기술

Web Servelet - Spring MVC
Web Reactive - Spring WebFlux

스프링 웹 플럭스

특징

비동기 넌 블러킹 처리
최소 쓰레드로 최대 성능 - 쓰레드 컨텍스트 스위칭 비용 효율화
함수형 스타일로 개발 - 동시 처리 코드 효율화
서블릿 기술 사용 X 하지만
웹 플럭스는 기술적 난이도 매우 높음
아직은 RDB 지원 부족
일반 MVC의 쓰레드 모델도 충분히 빠름
실무에서 아직 많이 사용하지는 않음(전체 1% 이하)

뷰 템플릿 역사

HTML을 편리하게 생성하는 뷰 기능

JSP

속도 느림, 기능 부족
요샌 스프링 부트에서 권장하지 않음. 프리마커(Freemarker), Velocity(벨로시티)
속도 문제 해결, 다양한 기능 타임 리프(Thymeleaf)
내추럴 템플릿: HTML의 모양을 유지하면서 뷰 템플릿 적용 가능
스프링 MVC와 강력한 기능 통합
최선의 선택임.