Web Server와 WAS 이해하기

Java를 기준으로 작성되었습니다.

 

Web Server와 WAS(Web Application Server)

웹 서버와  WAS의 역사

초기의 웹서버는 클라이언트의 요청에 대해 기존에 생성된 정적인 컨텐츠(Static Contents)만 응답할 수 있었다. 그 후 사용자의 요청에 따라 로직을 수행 후 변경된 동적인 컨텐츠(Dynamic Contents)를 응답할 필요가 생겼는데, 이를 Application이 붙은 Web Server라 하여 WAS라고 부른다.

웹 서버의 역할을 WAS가 대체할 수 있지만, WAS는 동적 컨텐츠를 제공하는데 집중하고 웹 서버는 정적 컨텐츠 제공 뿐만 아니라 여러 대의 WAS에게 분산하여 요청하는 등의 역할이 나뉘어 발전하게 되었다.

 

웹 서버

• '미리 생성해 저장해놓은' 정적인 컨텐츠(Static Contents)만 응답할 수 있다.
• 전통적으로 Apache가 많이 사용되었으나, 최근에는 Nginx가 대세이며 Node.js 역시 웹서버로서 많이 사용되는 추세다.
  Nginx 개념) 2021.12.19 - [Back-End/Server] - [WebServer] Nginx 작동 방식, Apache와 비교 
• Client가 요청하는 Web Server의 포트는 Http: 80포트, Https:443포트로 접속이 된다. 80포트, 443포트는 국룰이다.
  즉, http://www.naver.com로 접속하면  http://www.naver.com:80으로 접속하게 되는것이다.
• React와 같은 SPA로 개발할 경우 React 빌드 앱을 Web Server로 배포하였지만, 최근에는 서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 페이지를 보여주는 방식인 SSR(Server-Side-Rendering)를 많이 도입하고 있다.

 

WAS(Web Application Server)

• WAS는 Web Server와 응용 프로그램이 담긴 Web Container가 합쳐진 것으로 이해할 수 있다. 웹 서버가 있다고 했으므로, WAS에는 웹 서버 기능을 내장하고 있다는 뜻이다. 
• 동적인 기능을 제공하기 위해 Web Container가 존재한다. Web Container는 Java를 사용해 웹 페이지를 동적으로 생성하는 Servlet이 포함되어 있다.
• 과거에는 WAS를 도입하지 않고 Web Server로만 동적이 기능을 제공하기 위해 Apache + Php + MySQL 연동을 통해 동적인 컨텐츠를 제공하기도 했다.
• WAS로 Apache에서 만든 Tomcat, IBM Web Sphere, TMax Jeus 등이 있으며 주로 Tomcat이 주로 사용된다. 요즘에는 Spring Boot에 Tomcat이 내장되어 있다.
• Tomcat 사용 방법
  • Spring + Java로 개발한 웹앱을 .war 파일로 빌드하면 .class 파일, jsp, 이미지, css, javascript 파일 등이 압축되어 있다.
  • Tomcat의 특정 폴더에 .war 파일을 넣고 명령어 입력하면 Spring이 Tomcat을 사용해 서비스한다.
  • 요즘에는 반대로 Tomcat이 내장된 Spring을 jar 파일로 빌드해 배포한다.

 

정적인 컨텐츠(Static Contents) vs 동적인 컨텐츠(Dynamic Contents)

• 정적인 컨텐츠에 대해 정확히 표현하자면 '기존에 생성된 파일' 그 자체로 이해할 수 있다. 즉, '미리 생성해 저장해 놓은' HTML 문서나, 이미지 파일 등을 그대로 전달해주는 것이다.
• 반면, 동적인 컨텐츠는 '사용자의 요청에 따라 내용을 변경해 생성한' HTML 문서, 이미지 파일 등을 전달해주는 것이다. 이 때 사용자의 요청에 따라 내용을 변경하는 것이 Web Container에서 Java가 로직을 수행하는 부분이 된다.

 

웹 서버와 WAS를 분리하는 이유

• WAS도 웹 서버를 포함하고 있음에도 일반적으로 웹 서버와 WAS를 분리한 아키텍처를 설계한다. 즉, 웹 서버를 사용하는 이유와 특징을 파악하면 굳이 분리하는 이유를 알 수 있다.  Key Point는 보안 강화, 역할 분담과 그에 따른 부하 분산, 성능 최적화다.

 

1. Reverse Proxy
   사용자들에게 WAS의 내부 구조를 감추는데 사용할 수 있다. URI를 입력할 때 서버의 내부 구조가 드러날 수 있다. 하지만 Client는 Web Server에만 요청하고, Web Server가 WAS에게 요청하는 구조이므로 Client는 WAS의 폴더 구조, 포트 번호 등을 알 수 없다. 즉, Web Server가 Reverse Proxy 역할을 하는 것이다.
2. Load Balancing
   WAS가 여러대일 경우 Client로부터 오는 요청(HTTP Request)을 분산할 수 있는데 이를 Load Balancing(부하 분산)이라 한다. Nginx가 제공하는 부하 분산 방식은 순차 순회 방식(Round-robin), 가장 클라이언트 연결 갯수가 적은 서버로 전달하는 방식(least-connenction) 등이 있다.
3. Caching
   Client가 요청하는 데이터 중 WAS에게 이미 응답을 받았던 것이라면 WAS에게 재요청하지 않고 Cahcing 했다가 Client에게 응답한다.
4. WAS Health Check
   WAS가 정상적으로 작동하고 있는지 체크

 

'스마트폰 앱, SPA'의 등장에 따라 달라진 WAS의 역할 (feat. API 서버)

• 스마트폰 앱, SPA(Angular, React, Vue)의 등장에 따라 WAS의 역할이 달라지기 시작한다.
• 과거 스마트폰 앱, SPA가 등장하기 전 웹 브라우저 환경이 전부였을 때 WAS는 동적으로 'HTML을 생성해' Web Server에게 전달했다. HTML을 생성했다는 것은 UI를 WAS 레벨에서 직접 만들었다는 뜻이 된다.
• 하지만 Java와 안드로이드 OS를 기반으로 UI를 그릴 수 있는 스마트폰과 React, JavaScript 기반으로 UI를 그리는 SPA가 등장함에 따라 Client 레벨(스마트폰, 웹브라우저)에서 모든 UI를 그릴 수 있게 되었다. 즉, Client가 필요한 것은 오로지 UI를 그리는데 필요한 '데이터'다.
• 이렇게 Client의 요청에 따라 필요한 데이터만을 제공하는 서버를 API 서버라고 한다. 최근 Back-End 서버는 이렇게 데이터만 제공하는 API 서버가 주를 이룬다.
• 이렇듯 Back-End 서버는 비즈니스 로직을 수행하는데 집중할 수 있으므로 부하가 더 줄어든다고 볼 수 있다.

 

• 스마트폰 앱, SPA 등장 이전 WAS의 역할: 동적 웹 페이지(HTML) 생성

스마트폰 앱, SPA 등장 이전 WAS의 역할

 

• 스마트폰 앱, SPA 등장 이후 WAS의 역할: API 서버

스마트폰 앱, SPA 등장 이후 WAS의 역할: API 서버

 

 

 

[Reference]

WAS vs WS : https://www.youtube.com/watch?v=6xl3wKMjmWg 

어서 와, SSR은 처음이지? : https://d2.naver.com/helloworld/7804182

Nginx Load Balancing: https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/