웹 서버와 WAS의 차이 (Web Server, Web Application Server)

웹 서버(Web Server)는 HTTP 요청을 받아 HTML, 이미지, 자바스크립트(JavaScript) 파일 같은 정적 자원을 그대로 응답하는 소프트웨어이고, WAS(Web Application Server)는 애플리케이션 코드를 실행해 데이터베이스 조회와 비즈니스 로직 처리를 거친 동적 응답을 만들어 내는 소프트웨어다. 엔진엑스(Nginx)와 아파치(Apache)가 전자의 대표이고 톰캣(Tomcat)이 후자의 대표다. 실무에서는 두 계층을 겹쳐 배치해 정적 처리와 동적 처리를 분담시키는 구조가 표준이다.

정적 콘텐츠와 동적 콘텐츠

정적 콘텐츠는 누가 언제 요청해도 같은 내용이 반환되는 파일이다. 로고 이미지, CSS, 빌드된 자바스크립트 번들이 여기에 속하며, 디스크의 파일을 읽어 보내기만 하면 되므로 처리 비용이 매우 작다. 동적 콘텐츠는 요청자와 요청 시점, 파라미터에 따라 내용이 달라지는 응답이다. 로그인한 사용자의 주문 내역 페이지나 JSON(JavaScript Object Notation)을 반환하는 API 응답이 그 예로, 코드 실행과 데이터베이스 접근이 필요해 비용이 크다. 웹 서버는 전자를 빠르게 흘려보내는 데 특화되어 있고, WAS는 후자를 만들어 내는 실행 환경, 즉 스레드 풀(Thread Pool), 데이터베이스 커넥션 풀(Connection Pool), 트랜잭션과 세션 관리 기능을 갖추고 있다. 자바(Java) 진영에서는 서블릿(Servlet) 컨테이너인 톰캣이 WAS 역할을 하며, 스프링 부트(Spring Boot)는 톰캣을 내장해 애플리케이션 하나로 실행되게 만든 형태다. 참고로 정적 파일 전송은 WAS도 할 수 있지만 웹 서버만큼 효율적이지 않고, 반대로 웹 서버는 애플리케이션 코드를 실행하지 못한다는 것이 역할의 경계다.

왜 웹 서버를 WAS 앞에 두는가

WAS 혼자서도 서비스는 가능하다. 그런데도 웹 서버를 앞단에 두는 이유는 여러 가지다. 첫째, 부담 분리다. 정적 요청을 웹 서버가 끊어 주면 WAS는 비싼 동적 처리에만 자원을 쓸 수 있다. 둘째, 리버스 프록시(Reverse Proxy)와 로드 밸런싱(Load Balancing)이다. 웹 서버가 요청을 받아 뒤의 여러 WAS 인스턴스에 분배하면 수평 확장과 무중단 배포가 가능해지고, 특정 WAS가 죽어도 나머지로 서비스를 잇는 장애 격리(Failover)가 된다. 셋째, 보안이다. WAS와 내부 구조를 외부에서 감추고, TLS(Transport Layer Security) 암호화 처리를 웹 서버가 대신 끝내는 TLS 종료(TLS Termination)로 WAS의 연산 부담을 던다. 넷째, 부가 기능이다. 응답 압축, 캐싱, 요청 제한, 접근 로그 같은 공통 기능을 애플리케이션 코드 밖에서 일괄 처리할 수 있다. 이런 이유로 전형적인 구성은 다음과 같은 계층이 된다.

클라이언트
  -> (CDN: 정적 자원 캐시)
  -> 웹 서버 (Nginx: TLS 종료, 정적 파일, 리버스 프록시)
  -> WAS 여러 대 (Tomcat: 애플리케이션 실행)
  -> 데이터베이스