[Server] Web Server / WAS 개념 및 차이점

 

Web Server

Web Server는 정적인 웹 리소스(HTML, CSS, 이미지 파일 등)를

서비스하는 데 특화된 서버 소프트웨어를 의미한다.

웹 서버는 클라이언트의 HTTP 요청을 받아 해당 요청에 맞는 정적 컨텐츠를 반환한다.

웹 서버는 주로 웹 애플리케이션의 비즈니스 로직을 처리하지 않고,

단순히 클라이언트에게 정적인 웹 페이지를 제공하는 데 사용된다.

웹 서버의 주요 기능과 특징은 다음과 같다.

 

정적 컨텐츠 제공

웹 서버는 HTML, CSS, JavaScript, 이미지, 비디오 등과 같은

정적인 웹 리소스를 클라이언트에게 전송한다.

이러한 리소스는 웹 애플리케이션의 비즈니스 로직과 상관없이 변하지 않는 고정된 내용이다.

HTTP 요청 처리

클라이언트의 HTTP 요청을 받아 해당 요청에 맞는 파일이나 리소스를 찾아 반환한다.

일반적으로 웹 서버는 웹 브라우저와의 HTTP 통신을 처리한다.

인증과 보안

웹 서버는 SSL/TLS를 사용하여 암호화된 HTTPS 연결을 제공하여 보안을 강화할 수 있다.

또한 웹 서버는 간단한 인증 방법을 통해 클라이언트의 접근을 제어할 수도 있다.

로드 밸런싱

웹 서버는 여러 대의 서버로 분산된 트래픽을 처리하기 위해 로드 밸런싱을 수행할 수 있다.

이렇게 하면 웹 애플리케이션의 성능과 가용성을 향상할 수 있다.

Reverse Proxy

웹 서버는 리버스 프록시로 동작하여 클라이언트의 요청을

웹 애플리케이션 서버로 전달하는 역할을 할 수도 있다.

이를 통해 웹 서버와 웹 애플리케이션 서버를 분리하여 웹 애플리케이션의 보안과 성능을 개선할 수 있다.

대표적인 웹 서버로는 Nginx, Apache, Microsoft IIS 등이 있으며,

이들 웹 서버는 다양한 운영체제에서 실행되어

웹 애플리케이션과 정적인 웹 페이지를 제공하는 데 사용된다.

로드 밸런싱과 Reverse Proxy에 대한 자세한 내용은 아래 포스팅을 참고하면 된다.

[Server] Reverse Proxy / Forward Proxy

[Server] What is Load Balancing?

 

WAS ( Web Application Server )

웹 애플리케이션을 실행하기 위한 서버 소프트웨어를 의미한다.

WAS는 클라이언트의 요청에 따라 동적인 웹 페이지를 생성하고

데이터베이스와의 상호작용, 트랜잭션 처리, 보안, 세션 관리 등

웹 애플리케이션의 핵심 비즈니스 로직을 수행하는 역할을 담당한다.

WAS는 다음과 같은 주요 기능과 특징을 갖는다.

 

동적 웹 페이지 생성

클라이언트의 요청에 따라 동적으로 웹 페이지를 생성하여 반환한다.

웹 애플리케이션의 비즈니스 로직을 실행하고,

결과를 HTML, JSON 등의 형식으로 클라이언트에게 전달한다.

 

데이터베이스 연동 

웹 애플리케이션은 데이터베이스와 상호작용하여

데이터의 조회, 삽입, 수정, 삭제 등을 수행해야 한다.

WAS는 이러한 데이터베이스 연동을 지원한다.

 

트랜잭션 관리

웹 애플리케이션에서 발생하는 데이터베이스 등의 작업은 트랜잭션 단위로 관리되어야 한다.

WAS는 트랜잭션 관리를 제공하여 데이터 일관성과 안정성을 유지한다.

 

보안 기능

웹 애플리케이션은 보안적으로 민감한 정보를 다루기도 한다.

WAS는 인증, 권한, 부여, 암호화 등의 보안 기능을 제공하여

웹 애플리케이션의 보안을 강화한다.

 

세션 관리

웹 애플리케이션은 상태를 유지해야 할 때가 있다.

이를 위해 WAS는 세션 관리를 지원하여 클라이언트의 상태 정보를 저장하고 관리한다.

 

다양한 프로토콜 지원

WAS는 주로 HTTP, HTTPS를 비롯하여 다양한 프로토콜을 지원하여 클라이언트와 통신한다. 

대표적인 WAS로는 Apache Tomcat, Oracle WebLogic Server,

IBM WebSphere, Red Hat JBoss 등이 있다.

각 WAS는 특정 프로그래밍 언어나 기술에 특화되어 있으며,

웹 애플리케이션을 실행하고 관리하는 데 사용된다.

 

WAS vs Web Application

WAS의 역할을 보면 여러 역할을 지원해 주는 것을 볼 수 있는데

Spring boot 또는 Node,js를 통해 만든 웹 애플리케이션과의 차이는 무엇일까?

웹 애플리케이션은 WAS가 제공하는 기능을 활용하여 비즈니스 로직을 구현하는 것이 목적이다.

웹 서비스가 복잡해지고 기능이 다양해지며 데이터를 가공해서

처리하는 비즈니스 로직이 필요하게 되었고, 이를 웹 애플리케이션에서 구현하는 것이다.

웹 애플리케이션의 구성이 다음과 같이 3가지로 구성되는 것이다.

• 프론트엔드
  사용자 인터페이스를 담당하며, HTML, CSS, JavaScript를 사용하여 사용자와 상호작용
• 백엔드
  비즈니스 로직을 처리하고, 데이터베이스와 상호작용하는 역할.
  이 부분에서 Spring과 같은 프레임워크를 사용하여 WAS와 상호작용한다.
• 데이터베이스
  웹 애플리케이션에서 필요한 데이터를 저장하고 관리하는 역할

WAS와 웹 애플리케이션의 관계를 보면 다음과 같다. 

WAS는 웹 애플리케이션을 호스팅 한다.

즉, 개발자가 개발한 웹 애플리케이션이 실제로 사용자에게 서비스될 수 있도록 서버 환경을 제공해 준다.

Spring 프레임워크는 WAS 위에서 동작하며, WAS의 기능을 활용하여 비즈니스 로직을 구현한다.

Spring은 다양한 기능(의존성 주입, AOP 등)을 제공하여

개발자가 효율적으로 웹 애플리케이션을 만들 수 있도록 도와주는 것이다.

 

Spring boot의 처리 과정을 예시로 살펴보면 다음과 같다.

사용자가 웹 애플리케이션의 특정 페이지에 요청을 보내면,

WAS는 요청을 받아 해당 요청을 처리하기 위해 Spring의 컨트롤러를 호출한다.

컨트롤러는 비즈니스 로직을 수행하고, 필요한 경우 데이터베이스에서 정보를 조회한다.

데이터베이스와의 상호작용은 WAS의 데이터베이스 연동 기능을 통해 이루어진다.

최종적으로 처리된 결과는 WAS를 통해 클라이언트에 전달된다.

결론적으로, WAS는 웹 애플리케이션이 동작할 수 있는 환경과 기능을 제공하는 반면,

개발자가 개발하는 웹 애플리케이션은 사용자 요구를 충족시키기 위해

이러한 기능을 활용하여 실제 비즈니스 로직을 구현하는 것이라고 할 수 있다.

 

 

Web Server / WAS 분리 및 효율적 사용

Web Container

 

먼저 분리의 이유를 살펴보기 전 Web Container에 대해 살펴보아야 한다.

위의 설명에서는 Web Container를 다루지 않았지만,

서블릿을 이해하기 위해 Web Container에 대해 알아야 한다.

웹 컨테이너는 동적인 데이터들을 처리하여 정적인 페이지로 생성해 주는 소프트웨어 모듈이다.
사용자의 요청이 들어오면 웹 서버는 정적인 요소만 클라이언트 측에 보낼 수 있고,

동적으로 처리해야 하는 부분은 처리할 수 없다.
컨테이너는 이러한 부분을 대신 처리해서 웹 서버에 정적인 파일로 만들어서 보내주는 모듈이다.

즉 WAS를 다시 정의하면 웹 서버로부터 오는 동적인 요청을 처리하는 서버로,

웹 서버와 웹 컨테이너를 붙여놓은 형태이다.

 

CGI & Servlet

Common Gateway Interface(공용 게이트웨이 인터페이스)라는 CGI라는 개념이 있다.

인터페이스로서, 웹 서버 상에서 프로그램을 동작시키기 위한 방법을 정의한 프로그램이다.
웹 서버와 외부 프로그램 사이에서 정보를 주고받는 방법이나 규약을 나타낸다.

CGI는 특별한 라이브러리나 도구를 의미하는 것이 아닌 

웹 서버와 외부 프로그램 사이에서 정보를 주고받는 방법, 즉 표준 스펙이자 Interface를 말한다.

즉, 서버 프로그램과 외부 프로그램과의 연계법을 의미하기 때문에

PHP, Perl, Python 등 다양한 언어로 CGI를 적용시킬 수 있다.

하지만 JAVA에서는 CGI와 유사한 방식으로 구현된 서블릿(Servlet)이라는 프로그램이 존재한다.

 

서블릿은 웹페이지를 동적으로 생성할 때 사용되는 서버 측 프로그램이다.

자바 서블릿은 웹 서버의 성능을 향상하기 위해 사용되는 자바 클래스의 일종이다.

자바 서블릿은 자바 EE 사양의 일부분으로,

클라이언트의 요청에 대해 처리하는 역할을 하는 자바 프로그램이다.

 

CGI와 서블릿의 차이점을 살펴보면 다음과 같다.

• CGI는 매 요청이 들어올 때마다 프로세스가 생성되고 각각의 CGI 구현체를 통해 처리한다.
• 서블릿은 각 요청마다 스레드가 생성되거나 스레드 풀에서 기존의 스레드를 사용하여 동작한다.

메모리를 공유하는 스레드에 비해서 프로세스는 각자의 공간을 지니기 때문에

무겁고 생성되는데 시간이 상대적으로 오래 걸린다.

또한 Servlet은 싱글톤 패턴을 통해 사용되기 때문에 하나의 구현체를 통해 동작할 수 있다.

 

CGI를 통한 처리

Servlet를 통한 처리

 

따라서 웹 컨테이너와 서블릿 컨테이너는 같은 말이다.

주어진 환경에 따라 웹 컨테이너가 CGI를 통해 처리하는 컨테이너가 되거나,

Servlet을 사용하는 서블릿 컨테이너가 되는 것이다.

서블릿을 만들었다고 해서 스스로 작동하는 것이 아니고

서블릿을 생성, 소멸 및 관리해 주는 것이 필요한데 이 역할을 하는 것이 바로 서블릿 컨테이너인 것이다.

예를 들어, 서블릿이 어떠한 역할을 수행하는 정의서라고 하면,

서블릿 컨테이너는 그 정의서를 보고 수행한다고 할 수 있다.

서블릿 컨테이너는 IoC 및 DI를 할 수 있는 것이다.

 

이러한 웹 컨테이너의 작동을 살펴보면 다음과 같다.

1) 클라이언트는 웹서버로 request(요청)을 보낸다.

2) 서블릿을 포함하는 WAS는 컨테이너로 요청을 보낸다.

3) 컨테이너가 요청을 각 서블릿에게 전달한다.

4) 서블릿 메서드가 로드된다.

5) 서블릿은 컨테이너에 관련 response(응답)을 넘겨준다.

6) 컨테이너는 이를 서버에 전달한다. 서버는 응답을 클라이언트에게 전달한다.

Web Server Was의 분리

 

다시 한번 위의 사진을 보면 WAS 내부 안에 Web Server가 존재하고 웹서버가 할 수 있는 일을

WAS가 전부 가능하다면 웹서버는 굳이 사용하지 않아도 되는 것처럼 보인다.

물론 정적인 콘텐츠만을 제공하는 웹사이트를 서버에 배포한다면 웹서버만으로도 충분하다.

그런데 동적인 컨텐츠를 제공해야 하는 웹서비스 배포를 해야 한다고 한다면 정적, 동적 요청 처리가

모두 가능한 WAS만을 사용해도 되지 않겠냐는 생각을 할 수도 있는 것이다.

 

하지만 WAS는 DB 조회 및 다양한 로직을 처리하는 데 집중해야 한다.
따라서 단순한 정적 콘텐츠는 웹 서버에게 맡기며 기능을 분리해 서버 부하를 방지해줘야 한다.

만약 WAS가 정적 콘텐츠 요청까지 처리하게 된다면,

부하가 커지고 동적 컨텐츠 처리가 지연되면서 수행 속도가 느려지고

이에 따라 페이지 노출 시간이 늘어나는 문제가 발생하여 효율성이 크게 떨어지게 된다.

따라서  웹 서버와 WAS를 분리해야 하는데 그 이유를 보면 다음과 같다.

 

서버 부하 방지

WAS와 웹 서버는 분리하여 서버의 부하를 방지해야 한다.

WAS는 DB 조회나 다양한 로직을 처리하고, 단순한 정적 컨텐츠는 웹 서버에서 처리해줘야 한다.

만약 정적 컨텐츠까지 WAS가 처리한다면 부하가 커지게 되고, 수행 속도가 느려질 것이다. 

 

보안 강화

SSL에 대한 암호화, 복호화 처리에 웹 서버를 사용 가능하다.

 

여러 대의 WAS 연결 가능

로드 밸런싱을 위해 웹 서버를 사용할 수 있다.

여러 개의 서버를 사용하는 대용량 웹 애플리케이션의 경우 웹 서버와 WAS를 분리하여

무중단 운영을 위한 장애 극복에 쉽게 대응할 수 있다. 

 

여러 웹 애플리케이션 서비스 가능

하나의 서버에서 PHP, JAVA 애플리케이션을 함께 사용할 수 있다. 

 

이러한 이유로 웹 서버를 WAS 앞에 두고

필요한 WAS들을 웹 서버에 플러그인 형태로 설정하면 효율적인 분산 처리가 가능하다.

따라서 비효율적인 아키텍처와 효율적으로 사용하는 아키텍처를 살펴보자.

 

비효율적인 웹 시스템 구성

효율적인 웹 시스템 구성

 

위의 그림과 같이 웹서버를 앞단에 두고 WAS는 웹서버가 처리하기 힘든

서버 사이드 코드의 로직 등을 수행하여 웹서버와 함께 사용자에게 양질의 컨텐츠를 제공할 수 있다.

사람들이 많이 접속하는 대용량 WAS인 경우, 서버의 수가 여러 대일 수 있다.

만약 사용 중 WAS에서 문제가 생겨 WAS를 재시작해야 하는 경우가 생긴다면

이때 재시작하기 위해 앞단의 웹서버에서 WAS를 사용하지 못하도록 요청을 차단한 후

WAS를 재시작한다면, 사용자들은 WAS에 문제가 발생한 지 모르고 이용할 수 있다.

이러한 처리를 장애 극복 기능이라고 한다. 즉 규모가 커질수록 웹서버와 웹앱 서버를 분리하는 것이다.

그리고 자원을 이용하면서 효율성, 배포 및 유지보수 편의성을 위해 대체로 분리하여 보관한다.

웹 서비스는 아래처럼 다양한 구조를 가질 수 있다.

1. Client -> 웹서버 -> DB
2. Client -> WAS -> DB
3. Client -> 웹서버 -> WAS -> DB

3가지의 구조에서 3번 구조의 동작과정을 살펴보면 다음과 같다.

3번 구조가 위에서 말한 효율적인 웹 시스템 구성을 나타내는 아키텍처이다.

Web Service Architecture

1. Web Server는 웹 브라우저 클라이언트로부터 HTTP 요청을 받는다.
2. Web Server는 클라이언트의 요청(Request)을 WAS에 보낸다.
3. WAS는 관련된 Servlet을 메모리에 올린다.
4. WAS는 web.xml을 참조하여 해당 Servlet에 대한 Thread를 생성한다. (Thread Pool 이용)
5. HttpServletRequest와 HttpServletResponse 객체를 생성하여 Servlet에 전달한다.
     5-1. Thread는 Servlet의 service() 메서드를 호출한다.
     5-2. service() 메서드는 요청에 맞게 doGet() 또는 doPost() 메서드를 호출한다.
6. doGet() 또는 doPost() 메서드는 인자에 맞게 생성된

    적절한 동적 페이지를 Response 객체에 담아 WAS에 전달한다.
7. WAS는 Response 객체를 HttpResponse 형태로 바꾸어 Web Server에 전달한다.
8. 생성된 Thread를 종료하고, HttpServletRequest와 HttpServletResponse 객체를 제거한다.

 

차이점

따라서 Web Server와 WAS의 차이점을 정리하면 다음과 같다.

WAS는 웹 애플리케이션의 비즈니스 로직과 데이터 처리를 담당하여

Web Server는 정적인 웹 리소스를 서비스한다.

 

WAS는 웹 서버의 기능도 가지고 있을 수 있으나,

보다 복잡하고 고급 기능을 제공하는 애플리케이션 서버이다.

웹 서버는 주로 리버스 프록시로 동작하여 요청을

WAS로 전달하거나 로드 밸런싱, 캐싱 등의 역할을 수행한다.

WAS와 Web Server는 종종 함께 사용되어

웹 애플리케이션을 제공하는데 필요한 기능을 모두 제공한다.

 

간단하게 정리하면 Web 서버는 정적 리소스를 제공,

WAS는 애플리케이션 로직까지 실행할 수 있다고 정리할 수 있다.

하지만 Web 서버도 프로그램을 실행하는 기능을 포함하고

WAS도 웹 서버의 기능을 제공하기 때문에 이 둘의 차이가 애매하게 느낄 수 있다.

명백한 차이가 있다고 하면 서블릿 컨테이너의 유무 차이라고 할 수 있고,

WAS는 애플리케이션 코드를 실행하는데 더 특화되어 있다고 할 수 있다.

 

 

참고자료

https://velog.io/@jinyeong-afk/%EA%B8%B0%EC%88%A0-%EB%A9%B4%EC%A0%91-WSWeb-Server%EC%99%80-WASWeb-Application-Server%EC%9D%98-%EC%B0%A8%EC%9D%B4

https://hstory0208.tistory.com/entry/Web%EA%B3%BC-WAS%EB%9E%80-%EC%9B%B9-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%9D%98-%EA%B5%AC%EC%A1%B0%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

https://story.pxd.co.kr/1647

https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

https://velog.io/@developerjun0615/WEB-WAS-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C