[Web]웹 서버와 WAS에 관하여
와스..와쓰...WAS...
많이 들어봤지만 'WAS가 뭐야?' 라고 누군가에게 질문이 들어온다면 잘 설명할 수 있을까요?
지금 당장 생각나는 대답은 "그 있잖아요...스프링 프로젝트 만들고 웹에서 실행시킬라고 톰캣 붙이잖아요 그 톰캣이 WAS에요!"
이정도의 형편 없는 대답일뿐...
그럼 웹서버는 뭐야? 라고 질문이 들어오면 어떻게 대답 하겠습니까?
-> "웹서버랑 WAS랑 똑같은말 아닌가요"
알것같으면서도 막상 물어보면 대답하기 힘든 개념
지금부터 웹 서버와 WAS에 대해 정리를 해보겠습니다.
java와 spring을 다루는 개발을 처음 시작할 때면 웹 애플리케이션을 만들어야 할 때 아무런 고민 없이 spring으로 만든 다음 tomcat을 띄워 연결하는 경우가 있습니다.
spring boot를 사용할 경우엔 내장 톰캣을 사용하게 되는데요,
그전에 우리가 '서버'를 띄워야 할 때 웹서버를 사용해야 할지 WAS를 사용해야 할지, 아니면 두 개를 혼합해서 사용해야 할지에 대한 고민이 필요합니다.
각각의 역할이 명확히 다르고 혼합해서 사용할 경우 보다 확장성이 높은 아키텍처를 가져갈 수도 있는데요.
이번 포스팅에서는 누군가에겐 당연하다고 느껴질지 모르는, 그렇지만 웹서비스 개발자라면 꼭 알고 있어야 하는 웹서버와 WAS의 차이점에 대해 이야기하고 있습니다.
웹서버의 역할, WAS의 역할을 명확히 구분하고 장애 극복을 위해 분리를 한다면 보다 더 견고한 웹서비스를 구성할 수 있기 때문에 가볍게 읽어보는 것도 좋을 것 같습니다.
웹 서버(Web Server) 란?
웹서버는 클라이언트(사용자)가 브라우저 주소창에 url을 입력하여 어떤 페이지를 요청하게 되면 http 요청을 받아들여 HTML 문서와 같은 정적인 콘텐츠를 사용자에게 전달해주는게 가장큰 역할입니다.
웹서버의 임무는 대표적으로는 2가지입니다.
- 단순히 저장된 웹 리소스들을 클라이언트로 전달하고, 클라이언트로부터 콘텐츠를 전달받아 저장하거나 처리한다.
- 사용자로부터 동적인 요청이 들어왔을 때 해당 요청을 웹서버 자체적으로 처리하기 어렵기 때문에 해당 요청을 WAS에게 요청.
대표적인 웹서버의 종류
- Apache(정확히는 Apache HTTP 서버): 유연성과 안정성이 높으며, 다양한 모듈을 지원하여 기능 확장이 용이합니다. 하지만, 다른 웹 서버에 비해 처리 속도가 상대적으로 느릴 수 있습니다.
- Nginx: 고성능이라는 장점이 있으며, 리버스 프록시 서버로의 사용이 쉽습니다. 하지만, 복잡한 설정이 필요한 경우가 많아서 러닝 커브가 높을 수 있습니다.
- Microsoft IIS(windows 전용 웹서버): 윈도우즈와의 통합성이 뛰어나며, ASP.NET 등 Microsoft 플랫폼 기술을 지원합니다. 하지만, 다른 플랫폼과의 연동이 어려울 수 있습니다.
- Lighttpd: 경량화된 설계로 자원 소모가 적으며, 높은 처리 속도를 지원합니다. 하지만, 일부 모듈이 미비하거나 제한적일 수 있습니다.
- Caddy: 간편한 설정 및 Let's Encrypt를 지원하여 SSL 인증서 발급이 간편합니다. 하지만, 아직은 상대적으로 새로운 제품이기 때문에 기능이 제한적일 수 있습니다.
WAS(Web Application Server) 란?
WAS 또한 웹서버와 동일하게 HTTP 기반으로 동작합니다.
웹서버가 할 수가 있는 기능 대부분이 WAS에서도 처리가 가능하며 비즈니스 로직(서버사이드 코드)을 처리할 수 있어 사용자에게 동적인 콘텐츠를 전달 할 수가 있으며, 주로 데이터베이스 서버와 같이 수행됩니다.
즉 WAS의 주요 임무는 동적인 요청을 받아 처리해주는 서버입니다.
WAS는 웹서버보다 다소 생소한 영역일 수 있어서 위키백과에서 정의한 내용을 더해보겠습니다.
| 웹 애플리케이션 서버(Web Application Server, 약자 WAS)는 웹 애플리케이션 과 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임워크 이다. 인터넷 상에서 HTTP 를 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해 주는 미들웨어 (소프트웨어 엔진)으로 볼 수 있다. 웹 애플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행이 된다. 한국에서는 일반적으로 “WAS” 또는 “WAS S/W”로 통칭하고 있으며 공공기관에서는 “웹 응용 서버”로 사용되고, 영어권에서는 “Application Server” (약자 AS)로 불린다. |
대표적인 WAS의 종류
- Apache Tomcat: Java 서블릿 컨테이너로, Java 기반 애플리케이션을 실행하는 WAS입니다. Tomcat은 다양한 프로그래밍 언어와 데이터베이스에 대한 지원이 풍부하며, 특히 Java EE(Enterprise Edition)의 스펙을 준수하여 대규모 애플리케이션을 운영하기에 적합합니다. 또한, 경량화된 설계로 자원 소모가 적어서 높은 성능을 제공할 수 있습니다. 하지만, 복잡한 설정이 필요하거나 고급 기능을 사용하기 위해서는 러닝 커브가 높을 수 있습니다.
- JBoss: Java EE 스펙을 준수하는 또 다른 대규모 WAS로, 오픈소스로 개발되어 있어 무료로 사용할 수 있습니다. 자유로운 확장성과 매우 높은 안정성, 그리고 다양한 기능들을 제공하며, 개발 생산성을 높일 수 있습니다. 하지만, 초기 설정이 복잡하고, 적극적인 커뮤니티가 유지되지 않고 있어 일부 사용자들의 지원이 불안정할 수 있습니다.
- Jeus: 안정적이고 클라우드 환경에서 우수한 호환성을 가지며 빠른 개발 생산성을 지원하는 장점이 있지만, 시장 점유율이 낮고 공식 문서가 제한적이며 라이선스 비용이 발생할 수 있다는 단점이 있습니다.
- IBM Web Sphere: Java EE 스펙을 지원하는 WAS로, 대규모 애플리케이션을 구축하거나 통합할 때 적합합니다. 풍부한 기능과 확장성을 제공하며, 클러스터링 및 HA(High Availability) 기능이 뛰어나지만, 설정과 관리가 복잡하고, 비용이 높은 편입니다.
- Oracle WebLogic: Java EE 스펙을 준수하는 WAS로, 안정성과 보안성이 뛰어나며, 고성능 트랜잭션 처리와 가용성 관리 기능 등이 우수합니다. 또한, 다양한 연동 기능과 확장성을 지원하며, 클라우드 환경과도 호환성이 높습니다. 하지만, 설치와 설정이 복잡하며, 높은 비용과 라이선스 비용이 부담이 될 수 있습니다.
차이
위 각각의 설명글을 읽었다면 충분히 파악할 수도 있는 부분이지만 정리하자면 기능적으로 동일한 영역이 있으며 WAS가 웹서버 기능의 많은 부분을 포함하여 수행하기도 하지만 사용의 “목적”이 다릅니다.
웹서버는 정적인 데이터를 처리하는 서버입니다.
이미지나 단순 html 같은 정적인 리소스들을 전달하며 WAS만을 이용할 경우보다 빠르고 안정적으로 기능을 수행합니다.
WAS는 동적인 데이터를 위주로 처리하는 서버입니다.
DB와 연결되어 사용자와 데이터를 주고받고 조작이 필요한 경우 WAS를 활용합니다.
효율적인 사용
그렇다면 웹서버가 할 수 있는 일을 WAS가 전부 가능하다면 웹서버는 굳이 사용하지 않아도 되지 않을까…? 라고 생각이 들 수 있는데 그렇진 않습니다
물론 정적인 콘텐츠만을 제공하는 웹사이트를 서버에 배포한다면 웹서버만으로도 충분합니다.
그런데 동적인 컨텐츠를 제공해야 하는 웹서비스 배포를 해야한다고 한다면 정적, 동적 요청 처리가 모두 가능한 WAS만을 사용해도 되지 않겠냐는 생각을 할 수도 있습니다.
하지만 WAS는 DB 조회 및 다양한 로직을 처리하는 데 집중해야 합니다.
따라서 단순한 정적 콘텐츠는 웹 서버에게 맡기며 기능을 분리해 서버 부하를 방지해줘야 합니다.
만약 WAS가 정적 콘텐츠 요청까지 처리하게 된다면, 부하가 커지고 동적 컨텐츠 처리가 지연되면서 수행 속도가 느려지고 이에 따라 페이지 노출 시간이 늘어나는 문제가 발생하여 효율성이 크게 떨어지게 됩니다.
위의 그림과 같이 웹서버를 앞단에 두고 WAS는 웹서버가 처리하기 힘든 서버 사이드 코드의 로직 등을 수행하여 웹서버와 함께 사용자에게 양질의 컨텐츠를 제공할 수 있습니다.
사람들이 많이 접속하는 대용량 WAS인 경우, 서버의 수가 여러 대일 수 있습니다. 만약 사용 중 WAS에서 문제가 생겨 WAS를 재시작해야 하는 경우가 생긴다면 이때 재시작하기 위해 앞단의 웹서버에서 WAS를 사용하지 못하도록 요청을 차단한 후 WAS를 재시작한다면, 사용자들은 WAS에 문제가 발생한지 모르고 이용할 수 있습니다.
이러한 처리를 “장애 극복 기능"이라 합니다. 즉 규모가 커질수록 웹서버와 웹앱 서버를 분리하는 것입니다.
그리고 자원을 이용하면서 효율성, 배포 및 유지보수 편의성을 위해 대체로 분리하여 둡니다
소프트웨어 공학에서 '장애극복기능'이란 컴퓨터 서버, 시스템, 네트워크 등에서 이상이 생겼을때 예비 시스템으로 자동전환될수 있도록 처리하는 기능입니다.
반면 수동으로 직접 전환 처리하는것을 스위치 오버라고 합니다.
웹 서비스는 아래처럼 다양한 구조를 가질 수 있습니다.
- Client -> 웹서버 -> DB
- Client -> WAS -> DB
- Client -> 웹서버 -> WAS -> DB
또한 *리버스 프록시의 구조를 가져가며 서버부하 방지와 보안적 효율을 얻을수있습니다.
덧붙이는 글
윗을 읽고 나면 조금 의문이 드는 부분도 있을 겁니다.
웹서버만으로도 분명 동적인 요청 처리가 가능하거든요 예를 들면 PHP의 경우 WAS 없이 아파치나 nginx만을 통해서 동적인 요청 처리가 가능합니다.
그걸 가능하게 해주는 게 🔗 CGI입니다 웹서버에 별도로 설정해주어야 합니다.
CGI는 이름 그대로 인터페이스로서, 웹 서버상에서 프로그램을 동작시키기 위한 방법을 정의한 프로그램(또는 스크립트)입니다.
CGI란 위에 설명해 놓았듯이 동적컨텐츠를 제공하기 위해 웹서버 내에 프로그랭밍 기능이 들어가는 방식 입니다.
즉 PHP, Perl, Python 등의 언어들은 CGI를 구현해놓았기 때문에, 아파치에서 다양한 언어로 짜여진 각 프로그램을 실행할 수 있는데 예를 들어 아파치에 PHP 모듈을 설치했을 경우, 요청이 왔을 때 아파치는 HTTTP 헤더를 분석하고 파싱하여 PHP로 파라미터를 넘겨주며 그러면 PHP에서는 파라미터를 받아 응답 할 HTML 문서를 만들어서 아파치에 전달하죠.
HTML 문서를 전달 받은 아파치는 CSS, JS, img 등 정적인 자원들과 함께 브라우저로 반환해줍니다.
하지만 이 역시(CGI) 효율이 떨어지기 마련입니다.
CGI만으로는 규모가 큰 웹서비스를 구현하기 사실상 어렵습니다(WAS의 반대 경우입니다).
많은 프로그래머들이 JAVA를 견고한 언어라고 평가하는 이유도 여기에 어느정도 포함되어 있다고 생각합니다.
🔗 자바 서블릿 은 CGI를 사용하지 않습니다.
그래서 WAS에 대해 설명 할때 대표적으로 JAVA, 톰캣, 아파치로 대부분 예시를 들어줍니다.
가장 이상적인 웹서버 + WAS의 사용이라고 보여집니다.
마치며...
많이 부족하지만, 웹서버와 WAS의 기본적인 설명, 차이, 구조적인 부분에 관해서 얘기해봤습니다.
웹 개발 및 웹 서비스 환경은 근래 들어 빠르게 성장해 왔습니다.
예를 들어 원래는 브라우저에 종속된 언어였던 Javascript의 경우 웹 개발에 있어서 Client Side와 Server Side를 가리지 않으며 딥러닝 개발까지도 가능합니다.
앞서서 이러한 얘기를 하는 이유는 그만큼 빠르게 변화하고 있는 개발환경에 있어서 어느 것도 특정 기능의 범주로서 정의할 수는 없다고 생각하기 때문입니다.
글을 작성하며 여러 참고 자료들을 찾다 보니 현재에 와서는 개발환경과 서비스 배포에 대한 기술이 발전됨에 따라 WAS는 어느 정도 정의하기 나름인 것으로 보였습니다.
Node.js의 express를 WAS로 정의하거나 범주로 볼 수 있을까?
Python의 Django는?
어디까지나 서비스를 기획 및 제작 배포하는 사람들의 아키텍처 구상에 달리지 않나 하는 생각입니다.