웹 서버(Web Server)와 WAS(Web Application Server)란 ?
웹 서버(Web Server)란?
웹 서버는 클라이언트(주로 웹 브라우저)로 부터 요청을 받아 정적 컨텐츠(HTML, CSS, JavaScript, 이미지 등)를 제공하는 역할이다.
주요 기능
- HTTP 요청 처리
- 정적 리소스 제공
- 요청에 따라 적절한 컨텐츠 반환
예시
- Apache HTTP Server
- Nginx
- IIS(Internet Information Service)
한계점
동적 컨텐츠(예 : 사용자 입력을 처리하거나 데이터베이스와 상호작용) 제공이 어렵다.
WAS(Web Application Server)란?
WAS는 동적인 컨텐츠를 처리하는 서버로, 애플리케이션 로직 실행을 담당한다. 클라이언트의 요청을 처리하기 위해 데이터베이스와 상호작용하거나 비즈니스 로직을 수행한 뒤 결과를 반환한다.
주요 기능
- 동적 컨텐츠 생성
- 애플리케이션 로직 실행
- 데이터베이스와의 통신
예시
- Apache Tomcat
- JBoss/WildFly
- WebSphere
- Spring Boot 내장 WAS (예: 톰캣)
추가 기능
웹 서버와 WAS의 차이
구분 | 웹 서버 | WAS |
---|
제공 컨텐츠 | 정적 컨텐츠 (HTML, CSS 등) | 동적 컨텐츠 (애플리케이션 로직 처리) |
주요 역할 | 요청 분배 및 정적 리소스 제공 | 비즈니스 로직 처리 및 데이터 연동 |
대표 서버 | NginX, Apache | Tomcat, WebLogic |
주요사용 사례 | 정적 웹 사이트, 리버스 프록시 서버 | API 서버 |
웹 서버와 WAS의 협업 구조
웹 서버와 WAS는 함께 사용되는 경우가 많다.
- 클라이언트 : 웹 브라우저를 통해 서버로 요청을 보낸다.
- 서버 : 정적 리소스를 제공하거나, 동적 요청은 WAS로 전달한다.
- WAS : 비즈니스 로직을 처리하고, 필요한 데이터를 데이터베이스에서 가져온다.
- 웹 서버 : WAS로부터 받은 응답을 클라이언트에 반환한다.
예시 아키텍처
- Nginx(웹 서버) + Tomcat(WAS)
- Apache(웹 서버) + Spring Boot 내장 WAS
웹 서버와 WAS를 분리하는 이유
성능 향상
정적 컨텐츠는 웹 서버에서 처리하고, 동적 컨텐츠는 WAS가 처리하도록 분리하면 효율적이다.
확장성
트래픽이 증가할 경우 웹 서버와 WAS를 각각 독립적으로 확장 가능하다.
보안 강화
웹 서버를 리버스 프록시로 활용하여 WAS를 외부에 직접 노출하지 않도록 설정할 수 있다.
결론
웹 서버와 WAS는 각자의 장점을 가지고 있으며, 현대 웹 환경에서 주로 사용된다. 적절한 설정과 아키텍처 설계를 통해 성능과 안정성을 극대화할 수 있다.
나는 웹서버를 따로 사용하지 않는데 ?
Spring Boot와 같은 내장 톰캣(Web Application Server)를 사용하는 경우, 웹 서버와 WAS가 하나의 프로세스내에서 동작한다. 이 경우 별도의 외부 웹 서버(Nginx, Apache 등)를 사용하지 않아도 웹 요청을 처리할 수 있다.
내장 톰캣(Spring Boot)에서의 동작 방식
내장 톰캣 역할
Spring Boot는 애플리케이션에 톰캣(WAS)를 내장하고 있어, 정적 리소스와 동적 리소스 모두 처리할 수 있다.
정적 리소스 처리
/static, /public, /resources 디렉토리에 있는 정적 파일(HTML, CSS, JavaScript 등)을 직접 클라이언트에 전달한다.
정적 컨텐츠 제공 역할은 외부 웹 서버가 아닌 내장 톰캣이 수행한다.
동적 리소스 처리
REST API 요청 또는 데이터베이스 연동과 같은 동적 작업은 Spring MVC와 같은 애플리케이션 로직을 통해 처리된다.
내장 톰캣이 HTTP 요청을 수신하고 이를 DispatcherServlet(Spring MVC)으로 전달한다.
내장 톰캣 사용 시 요청 흐름
요청 흐름
-
클라이언트 요청
- 클라이언트(브라우저, REST 클라이언트 등)가 HTTP 요청을 전송한다.
-
톰캣이 요청 수신
- 내장 톰캣이 기본적으로 설정된 포트(예 : 8080)에서 요청을 수신한다.
-
정적 리소스 처리
- 요청한 리소스가 /static, /public, /resources 등에 존재하면, 톰캣이 해당 정적 파일을 직접 반환한다.
- 예 : /index.html 요청 시 /src/main/resources/static/index.html 파일을 반환
-
동적 요청 처리
- 요청이 정적 리소스가 아닌 경우, 톰캣이 DispatcherServlet(Spring MVC 핵심 컴포넌트)으로 요청을 전달한다.
- DispatcherServlet은 Controller와 Service를 거쳐 비즈니스 로직을 실행하고 응답을 생성한다.
- 예 : /api/products 요청 시 Controller에서 데이터를 조회하여 JSON 응답 반환
-
응답 반환
- 톰캣이 처리 결과를 HTTP 응답으로 클라이언트에 반환
외부 웹 서버 없이 내장 톰캣만 사용하는 이유
장점
-
단순한 배포
- 애플리케이션과 톰캣이 하나의 실행 파일로 통합되어 별도 웹 서버 설정이 필요 없다.
- JAR 파일만 실행하면 애플리케이션과 웹 서버가 함께 작동.
-
개발 편의성
- 내장 톰캣은 Spring Boot에서 자동으로 설정되므로, 별도 WAS 설치 및 설정 작업이 필요 없다.
-
효율적인 리소스 사용
- 내장 톰캣은 애플리케이션과 동일한 JVM에서 실행되어 리소스를 공유한다.
-
배포 아키텍처 단순화
- 별도의 외부 웹 서버를 구성할 필요가 없어 배포 아키텍처가 단순하다.
단점
-
정적 컨텐츠 처리 성능 제한
- Nginx, Apache 같은 전문 웹 서버에 비해 정적 컨텐츠 처리 성능이 떨어질 수 있다.
- 특히, 많은 정적 리소스를 제공하거나 CDN(Content Delivery Network)을 사용하는 경우 한계가 있을 수 있다.
-
확장성 부족
- 내장 톰캣은 단일 프로세스이기 때문에 트래픽이 급증하면 부하 분산이 어렵다.
- 리버스 프록시(Nginx, Apache)를 추가하면 해결 가능.
결론
내장 톰캣은 작은 규모의 애플리케이션이나 빠른 개발에 적합하다. 외부 웹 서버를 추가하지 않고도 간단히 작동하므로 개발 초기 단계에서 유용하다.
그러나 대규모 트래픽 처리나 복잡한 정적 리소스 관리가 필요한 경우, 외부 웹 서버를 추가해 리버스 프록시와 같은 구조로 확장하는 것이 좋다.
리버스 프록시
리버스 프록시는 클라이언트와 서버 사이에 위치해 요청과 응답을 중계하는 역할을 하는 서버이다. 이를 통해 클라이언트는 실제 서버와 직접 통신하지 않고 리버스 프록시를 통해 간접적으로 통신하게 된다.
왜 리버스 프록시를 쓰는가
1. 보안 강화
- 클라이언트는 실제 서버의 IP 주소를 알지 못하므로, 서브를 직접 공격하기 어렵다.
- 리버스 프록시가 방패 역할을 한다.
2. 로드 밸런싱
- 리버스 프록시가 여러 서버로 요청을 분산시켜서, 하나의 서버에 과부하가 걸리지 않게 한다.
- 예를 들어, Nginx 리버스 프록시는 여러 서버에 트래픽을 나누어 분산 처리한다.
3. 정적 리소스 처리
- HTML, CSS, JavaScript 같은 정적 파일은 리버스 프록시(Nginx, Apache)가 빠르게 처리하고, 동적 요청(API 등)만 실제 서버로 보낸다.
4. SSL(HTTPS) 처리
- 리버스 프록시가 HTTPS 인증서를 관리하고 암호화된 통신을 처리한다. 실제 서버는 HTTP만 처리하므로 더 간단해진다.
5. 캐싱
- 자주 요청되는 데이터를 리버스 프록시에 저장해 클라이언트 요청이 더 빠르게 응답한다.(예 : 이미지 파일)
리버스 프록시 vs 포워드 프록시
- 리버스 프록시 : 클라이언트를 대신해 서버와 통신 (서버를 보호)
- 포워드 프록시 : 서버를 대신해 클라이언트가 통신 (클라이언트를 보호)