이 두 단어는 이전 글인 Servlet의 WAS를 조사하며 나온 단어들이다. WAS는 클라이언트와 웹서버를 연결할 수 있도록 도와주는 미들웨어로 서버와 함께 동작한다고 배웠다. 그럼 Tomcat과 Nginx 둘 모두 서버를 도와주는 미들웨어라는 뜻인데.. 이것이 무엇인지 자세히 알아보자.
WS(Web Server)
둘 모두 서버를 도와주는 친구들이라고 했으니 먼서 웹서버가 무엇인지 살펴본다.
개념
웹 페이지를 클라이언트에게 HTTP나 HTTPS를 이용해 필요한 HTML 문서 혹은 데이터를 전달해주는 기능을 하는 컴퓨터 프로그램.
→ 정적 데이터를 제공해주는 서버.
역할
정적 데이터를 다루는 만큼 당연히 정적 데이터 처리가 주요 역할이다.
이는 곧 단순히 웹 리소스를 클라이언트로 전송하고, 클라이언트로 받은 정보를 저장하거나 처리한다는 뜻이다.
하지만 우리는 정적인 데이터만을 사용하지 않는다.
이를 보조하기 위해 나온 것이 이전에 공부한 WAS 이다.
대표적인 WS의 종류엔 Apache, Nginx 등이 있다고 한다.
WAS(Web Application Server)
둘의 차이를 비교하기 위해 기존에 작성한 것을 가져왔다.
개념
인터넷 상에서 HTTP 프로토콜을 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어, 주로 동적 서버 컨텐츠를 수행하는 것으로 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행된다.
→ 웹 서버와 웹 컨테이너가 합쳐져 서버 만으로 처리하기 어려운 비즈니스 로직들을 처리할 수 있도록 해주는 프로그램이다. 이때 JSP, Servlet 등을 제공하기 때문에 웹 컨테이너, 서블릿 컨테이너 등으로 불리기도 한다.
역할
- 프로그램 실행 환경과 DB 접속 기능 제공
- 여러 개의 트랜잭션 관리 기능
- 업무 처리하는 비즈니스 로직 수행
여기서 중요한 부분은 개념에서 보이듯 웹 서버와 웹 컨테이너가 합쳐지면서 동적인 데이터 처리가 가능하다는 것이다.
또한 동적인 것 만이 아니라 정적인 것도 가능하다.
대표적인 WAS의 종류엔 Tomcat, JBoss 등이 있다.
WS와 WAS의 사용 이유
WAS의 설명에서 볼 수 있듯이 WAS는 정적인 데이터와 동적인 데이터 모두 처리 가능하다. 그런데 왜 WS를 쓰는 것일까?
- 기능 분리로 서버 부하 방지
- WAS는 DB 조회나 다양한 로직 처리, WS는 단순 정적 데이터 처리를 통한 용도 분리로 동적으로 빠르게 처리해야 하는 WAS의 부담을 줄인다.
- 유지보수 및 확장
- 1번의 연장선으로 볼 수 있는데 기능 분리를 했다면 각 기능에 따른 유지보수를 할 수 있다는 뜻이므로 이에 강점이 생긴다. 또한 각 역할이 정해졌으니 필요한 기능 추가에 대한 부담도 감소할 것이다.
- 보안 강화
- SSL에 대한 암호화, 복호화 처리에 웹 서버를 사용 가능하다. 이때 포트가 WAS에 직접 연결된다면 중요 설정 파일들이 노출될 수 있다. 만약 WS와 WAS를 같이 사용하면 서버와 WAS에 접근하는 포트번호가 달라 WAS에 들어오는 포트에 방화벽을 만들어 보안에 강점을 챙길 수 있다.
- 여러 웹 애플리케이션 서비스 가능.
- 하나의 서버에 PHP, Java 등을 같이 사용 가능하다.
위의 내용 중에서 가장 중요한 점은 서버 부하 방지의 기능인데 이 기능을 이해하기 위해서는 리버스 프록시(Reverse proxy)서버를 알아야 한다.
리버스 프록시 서버(Reverse proxy server)
프록시 서버(proxy server)
클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다.
- 프록시: 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을
→ 그 중계 기능을 하는 것이 프록시 서버
포워드 프록시 서버(forward proxy server)
위에서 말하는 프록시 서버는 포워드 프록시 서버를 의미한다.
프록시 서버는 그림처럼 클라이언트 앞에 놓여 있다. 그림을 보면, 클라이언트가 인터넷 웹 서버에 요청을 보내면 중간에서 그 요청을 프록시가 가로챈다.
이후 프록시 서버는 해당 요청을 웹 서버에게 다시 보내고 웹 서버에 받은 응답을 다시 클라이언트에게 전달한다.
이는 해당 기관에 속한 사람들이 웹사이트에 직접적으로 방문하는 것을 방지하고, 특정 사이트에 접속하는 것을 금지하고, 사용자의 정보를 감추기 위해 사용된다.
리버스 프록시 서버(reverse proxy server)
리버스 프록시 서버는 아래 그림처럼 웹 서버 앞에 놓여 있다. 포워드 프록시 서버는 클라이언트 앞에 놓여 있는 반면, 리버스 프록시는 웹 서버 앞에 놓여 있는 것이다.
Apache
WS를 설명할 때 이에 대한 예시로 Apache를 들었다. Apache라는 이름을 많이 들어봤을 텐데 그 이유는 Apache라는 기업은 다양한 영역에서 오픈 소스 소프트웨어를 만드는 비영리단체 이기 때문이다.
Maven, Groovy 등을 비롯해 여기서 말할 Apache HTTP Server도 포함된다.
개념
WS의 대표적인 소프트웨어로 위의 설명처럼 Apache HTTP Server라고 불리기도 하며 HTTP WS이다.
장점
오픈 소스로 운영되는 만큼 굉장히 다양하고 기능적인 면에서 우수하다고 한다. 또한 구축이 쉽다는 점 때문에 많이 사용한다.
단점
하지만 Apache 자체가 무겁다는 단점과 더불어 C10K 문제가 있었다.
- C10K
- 커넥션 마다 프로세스를 할당하기에 메모리 부족 발생
- 확장성이라는 장점이 프로세스의 리소스 양을 늘려 무거운 프로그램이 됨
- 많은 커넥션 요청이 들어오면 프로세스 생성으로 인한 CPU 부하가 높아짐
이런 문제를 보완하기 위해 나온 소프트웨어가 NginX 이다.
Nginx
개념
Apache와 마찬가지로 오픈소스 WS이며 고성능과 확장 가능한 웹 응용 프로그램을 제공하기 위해 설계된 소프트웨어이다.
특징
- 기본 아파치의 Process Driven 동작 방식에서, Event Driven 이라는 방식을 통해 요청을 처리해주게 되었다.
- 이벤트 발생에 따라 작업을 진행하는 구조. 이 구조는 아래에서 설명한다.
- 리버스 프록시 사용 가능
- 위의 프록시 서버 설명과 같이 프록시가 클라이언트와 있는 것이 아니라 웹 서버와 같이 있는 것이다.
- 인터넷과 백엔드 사이의 서버 영역으로서 매개체 역할을 맡을 수 있다.
- 로드 밸런싱, 캐싱 서버가 가능하고 보안 효과도 있다.
- 로드 밸런싱: 애플리케이션을 지원하는 리소스 전체에 네트워크 트래픽을 균등하게 배포하는 방법.
- SSL 지원
- 보안 프로토콜을 지원하며 신원 인증이 가능해진다.
- 데이터 압축
- 클라이언트가 보내는 요청이 텍스트일 경우, gzip을 사용해 해당 데이터를 압축 시킬 수 있다.
구조
- 하나의 마스터 프로세스와 여러 개의 워커 프로세스로 구성된다.
- 실제 동작을 하는 것은 워커 프로세스이다.
- 커넥션은 정해진 시간(Keep Alive 시간) 만큼 유지되는데, 이렇게 커넥션이 형성되었다고 해서 커넥션 하나만 담당하지는 않는다.
-
형성된 커넥션에 아무런 요청이 없으면 새로운 커넥션을 형성하거나 이미 만들어진 다른 커넥션으로부터 들어온 요청을 처리한다.
→ NginX는 이런 커넥션 형성과 제거, 새로운 요청을 처리하는 것을 이벤트(event) 라고 부른다.
-
- 이벤트들은 큐 형식으로 워커 프로세스에 전달되고 비동기 방식으로 차례차례 대기한다. 워커 프로세스는 Thread 하나로 이벤트를 꺼내서 처리한다.
- 요청 하나가 오래 걸릴 경우 Thread Pool을 만들어 따로 수행한다. 이 과정이 있기에 효율적 처리가 가능해진다.
- 워커 프로세스 수는 CPU 코어 수만큼 생성하여 코어가 담당하는 프로세스를 바꾸는 횟수를 줄여 스위칭 횟수를 줄인다.
장점
- 이벤트 기반 구조의 효율성
- 단일 스레드로 여러 연결을 처리
단점
- Apache를 확장한 개념이다 보니 WS를 따른다. 이에 따라 동적 데이터 처리가 기본적으론 불가능하다.
- 따라서 동적 컨텐츠에 대한 요청 처리는 프로세스 속도를 저하시키는 요인이 된다.
이런 점 때문에 WAS의 동적 컨텐츠 처리를 할 수 있는 서버가 필요했고 Tomcat이 나왔다.
Tomcat
개념
Tomcat도 위의 서버 프로그램과 마찬가지로 Apache에서 개발한 프로그램이지만 다른 것과 달리 WAS로 동작한다. 즉, 동적인 데이터를 처리할 수 있는 서버이다.
또한 WAS로서 Java Servlet과 JSP의 실행환경을 제공해서 동적 웹페이지를 생성하는 컨테이너의 기능을 담당한다. 여기서 DB 연결 및 데이터 조작, 타 응용프로그램과의 상호작용 등이 가능하다.
→ 이 부분이 Tomcat을 쓰는 가장 큰 이유이지 않을까 한다.
특징
- 자체적으로 보유하고 있는 내부 웹 서버와 함께 독립적으로 사용할 수 있다
- Apache나 IIS 등 다른 웹 서버와 함께 사용하는 것도 가능하다.
- 톰캣을 실행하려면 JRE1.1 이상의 자바 런타임 환경이 필요하다.
장점
- Java 기반의 웹 애플리케이션을 실행하고 관리하기 쉽다.
- 오픈소스로 무료 사용 가능하다.
- 자유로운 다운로드 및 사용이 가능하다.
- Servlet 컨테이너의 표준을 준수하여 다양한 웹 애플리케이션과 호환성이 좋다.
→ 위의 장점들 덕분에 호환성을 높일 수 있고 개발과 배포가 쉬워진다.
- 경량화 되어 있어서 시스템 자원 사용량이 적다.
- 이 또한 빠르게 배포 및 실행이 가능하도록 도와준다.
단점
- Java 외의 언어를 사용한 웹 애플리케이션에는 적합하지 않다.
- 대규모 웹 서비스에는 다른 WAS에 비해 성능이 떨어질 수 있다.
조합
WS와 WAS를 말하며 이 두가지 서버를 섞어 사용한다고 하였다. 그렇다면 그럼 이때 우리가 사용해야 하는 WS는 무엇이고 WAS는 무엇일까.
지난 Spring Boot 게시물을 기억할 지 모르겠다. 이때 Spring Boot에는 Tomcat이 기본으로 깔려 있어 웹 서버를 구현할 때 간편하다고 했었다. 즉, Tomcat은 이미 호환이 잘 되어 있고 오히려 다른 WAS를 사용 하는 것이 추가 설정이 필요한 상황이 된다.
따라서 Tomcat은 고정하고 간다면 Apache와 NginX의 차이에 의해 선택이 갈릴 것이다.
Apache + Tomcat
- 초창기에 만들어졌기에 다양한 가이드와 라이브러리들이 나와있다.
- NginX에 비해 무겁고 느리다.
Nginx + Tomcat
- 가볍고 성능이 좋다.
- Apache 보다 최신의 서버이기 때문에 비교적으로 정보가 부족하다.
→ 가볍고 고성능이 필요한 환경이라면 NginX와의 융합을 / 다양한 환경과 검증된 기능들이 필요하다면 Apache를 사용하는 것이 좋다.
결론
WS는 정적 데이터를 다루는 서버, WAS는 WS에 더해 동적인 데이터를 다룰 수 있는 서버이다 .
WS에는 Apache, NginX가 있고 WAS에는 Tomcat이 있다.
NginX는 Apache의 성능을 올리고자 개발되어 확실히 더 좋은 성능을 보이고 있으나 기존의 검증되고 다양한 라이브러리를 활용하기 위해서 Apache를 사용하는 경우도 있다.
