Web Server 왜 사용해야해?

hwstar·2024년 6월 25일

web server가 하는 일에 대해 생각해 보면 대표적으로 2가지가 생각난다.
1. 정적 요청이 들어오면 웹 서버는 클라이언트에게 정적 리소스를 응답해 준다.
2. 동적 요청이 들어오면 WAS로 다시 요청한다.

궁금증

2번에서 " WAS로 동적 요청을 다시 할 것이라면 그냥 정적,동적 요청을 둘 다 처리할 수 있는 WAS 하나만 사용하면 되는 게 아닌가? " 라는 생각이 든다.
( 스크립트 언어의 경우 web server + CGI 조합으로도 동적 요청 처리가 가능은 하다. php,nginX+CGI )

Client -> WAS -> DB
이러한 이유에서 프로젝트를 할 때 WAS 서버만 사용해서 개발했던 것 같다.

Client -> Web Server -> WAS -> DB
하지만 동적 처리가 필요한 곳에서 WAS 서버만을 사용해서 서비스하고 있지 않고 위와 같이 구성하고 있다.
직관적으로 생각해 보았을 때 정적,동적 리소스를 분리해서 관리하고 요청과 응답을 받을 수 있다는 것을 장점으로 생각해 볼 수 있다.

두 개 서버 조합의 장점이 이것뿐만이 아닐 것이라고 생각하여 검색해 본 결과 생각보다 여러 이유가 존재했다.

web server + WAS 조합의 장점
1. 정적, 동적 요청에 각 서버가 최적화 되어있으므로 처리의 효율성이 증가
2. WAS가 동적 요청만 처리하면 되므로 서버 부하 감소
3. 웹 애플리케이션의 성능과 보안 향상 (reverse proxy, load balance)

1. 정적, 동적 요청에 각 서버가 최적화 되어있으므로 처리의 효율성이 증가

Web Server
주로 정적인 리소스(HTML, CSS, JavaScript, 이미지)를 빠르게 제공하기 위해 설계되었다.
단순히 파일 시스템에 저장된 리소스들을 읽어서 제공하므로 처리 속도가 빠르다.
또한 서버 입장에서 동일한 요청이 반복될 때 디스크 I/O를 줄이고 메모리에서 직접 파일을 제공하는 캐싱을 지원한다.
WAS (Web Application Server)
주로 동적 콘텐츠를 생성하고 복잡한 비지니스 로직, DB와의 상호작용하는 일에 최적화 되어있다. 단순히 파일 읽기와 다르게 코드 실행, 다양한 연산을 수행하는 것이 가능하다.

2. WAS는 동적 요청만 처리하면 되므로 서버 부하 감소

WAS는 DB 조회 및 애플리케이션 로직 처리에 집중해야 한다.
분리하지 않는다면 WAS는 정적, 동적 요청을 모두 처리해야 하게 되는데 이는 서버에 부하가 발생하여 처리 속도가 느려질 것이다.

만약에 WAS에 요청이 크게 증가하면 장애가 발생할 수 있고 리소스 전달 불가 상태로 사용자에게 불편함을 주게된다.
장애로 인한 WAS를 재시작 해야하는 경우에 앞단에 web server가 있다면 web server는 WAS으로의 요청을 차단한 후 사용자에게 서버에 문제가 있음을 html 파일만으로도 알릴 수 있게 되어 피드백을 줄 수 있게 된다.

혹은 동적인 요청이 많아지면 WAS를 증설하여 운영하는것도 가능하다. 이러한 방식을 'scale out' 이라고 부르는데 요즘 클라우드 환경에서는 이것을 사용하여 더 쉽게 트래픽에 유연하게 대응할 수 있도록 해준다.

3. 웹 애플리케이션의 성능과 보안 향상

web server 앞쪽에서 reverse proxy 설정을 해놓으면 성능과 보안 측면에서 이점이 크다.

client의 요청이 들어오면 reverse proxy가 web server의 중간에 위치하여 client 대신 적당한 서버에 요청하게 되고 해당 서버로부터 응답을 받게 된다.
client는 어떤 서버에 요청했는지 모른다. 접속 서버의 IP 주소를 노출하지 않고 client는 요청만 하는 것으로 보안에 이점이 있다.
여기에서 적당한 서버에 요청한다고 하였는데 이는 대량의 트래픽이 특정 서버에 몰리지 않게 트래픽을 분산시키는 로드 밸런싱을 사용한 것을 말한다.
이를 통해 서버 과부하를 방지하고 응답 속도를 개선하며 가용성을 높일 수 있게 된다.
보통 client와 server간에 통신을 할때 서버 측에서 SSL을 사용하여 암호화, 복호화를 하는 경우가 많다.
이를 reverse proxy가 대신 암호화,복호화를 해주면 서버 측의 부하도 줄이고 SSL 인증서를 중앙에서 관리할 수 있게 된다.

이러한 아키텍처의 이점을 가져가기 위해 사용되는 웹 서버에는 어떤 것들이 있을까?

대표적인 Web server의 종류

Apache
- Prefork MPM(멀티 프로세스 모듈)
  : 각 요청마다 프로세스 생성하지 않고 미리 만들어놓고 사용하는 방식
- Worker MPM
  : 각 요청마다 스레드를 할당하여 작업하는 방식
- 안정성 : 오랫동안 사용해 오며 다양한 운영 환경에서의 신뢰성으로 검증된 모듈들을 제공
Nginx
- 비동기 event-driven 방식
  : 고정된 프로세스를 생성하고 event-handler를 통해 비동기 방식으로 처리
- 성능과 가벼움
  : Apache에 비해 적은 리소스를 사용하여 높은 동시 접속 처리 가능

Apache는 프로세스,스레드 생성 비용이 들어 대용량 요청에서 한계를 보이는데 Apche 2.4 버전 이후로는 Event MPM을 지원하면서 nginx와 유사한 기능을 제공한다. 이보다 더 많은 종류가 있고 각 웹서버는 고유의 장단점을 가지고 있다.
그러므로 특정 상황이나 요구 사항에 따라 조건을 따져보고 선택하는 것이 좋을것이다.

결론

웹 서버와 WAS를 조합하여 사용하는 아키텍처는 각 서버의 특성과 장점을 살려 효율성과 성능, 보안을 극대화할 수 있다. 웹 서버는 정적 리소스를 빠르게 제공하고, WAS는 동적 요청과 비즈니스 로직 처리에 집중하여 처리한다. 이를 통해 서버의 부하를 분산시키고, 장애 발생 시에도 빠른 대응이 가능해지게된다. 또한, 리버스 프록시와 로드 밸런싱을 통해 보안과 성능을 향상시키고, 유연한 트래픽 관리가 가능하다. Apache는 다양한 모듈과 안정성을 바탕으로 오랜 기간 신뢰를 받아왔고, Nginx는 비동기 이벤트 기반 처리 방식으로 높은 성능과 효율성을 제공한다.

결국, 웹 서버와 WAS의 조합은 현대 웹 애플리케이션에서 높은 성능과 안정성을 보장하기 위한 필수적인 아키텍처라고 생각했다.
이를 통해 사용자에게 빠르고 안정적인 서비스를 제공할 수 있게되고, 향후 트래픽 증가에도 유연하게 대응할 수 있는 인프라를 구축할 수 있다.