들어가기 앞서 머릿글
일반적인 회사 웹서비스를 보면 아키텍쳐 구조를 보면 [ 웹서버 + WAS(WebApplicationServer) + DB ]로 이루어져있다.
그런데 과거에는 이런 구조가 아닌 [ 웹서버 + DB ]만을 이용하여 웹서비스를 하였다고 한다.
그렇다면 과거 웹서비스는 왜 그런한 구조였고 어떠한 이유에 발전해 왔을까? 한번 알아보자!
과거 웹서비스 [ 2 Tier ]
위에서 말했듯이 과거의 [ 웹서버 + DB ] 구조를 Tier 2 라고 한다.
과거에는 오늘날과 같이 인터넷이 대중화되고 보급되지 않았기 때문에 웹서버에서 PHP, ASP, JSP 등으로 DAO를 만들어 해당 DB데이터를 받아오는 파일의 경로로 요청해 리다이렉트시켜 처리하여도 크게 지장이 없었다.
(그래서 웹서비스가 페이지 단위의 정적 동기적 처리였다.)
- Tier 2 아키텍쳐 동작
위와 같이 Web Browser(사용자, 클라이언트)가 서비스 제공사의 Web Server(서버 PC의 웹서버 프로그램)에
해당 도메인의 웹페이지 경로로 서비스를 요청하면, 웹서버가 요청하는 자원 별로 바로 주거나(사진, html) 서버 페이지(JSP, ASP, ..) 요청일 경우 웹서버에 해당 언어의 플러그인을 통해 처리하여 DB에 받아온 데이터를 가공 or DBMS의 프로시저를 요청해서 HTTP 서블릿을 통해 데이터를 담아 리다이렉트를 요청한다.
- Tier 2의 단점
인터넷이 대중화되면서 인터넷 사용자들이 증가하였고 그로인해 기존의 웹서비스 요청 많아 졌는데 이를 처리하기 위해 웹서버를 증설하여도 데이터베이스에서 데이터를 받아와야하는데 하나의 데이터베이스가 여러 웹서버의 요청을 처리하기 역부족이었고 더불어 DB의 프로시저는 DBMS의 연산처리 증가로 DB가 뻗어버리는 경우가 허다했다.
또한 웹서버 측면에서는 악의적 사용자가 일부로 웹서버에 많은 요청을 보내 고의적으로 트래픽을 일으키거나, url에 여러 요청을 보낸 다음 응답하는 데이터 분석하여 개인정보를 빼가거나 쿠키정보를 열어보아 개인정보나 서버 데이터를 빼내고 비지니스 로직이 웹서버에 다 있기 때문에 웹서버가 해킹 당할 경우 비지니스로직을 유출되는 불상사가 발생하여 보안성이 취약하였다.
(트래픽증가, DB 과부화, 보안성 취약)
현재 웹서비스 3 Tier
위 그림은 앞선 웹서비스 2 tier의 문제를 줄여주는 WAS가 추가된 것을 볼 수 있다.
그렇다면 WAS란 무엇일까?
WAS는 WebApplicationServer의 약자로 과거 2 Tier에서 웹서버가 처리했던 비지니스 로직과 DB접근 처리만을 담당하는 서버이다.
웹서버에 사용자 요청이 오면, 웹서버가 WAS에게 해당하는 요청에 따른 비지니스로직을 처리하게 요청하고
웹서버는 was에서 가공된 데이터를 받아 매핑해 사용자에게 응답한다.
이렇게 함으로써 웹서버에서 비지니스로직을 볼 수 없고 데이터 가공을 위한 연산 처리가 없음으로 사용자요청에 과부화가 걸릴일이 줄어들고 빠른 요청응답을 할 수 있게 해주었다.
또한 데이터베이스의 프로시저를 줄이고 WAS에서 연산 처리를 집중시키어 DB에 안정성도 올라가게 해주었다.
WAS가 더해지면서 웹서버가 해킹당해도 비지니스로직, 개인정보를 유출당할 일이 줄었고 세션, 토큰과 같은 처리를 쉽게 하고 동적인 요청 처리를 쉽게 해줄 수 있게 되었다 (이전에는 페이지 단위로 요청에 응답하고 리다이렉트했다면 이제는 WAS의 요청 정보의 처리 결과에 따라 뷰를 동적으로 바꾸어 리턴해 줌으로써)