[스프링 MVC 1편] # 1. 웹 애플리케이션 이해

[seyxxn]

1_웹 애플리케이션 이해

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

• 웹은 HTTP 기반으로 통신
• 모든 것이 HTTP, HTTP 메시지에 모든 것을 전송

웹 서버 (Web Server)

• HTTP 기반으로 동작
• 정적 리소스 제공, 기타 부가기능
• 정적 리소스이기 때문에 특정 사용자마다 다르게 보여주는 것이 불가능함

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

• HTTP 기반으로 동작
• 웹 서버 기능 포함 + (정적 리소스 제공 가능)
• 프로그램 코드를 실행해서 애플리케이션 로직을 수행
  • 동적 HTML, HTTP API(JSON)
  • 서블릿, JSP, 스프링 MVC
• 프로그래밍을 할 수 있기 때문에 사용자에 따라 다르게 보여주는 것이 가능함

웹 서버와 웹 애플리케이션 서버의 차이점

• 웹 서버는 정적리소스(파일)
• WAS는 애플리케이션 로직
• 사실 둘의 용어도 경계도 모호함
  • 웹 서버도 프로그램을 실행하는 기능을 포함하기도 함
  • 웹 애플리케이션 서버도 웹 서버의 기능을 제공
• 자바는 서블릿 컨테이너 기능을 제공하면 WAS
• WAS는 애플리케이션 코드를 실행하는데 더 특화되어 있음

웹 시스템 구성 - WAS, DB

• WAS와 DB만으로도 시스템 구성이 가능함
• WAS는 정적 리소스, 애플리케이션 로직 모두 제공 가능함
• 하지만, 이렇게 구성하게 되면 WAS가 너무 많은 역할을 담당하게 됨 -> 서버 과부하 우려
  • 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있음
  • WAS 장애 시 오류 화면도 노출이 불가능함

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

• 정적 리소스는 웹 서버가 처리
• 웹 서버는 애플리케이션 로직 같은 동적인 처리가 필요하면 WAS에 요청을 위임
• WAS는 중요한 애플리케이션 로직 처리를 전담함
• 효율적인 리소스 관리
  • 정적 리소스가 많이 사용되면 Web 서버를 증설
  • 애플리케이션 리소스가 많이 사용되면 WAS를 증설
• 정적 리소스만 제공하는 웹 서버는 잘 죽지 않음
• 애플리케이션 로직이 동작하는 WAS 서버는 잘 죽으
• WAS, DB 장애 시 WEB 서버가 오류 화면을 제공할 수 있음

서블릿

• WAS는 HTTP를 기반으로 동작함
• 구체적으로 WAS가 어떤 식으로 돌아갈까 ?
• 클라이언트가 Post를 전송하여 데이터를 저장하는 상황을 가정해보고, WAS 내부 동작을 살펴봄

• HTTP 요청 하나를 위해서 WAS가 동작해야할 것들이 매우 많음
• 의미있는 비즈니즈 로직이 중요한데, 나머지 구현이 매우 많음
• 따라서, 개발자가 중요한 비즈니스 로직만을 구현할 수 있도록 도와주는 것이 서블릿

@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 스펙을 매우 편리하게 사용

서블릿 동작 구조

1. 웹 브라우저에서 localhost:8080/hello 요청
2. WAS 서버에서 요청 메세지를 기반으로 request, response 객체를 새로 생성
3. 이때 request, response 객체를 파라미터로 넣으면서 서블릿 컨테이너의 helloServlet을 실행 (service 메서드 호출)
4. 그 후 결과물을 Response 객체에 담음
5. WAS는 Response 객체에 담긴 내용으로 클라이언트를 통해서 Http Response를 전송함
6. 응답이 끝나면 Request와 Response 객체를 소멸

서블릿 정리 - HTTP 요청, 응답 흐름

• HTTP 요청 시
  • WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출
  • 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 써내서 사용
  • 개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력
  • WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성

서블릿 컨테이너

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

동시 요청 - 멀티 쓰레드

쓰레드란?

• 실행 중인 프로그램 내에서 실제로 작업을 수행하는 주체 (어플리케이션 로직을 하나하나 순차적으로 진행하는 것)

• 단일 쓰레드로 시스템을 구성하면 발생하는 문제
  

• 요청1이 먼저 들어와서 쓰레드가 servlet 객체를 호출받아 처리 중에 처리 지연이 생겼다고 가정

• 지연되는 동안 요청2가 들어옴

• 요청2는 아무것도 하지 못하고 대기를 하게되는 상황 발생

• 그렇다면 요청마다 쓰레드를 생성하여 다른 요청이 들어와도 그때마다 쓰레드를 부여하면 어떨까?

  • 장점
  1. 동시 요청을 처리할 수 있음
  2. 리소스(CPU, 메모리)가 허용할 때까지 처리 가능
  3. 하나의 쓰레드가 지연 되어도, 나머지 쓰레드는 정상 동작함
  • 단점
  1. 쓰레드는 생성 비용이 매우 비쌈
     • 고객의 요청이 올 때 마다 쓰레드를 생성하면, 응답 속도가 늦어짐
  2. 쓰레드는 컨텍스트 스위칭 비용이 발생
  3. 쓰레드 생성에 제한이 없음
     • 고객 요청이 너무 많이 오면, CPU, 메모리 임계점을 넘어서 서버가 죽을 수도 있음

쓰레드 풀

• 따라서 우리는 쓰레드를 미리 모아둔 쓰레드 풀을 이용
  • 이전에는 쓰레드를 요청할 때마다 생성하고, 사용한 후 쓰레드를 죽이는 방식을 사용했기 때문에 위와 같은 문제점이 발생해었음
  • 쓰레드 풀이라는 곳에 쓰레드를 모아놓고 쓰레드 풀에서 쓰레드를 받아 사용하고 반환하는 방식으로 사용

• 쓰레드 풀을 사용하여 요청마다 쓰레드가 생성하는 단점을 보완할 수 있음
• 특징
  • 필요한 쓰레드를 쓰레드 풀에 보관하고 관리
  • 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리 (톰캣은 최대 200개 기본 설정)
• 사용
  • 쓰레드가 필요하면, 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내서 사용
  • 사용을 종료하면 쓰레드 풀에 해당 쓰레드를 반납
  • 최대 쓰레드가 모두 사용중이어서 쓰레드 풀에 쓰레드가 없으면?
    • 기다리는 요청은 거절하거나 특정 숫자만큼 대기하도록 설정할 수 있음
• 장점
  • 쓰레드가 미리 생성되어 있으므로, 쓰레드를 생성하고 종료하는 비용(CPU)이 절약되고, 응답 시간이 빠르다.
  • 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있음

HTML, HTTP API, CSR, SSR

정적 리소스

• 고정된 HTML 파일, CSS, JS, 이미지, 영상 등을 제공
• 요청이 오면 웹 서버에서 폴더에 있는 이미 생성된 리소스 파일을 제공

HTML 페이지

• 동적으로 필요한 HTML 파일을 생성해서 전달
• 요청이 오면 애플리케이션 로직을 수행할 수 있는 WAS가 DB를 통해서 정보를 조회한 후, 뷰 템플릿(JSP, 타임리프 등)을 가지고 동적으로 HTML을 생성 후 웹 브라우저에 내려줌

HTML API

• HTML이 아니라 데이터를 전달
• 주로 JSON 형식을 사용
• 요청이 오면 WAS가 DB에서 정보를 조회해서 웹 브라우저에 데이터를 바로 내려줌, UI 화면이 필요하면 클라이언트가 별도 처리
• 주로 앱, 웹 클라이언트, 서버 to 서버에서 사용

SSR, CSR

• SSR : 서버 사이드 렌더링
• CSR : 클라이언트 사이드 렌더링
• 주로 프론트 개발을 할 때 들을 수 있는 용어들

SSR - 서버 사이드 렌더링

• 서버에서 최종 HTML을 생성해서 클라이언트에 전달
• 서버에서 만들어서 렌더링하는 것
  • 프론트에서는 요청만 하면 HTML에 모든 결과를 담아 페이지를 브라우저에 뿌리기만 하면 끝
  • 정적인 화면에는 대부분 SSR을 사용
  • JSP, Thymleaf가 이에 해당

CRS - 클라이언트 사이드 렌더링

• HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 사용
• 자바스크립트에서 HTML을 동적으로 생성 (클라이언트 쪽에서 HTML 생성)
• 주로 동적인 화면에서 사용
• React, Vue.js를 CSR + SSR 동시에 지원하는 웹 프레임워크도 있음
• SSR을 사용하더라도, 자바스크립트를 사용해서 화면 일부를 동적으로 변경 가능

---

🔗 출처

• 김영한 - 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술