회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
AWS 이용 중이라면 최대 700만 원 지원받으세요
국내 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하는 걸까요?
회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
회원가입을 하면
성장에 도움이 되는 콘텐츠를
스크랩할 수 있어요!
확인
국내 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하는 걸까요?
이번 글은 사용자를 가까이 관찰하고 데이터를 얻어 디지털 프로덕트와 서비스 전략을 설계하는 'pxd'가 웹 서버(WS)와 웹 애플리케이션 서버(WAS)의 차이점과 효율성에 대해 분석했습니다.
최근 네트워크에 관련하여 소소하게 책을 읽으며 스터디하는 시간을 가졌는데, 그중 관련이 있을법한 주제로 포스팅하려고 합니다.
네트워크를 공부하면서 자연스럽게 관련이 있는 웹 서버에 대해 알아보게 되었습니다. 그동안 웹 서버(WS)와 웹 애플리케이션 서버(WAS)에 대해 대략 이렇다~ 할 정도의 지식은 있었지만, 구체적인 차이점이나 장단점, 왜 웹 애플리케이션 서버(WAS)를 쓰면서도 웹 서버를 따로 두는지 명확한 이유를 알지 못한 채 넘어갔었습니다.
이번 글을 통해 한 번 더 학습하면 좋을 것 같아 작성했습니다. 웹서비스가 어떻게 사용자(client)에 정보를 제공하며, 그중 웹 서버와 WAS가 하는 역할이 무엇인지 차이점과 효율성에 대하여 얘기해 보겠습니다.
웹 서버는 클라이언트(사용자)가 브라우저 주소창에 url을 입력하여 어떤 페이지를 요청하면, http 요청을 받아들여 HTML 문서와 같은 정적인 콘텐츠를 사용자에게 전달해주는 역할을 합니다.
웹 서버의 임무는 대표적으로는 2가지로
1) 단순히 저장된 웹 리소스들을 클라이언트로 전달하고, 클라이언트로부터 콘텐츠를 전달받아 저장하거나 처리한다.
2) 사용자로부터 동적인 요청이 들어왔을 때, 해당 요청을 웹 서버 자체적으로 처리하기 어렵기 때문에 WAS에게 요청함.
WAS 또한 웹 서버와 동일하게 HTTP 기반으로 동작합니다. 웹 서버가 할 수 있는 기능 대부분이 WAS에서도 처리가 가능하며, 비즈니스 로직(서버사이드 코드)을 처리할 수 있어 사용자에게 동적인 콘텐츠를 전달할 수 있습니다. 주로 데이터베이스 서버와 같이 수행됩니다.
즉 WAS의 주요 임무는 동적인 요청을 받아 처리해 주는 서버입니다. WAS는 웹 서버보다 다소 생소한 영역일 수 있어서 위키백과에서 정의한 내용을 더해보겠습니다.
웹 애플리케이션 서버(Web Application Server, 약자 WAS)는 웹 애플리케이션과 서버 환경을 만들어 동작시키는 기능을 제공하는 소프트웨어 프레임워크이다. 인터넷상에서 HTTP를 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해 주는 미들웨어(소프트웨어 엔진)으로 볼 수 있다. 웹 애플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행된다. 한국에서는 일반적으로 ‘WAS’ 또는 ‘WAS S/W’로 통칭하고 있으며 공공기관에서는 ‘웹 응용 서버’로 사용되고, 영어권에서는 ‘Application Server’(약자 AS)로 불린다.
위 각각의 설명을 읽었다면 충분히 파악할 수 있는 부분이지만, 정리하면 기능적으로 동일한 영역도 있고 WAS가 웹 서버 기능의 많은 부분을 포함하여 수행하지만 사용의 ‘목적’이 다릅니다.
웹 서버는 정적인 데이터를 처리하는 서버입니다. 이미지나 단순 html 같은 정적인 리소스들을 전달하며, WAS만을 이용할 때보다 빠르고 안정적으로 기능을 수행합니다. 반면 WAS는 동적인 데이터를 위주로 처리하는 서버입니다. DB와 연결되어 사용자와 데이터를 주고받고, 조작이 필요한 경우 WAS를 활용합니다.
그렇다면 웹 서버가 할 수 있는 일을 WAS로도 전부 가능하다면, 웹 서버는 굳이 사용하지 않아도 될까요? 물론 정적인 콘텐츠만을 제공하는 웹사이트를 서버에 배포한다면 웹 서버만으로도 충분합니다. 그런데 동적인 콘텐츠를 제공하는 웹서비스 배포해야 할 때는 정적, 동적 요청 처리가 모두 가능한 WAS만을 사용해도 되지 않겠냐는 생각을 할 수도 있습니다.
하지만 WAS는 DB 조회 및 다양한 로직을 처리하는 데 집중해야 합니다. 따라서 단순한 정적 콘텐츠는 웹 서버에게 맡기고, 기능을 분리해 서버 부하를 방지해야 합니다.
만약 WAS가 정적 콘텐츠 요청까지 처리하게 된다면, 부하가 커지고 동적 콘텐츠 처리가 지연되면서 수행 속도가 느려집니다. 이에 따라 페이지 노출 시간이 늘어나는 문제가 발생하여 효율성이 크게 떨어지게 됩니다.
위 그림과 같이 웹 서버를 앞단에 두고, WAS는 웹 서버가 처리하기 힘든 서버 사이드 코드의 로직 등을 수행하여 웹 서버와 함께 사용자에게 양질의 콘텐츠를 제공할 수 있습니다.
사람들이 많이 접속하는 대용량 WAS인 경우, 서버의 수가 여러 대일 수도 있습니다. 만약 사용 중 WAS에서 문제가 생겨 WAS를 재시작해야 하는 경우가 생긴다면 이때 앞단의 웹 서버에서 WAS를 사용하지 못하도록 요청을 차단합니다. 그다음 WAS를 재시작한다면, 사용자들은 WAS에 문제가 발생한지 모르고 이용할 수 있습니다.
이러한 처리를 ‘장애 극복 기능’이라고 합니다. 즉 규모가 커질수록 웹 서버와 웹앱 서버를 분리하는 것입니다. 그리고 자원을 이용하면서 효율성, 배포 및 유지 보수 편의성을 위해 대체로 분리하여 둡니다.
소프트웨어 공학에서 장애 극복 기능이란 컴퓨터 서버, 시스템, 네트워크 등에서 이상이 생겼을 때, 예비 시스템으로 자동 전환될 수 있도록 처리하는 기능입니다. 반면 수동으로 직접 전환 처리하는 것을 스위치 오버라고 합니다.
웹 서비스는 아래처럼 다양한 구조를 가질 수 있습니다.
1) Client -> 웹 서버 -> DB
2) Client -> WAS -> DB
3) Client -> 웹 서버 -> WAS -> DB
또한 *리버스 프록시의 구조를 가져가며 서버 부하 방지와 보안적 효율을 얻을 수 있습니다.
위 글을 읽고 나면 조금 의문이 드는 부분도 있을 겁니다. 웹 서버만으로도 분명 동적인 요청 처리가 가능하기 때문입니다. 예를 들면 PHP의 경우 WAS 없이 아파치나 nginx만을 통해서 동적인 요청 처리가 가능합니다. 그걸 가능하게 해주는 게 CGI인데 웹 서버에 별도로 설정해 주어야 합니다. CGI는 이름 그대로 인터페이스로서, 웹 서버상에서 프로그램을 동작시키기 위한 방법을 정의한 프로그램(또는 스크립트)입니다.
CGI란 위에 설명해 놓았듯이 동적 콘텐츠를 제공하기 위해 웹 서버 내에 프로그래밍 기능이 들어가는 방식입니다.
즉 PHP, Perl, Python 등의 언어들은 CGI를 구현해놓았기 때문에, 아파치에서 다양한 언어로 짜인 각 프로그램을 실행할 수 있습니다. 예를 들어 아파치에 PHP 모듈을 설치했을 경우, 요청이 왔을 때 아파치는 HTTP 헤더를 분석하고 파싱하여 PHP로 파라미터를 넘겨줍니다. 그러면 PHP에서는 파라미터를 받아 응답할 HTML 문서를 만들어서 아파치에 전달합니다.
HTML 문서를 전달받은 아파치는 CSS, JS, img 등 정적인 자원들과 함께 브라우저로 반환해 줍니다. 하지만 이 역시 CGI 효율이 떨어지기 마련입니다. CGI만으로는 규모가 큰 웹서비스를 구현하기 사실상 어렵습니다(WAS의 반대 경우입니다).
많은 프로그래머들이 JAVA를 견고한 언어라고 평가하는 이유도 여기에 어느 정도 포함되어 있다고 생각합니다. 자바 서블릿 은 CGI를 사용하지 않습니다. 그래서 WAS에 대해 설명할 때 대표적으로 JAVA, 톰캣, 아파치로 예시를 들어줍니다. 가장 이상적인 WS + WAS의 사용으로 보입니다.
많이 부족하지만 웹 서버와 WAS의 기본적인 설명, 차이, 구조적인 부분에 대해 얘기해 봤습니다. 웹 개발 및 웹 서비스 환경은 근래 들어 빠르게 성장해 왔습니다.
예를 들어 원래는 브라우저에 종속된 언어였던 JavaScript의 경우, 웹 개발에 있어서 Client Side와 Server Side를 가리지 않으며 딥러닝 개발까지도 가능합니다.
앞서서 이런 얘기를 하는 이유는 그만큼 빠르게 변화하고 있는 개발 환경에 있어, 어느 것도 특정 기능의 범주로서 정의할 순 없다고 생각하기 때문입니다. 글을 작성하며 여러 참고 자료들을 찾다 보니, 현재에 와서는 개발 환경과 서비스 배포에 대한 기술이 발전됨에 따라 WAS는 어느 정도 정의하기 나름인 것으로 보였습니다. Node.js의 express를 WAS로 정의하거나 범주로 볼 수 있을까? Python의 Django는? 어디까지나 서비스를 기획 및 제작 배포하는 사람들의 아키텍처 구상에 달리지 않았나라는 생각입니다.
혹시 본문에 틀린 부분이나 수정해야 할 부분이 있다면 언제든지 피드백 부탁드리겠습니다. 또한 사용된 용어들에 대한 설명이 많이 부족할 수 있는데, 본 포스팅 주제보다 내용이 방대해질 우려가 있어 좀 더 길게 풀어내지 못한 점 양해 부탁드립니다. 읽어주셔서 감사합니다.
<원문>