- WAS?
- Web Server?
- WAS vs Web Server
이번에 웹 프로젝트를 진행하며 Tomcat를 사용하게 되었다. 작업을 위해 로컬셋팅은 검색하며 완료하였지만,
셋팅중에서 Tomcat 즉 WAS가 정확하게 무엇인지 모르고 가이드로 접한 느낌이 있어 WAS에 대해 정리해보고,
WAS와 Web Server는 어떤 차이가 있고 둘의 관계에 대해서도 정리하려고한다.
WAS ?
: Web Application Server
✅ WAS
WAS는 웹에서 직접적으로 처리할 수 없는 DB조회나 조건에 따른 다양한 로직 처리를 요구하는 동적인 콘텐츠를 제공하기 위해 만들어진 Application Server라고 하며, HTTP를 통해 컴퓨터나 장치에 Application을 수행해주는 미들웨이(소프트웨어 엔진)이다.
WAS를 웹 컨테이너(Web Container) 혹은 서블릿 컨테이너(Servlet Container)이라고도 한다.
* Container?
JSP, Servlet을 실행시킬 수 있는 소프트웨어 (즉 WAS는 JSP, Servlet 구동환경을 제공한다.)
✅ WAS의 역할
WAS는 WEB Server와 Web Container 더한 의미를 가지며,
Web Server 기능들을 구조적으로 분리하여 처리하고자 하는 목적으로 제시되었다.
WAS는 1)프로그램실행 환경과 DB접속 기능 제공을 하고,
2)여러 개의 트랜잭션관리 기능을 제공한다.
또한 3)업무를 처리하는 비즈니스 로직도 수행하는 주요기능을 포함하고 있다.
*WAS의 예시
: Tomcat, JBoss, Jeus, Web Sphere
Web Server?
WAS에 대해 언급하며 위에서 말했듯이, WAS와 Web Server는 크게보는지 작게보는지 즉 범위를 얼마로 가지냐의 따라 다르게 정의된 것이지 WAS와 Web Server는 완전히 분리되고 다른것이 아니다.
Web Server는 하드웨어(FILEs) 와 소프트웨어 (HTTP Server)로 구성되어 있고, Browser(Client)접속 시 WAS에서 가장 먼저 Request받는 부분이다.
[PROCESS]
(1) Request → (2) URL Matching → OK → (3) FILE RETURN
→ NO → 404 Not Found
WAS vs Web Server
우선 WAS와 Web Server를 분리하는 이유는 뭘까?
앞서 말한 내용과 같이 Client는 HTML문서를 우선적으로 받고, 이후 클라이언트측에서 필요한 파일을 Web Server에 요청하여 그때서야 다른 필요한 정보의 파일을 받아온다.
이러한 과정을 Application Server까지 안가고, Web Server에서 처리가능한 작업이다.
그렇기에 굳이 뒷단의 Application Server까지 가는 부담을 제외하고 정적콘텐츠를 처리하도록 기능을 분배하여
서버의 부담을 줄인 것이다.
WAS가 필요한 이유는 웹 페이지에 모두 존재하는 동적인 콘텐츠와 정적인 콘텐츠를 사용자의 요청에 맞게,
결과 값을 미리 준비 만들어 놓고 서비스를 해야한다. 하지만 그렇게 수행하기에는 자원이 절대적으로 부족하기에
WAS를 통해 요청에 맞는 데이터를 DB에서 가져와 비즈니스 로직에 맞게 결과를 제공하는 것이다.
이는 자원측면에서 효율적인 운용이기에 WAS의 필요성은 자원관리 측면에서 유의미하다.
🙄 WAS가 Web Server의 기능도 모두 수행하면 되지 않을까?
결론적으로, 앞서 계속 언급했던 자원 이용의 효율성측면위해
Web Server와 WAS를 분리하는 것이 올바르다.
그 이유는 아래와 같다.
1. WAS는 DB조회나 다양한 로직을 처리하느라, 바쁘다.
때문에 단순 정적 컨텐츠는 Web Servser에서
빠르게 클라이언트에게 제공하는 것이 좋다.
2. WAS는 기본적으로 동적 컨텐츠를 제공하기 위해 존재하는 서버이다.
3. 만약 정적 콘텐츠 요청까지 WAS가 처리한다면 정적 데이터 처리로 인해
부하가 커지게 되고, 동적 컨텐츠의 처리가 지연됨에 따라
수행 속도가 느려진다.
4. 즉 이로 인해 페이지 노출 시간이 늘어나게 될 것이다.
- SSL 대한 암복호화 처리에 Web Server를 사용
1. Load Balancing을 위해서 Web Server를 사용
2. Fail over(장애 극복), fail back 처리에 유리
3. 특히 대용량 웹 어플리케이션의 경우(여러 개의 서버 이용) Web Server와
WAS를 분리하여 무중단 운영을 위한 장애 극복에 쉽게 대응할 수 있다.
4. 예를 들어 앞 단의 Web Server에서 오류가 발생한 WAS를 이용하지
못하도록 한 후 WAS를 재시작함으로써 사용자는 오류를 느끼지 못한다.
- 예를 들어, 하나의 서버에서 PHP Application와 JAVA Application을 함께 사용하는 경우
- 접근 허용 IP관리, 2대 이상의 서버에서의 세션 관리 등도 Web Server에서 처리하면 효율적이다.
결론적으로
을 위해 Web Server와 WAS를 분리한다.
✔ Web Server를 WAS 앞에 두고 필요한 WAS들을 Web Server에 플로그인 형태로 설정하면 더욱 효울적인 분산 처리가 가능하다.
Web Service Architecture 🔧
WAS의 다양한 구조
DBMS와 MiddleWare의 개념
DBMS Server 직접 접속동작의 문제점
: Client에 로직이 많아지고 이에따라 Client Program의 크기가 커진다.
로직이 변경될 때마다 매번 배포된다. 즉 Client에 대부분의 로직이 포함되어 배포가 되기 때문에 보안에 취약한다
→ 이를 해결하기 위해 MiddleWare가 등장했다.
MiddleWare
Client - MiddleWare Server - DB Server(DBMS)
→ 즉 비즈니스 로직을 Client와 DBMS사이의 MiddleWare Server에서 동작하도록
함으로써 Client는 입력과 출력만 담당하게 된다.
https://story.pxd.co.kr/1647
https://developer.mozilla.org/ko/docs/Learn/Common_questions/Web_mechanics/What_is_a_web_server
https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html