[Spring MVC] 웹 어플리케이션의 이해

이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.

---

웹 서버, 웹 애플리케이션 서버

웹은 HTTP 프로토콜 기반으로 통신하여 데이터를 주고받는다.

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML (API) 등

 

웹 서버 (Web Server)

• HTTP 기반으로 동작
• 정적 리소스 제공, 기타 부가기능
• 정적 (파일) HTML, CSS, JS, 이미지, 영상 
• NGINX, APACHE 등이 웹 서버로 사용

 

웹 애플리케이션 서버 WAS (Wep Application Server)

• HTTP 기반으로 동작
• 웹 서버 기능 + 프로그램 코드 실행하여 애플리케이션 로직 수행
• 동적 HTML, HTTP API(JSON), 서블릿, JSP, 스프링 MVC
• 톰캣, Jetty, Underflow 등이 WAS로 사용

 

웹 서버와 웹 어플리케이션 서버 (WAS) 차이

• 웹 서버는 정적 리소스, WAS는 애플리케이션 로직까지 수행
• 웹 서버도 프로그램 실행할 수도 있고, WAS도 웹 서버의 기능을 제공함  → 용어와 경계가 모호
• WAS는 애플리케이션 코드를 실행하는데 더 특화

 

웹 시스템 구성 (WAS + DB)

WAS와 DB만으로도 시스템을 구성가능

WAS가 정적리소스와 애플리케이션 로직 모두 제공

 

하지만 이렇게 구성할 경우 WAS가 많은 역할을 담당하여 서버가 과부하 될 수 있다.
비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수도 있고, WAS에 장애가 있을시에 오류 화면을 노출을 못할 수도 있다.

 

웹 시스템 구성 (Web Server + WAS + DB)

정적 리소스는 웹 서버가 처리, 동적 리소스는 WAS가 처리 

• 웹 서버는 애플리케이션 로직같은 동적인 처리가 필요하면 WAS에 요청한다.
• WAS가 중요한 애플리케이션 로직 처리 전담
• 리소스 관리를 효율적으로 할 수 있다.

 

• 정적 리소스 사용이 많다면 → WEB 서버 증설
• 애플리케이션 리소스 사용이 많다면 → WAS 증설
• 이런식으로 유연하게 관리 가능

 

WAS, DB 장애시 WEB 서버가 오류 화면 제공 가능

 

서블릿

동적인 웹 페이지를 만들 때 사용되는 자바 기반 웹 애플리케이션 프로그래밍 기술
클라이언트의 요청을 처리 후 결과를 반환해준다.

서블릿이 없다면 위 그림에서 가장 중요한 초록색으로 영역이 칠해진 비즈니스 로직 말고도 개발자가 처리해야할 일들이 너무 많다.

하지만 서블릿이 비즈니스 로직에만 집중할 수 있게 해준다.

즉, 비즈니스 로직 작성 외에 나머지를 서블릿이 모두해준다.

 

서블릿 특징

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

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

 

• urlPatterns(/hello)의 URL이 호출되면 서블릿 코드 실행
• HttpsServletRequest - HTTP 요청 정보를 편리하게 사용
• HttpsServletResponse - HTTP 응답 정보를 편리하게 제공
• → 서블릿을 통해 개발자는 HTTP 스펙을 편리하게 사용

 

1. 웹 브라우저에서 localhost:8080/hello 라고 요청을 함
2. WAS에서 HTTP 요청 메시지를 기반으로 Request와 Response 객체 생성
3. Request, Response를 파라미터로 넘기면서 Servlet 객체 호출
4. 개발자는 Request 객체에서 HTTP 요청 정보를 꺼내서 사용하고, Response 객체에 HTTP 응답 정보를 입력할 수 있음.
5. Servlet이 응답 정보 입력을 완료하면 WAS는 Response 객체 정보로 HTTP 응답 생성
6. 웹 브라우저에 클라이언트에게 전달

 

서블릿 컨테이너

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

 

멀티 쓰레드

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

 

쓰레드

서블릿 호출은 쓰레드가 한다.

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

 

2023.08.01 - [Java Category/Java] - [Java] 멀티 스레드

[Java] 멀티 스레드

 

요청마다 쓰레드를 생성

장점

• 동시 요청을 처리할 수 있다.
• 리소스(CPU, 메모리)가 허용할 때 까지 처리가능
• 하나의 쓰레드가 지연 되어도, 나머지 쓰레드는 정상 동작

 

단점

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

 

쓰레드풀

2023.08.02 - [Java Category/Java] - [Java] 데몬 스레드와 스레드풀

[Java] 데몬 스레드와 스레드풀

 

특징

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

 

사용

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

 

장점

• 쓰레드가 미리 생성되어 있음 → 쓰레드를 생성하고 종료하는 비용(CPU)이 절약 & 응답 시간이 빠르다.
• 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있다.

 

HTML, HTTP API, CSR, SSR

정적 리소스

• 고정된 HTML 파일, CSS, JS, 이미지 영상 등
• 주로 웹 브라우저에서 요청하면 웹 서버에서 리소스 파일 전달

 

HTML 페이지

• 웹 브라우저에서 요청이 오면 WAS는 DB에서 조회 후, 동적으로 HTML 생성하여(뷰 템플릿) 웹 브라우저에게 전달
• 웹 브라우저는 HTML을 받아서 해석

 

HTTP API

• HTML이 아닌 데이터만 전달
• 주로 JSON 형태로 데이터 통신
• 웹브라우저에서 요청이 오면 WAS는 DB에서 조회하여 주로 JSON 형식 사용하여 웹 브라우저에게 전달

 

• 다양한 시스템에서 호출(앱, 웹 클라이언트, 서)
• 데이터만 주고 받음, UI 화면이 필요하면, 클라이언트가 별도 처리

 

CSR (Client Side Rendering)

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

 

SSR (Server Side Rendering)

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

 

자바 백엔드 웹 기술 역사

역사

1. 서블릿 : HTML 생성이 어렵다.
2. JSP : HTML 생성 편리, 비즈니스 로직까지해서 많은 역할 담당, 유지보수 어려움
3. 서블릿, JSP 조합의 MVC 패턴 사용 : 모델, 뷰 컨트롤러로 역할을 나눠서 개발
4. 애노테이션 기반의 스프링 MVC - 현재는 이 기술을 적어도 자바 진영에서는 모두 사용

스프링 부트

-스프링 부트는 서버를 내장
-과거에는 서버에 WAS를 직접 설치하고, 소스는 War 파일을 만들어서 설치한 WAS에 배포
-스프링 부트는 빌드 결과(Jar)에 WAS 서버 포함 -> 빌드 배포 단순화

 

스프링 웹 기술의 분화

• Web Servlet - Spring MVC : 서블릿을 사용함, 현재 실무에서 가장 많이 사용
• Web Reactive - Spring WebFlux : 서블릿을 사용 안함, 함수형 스타일, 여러 문제점으로 실무에서 사용안함.

 

자바 뷰 템플릿 역사

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

• JSP : 속도 느림, 기능 부족
• 프리마커(Freemarker), Velocity(벨로시티) : 속도 문제 해결, 다양한 기능
• 타임리프(Thymeleaf)
  -내추럴 템플릿: HTML의 모양을 유지하면서 뷰 템플릿 적용 가능
  -스프링 MVC와 강력한 기능 통합
  -최선의 선택, 단 성능은 프리마커, 벨로시티가 더 빠름