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

 

웹에서는 모든 것이 HTTP 기반으로 데이터를 주고받는다.

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML (API)
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

 

웹 서버(Web Server)

• HTTP 기반으로 동작하는 서버
• 정적 html파일을 HTTP 요청하면, HTTP 응답으로 반환해준다.
• 정적(파일) HTML, CSS, JS, 이미지, 영상등
• ex) NGINX, APACHE

 

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

• HTTP 기반으로 동작
• 웹 서버 기능 포함 (정적 리소스 제공 가능)
• HTTP 요청이 오면 프로그램 코드를 실행해서 애플리케이션 로직 수행
  • 사용자마다 다른 화면 제공 가능
• 동적 HTML, HTTP API(JSON) 제공
• 서블릿, JSP, 스프링 MVC이 WAS에서 동작
• ex) 톰캣(Tomcat), Jetty, Undertow

 

웹 서버, 웹 애플리케이션 서버(WAS) 차이

• 웹 서버는 정적 리소스(파일)제공, WAS는 애플리케이션 로직까지 실행 가능
• 자바는 서블릿 컨테이너 기능을 제공하면 WAS라고 함
  • 서블릿 없이 자바코드를 실행하는 서버 프레임워크도 있기도 함 -> 애매
• 웹 서버도 프로그램을 실행하는 기능을 포함하기도 하고, WAS도 웹서버의 기능을 제공해 둘의 경계가 모호하다.
• WAS는 애플리케이션 코드를 실행하는데 더 특화되어 있다고 보면 된다.

 

 

웹 시스템 구성 - WAS, DB

• WAS, DB 만으로 시스템 구성 가능하다. 정적 리소스를 제공할 수도 있고, 애플리케이션 로직으로 데이터베이스를 조회해 필요한 html을 동적으로 만들어 낼 수 있다.
• 하지만 WAS 혼자 담당하면 너무 많은 역할을 맡아 서버 과부하 우려가 있다.
• 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있음
• WAS 장애시 웹브라우저에서 WAS에 접근 자체가 안되기 때문에 오류 화면도 노출 불가능

 

 

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

• 웹 서버를 앞에 두어 정적 리소스(HTML, CSS, JS, 이미지..) 를 처리한다.
• 웹 서버는 애플리케이션 로직같은 동적인 처리가 필요하면 WAS에 요청을 위임
• 장점
  • WAS는 중요한 애플리케이션 로직 처리 전담-> 업무 분담 가능
  • 효율적인 리소스 관리
    • 정적 리소스가 많이 사용되면 Web 서버 증설
    • 애플리케이션 리소스가 많이 사용되면 WAS 증설
  • 정적 리소스만 제공하는 웹 서버는 잘 죽지 않는다. 그런데 애플리케이션 로직이 동작하는 WAS 서버는 잘 죽음(개발자의 로직 오류, DB문제 등 )
  • 이런 WAS, DB 장애시 WEB 서버가 오류 화면 제공 가능

 

 

 

 

서블릿

 

서블릿을 지원하는 WAS를 사용하면 비지니스 로직 실행을 제외하고 모든 일을 지원한다.

 

 

 

urlPatterns(/hello)의 URL이 호출되면 서블릿 코드가 실행된다.

 

HttpServletRequest, HttpServletResponse로 HTTP 요청 정보, 응답 정보를 편리하게 사용할 수 있다.

 

 -HttpServletRequest: request.getParameter("username") 등으로 정보 추출 가능 

 -HttpServletResponse: HTTP 응답 정보를 직접 만드는 것이 아니라, response 객체에 원하는 데이터를 담기만 하면 된다.

 

HTTP 요청, 응답 흐름

 

- http 요청 시 WAS 에서 요청 메세지를 기반으로 request, response 객체를 새로 만듬

- request, response를 파라미터로 넘겨 서블릿 컨테이너의 서블릿 객체를 호출해 실행

- 개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력 가능

- 실행이 끝나고 종료되면 reponse 객체 정보를 바탕으로 HTTP 응답 정보 생성

- 웹 브라우저에게 응답 정보를 넘겨 HTML 렌더링

 

 

서블릿 컨테이너

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

 

쓰레드

• 애플리케이션 코드를 하나하나 순차적으로 실행하는 것을 쓰레드라고 함
  • 프로세스: 실행중인 프로그램
  • 스레드: 프로세스를 구성하는 실행 단위
• 자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행
• 쓰레드가 없다면 자바 애플리케이션 실행이 불가능
• 쓰레드는 한번에 하나의 코드 라인만 수행
• 동시 처리가 필요하면 쓰레드를 추가로 생성해줘야 함

 

 

요청마다 쓰레드를 생성할 때의 장단점

장점

• 동시 요청을 처리할 수 있다.
• 하나의 쓰레드가 지연 되어도, 나머지 쓰레드는 정상 동작한다.

단점

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

 

 

 

쓰레드 풀

이 단점을 보완하기 위해 쓰레드 풀을 사용한다.

풀 안에 쓰레드를 미리 만들어 놓고, 요청이 올 때 쓰레드들를 쓰는 것

사용 종료하면 쓰레드 풀에 다시 반납

 

특징

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

 

 

WAS의 멀티 쓰레드 지원

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

 

 

 

HTML, HTTP API, CSR, SSR

1. 정적 리소스
   • 고정된 HTML 파일, CSS, JS, 이미지, 영상 을 웹 브라우저로 제공
2. HTML 페이지
   • 동적으로 필요한 HTML 파일을 생성해서 웹 브라우저에 전달
3. HTTP API
   • HTML이 아니라 데이터를 전달 (JSON 형식)
   • UI 클라이언트 접점(앱 클라이언트, 웹 클라이언트)
   • 서버 to 서버 통신
4. SSR-서버 사이드 렌더링
   • 서버에서 최종 HTML을 생성해서 클라이언트에 전달
   • 관련기술: JSP, 타임리프 -> 백엔드 개발자
5. CSR - 클라이언트 사이드 렌더링
   • HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용
   • 관련기술: React, Vue.js -> 웹 프론트엔드 개발자

 

 

 

 

참고

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1