매일 반복적인 일상을 지루하게 보내던 중 예전에 같이 국비 학원에서 만났던 취준 중인 동기가 나에게 카톡이 왔다.
동기 : "너 혹시 WEB과 WAS의 차이가 뭔지 알아?"
나 : "음...? Web Server는 정적인 자원 관리하고 WAS는 동적인 자원 관리하는 차이 아닌가?"
예전에 나도 취준 할 때 뭔가 달달 외우고 다녔던 것 같은데 갑자기 확신이 없었던 걸까 답변을 시원하게 하지 못했다. '머리로는 이해하고 있지만 말로 설명을 못한다'라는 것을 나는 '잘 모른다'라고 판단한다. 이번에는 웹 서버와 WAS의 개념을 간단하게 복습하고 WAS의 구조를 좀 더 깊이 알아보겠다.
웹의 기본 구조 WEB과 WAS
외부에 검색하면 WEB과 WAS의 개념과 기능 등 자세하게 정리된 글들이 많으니 웹 서버와 WAS의 개념과 기능은 간단하게 정리만 하고 넘어가자.
Web Server
" 정적인건 나에게 맡겨! 야 잠깐만, 이건 WAS 네가 해줘~ "
웹 서버는 클라이언트에게 요청을 받으면 해당 요청을 판단하여 정적인 자원은 WAS를 거치지 않고 바로 응답해주고 동적인 자원은 WAS에 요청을 전달하여 WAS에서 받은 결과를 클라이언트에게 응답한다.
WAS (Web Application Server)
" 웹컨테이너 깨우고... 디비 조회도 하고... 로직도 처리하고... 됐다. 야 WEB 이거 받아넘겨~ "
WAS는 웹 컨테이너 또는 서블릿 컨테이너들의 구동 환경을 제공하고 컨테이너를 통해 비즈니스 로직을 처리하거나 DB 조회 등 동적인 자원을 제공한다. 또한 WAS는 Web Server의 기능도 수행 가능하다.
WEB과 WAS의 차이
현재 WAS의 웹 서버도 성능상 차이가 없는 정적인 자원 처리를 수행하고 있기 때문에 WEB웹 서버와 WAS의 명백한 차이는 웹 컨테이너가 있고 없고의 차이라고 말할 수 있다.
그렇다면 왜 굳이 WEB과 WAS를 분리했나?
웹 서버 + WAS인 WAS가 아무리 정적인 자원가 동적인 자원을 처리할 수 있다고 해서 대량의 데이터를 처리해야 하고 동시 요청 건 수도 많아지면 WAS도 부하가 걸리기 마련이다. 이러한 서버 부하 방지를 위해서 웹 서버와 WAS를 분리한다. 이렇게 분리된 웹 서버는 기존보다 훨씬 더 많은 기능을 수행한다. 또란 다중 WAS를 연결하여 서버 유지력을 향상할 수 있다. 대용량 웹 애플리케이션에서는 서버 내 트래픽이 증가하면서 부하로 인해 서버가 뻗게 되거나 하는 장애가 발생할 수 있는데 여러 개의 WAS를 돌리면서 하나의 서버가 죽더라도 웹 서버가 다른 서버를 이용할 수 있게 함으로써 서버 유지력 향상과 무중단 운영을 방지 할 수 있다.
JAVA Aplication WAS 구조
용어 정리
-
HttpservletRequest : 클라이언트가 브라오저를 통해 url을 요청한다. 이 요청 정보는 header에 입력되어 서버에 전달된다.
-
HttpservletResponse : 클라이언트가 요청한 결과를 header에 입력된 정보로 html문서를 보낸다.
-
Redirect : 클라이언트의 요청 페이지가 정적인 경우에 WAS를 거치지 않고 바로 요청한 html문서를 보낸다.
-
HTTPD : httpd란 HTTP Protocol을 지원하는 daemon이라는 말로써 브라우저가 해독 가능한 html문서를 전송해주는 역할을 한다. 즉, httpd는 클라리언트의 요청이 정적인지 동적인지 판단하고 WAS로 요청을 전달하거나 html문서를 응답해준다.
Tomcat 컴포넌트 3요소
-
Coyote : 코요테는 http 컴포넌트이며 톰캣에 TCP를 통한 프로토콜을 지원한다. 즉 톰캣의 HTTP Connector 역할로 http 또는 http/ssl 등 여러 가지로 방법으로 전달한 클라이언트의 요청을 엔진이 동일한 처리를 할 수 있게 접속 요건 처리를 한다. 처리된 요청내용을 JSP엔진한테 전달하고 엔진의 결과를 다시 웹서버로 전달한다.
-
Jasper : 재스퍼는 톰캣의 JSP 엔진이다. JSP페이지의 요청을 처리하기 위해 JSP페이지를 java로 변환하고 class파일로 컴파일하는 과정을 수행한다. 즉, jsp파일의 구문을 분석하여 java 코드를 서블릿으로 컴파일하고 실행한다. 또한 재스퍼는 이러한 컴파일 과정을 최초 1회만 수행하고 컴파일 자료를 메모리에 저장해둔다. 그리고 서버 런타임 중에 jsp파일의 변경 내용을 감지하고 필요에 따라 재컴파일을 수행한다. 그 이유는 톰캣 5 버전 이후의 재스퍼에서 재스퍼 2로 업데이트되기까지 중요한 기능이 추가되었기 때문이다.
- JSP 태그 라이브러리 풀링 - JSP 파일의 각 태그 마크업은 태그 처리기 클래스에 의해 처리된니다. 태그 처리기 클래스 객체를 풀로 만들고 전체 JSP 서브릿에서 다시 사용할 수 있다.
- 백그라운드 JSP 컴파일 – 수정 된 JSP Java 코드를 다시 컴파일하는 동안 이전 버전은 서버 요청에 계속 사용할 수 있다. 새 JSP 서블릿이 다시 컴파일되면 이전 JSP 서블릿이 삭제된다.
- 페이지 변경이 포함 된 경우 JSP를 다시 컴파일합니다. 런타임에 페이지를 JSP에 삽입하고 포함할 수 있다. JSP는 JSP 파일 변경 사항뿐만 아니라 포함된 페이지 변경 사항으로 다시 컴파일된다.
- 효과 : 개발 중 수정한 jsp파일을 서버에 반영하기 위해서 서버를 재시작할 필요가 없다.
-
Catalina : 카탈리나는 서블릿 컨테이너(Servlet Container)로 자바 서블릿을 호스팅하는 환경을 제공한다. 클라이언트의 http 요청을 Coyote가 받으면 카탈리나의 서블릿 컨테이너에서 DocBase를 찾고 WEB-INF/web.xml 파일 내용을 참조하여 url을 특정 servlet에 매핑하고 요청자가 올바른 액세스 권한을 갖게 한다. 또한 servlet과 jsp 파일에 대한 요청을 처리하며 servlet의 생명 주기도 관리한다.
- url과 서블릿 매핑
- 서블릿 인스턴스 생성
- 서블릿 로드 및 언로드
- 요청 및 응답 객체 생성 및 관리
- 기타 서블릿 관리 작업 수행
