정적 페이지
초기 웹 서버는 페이지의 내용이 변하지 않는 정적 페이지만을 제공했다. 즉 파일의 내용이 변하지 않는 정적 리소스 (HTML, CSS, JS ··)만을 제공했다. 이 방식은 매우 쉽고 빠르지만 아래의 문제들이 발생한다.
- 페이지 수만큼의 정적 리소스가 웹 서버내에 저장되어야 한다. 만약 만 개의 페이지를 제공한다면 만 개의 HTML 파일이 존재해야한다. 저장 용량에 많은 부분을 차지할 뿐만 아니라 수정도 힘들다. 만약 홈페이지 로고를 바꾼다면 만 개의 HTML 파일을 모두 수정해야 하는 대작업이 벌어진다.
- 사용자가 페이지를 추가 할 수 없다. 사용자가 페이지를 추가하기 위해서는 웹서버 관리자에게 페이지를 구성하는 리소스를 줘야한다.
동적 페이지
이러한 문제를 해결하기 위해 웹 서버는 페이지의 내용이 변하는 동적 페이지를 제공한다. 즉 정적 리소스와 더불어 html을 동적으로 생성해 제공한다. 동적으로 리소스를 생성하는 과정에서 웹 애플리케이션 로직이 실행된다.
위 구조의 웹서버는 정적 리소스를 제공하고 웹 애플리케이션 로직을 수행하므로 너무 많은 일을 한다. 사용자가 많다면 아래와 같이 역할을 분담하는 편이 좋다.
아래와 같이 스케일 아웃도 쉽게 가능하다.
즉 웹서버와 WAS로 역할을 분담하면 아래의 이점을 가진다.
- 서버 과부하 방지 : 웹 애플리케이션 로직을 수행하는 건 비용이 많이 드는 작업이다. 웹 애플리케이션 로직을 수행하는 서버와 정적 리소스를 제공하는 서버로 나눠 서버 과부하를 방지한다. 또한 웹서버의 로드밸런싱을 통해 서버 부하를 분리한다.
- 보안 향상 : 웹 서버는 DMZ에 두고 WAS는 내부망에 위치시킴으로써 외부에서 WAS로의 접근을 아예 차단한다.
- 여러 웹 애플리케이션 실행 : 웹서버의 로드밸런싱을 통해 다양한 웹 애플리케이션을 실행할 수 있으며 요청 프로토콜에 따라 어떤 웹 애플리케이션이 동작할지 설정할 수 있다.
웹서버 VS WAS
웹 서버와 Application 서버는 아래와 같이 구분할 수는 있다. 하지만 언어 진영마다 웹 서버와 Application 서버의 정의가 약간씩 다르며 각 서버가 서로의 기능을 추가함에 따라 웹서버와 Application 서버의 경계가 모호해졌다. 따라서 이제 같은 Application 서버의 의미로 사용된다. 이런 이유로 많은 문서들이 웹 서버, Application 서버를 구분하지 않고 웹 서버로 통칭하거나 Application 서버로 통칭한다. 위 그림에서도 둘을 구분해놨지만 딱히 구분할 필요는 없다.
- Web Server : HTTP 요청에 대해 HTTP 응답으로 정적 리소스만을 제공하는 서버
- Application Server (= WAS) : HTTP 요청에 대해 HTTP 응답으로 정적 컨텐츠를 제공할 뿐만 아니라 웹 어플리케이션의 코드를 수행해 동적 리소스(HTML, JSON)를 만들어 제공하는 서버, HTTP뿐만 아니라 다양한 프로토콜도 지원
HTTP API
웹서버가 HTML를 제공하는 것이 아닌 HTTP API를 제공하는 경우도 많다. HTTP API를 호출하면 JSON와 같은 데이터를 응답으로 준다.
HTTP API를 제공하면 다양한 시스템에서 HTTP API를 호출해 사용할 수 있다는 장점이 있다.
참고)
https://www.ibm.com/cloud/learn/web-server-vs-application-server
