Web Server와 WAS란? 그리고 Servlet

Web Server와 WAS란? 그리고 Servlet

웹서버와 웹애플리케이션서버의 역할과 차이를 알아봅니다. 웹 환경이 어떤 식으로 응용애플리케이션을 제공하는지, Apache/Java 진영을 예로 들어 설명합니다.

Web Server와 WAS

---

특징을 최대한 간략하게 요약해볼게요.

• Web Server
  • 오래된 역사.
  • 정적 리소스(html, image, css, js...) 전달이 주 목적.
• WAS
  • 상대적으로 최근.
  • 이름으로 보아 알 수 있듯 어플리케이션을 실행할 수 있음. 따라서 동적인 리소스를 제공하는 것이 가능.
• 그런데 최근 추세는...
  • Web Server도 동적 리소스 제공을 지원하기도 하고, WAS도 리소스를 서빙하기도 하는 등, Web Server와 WAS의 경계가 모호해지고 있습니다.
  • 하지만 WAS 앞에 Web Server를 놓거나 다른 서비스 계층을 두는 식의 n-tier 구조는 여전히 유효해요. 왜냐면, 어플리케이션을 실행하는 비용은 매우 크기 때문입니다. 만약에 WAS를 맨 앞에 놓고 리소스 서빙까지 시키면 어떤 곤란한 일이 일어날까요?
    1. WAS가 부하에 매우 시달릴 거에요. 프로그램 실행도 힘든데, 서빙까지 해야하니까요.
    2. 그렇다고 분산처리를 하게 되면, 비용이 큰 WAS를 여러개로 늘리게 되는 셈이다. 같은 성능을 내는 목표라면, Web Server 분산처리가 훨씬 저렴하겠죠?
    3. 부하에 시달리던 WAS가 뻗어도 에러 메시지를 확인하기 어렵습니다. WAS 이전의 계층은 곧장 클라이언트가 되니까, 만약 직접 확인하고 싶으면 클라이언트에게 전화해서 오류메시지 좀 읽어달라고 부탁하든지 해야할텐데, 그건 좀 어려운 일일 거에요. WAS보다는 웹서버의 기술이 훨씬 오랫동안 안정되어왔기 때문에, 튼튼한 웹서버를 앞에 두면 버티기도 잘 버티고, 웹서버 쪽에서 WAS의 오류도 확인할 수 있으니 일석이조일 겁니다.
  • 물론 어플리케이션을 개발하는 입장에서는 둘의 차이를 크게 신경쓸 필요는 없습니다! (약은 약사에게 인프라는 devOps에게)

요청/응답 처리의 주체와 과정

---

서버 사이드에 HTTP Request가 들어오면 그걸 누가 받아서 처리해줄까요?
예전에 오래된 웹서비스(cgi라는 이름을 가진)에서는 하나의 요청을 하나의 프로세스가 담당했습니다. 근데 웹 환경은 멀티 유저잖아요? 멀티 프로세스인거죠. 하나의 요청이 들어올 때마다 하나의 프로세스가 담당합니다. 멀티 프로세스 환경인거죠. 그런데 이런 방식은... 매우 무거웠습니다. 웹서버도 힘들어할 뿐더러 비용도 많이 들었던 거죠.
그래서 이런 비효율을 개선하기 위해서(그 밖의 유용한 기능들도 함께 제공하기 위해서) Java 진영에서는 서블릿Servlet이라는 것을 도입했습니다.

• 서블릿은 말이죠
  • HTTP 요청과 응답을 관리해주고요.
  • 메시지도 적절히 파싱해주고요.
  • 네트워크 소켓도 관리해주었고요.
  • 무엇보다도 스레드 기반이었기 때문에 cgi 방식에 비해 훨씬 적은 비용으로 사용할 수 있었습니다.

그래서 서블릿은 요청/응답의 처리 있어서 주요한 역할을 쭉 맡게 되었어요.

• 그럼 그들을 어떤 과정을 통해 사용할 수 있을까요?
  • 요청이 들어오면 WAS는 요청/응답 객체를 만들어서 서블릿에 맡깁니다.
  • 서블릿을 통해서 요청 객체의 메시지를 응용프로그램에서(개발자가) 편하게 확인할 수 있고, 응답 메시지를 담을 수가 있습니다.
  • 서블릿이 처리를 마치면 WAS는 처리결과를 토대로 HTTP Response를 만들어 내려줍니다.

하나만 주의하자면, 서블릿은 싱글톤으로 관리되기 때문에 어플리케이션을 작성하는 개발자는 늘 멀티 환경을 염두에 두고 코드를 작성해야 합니다!