웹 애플리케이션의 이해

목차

 

웹 서버 Web Server : 정적 리소스 제공

클라이언트에게 정적 리소스(html, css, js, 이미지 등등) 들을 제공해준다.

EX) NGINX, APACHE

 

웹 애플리케이션 서버 Web Application Server : 정적 + 동적 리소스 제공

클라이언트에게 동적 리소스(비즈니스로직, JSP, 스프링 MVC 등등)을 제공해준다.

웹 서버의 기능을 포함한다(정적 리소스 제공)

EX) TOMCAT ...

 

=> WAS가 애플리케이션 코드를 실행하는데 더 특화되어있다.

 

웹 시스템 구성 WEB, WAS, DB

WAS로만 서버를 구성하는 경우

⭐ "죄송합니다 현재 접근불가합니다" 라는 정적페이지를 보여주려해도 WAS에 장애가 일어나면 정적페이지 조차 노출 불가능해진다.

⭐ 정적리소스에 대한 기능만 추가로 필요해도 WAS 자체를 증설해야한다 (불필요하게 동적리소스에 대한 기능도 추가가된다)

 

💡 정적리소스는 웹서버로, 동적리소스는 WAS로 서버를 구성하는 경우

현재 가장 많이 사용되는 방법이다.

 

⭐ 웹서버는 정적리소스에만 집중, WAS는 동적리소스에만 집중할 수 있게된다.

⭐ WAS에 오류가 발생해도 웹서버에서 "죄송합니다 현재 접근불가합니다"라는 정적페이지를 보여줄 수 있게된다.

⭐ 정적리소스가 많아지면 웹서버만 증설하면되는 것처럼 필요에 따라서 효율적으로 리소스를 관리할 수 있다.

 

 

 

---

 

 

서블릿? HTTP의 요청 확인, 응답 전달 등을 자동으로 처리해주는 것

클라이언트가 DB에 username = kim을 저장하려한다.

서버에서 처리해야하는 업무를 나열해보면 아래와 같다

 

 - 서버TCP/IP연결 대기, 소켓 연결

 - HTTP 요청메시지 파싱

 - POST방식, URL확인.....

 - ..... 등등..

 - 비즈니스로직 실행

 - 데이터베이스에 저장 요청

 - HTTP 응답메시지 생성 시작

 - Header 생성.....등등...

 

파란색 부분을 제외한 부분은 HTTP 요청 분석, 응답 생성 및 전달을 위한 과정인데

매번 이것을 사용자가 처리해주는건 비효율적이다.

따라서 의미있는 파란색 부분을 제외한 나머지를 자동으로 지원해주는 서블릿이 탄생하게되었다!

요즘 서블릿은 대부분 WAS에서 지원해준다.

 

스프링의 서블릿처리부분을 확인해보자

 

@WebServlet(name="helloServlet", urlPatterns="/hello")
public class HelloServlet extends HttpServlet{
	
    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response){
    	//HttpServletRequest가 HTTP요청정보를 의미한다.
        //HttpServletResponse가 HTTP응답정보를 의미한다.
        
    	//애플리케이션 로직 작성
    }
}

 

urlPatterns("/hello") : 주소창에 ~도메인~/hello가 입력되면 아래의 HelloServlet 메서드가 실행된다는 것을 의미한다. 

 

 

컨테이너?

컨테이너는 객체 관리를 주로 수행하는 그릇이다.

객체 인스턴스의 생명주기를 관리, 추가적인 기능을 제공하는 것이다.

내 설정코드를 바탕으로 처리과정을 위임받은 것이다.

 

서블릿 컨테이너

WAS안에 포함되어있다.

서블릿 컨테이너는 서블릿 객체를 자동으로 생성해준다. (개발자가 생성하지 않아도 되게끔)

WAS환경에 맞게 서블릿 객체의 생성, 호출, 관리 등의 생명주기를 자동으로 관리해준다.

서블릿 객체를 싱글톤으로 관리해준다.

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

 

 

HTTP 요청, 응답 흐름

1. 클라이언트가 서버(WAS)에게 HTTP요청을 보내면

2. WAS는 HttpServletRequest/Response 객체를 새로 만들어서 서블릿 객체를 호출한다.

3. 개발자는 HttpServletRequest 객체를 통해 비즈니스로직을 처리하고 HttpServletResponse 객체를 통해 응답정보를 입력한다.

4. WAS는 HttpServletResponse 객체를 바탕으로 HTTP 응답정보를 생성한다.

 

 

 

---

 

 

WAS의 멀티쓰레드 지원

Thread 쓰레드 : 애플리케이션 코드를 순차적으로 실행하는 것

자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행된다.

쓰레드가 없다면 자바 애플리케이션 실행이 불가능하다.

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

동시처리가 필요하면 쓰레드를 추가로 생성할 수 있다.

 

 

클라이언트1과 클라이언트2의 요청을 동시에 수행하고 싶을 때는 쓰레드를 어떻게 구성할까?

 

방법 1 : 쓰레드를 하나 생성하고, 클라이언트1의 요청 수행 후 클라이언트2의 요청을 수행하는 방법

-> 클라이언트1의 요청 수행 중에 오류가 발생하면 클라이언트2의 요청 수행 불가하게된다

 

방법 2 : 쓰레드를 요청마다 생성한다. 쓰레드1로 클라이언트1의 요청을 수행하고 쓰레드2로 클라이언트2의 요청을 수행한다.

-> 하나의 쓰레드가 지연되어도 나머지 쓰레드는 정상동작 가능하다.

-> 하지만 쓰레드 생성비용과 컨텍스트 스위칭(클라이언트1에서 클라이언트2로 넘어가는 과정) 비용이 비싸기때문에 응답속도가 늦어지고, 메모리 임계점을 넘어 서버가 죽을 수 있다.

 

 

Thread Pool 쓰레드풀

WAS안에 쓰레드풀이라는 공간에 쓰레드를 여러개 생성해 놓고

클라이언트에게 요청이 들어오면, 쓰레드풀에게 놀고있는 쓰레드를 달라고 요청한다.

요청을 수행한 후에는 쓰레드를 소멸시키는 것이 아닌, 쓰레드풀에 반환한다.

톰캣은 최대 200개의 쓰레드를 쓰레드풀에 보관한다.(변경 가능)

 

쓰레드풀의 장점은

쓰레드풀의 모든 쓰레드가 사용중이면 다음으로 들어오는 요쳥을 대기시키거나 거절시켜서 기존의 요청을 안전하게 처리할 수 있다.

쓰레드가 미리 생성되어있으므로, 쓰레드를 생성하고 종료하는 비용이 절약되고 응답시간이 빨라진다.

 

 

멀티쓰레드

위와 같은 이런 복잡한 내용을 개발자가 하나하나 다 구현하지 않아도 WAS가 알아서 처리해준다!!

=> 개발자는 비즈니스 로직에만 신경쓸 수 있게된다

 

 

✨TIP

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

값을 너무 낮게 설정할 때 동시요청이 많으면 

서버 리소스는 여유롭지만 클라이언트는 응답이 쉽게 대기되거나 거절된다

 

값을 너무 높게 설정할 때 동시요청이 많으면

CPU, 메모리 리소스 임계점 초과로 서버가 다운된다.

 

그럼 쓰레드풀의 적정숫자는 어떻게 찾을까??

애플리케이션 로직의 복잡도, CPU, 메모리 상황에 따라 모두 다르기때문에

아파치 ab, 제이미터, nGrinder등을 통해 성능테스트를 시도해서 찾아내야한다

 

 

---

 

HTTP API : 데이터만 주고받는다

HTML이 아닌 데이터를 전달하는 방법이다.

주로 JSON형식으로 데이터만 주고받는 곳에서 사용된다.

 

백엔드 개발자는 3가지 방식에 대해 고민해야한다.

정적 리소스 어떻게 제공할 것인가
동적 리소스 어떻게 제공할 것인가
HTTP API 어떻게 제공할 것인가

 

SSR 서버사이드렌더링

서버에서 최종 HTML을 생성해서 클라이언트에게 전달하는 방법

주로 정적인 화면에 사용된다.

JSP, 타임리프 등을 사용한다.

 

 

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

최종 HTML을 자바스크립트를 사용해 웹브라우저에서 동적으로 생성하는 방법

주로 동적인 화면에 사용한다. 웹 환경을 마치 앱처럼 부분부분 변경할 수 있다.

React, Vue.js 등을 사용한다.

 

 

---

 

자바 웹 기술의 역사

HTTP의 연결, 요청 분석, 응답 전달 등을 편리하게 하기 위해 서블릿 등장

 

서블릿의 동적 HTML생성 어려움을 해결하기 위해 JSP 등장

JSP는 HTML생성은 편리하지만 비즈니스로직까지 너무 많은 역할을 담당하게됨

(한 페이지에서 DB연결부터 페이지 구성까지...)

 

서블릿, JSP를 조합한 MVC 패턴 사용

 

애노테이션 기반의 스프링 MVC 등장

서버에 WAS를 직접 설치하고, 소스는 WAR파일을 만들어서 설치한 WAS에 배포해야됨. (빌드 배포 복잡)

 

스프링 부트 등장

기존 스프링에서 WAS를 내장하게됨.

빌드결과(JAR)에 WAS서버를 포함해서 빌드 배포가 단순화됨.

 

 

 

 

 

인프런 - 스프링MVC 백엔드 웹개발 핵심기술