[Spring Framework] 웹 애플리케이션의 이해

1. 웹 서버와 웹 애플리케이션 서버

1)  웹 서버(Web Server)

• HTTP기반으로 동작하고 정적 리소스와 기타 부가기능 제공
• NGINX, APACHE 등이 있다.

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

• HTTP기반으로 동작하며 웹 서버 기능 + 프로그램 코드를 실행해서 애플리케이션 로직 수행
• 동적 HTML, HTTP API(JSON), Servlet, JSP, 스프링 MVC
• Tomcat, Jetty, Undertow 등이 있다.

그렇다면 웹 서버와 WAS의 차이점은?

• 보통 웹 서버는 정적 리소스, WAS는 애플리케이션 로직을 처리한다.
• 자바는 서블릿 컨테이너 기능을 제공하면 WAS라고 한다. 웹 서버도 프로그램을 실행하는 기능을 포함하기도 하지만 WAS가 애플리케이션 코드를 실행하는데 더 특화되어 있다.
• WAS는 비싸고 잘 죽는다.(웹 서버는 잘 죽지 않는다.)
  • → 정적 리소스는 웹 서버가 처리하고 동적인 처리가 필요한 애플리케이션 로직을 WAS에 요청한다.(WAS 장애 시 웹 서버의 정적 리소스를 가지고 오류 화면을 제공한다.)
  • → 따라서 효율적인 리소스 관리가 가능하다.
    • 정적인 리소스가 많이 사용되면 웹 서버를 증설하면 되고 
    • 애플리케이션 리소스가 많이 사용되면 WAS를 증설하면 된다.
  • 단순 데이터만 제공하는 API서버의 경우 웹 서버 없이 WAS만 이용하는 경우도 많다.(굳이 필요가 없기 때문)

2. 서블릿(Servlet)

내가 직접 웹 애플리케이션 서버를 구현하면 TCP/IP, 소켓 연결, HTTP 메시지 파싱 등 내가 다 해야 한다.

#############################################################

TCP/IP 대기, 소켓 연결

HTTP 요청 메시지 파싱 및 읽기

HTTP method, url 인지 및 Content-Type 확인

HTTP 메시지 바디 내용 파싱

저장 프로세스 실행

비지니스 로직 실행

HTTP 응답 메시지 생성(시작 라인 생성, Header생성, 메시지 바디에 HTML 생성 입력)

TCP/IP에 응답 전달 및 소켓 종료

#############################################################

하지만 WAS를 사용하면 '비지니스 로직' 만 구현하면 된다.

서블릿이 비지니스 로직을 제외한 나머지 일들을 다 해준다.

 

1) 서블릿의 형태

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {
    @Overrideprotected void service(HttpServletRequest request, HttpServletResponse response){
			//애플리케이션 로직
    } 
}

// /hello라는 URL 패턴이 호출되면 서블릿 코드가 실행됨
// HttpServletRequest : 요청정보를 편리하게 사용할 수 있음
//HttpServletResponse : 응답정보를 편리하게 제공할 수 있음

➡️ 개발자가 HTTP스펙을 편리하게 사용할 수 있게 해준다.

2) HTTP요청, 응답 흐름

1. HTTP요청이 오면
2. WAS가 Request, Response객체를 새로 만들어서 서블릿 객체를 호출한다.
3. 개발자는 Request객체에서 요청정보를 꺼내서 사용하고
4. Response객체에 응답정보를 입력한다.
5. WAS는 Response객체에 담긴 내용으로 HTTP응답정보를 생성한다.

3) 서블릿 컨테이너란

• 서블릿 객체의 생명주기(생성, 초기화, 호출, 종료)를 관리한다.
• 서블릿 객체는 싱글톤으로 관리된다.
• 동시 요청을 위한 멀티 쓰레드 처리를 지원한다.
• 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 한다.

 

3. 멀티 쓰레드

쓰레드라는 것은 한 번에 하나의 코드 라인만 수행 → 동시 처리가 필요할 경우 쓰레드를 추가 생성해야 한다.

1) 요청마다 쓰레드를 생성할 경우

• 장점 : 동시요청을 처리할 수 있고, 하나의 쓰레드가 지연되어도 나머지 쓰레드는 정상 동작함
• 단점
  • 쓰레드 생성 비용이 비쌈 → 고객의 요청이 올 때마다 생성하면 응답속도 느려짐
  • 컨텍스트 스위칭 비용이 발생함
  • 생성 제한이 없음 → CPU, 메모리 한계를 넘어서 서버가 죽을 수도 있음

➡️ 이러한 단점을 극복하기 위해서 쓰레드 풀을 사용

 

2) 쓰레드 풀(Thread Pool)

필요한 쓰레드를 풀에 보관, 관리한다. → 생성 가능한 쓰레드의 최대치를 관리한다.

• 장점
  • 쓰레드가 미리 생성되어 있기 때문에 쓰레드의 생성, 종료하는데 드는 비용을 줄이고 응답시간이 빨라진다.
  • 쓰레드를 생성하는데 최대치가 정해져 있기 때문에 너무 많은 요청이 오더라도 기존의 요청을 안전하게 처리 가능하다.
• 쓰레드 수를 너무 많이 설정하면 CPU, 메모리 리소스의 임계점을 넘어 서버가 다운될 수 있다.
• 그렇다고 쓰레드 수를 너무 적게 설정하면 클라이언트의 응답이 지연될 수 있다.
• 따라서 쓰레드 수를 적절하게 설정해야 한다.

 

 

 

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