WAS (웹 애플리케이션 서버)
A Web Application Server is a server program in a computer on a distributed network that provides the business logic for an application program.
— 엔터프라이즈 시스템 디자인 패턴 가이드라인의 WAS 공식 정의
정적 파일만 기계적으로 실어 나르는 웹 서버 뒷단에 은밀하게 숨어서, 로그인 상태를 판단하고 데이터베이스를 탈탈 털어 사용자 맞춤형 화면을 실시간으로 조립해 주는 진짜 백엔드의 지배자. 사용자가 1만 명만 넘어가도 DB 응답 속도 병목과 가비지 컬렉션 동결 크리티컬이 겹치며 서버가 굳어버리는데, 상사로부터 '장비 사양 높이기 전에 코드 튜닝부터 하라'는 사형 선고를 들을 때의 절망감은 엄청나다.(...)
1. 개요
웹 애플리케이션 서버(Web Application Server). 흔히 약자로 WAS로 지칭된다. 클라이언트의 브라우저가 보낸 HTTP 요청을 분석하여, 데이터베이스 조회나 다양한 연산 비즈니스 로직을 처리한 뒤 그 결과를 동적으로 변형된 HTML이나 JSON 포맷으로 생성해 반환하는 미들웨어 서버이다. 단순 정적 페이지(이미지, CSS 등)만 제공하는 기존의 웹 서버(Web Server)와 엄격히 구분되는 개념으로, 현대적인 쇼핑몰, 은행, SNS 등 살아 움직이는 고도화된 인터랙티브 웹 서비스를 구동하기 위한 핵심 백엔드 구동 엔진 역할을 맡는다.
2. 웹 서버(Web Server)와의 영원한 전쟁과 공존
초보 개발자들이 가장 많이 헤매는 영역이 바로 웹 서버(Nginx, Apache 등)와 WAS(Tomcat, JEUS 등)의 차이점이다. 웹 서버는 사용자가 '강아지.jpg 보여줘'라고 보낸 요청을 기계적으로 하드디스크에서 꺼내 던져주는 단순노동자에 불과하다. 반면 WAS는 사용자가 입력한 조건과 로그인 세션 상태를 검증하고, RDBMS에 쿼리를 전송해 데이터를 긁어와 화면을 동적으로 연산 및 조립하는 고도로 훈련된 지식 노동자이다.1 실무에서는 성능 극대화를 위해 이 둘을 완벽히 격리하여 배치하는 구조를 선호한다. 프론트 아일랜드 최전선에 가벼운 웹 서버(Nginx)를 배치해 정적 파일을 0.001초 만에 뿌리고 리버스 프록시(Reverse Proxy) 설정을 통해 무거운 연산이 필요한 API 요청만 쏙 골라 뒷단의 WAS로 중계 전송하는 부하 분산 아키텍처를 완벽하게 구사하는 것이 현대 인프라 설계의 오랜 정석이다.
3. 서버의 한계: 멀티스레드 동시성과 커넥션 풀
WAS의 성능과 운명을 가르는 결정적인 영역은 동시 처리 모델과 데이터베이스 커넥션 풀(DBCP) 튜닝에 있다. 자바 진영의 대표적인 WAS인 톰캣(Tomcat) 등은 들어오는 요청 하나마다 독립된 스레드(Thread)를 하나씩 붙여서 처리하는 멀티스레딩 모델을 채용해 왔다. 하지만 무한정 스레드를 생성할 수는 없기 때문에, 가용한 스레드를 수백 개 수준으로 묶어둔 '스레드 풀'과 미리 DB와 통신 통로를 뚫어놓는 '커넥션 풀'을 정교하게 세팅해야 한다.만약 접속자가 한순간에 몰려 커넥션 풀이 바닥나면 뒷단 사용자들은 무한 로딩 창을 보며 키보드를 부수게 된다.2 최근에는 자바 멀티스레드 오버헤드를 피하기 위해 비동기 단일 스레드 모델을 쓰는 Node.js 기반의 서버나 비차단 리액티브 프로그래밍을 지원하는 WebFlux 스택 등 가볍고 영리한 대안들이 나와 WAS 아키텍처의 트렌드를 맹렬히 뒤흔들고 있다.
4. Out Of Memory의 심연과 모니터링 수렁
4.1. java.lang.OutOfMemoryError: Java heap space
수많은 대기업 전산실과 백엔드 부서의 새벽잠을 확 깨우는 공포의 톰캣 에러 로그다. WAS가 동작하는 자바 가상머신(JVM)의 힙 메모리가 가득 차 더 이상 새로운 연산을 수행할 공간이 없을 때, 비명을 지르며 서버가 기절한다. 원인은 열어둔 데이터베이스 커넥션을 닫지 않고 방치하는 누수 코딩이거나, 메모리 가비지 컬렉터(GC)가 제때 쓰레기 수거를 완료하지 못해 발생하는 병목 등 참으로 다양하다. 이를 방지하겠다며 와탭(WhaTap)이나 제니퍼(Jennifer) 같은 수천만 원대 실시간 서버 성능 모니터링(APM) 툴의 그래프를 보며, 스레드가 굳어버리지 않았는지 24시간 실시간 관제를 도는 시스템 엔지니어들의 자조 가득한 모습은 가련한 IT 3D 업종의 생생한 풍경이 아닐 수 없다.(...)
5. 여담
- 오라클과 티맥스의 미묘한 자존심 대결: 과거 국내 공공기관이나 대형 금융사들은 미국의 거대 공룡인 오라클 웹로직(WebLogic)을 신주단지 모시듯 사용했으나, 국산 기업 티맥스소프트가 독자 개발한 WAS인 제우스(JEUS)가 특유의 공공 친화적 영업과 저렴한 라이선스로 공공 시장 안방을 대부분 국산화로 탈탈 털어버려 오랜 기술 자존심 전쟁을 일으켰다.
- 톰캣은 독자적인 웹 서버 기능도 있다: 많은 사람들이 톰캣(Tomcat)은 순수 WAS일 뿐 정적 웹서버 역할은 못 한다고 오해하지만, 실제로는 자체 웹 서버 엔진을 완벽하게 내장하고 있어 단독으로 정적 이미지 배포도 훌륭히 수행한다. 다만, 아파치나 엔지닉스에 비해 정적 파일 압축 전송 속도나 로드 밸런싱 편의성이 다소 투박해 여전히 웹서버 뒷단에 유폐당하는 처량한 신세를 면치 못하고 있다.
- CGI에서 Servlet으로의 생명 연장: 아주 먼 옛날 웹서버가 외부 연산 프로그램을 직접 켜서 결과를 받아오던 CGI(Common Gateway Interface) 시절에는, 요청 1개마다 무려 OS 프로세스 1개를 통째로 가동시키는 살인적인 오버헤드를 자랑해 서버가 툭하면 터져나갔다. 이에 자바 진영이 '프로세스가 아니라 가볍게 메모리 상의 스레드만 켜서 요청을 처리하자'며 서블릿(Servlet) 개념을 창안하며 오늘날 고성능 WAS의 초석을 다지게 되었다.