웹 애플리케이션의 이해 - WAS와 서블릿

✔️웹서버 vs 웹 어플리케이션 서버

웹서버

• HTTP 기반으로 동작
• 정적 리소스 제공, 기타 부가 기능
• 정적(파일) HTML, CSS, JS, 이미지, 영상 → 어떠한 파일에 대한 요청이 오면 그것을 그대로 제공함
• 예) NGINX, APACHE

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

• HTTP 기반으로 동작
• 웹서버 기능 대부분 포함 + (정적 리소스 제공 가능)
• 웹서버와 다른 점은 “프로그램 코드를 실행해서 애플리케이션 로직 수행” 한다는 것
  • 동적 HTML, HTTP API(JSON)
  • 서블릿, JSP , 스프링 MVC
  예를 들어 코드를 실행할 수 있기 때문에 각 사용자의 이름을 띄우는 것
• 예) 톰캣 Jetty, Undertow

💚웹 서버와 웹 어플리케이션의 차이

• “웹 서버는 정적 리소스(파일)을 제공해주는 것이고 웹 애플리케이션은 애플리케이션 로직까지 수행할 수 있는 것이다. “
• 둘의 경계가 모호하긴하다.
  • 웹서버도 플러그인을 설치하면 프로그램을 실행하는 기능도 포함되어 있고
  • 웹 애플리케이션 서버도 웹 서버의 기능을 제공하기 때문이다.
• 자바는 서블릿 컨테이너 기능을 제공하면 WAS라고 한다.
  • 서블릿 없이 자바 코드를 실행하는 서버 프레임워크도 있다.
• ⇒ WAS는 애플리케이션 코드를 실행하는데 더 특화되어있다. 라고 보면 된다.

✔️웹 시스템 구성

(1) 최소한의 구성 

최소한으로 구성하면 WAS + DB 만으로 시스템 구성이 가능하다.

• WAS는 정적 리소스, 애플리케이션 로직 모두 제공되기 때문이다.
• 하지만 이렇게 된다면 WAS가 많은 역할을 하고 있으므로 서버 과부하 우려가 생긴다.
• 가장 비싼 애플리케이션 로직(파일 제공은 싸지만 비즈니스 로직이 있는 것은 비싸다)이 정적 리소스 때문에 수행이 어려울 수 있다.
• WAS 장애시 오류 화면도 노출이 불가능하다. (WAS는 잘 죽는다)

(2) 일반적인 구성 WEB + WAS + DB 

최소한의 구성의 단점을 보완하기 위해

• 정적 리소스( HTML, CSS, JS, 이미지, 영상)는 웹 서버가 처리한다.
• 웹 서버는 애플리케이션 로직같은 동적인 처리가 필요하다면 WAS에 요청을 위임
• WAS는 중요한 애플리케이션 로직 처리 전담 (중요한 것만 전담)

구조 : [클라이언트] → [웹서버] → [WAS] → [DB]

• 장점
• (1) 효율적인 리소스 관리가 가능하다.
  • 정적 리소스가 많이 사용되면 WEB 서버 증설
  • 애플리케이션 리소스가 많이 사용되면 WAS 증설
• (2) WAS, DB 장애시 WEB 서버가 오류 화면 제공 가능하다.
  • 정적 리소스만 제공하는 웹 서버는 잘 죽지 않는다. (파일 제공만하기 때문에)
  • 애플리케이션 로직이 동작하는 WAS 서버는 잘 죽는다. (여러 가지 요인으로)

---

서블릿의 필요성을 알기 위해 일단, 웹 애플리케이션 서버를 직접 구현한다고 가정했을 때 어떤 작업들을 해야 하는지 나열해보자면,

 

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

 

2) HTTP 요청 메시지를 파싱해서 읽기

    POST 방식인지 (어떤 메소드)

    URL 인지 (/save 부분 인지)

    Content-Type 확인

    HTTP 메시지 바디 내용 파싱

        ex) username=kim&age=20 이라면 username, age 데이터를 사용할 수 있게 파싱

 

3) URL 에 맞게 프로세스 실행

     (/save이라면 저장 프로세스 실행)

 

4) 비즈니스 로직 실행 ⇒ 이 부분만 의미있는 “비즈니스 로직”이라고 할 수 있다.

     데이터베이스에 저장 요청

 

5) HTTP 응답 메시지 생성 시작

    HTTP 시작 라인 생성

    Header 생성

    메시지 바디에 HTML 생성에서 입력

 

6) TCP/IP 응답 전달, 소켓 종료

 

✔️ 비즈니스 로직을 구현하기 위해서 그 이외의 많은 것들을 신경써야한다. 비효율적이다.

→ 이에 대한 해결책으로 서블릿을 지원한다. (서블릿은 개발자가 HTTP 스펙을 매우 편리하게 사용한다)

 

✔️서블릿

• 서블릿을 지원하는 WAS를 사용한다면 비즈니스 로직 이외의 과정들을 자동화 해서 다 해결해준다

[특징]

@WebServlet(name= "helloServlet", urlPatterns = "\\hello")
public class HelloServlet extends HttpServlet{ //HttpServlet을 상속받아서 쓴다. 
	
	@Override
	protected void service(HttpServletRequest request, HttpServletResponse response)
	{
			//애플리케이션 로직 
	}
}

• 서버에 요청이 올 때 HTTP 메시지에 많은 내용이 있는데 HttpServletRequest으로 받아오면 get으로 쉽게 내용을 가져올 수 있다.
• 서버에서 다시 클라이언트로 HTTP 메시지를 보낼 때 많은 내용들이 있는데 HttpServletResponse을 사용하면 개발자가 간단한 작성을 통해 보낼 수 있다.

[과정]

1) 클라이언트에서 localhost:8080/hello 라고 요청을 보낸다.

2) WAS 서버에서 request(HTTP 요청 메시지를 기반으로 생성), response 객체를 새로 만든다.

3) 서블릿 컨테이너에 있는 helloServlet 객체를 호출하여 실행

    request 객체에 있는 정보들을 꺼내서 사용, response 객체에 정보를 편리하게 입력

4) WAS는 아까 요청들어왔을 때 만든 response 객체의 내용을 보고 HTTP 응답 메시지를 생성한다.

 

✔️서블릿 컨테이너란?

WAS 안에서 개발자가 만들어 놓은 Servlet 코드 기반으로 서블릿 객체를 자동으로 생성, 호출 , 관리(생명주기에 따라 WAS 가 내려갈 때 같이 내려가게 한다)

• 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 한다.
• 서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리한다.
• 서블릿 객체는 싱글톤으로 관리한다. (처음에 하나의 객체로 생성하고 모두가 공유해서 사용한다)
  • 고객의 요청이 올 때마다 계속 객체를 생성하는 것은 비효율적이다.
  • 최초 로딩 시점에 서블릿 객체를 싱글톤으로 미리 만들어두고 재활용한다.
  • 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근한다. (HTTP request, response 는 고객마다 다른 데이터이므로 요청할 때마다 새로운 객체를 만드는 것이 당연하지만 이를 처리하는 로직은 다 동일하므로 싱글톤으로 관리하는 것이 효율적이다)
  • 그래서 공유 변수 사용 주의
  • 서블릿 컨테이너 종료시 함께 종료한다.
• JSP도 서블릿으로 변환 되어서 사용
• 동시 요청을 위한 멀티 쓰레드 처리 지원해준다.
  • 동시에 많은 요청들이 들어와도 잘 처리하는 이유가 WAS가 멀티 스레드를 지원하기 때문이다.

 

이 글은 김영한님의 "스프링 MVC 1편"을 듣고 정리한 글입니다.