Web Server 와 WAS (Web Application Server) 의 차이

  • 2023-01-17

언젠가 한번쯤은 주제로 삼고 포스팅을 해야지 한 녀석. Java Spring 관점에서만 설명하는 여러 블로그 글들을 보면서, Web Server, WAS 에 대해 개인적으로 고민했었던 부분과 틀린 내용을 Web 변천사로 정리해 서술해 보려합니다.


Internet 의 탄생

처음 인터넷이란 기술은, TCP/IP 프로토콜을 이용해 서버간 정보를 주고받는 컴퓨터 네트워크로 등장했습니다.

그리고 이 기술을 활용해, 오늘날 우리 일상에서 접하는 인터넷 네트워크망을 구현한 시초는 1983년 미국 국방성의 '아파넷'을 통해서 세상에 나왔습니다. 


"생각보다 인터넷이 등장한 시점은 그리 오래되지 않았지만, 인터넷이 가져온 세상의 변화와 발전속도는 현재까지도 계속 주시하지 않으면 따라가기 벅찰정도로 빠릅니다"



Web Server 의 등장

웹서버는, 웹 사용자(guest) 가  어떻게 서버(host) 에 접근 하는지를 관리합니다.

일반적으로 웹서버는 HTTP(HyperText Transfer Protocol) 서버를 의미하며 HTTP 프로토콜을 이용해 브라우저가 서비스를 요청 (request) 하고 Host 는 자신의 정보를 '정적 (static) 또는 동적 (dynamice) ' 으로 처리한 결과를 제공(response) 합니다.




초기의 웹 서비스는 회사 소개글이나 책내용처럼, 단순한 정보 전달이 목적 이었기 때문에 html 같은 문서나 css, image 파일등 정적파일 전달로 충분하고 큰 무리가 없었습니다.



동적 파일 처리

시간이 지나 'html' 파일과 '스크립트 언어'가 결합되어 DB 와 연동해 동적으로(dynamic) 가공한 html 문서를 보낼 수 있도록 발전했습니다.

스크립트 언어로는 'cgi', 'asp', 'php', 'jsp' 와 같은 녀석이 있고, 이들을 활용해 서버에서 동적으로 html 문서를 만들어 유저(browser) 로 전달해주는 것을 SSR ( Server Side Rendering ) 이라고 합니다.



Background interfaceCGIASPPHPJSP/ Servlet
동작 운영체제allWindowsall
all
주 실행 웹 서버all
IIS (종속)apachevery much
실행 효율성slowfastmediumextremely fast
안정성HighMediumHighVery high
개발 시간LongShortShortMedium
개발 언어almost allVisual BasicPHPJava
출시 년도1990 초199619951999

현 시점에서는 이러한 스크립트 언어를 배우는게 그리 중요하지는 않지만, 1983 년 인터넷이 세상에 나온 이후 고작 10년만에 정적 파일만 처리하던 시절에서, DB를 활용해 동적으로 처리하는 시대가 도래 했다는 점에서 의의가 있습니다.   (* 참고로 1992 년은 Oracle 7 이 나올 시기 )


그리고 시간이 지나 JSP/ Servlet 을 이용해 개발을 좀 더 쉽게 해줄 수 있는 도구로 'Spring' 프레임워크(2003 년) 가 등장하였고, ASP 도 .Net Framework 에서 동작할 수 있는 'ASP.NET' (2002년 )이 출시하게 되면서 웹개발의 전성기를 맞이합니다.

그리고 이 시점에서 객체지향의 특성을 활용한 MVC, MVP, MVVM 구조등 많은 컨셉이 등장하고 발전을 하게됩니다. 


  • 여기서 중요한 점으로는 동적으로 파일을 처리하는 것이 Web Server 에서 구현된다는 것 입니다


WAS ( Web Application Server ) 란?

그런데 Java 공화국인 대한민국에서 이렇게 설명을 하면 어디선가 스피드 웨건이 등장해,  Web Server , WAS Server 를 구별해서 정적인 것은 Web Server 에서만, WAS 는 동적인 것만 처리하는 거야! 라며 면박을 주곤 합니다.



Java 기술 면접에서 단골로 나오는 녀석. 

( https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html )



.NET 으로 개발을 시작한 사람으로서, Spring 개발을 하는 친구와 기술 면접 버금가는 논쟁을 겪으면서 개인적으로도 궁금했습니다. WAS 란 무엇인가?


ASP.NET 의 경우 정적, 동적 처리를 모두 IIS 웹서버에서 처리가 가능 했기에( 해야만 했기에 )  Spring 처럼 굳이 Apache 나 Tomcat 컨테이너를 실행해서 구동할 필요가 없었습니다.

(* .Net Core 의 경우 내부 웹서버 Kestrel 을 활용하긴 합니다)


Python Flask 또한 CGI 를 계승한 WSGI 가 python 이라는 스크립트언어를 활용해 동적인 개발을 하도록 하는 방식이고 Flask 내부에 wsgi 웹서버가 탑재되어 있어서, Spring 의 WAS 라는 개념없이 Web 서버에서 동작이 됩니다



이렇게 'ASP.NET' , 'Flask' 모두 웹서버에서 처리되고, 동적인 처리도 웹서버에서 잘만 되는구만, 무슨 WAS 가 존재하고 Web Server , WAS 를 구별해야해?! 라고 의문이 들게 됩니다.



WAS 라는 표현이 하나의 정립된 구조로 굳어진 현시대에서, WAS 의 개념은 말 그대로 웹 애플리케이션이 동작되는 아키텍처 , 프로세스 단위가 아닐까 합니다.

다시말해, 기존 스크립트에서 처리 했던 동적 처리를 .NET, Spring 애플리케이션에 위임하고, 시간이 지나 애플리케이션 자체적으로도 웹서버가 탑재되도록 발전해왔기 때문에, WAS 는 애플리케이션이 실행하는 Process 단위, Java 의 JVM 이나 C# 의 CLR 를 지칭하지 않나 싶습니다.


Web Server + WAS 는 필요 없는 것인가?

그렇다면 Java, Spring 에서 거론 되어온, Browser 와 WAS 사이에 'Web Server' 두는 것은 필요 없는 것인가? 라는 질문이 나올 것 같은데요.정답은 또 그렇지 않다 입니다.


이렇게 구성했을 때, 얻을 수 있는 이점이 있습니다. 대표적으로 요새는 Nignx 웹서버(2004 년) 가 많이 쓰이고 있는데, 크게 3가지가 있습니다.


  • 1. 캐싱 및 서버 부하를 분담 한다.

WAS 는 대규모 사용자들의 트래픽을 견뎌야 하기 때문에 바쁩니다. 예시로 메인 화면에 접속할 때마다,많은 사진들을 같이 보여준다면, 사용자가 새로고침 할때마다 많은 데이터를 새로 가공 후 보여줘서해서 많은 부하를 유발하게 됩니다.


이때 이미지 같은 정적 파일은 WAS 앞 단의 Web Server 에서 처리하게 해주면, 부하도 줄게 되고,  캐싱을 이용해 파일 전송 속도도 더 빠르게 할 수 있습니다.

 


  • 2. 리버스 프록시(Reverse Proxy)로 보안을 강화한다

브라우저에서 WAS 로 요청(Request) 할때, 중간에 Proxy 를 두어서. Proxy가 요청(request) 정보의 'Port' 나 'address' 를 다시 재맵핑 하기에, WAS 의 정확한 위치를 모르게 할 수있습니다.


그리고 중간에서 SSL 인증서를 삽입해 HTTPS 통신을 가능하게 설정할 수 있습니다

이러한 역할로, 해커로부터 보안을 좀더 강화할 수 있습니다. 

 


  • 3. Web Server 에서 여러 대의 WAS 를 로드밸런싱 한다.

실제 안정적으로 운영되는 웹 서비스를 개발하기 위해서는 대규모 트래픽에 감당 할 수 있도록 '고 가용성'에 신경 써야 합니다. 이때 여러대의 WAS 에 균등하게 트래픽이 전송되도록 배분하는 역할을 하게 되고, 특정 WAS 에 트래픽을 가중하거나, 운영중에 죽어버린 WAS 에 대해 다른 WAS 로 분산되도록 할 수 있습니다. 





웹 서비스의 발전 SPA 

이렇게 WS + WAS 구조로 Web 세상이 돌아가다가, 서버에서 연산이 점점 복잡해지고 모바일이 등장(아이폰 2016년) 하면서 기존 방식의 문제점이 부각되고 이는 SPA ( Single Page Application ) 이라는 개념이 등장하게 됩니다.


당시에  웹 페이지 전체를 다시 로딩하지 않고 일부분만 갱신할 수 있게 하는 AJAX( Asynchronous JavaScript and XMl) 라는 기술이 등장하면서 SPA 의 붐이 시작 된 것으로 보이는데, 기존 SSR 의 단점으로는 아래와 같습니다. 


  • 첫번째 페이지를 로딩후에 다시 두번째 페이지를 로딩하게 되면 두번째 페이지에 포함된 CSS 파일들과 javascript 파일들이 또 다시 로딩하게 된다. -> 페이지 단위 호출 방식은 로딩 속도를 저하시킴.


  • 서버사이드 렌더링의 한계점으로, IOS 나 Android 앱을 개발하기 위해서는 네이티브에서 제공되는 UI 를 사용해서 개발을 해야하는데, 서버에서 렌더링 되어 html 이 리턴된다면 더이상 UI 를 렌더링 할 수 없게 됩니다.


이런 이슈로 인해서, 기존 WAS 서버는 RESTful( Representational State Transfer )서비스만 제공해주도록 역할이 축소 되었고, html 이 아닌 필요한 data 양식,  'XML', 'JSON', 'Binary' 형태로 제공해 주도록 변하게 되었습니다. 



Front Framework 의 등장 CSR 

이렇게 single page 에서 필요한 데이터만 가져와 브라우저(Client) 쪽에서 새롭게 렌더링해주는 기법을 CSR (Client Side Rendering) 이라고 합니다. 또한 이런 흐름이 .Net, Spring 같은 프레임워크에서 MVC 구조로 웹을 만들던 시기를 지나, React, Angular, Vue js 같은 프론트앤드 프레임워크가 등장하고, 기존 .Net, Spring 은 백엔드 프레임워크로 역할이 분리되게 됩니다.


그래서 웹서비스의 개념도, 백엔드의 Web Server ,WAS 서버를 넘어, 또하나의 Front Web Server 를 활용해 사용 되도록 변화해 왔으며, 이러한 구조형태로 오늘날 웹 서버가 구동되어 사용되고 있습니다.



마치며

Web 개발에 대한 변천사를 정리하면서, 신입 개발자 시절, 많은 고민을 했었던 부분에 대해서, 그리고 대략적으로만 알고있었던 개념에 대해서 제대로 정리 해본 계기가 되었습니다.



[Reference]

https://stackoverflow.com/questions/7764829/what-is-application-server-for-asp-net

https://stackoverflow.com/questions/11752355/whats-the-equivalent-of-rubys-rack-or-pythons-wsgi-for-java
https://www.c-sharpcorner.com/UploadFile/1ce252/introduction-to-servlet/

https://topic.alibabacloud.com/a/cgi-asp-php-jsp-asp-net-web-site-development-language-comparison

https://www.geeksforgeeks.org/difference-between-asp-and-asp-net/

http://www.tcpschool.com/ajax/ajax_intro_basic

https://itkjspo56.tistory.com/91