이번 포스팅에서는 웹 개발의 기본이 되는 "WS(Web Server), WA(Web Application), WAS(Web Application Server)"에 대해 자세히 알아보겠다.

우선 바로 WS, WA, WAS의 개념과 차이를 설명하기 보단 서저가 응답하는 2가지 형태를 먼저 알아볼 필요가 있다.

1. 서버 응답 형태

Static Pages

위 사진처럼 사용자가 요청을 보냈을 때 Web Server의 역할은 파일 경로 이름을 받아 경로와 일치하는 file contents를 반환한다.
즉, 요즘엔 사용하지 않는 형태라고 볼 수 있다.

Web Server

정의

Web Server는 클라이언트가 웹 브라우저를 통해 요청한 정적 콘텐츠(HTML 파일, CSS 파일, 이미지 등)를 제공하는 서버이다.
대표적인 웹 서버로는 Apache, Nginx, IIS 등이 있다.

역할

사용자의 요청에 따라 저장된 콘텐츠를 그대로 반환하는 역할.

주요기능

HTTP 프로토콜을 이용한 클라이언트와의 통신
정적 콘텐츠 제공
도메인 이름을 IP 주소로 변환하는 DNS 서비스 지원
SSL/TLS를 통한 보안 연결 지원
로드 밸런싱을 통한 트래픽 관리

Dynamic Pages

인자의 내용에 맞게 Dynamic 한 Contents를 반환한다. 즉, 웹 서버에 의해 실행되는 프로그램(Web Application)을 통해서 만들어진 결과물(Servlet, JSON, etc...)을 반환한다.

웹 서비스의 흐름

1. 클라이언트 요청: 사용자가 웹 브라우저를 통해 특정 웹 페이지를 요청.
2. 웹 서버(WS) 처리: 요청 받은 웹 서버는 정적 콘텐츠 요청인지, 동적 콘텐츠 요청인지를 판단.
   • 정적 콘텐츠 요청의 경우, 웹 서버(WS)가 직접 파일을 찾아 응답.
   • 동적 콘텐츠 요청의 경우, 웹 서버(WS)는 웹 애플리케이션 서버(WAS)에 요청을 전달.
3. WAS 처리: WAS는 요청에 맞는 웹 애플리케이션 로직을 실행하고, 필요한 경우 데이터베이스와 상호작용하여 결과를 생성.
4. 응답 전달: 생성된 동적 콘텐츠는 다시 웹 서버를 통해 클라이언트에게 전달.
5. 클라이언트 표시: 웹 브라우저는 받은 콘텐츠를 사용자에게 표시.

Web Application

정의

Web Application은 사용자의 요청에 따라 동적으로 콘텐츠를 생성하거나 데이터를 처리하는 애플리케이션이다.

역할

클라이언트의 요청에 따라 데이터베이스와의 상호작용, 로직 처리 등을 통해 동적인 웹 페이지를 생성하고 응답한다.

개발 언어 및 프레임워크

웹 애플리케이션은 다양한 프로그래밍 언어와 프레임워크를 사용하여 개발될 수 있다.
언어의 예로는 Java, Python, Ruby, PHP 등이 있으며, 각 언어별로 Spring, Django, Ruby on Rails, Laravel 등의 프레임워크가 사용된다.

Web Application Server

정의

Web Application Server는 웹 애플리케이션을 실행하고, 클라이언트의 요청에 따라 애플리케이션 로직을 처리하여 동적인 콘텐츠를 생성하는 서버이다.
즉, 웹 어플리케이션이 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임워크(http를 통해 컴퓨터나 장치에 애플리케이션을 수행하는 미들웨어)
대표적인 WAS로는 Apache Tomcat, JBoss, WebLogic 등이 존재한다.

역할

WAS는 클라이언트의 요청을 받아 해당 비즈니스 로직에 맞는 데이터 처리를 수행한 후 그 결과를 웹 서버에 전달하며, 웹 서버는 이를 클라이언트에게 전달한다.

주요 기능

웹 애플리케이션의 실행 및 관리
세션 관리, 트랜잭션 관리, 데이터베이스 연결 관리 등의 복잡한 비즈니스 로직 처리
다양한 프로그래밍 언어와 프레임워크 지원

• 참고로 현재 WAS를 가지고 있는 Web Server도 정적인 콘텐츠를 처리하는데 있어서 성능상 큰 차이는 없다.

2. WS, WAS의 관계?

Web Server 와 WAS 를 분리하지 않은 경우

모든 컨텐츠를 한 곳에 집중시켜 웹 서버와 WAS의 역할 동시에 수행한다.
스위치를 통한 Load Balancing, 사용자가 적을 경우 효율적이다.

Web Server 와 WAS 를 분리한 경우

웹 서버와 WAS의 기능적 분류를 통해 효과적인 분산 유도.
정적 데이터는 웹 서버에서 처리, 동적인 데이터는 WAS가 처리

Web Server 와 여러 대의 WAS 가 존재하는 경우

WAS 단을 프레젠테이션 로직과 비즈니스 로직으로 구분하여 구성.
특정 로직의 부하에 따라 적절한 대응을 할 수 있지만 설계단계, 유지보수 단계가 복잡해질 수 있다.

3. 그럼 왜 Web Server 와 WAS 를 분리할까?

1) Web Server가 필요한 이유

클라이언트(웹 브라우저)에 이미지 파일(정적 컨텐츠)를 보내는 응답이라 가정할 때 이미지 파일과 같은 정적인 파일들은 웹 문서(HTML 문서)가 클라이언트로 보내질 때 함께 가는 것이 아니다.
클라이언트는 HTML 문서를 먼저 받고 그에 맞게 필요한 이미지 파일들을 다시 서버로 요청하면 그때서야 이미지 파일을 받아온다.
즉, Web Server를 통해 정적인 파일들을 Application Server까지 가지 않고 앞단에서 빠르게 보내줄 수 있다.

따라서 Web Server에서는 정적 컨텐츠만 처리하도록 기능을 분배하여 서버의 부담을 줄일 수 있다.

2) WAS가 필요한 이유

웹 페이지는 정적 컨텐츠와 동적 컨텐츠 모두 존재한다. 이때 사용자의 요청에 맞게 적절한 동적 컨텐츠를 만들어서 제공해야 한다.
만약 Web Server만을 이용한다면 사용자가 원하는 요청에 대한 결과값은 모두 미리 만들어 놓고 서비스해야 한다. 하지만 이렇게 수행하기에 자원이 절대적으로 부족하다.

따라서 WAS를 사용하여 요청에 맞는 데이터를 DB에서 가져와서 비즈니스 로직에 맞게 그때 그때 결과를 만들어서 제공함으로써 자원을 효율적으로 사용할 수 있다.

3) WAS가 Web Server의 기능까지 모두 수행하면 되지 않을까?

a) 서버 부하 방지

WAS는 DB 조회나 다양한 비즈니스 로직 처리에 바쁘기 때문에 단순한 정적 컨텐츠는 Web Server에서 빠르게 클라이언트에 제공하는 것이 좋다.
만약 정적 컨텐츠 요청까지 WAS가 처리하게 될 경우, 정적 데이터 처리로 인해 부하가 커지게 되고, 동적 컨텐츠 처리가 지연됨에 따라 수행 속도가 느려진다.
즉, 이로 인해 페이지 로딩 시간이 늘어나게 된다.

b) 물리적으로 분리하여 보안 강화

Web Server와 WAS를 물리적으로 분리하고 그 사이에 방화벽을 두어 보안을 강화한다.
SSL를 통해 데이터를 패킷화하고 암복호화하여 전달하기 때문에 보안이 강화된다.

c) 여러 대의 WAS를 연결 가능

• 로드 밸런싱:
  웹 서버 앞단에 로드 밸런서를 배치하여 다수의 웹 서버로 트래픽을 분산시켜 시스템의 가용성과 내구성을 높일 수 있다.

• 스케일 아웃:
  트래픽 증가에 따라 웹 서버나 웹 애플리케이션 서버의 인스턴스를 추가하여 시스템의 용량을 확장할 수 있다. 이를 통해 높은 트래픽에도 안정적인 서비스 제공이 가능하다.

• failover와 failback 처리:
  특히 대용량 웹 어플리케이션의 경우(여러 개의 서버 사용) Web Server와 WAS를 분리하여 무중단 운영을 위한 장애 극복에 쉽게 대응할 수 있다.
  예를 들어, 앞 단의 Web Server에서 오류가 발생한 WAS를 이용하지 못하도록 한 후 WAS를 재시작함으로써 사용자는 오류를 느끼지 못하고 이용할 수 있다.

d) 여러 웹 어플리케이션 서비스 가능

하나의 서버에서 PHP 어플리케이션, Java 어플리케이션을 함께 사용하는 등 여러 웹 어플리케이션 서비스를 유연하게 제공할 수 있다.

e) 기타

접근 허용 IP 관리, 2대 이상의 서버에서의 세션 관리 등도 Web Server에서 처리하면 효율적이다.
즉, 지원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성을 위해 Web Server와 WAS를 분리한다.

4. Spring, Spring Boot 그리고 WAS

사실 앞서 설명한 것들은 spring, spring boot의 기본 구조와 명칭을 정확히 파악하기 위한 서론에 불과했다.

Spring Framework의 빌드와 배포

전통적인 Spring 프로젝트에서는 WAR(Web Application Archive) 파일 형태로 애플리케이션을 빌드하고, 이를 외부의 WAS(Web Application Server)에 배포하는 방식을 사용한다.

이 과정에서 개발자는 애플리케이션 서버(예: Tomcat, JBoss 등)를 별도로 설치하고 관리해야만 한다. 또한, 새로운 버전의 애플리케이션을 배포하기 위해서는 기존에 배포된 WAR 파일을 새로운 버전으로 교체하고, 애플리케이션 서버를 재시작하는 과정이 필요한다.
이러한 방식은 배포 과정에서 여러 단계를 거쳐야 하며, 서버 관리에 대한 추가적인 작업이 요구된다.

Spring Boot의 빌드와 배포

반면, Spring Boot는 내장된 Tomcat, Jetty 또는 Undertow 같은 내장 서버(WAS)를 사용하여 애플리케이션을 빌드하고 실행할 수 있게 해준다.
Spring Boot 애플리케이션은 대부분의 경우 JAR(Java Archive) 파일 형태로 패키징되며, 이 JAR 파일 안에는 애플리케이션 코드뿐만 아니라 내장 서버와 애플리케이션을 실행하는 데 필요한 모든 종속성들도 포함되어 있다.

이렇게 하면, 별도의 애플리케이션 서버에 애플리케이션을 배포하는 대신, java -jar 명령어를 사용하여 여러 애플리케이션(인스턴스)을 직접 또는 동시에 실행할 수 있다. 이는 마이크로서비스 아키텍처와 같이 분산 시스템을 구축할 때 유리하다.

이러한 과정은 배포 과정을 크게 단순화시키며, 개발자가 외부 서버의 설치 및 관리 없이도 애플리케이션을 빠르게 배포하고 실행할 수 있게 해준다.