[스프링 MVC] 웹애플리케이션 이해

인프런 spring MVC 1 강의 듣고 내용 정리중.

웹 기반에서는 모든 데이터를 HTTP를 사용하여 주고받는다.

서버간에 데이터를 주고 받을 때도 사용한다.

 

웹 서버

HTTP를 기반으로 동작.

정적 리소스를 제공하고, 기타 부가기능을 제공한다. ex) 정적파일 HTML, css, js, 이미지, 영상

대표적인 웹 서버 : 엔진엑스NGINX, 아파치 APACHE

 

웹 어플리케이션 서버 (Web Application Server, WAS)

프로그램 코드를 실행해서 애플리케이션 로직 수행

 - 동적 HTML, HTTP API(JSON), 서블릿, JSP, 스프링 MVC

대표적인 WAS : 톰캣

 

두 가지의 차이?

웹서버는 정적 리소스, 웹 어플리케이션 서버는 애플리케이션 로직(동적) 을 실행하는 서버다.

사실은 둘의 용어와 경계가 모호하다. 

 

웹 시스템 구성 - WAS, DB

WAS, DB 만으로 시스템 구성 가능

WAS 는 정적리소스, 애플리케이션 로직 모두 제공이 가능하다.

 

→ 그러나 WAS가 너무 많은 역할을 담당한다.

▶  서버 과부하 우려.

▶  가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려움.

▶  WAS 장애 시 오류 화면도 노출 불가능.

따라서 웹 시스템 구성은

→ 정적 리소스는 웹 서버가 처리

→ 웹 서버는 애플리케이션 로직같은 동적 처리 필요 시 WAS에 요청 위임

→ WAS 는 중요 애플리케이션 로직 처리 전담.

 

장점:    효율적인 리소스 관리

•  정적 리소스가 많이 사용되면 Web 서버 증설 (웹 서버는 잘 안죽음)
•  애플리케이션 리소스가 많이 사용되면 WAS 증설

---

HTML Form 데이터 전송

post 전송 - 저장

클라이언트가 form 태그를 post 방식으로 생성 후 작성해서 전송 버튼을 누르면?

웹브라우저가 HTTP 메시지를 만든다.

(내용으로는 post 방식, 작성 내용.. 담김)

 

그러나 항상 번거로운 작업들을 반복해서 하는 것은 비효율적.

그래서 등장한 것이 서블릿이다

서블릿
: 서블릿은 유의미한 비즈니스 로직을 제외한 모든 업무를 처리한다

ex. http 응답 메세지 생성, 소켓연결 등등. 아래 이미지에서 초록색 박스를 제외한 모든 부분!

서비스 로직 호출할 때 들어오는 파라미터 → HttpServletRequest 와 HttpServletResponse

HTTP 메세지를 직접 파싱하는 것은 번거로운 일이므로,

요청정보와 응답정보를 편리하게 사용할 수 있도록 서블릿이 만들어준 객체이다.

개발자는 이 객체들을 그냥 가져와서 사용하면 된다!

 

HTTP 요청, 응답 흐름 이해하기

HTTP 요청이오면 WAS가 Request, Response 객체를 새로 만들어서 서블릿 객체를 호출한다.

→ 개발자는 Request 객체에서 요청정보를 꺼내서 사용하고, Response 객체에 응답정보를 입력한다.

→ WAS 는 Response 객체에 담겨있는 내용으로 HTTP 응답정보를 생성한다.

 

서블릿 컨테이너란? 

서블릿을 지원하는 WAS 안에는 서블릿 컨테이너가 존재한다.

서블릿 객체는 컨테이너가 자동으로 생성,초기화, 호출, 종료 등 생명주기도 관리해준다.

서블릿 객체는 싱글톤으로 관리되며( 객체는 하나만 생성, 공유 해서 사용)

그렇기에 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근한다.

따라서 공유변수 사용을 주의하기!

서블릿 객체는 서블릿 컨테이너 종료시에 함께 종료된다.

 

JSP도 서블릿으로 변환되어 사용되고,

동시요청을 위한 멀티쓰레드 처리를 지원한다!

 

---

동시요청 - 멀티쓰레드

서블릿은 그럼 누가 호출할까? 쓰레드가 호출한다

애플리케이션 코드를 순차적으로 실행하는 역할을 쓰레드가 한다.

(ex. 자바의 메인 메서드 실행하면 main이라는 이름의 쓰레드 실행) 

쓰레드는 한번에 하나의 코드라인만 처리한다.

따라서 동시처리가 필요하다면 추가적으로 쓰레드를 생성해줘야한다.

 

그러나 요청이 올 때 마다 쓰레드를 생성한다면?

• 생성비용이 매우 비싸다.
• 응답속도가 늦어진다.
• 컨텍스트 스위칭 비용이 발생한다(다른 쓰레드로 전환)
• 쓰레드는 생성제한이 없음 → 고객요청이 너무 많이 오면, CPU, 메모리 임계점을 넘어서 서버가 죽을 수 있다. 

따라서 대부분의 경우 쓰레드 풀을 만들어서 필요한 경우 가져와서 쓴다.

쓰레드풀
: 필요한 쓰레드를 쓰레드 풀에 보관하고 관리하는 것.

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

 

WAS의 멀티쓰레드 지원

멀티쓰레드에 대한 부분은 WAS 가 처리해주므로, 개발자는 관련 코드를 신경쓰지 않아도 된다!!

---

HTTP API

- 다양한 시스템에서 호출

- 데이터만 주고받음, UI하면이 필요하면 클라이언트가 별도로 처리

- 주로 Json 형식을 사용.

 

---

스프링 부트의 등장

- 스프링부트는 서버를 내장.

- 빌드 결과(jar)에 was 서버 포함 → 서버에 톰캣을 설치할 필요 없음 → jar 파일을 실행하면 서버가 뜨면서 개발자가 만든 코드가 실행됨.

 

 

---

REFERENCE

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

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의