들어가며
서버라는 것은 요청이 들어오면 그에 대한 응답을 해준다 라는 것은 알고 있지만
보통 프로젝트를 진행하면서 WAS에 서버 코드를 올렸었는데
WAS가 무엇인지도 정확히 모르면서 사용을 하고 있었던 것...
웹 애플리케이션 서버(WAS)가 있고 웹 서버(WS)도 있다는데 둘의 차이점과 둘의 정확한 의미를 알고 싶었습니다.
웹 서버(Web Server), 웹 애플리케이션 서버(Web Application Server)
우선 웹 서버라는 것은 무엇일까요
우리가 브라우저에 접속해서 www.google.com을 치면 어떻게 될까요?
구글의 서버에 HTTP 통신으로 구글 서버에 있는 컴포넌트 파일(컴포넌트 파일에는 HTML 문서, images, CSS stylesheets, 그리고 JavaScript files가 있습니다.)을 요청을 통해서 가져옵니다.
그러면 우리의 브라우저는 가져온 컴포넌트 파일을 이용해서 화면을 띄우게 됩니다.
사실 우리 컴퓨터도 서버가 될 수 있습니다.
아파치 HTTP 서버를 이용해서 우리 컴퓨터의 어느 폴더에 HTML, CSS, JS 등과 같은 파일들을 넣어두고
폴더를 세상 사람들에게 공개를 하면 HTTP 통신을 통해서 우리 폴더의 컴포넌트 파일들을 들고 가도록 하면 됩니다.
이렇게 우리는 이미 정해진 양식의 템플릿을 HTTP 통신으로 주고받을 수 있습니다.
이것을 보통 "정적이다"라고 표현합니다.
그 안의 내용물이 바뀌지 않고 만들어놓은 그 상태 그대로 전달하고 읽는 것이죠.
하지만 현실의 많은 웹사이트들은 정적인 콘텐츠뿐만 아니라
데이터베이스에서 데이터를 들고 와서 HTML 템플릿을 채우고 있습니다.
또는 새로운 게시글을 쓰거나, 삭제, 편집과 같은 데이터베이스를 조작하는 많은 일을 웹사이트에서 수행하죠.
당장의 이 블로그만 해도 만들어진 HTML 템플릿에 데이터베이스에서 받은 데이터로 HTML을 채워 우리에게 보여주죠.
이 경우 "동적이다"라고 표현합니다.
HTML, CSS, JS 뿐만 아니라 동적인 콘텐츠를 제공하기 위해서 Apache의 모듈을 이용해
웹 서버에 요청이 들어오면, PHP에 적힌 코드대로 MySQL의 안에 있는 데이터를 가져와서 Apache가 요리를 해주는 그런 방식,
Apache + PHP + MySQL (APM 조합)을 이용해서 사용자에게 동적인 컨텐츠를 많이 제공했다고 합니다.
(Apache는 웹 서버 소프트웨어, PHP는 서버 프로그래밍 언어, MySQL 오픈소스 데이터베이스 관리 시스템입니다.)
그러면 웹 서버는 위와 같은 역할을 한다는 것을 대충은 알겠는데 그럼 웹 애플리케이션 서버(WAS)는 무엇일까요?
웹과 서버 사이에 애플리케이션이 들어갔습니다. 무언가 동작하는 프로그램이 있다는 뜻으로 유추할 수 있습니다.
서버로 요청이 들어오면 단순히 뭘 갖다 주는 것이 아니라 뭔가 프로그래밍된 걸 더 한다는 의미입니다.
웹 서버도 단순히 PHP 같은 간단한 작업들은 할 수 있지만, 스프링 같은 것들은 조금 더 전문적인 웹앱 서버(WAS)의 힘을 빌려야 합니다.
(WAS를 검색하면 죄다 자바의 내용이 많이 나오는데, 파이썬의 장고와 C#의 닷넷과 같은 것들에서는 딱히 WAS의 진영이다. WS의 역할이다라고 단정 지어 구분 짓지는 않는다고 합니다.)
공통적인 것은 프로그래밍 언어마다 WAS라고 부르진 않지만 WAS의 역할을 하는 친구들이 웹 서버 뒤에서 일을 하고 있는 거죠.
정적, 동적으로 WAS와 WS를 구분한다?
여러 페이지를 조사해본 결과 정적 vs 동적으로 웹 서버와 웹앱 서버를 많이 나눠서 설명합니다.
WAS는 동적이고, WS는 정적이다라고 단정 지어 설명합니다.
저도 검색을 하다 보니 잘못된 지식이라는 것을 알았습니다.
현재 많은 프로젝트가 WAS는 동적 콘텐츠를 제공하고 WS는 정적 컨텐츠를 제공하도록 설계를 합니다.
웹 서버가 정적인 콘텐츠만 제공할 수 있어서 또는 웹앱 서버는 동적인 컨텐츠만 제공할 수 있어서 그런 것은 아닙니다.
웹 서버도 위의 설명과 같이 동적인 콘텐츠를 제공을 할 수 있고, 웹앱 서버 또한 정적인 컨텐츠를 제공할 수 있습니다.
하지만 이 설계가 장점이 많고 구조적으로 이득이 많아하는 것입니다.
많은 프로젝트에서 웹서버(WS)를 앞단에 둬서 요청을 맞이하고, 웹앱 서버(WAS)를 그 뒤에 두어 요청을 처리하고 있습니다.
이 구조의 장점은 무엇일까요?
WAS와 WS를 분리시키는 이유
리버스 프록시 (Reverse proxy)
프록시는 중간 서버, 중개자라고 생각하면 됩니다.
보통은 프록시를 통해 사용자들이 정보를 감출 수 있게 하지만 리버스 프록시는 반대입니다.
들어오는 요청들로부터 서버의 정보를 감출 수 있습니다.
서버라는 큰 집의 주소만 사용자들에게 공개하고, 집의 내부는 감추는 것입니다.
정적 리소스들은 어디에 있는지, 동적 요소들은 어디에서 제공되는지, 서비스가 몇 번 포트로 돌아가는지, 서버 내부적으로 파일들이 어느 폴더에 들어가 있는지와 같은 정보들을 드러내지 않게 합니다.
아파치나 Nginx와 같은 웹 서버인 앞단의 친구들이 대신 자원을 가져오고 자원을 사용자들에게 건네줍니다.
이렇게 역할을 분리시킴으로써 보안을 강화시킬 수 있습니다.
로드밸런싱
프로젝트가 점점 커져 웹사이트에 들어오는 요청이 많아지면 하나의 웹앱 서버에 모든 요청에 대한 처리를 맡기면 서버의 성능이 떨어지게 됩니다.
그래서 하나의 웹앱서버에 모든 요청을 보내지 않고, 한 프로젝트에 웹앱 서버를 여러 개를 두어 처리를 분산시킬 수 있습니다.
그러면 자연스럽게 속도 증가와 같은 성능 향상을 할 수 있는 것이죠.
또한 지속성과 관련된 이점을 얻을 수 있습니다.
만약 프로젝트가 업데이트가 되어서 동적 부분, 즉 WAS까지 업데이트를 해주어야 하는 경우에는 구동시키고 있는 WAS를 멈추고 업데이트를 해야 합니다.
아주 잠깐의 시간이지만 만약 사용자가 업데이트를 하는 도중에 접근을 하려고 하면 사용자는 에러를 맞게 됩니다.
그러면 사용성이 떨어지고 고객은 떠나겠죠.
그래서 하나하나의 WAS를 업데이트시키면서, 업데이트 중인 WAS는 웹서버(WS)가 요청을 보내지 않도록 합니다.
이렇게 무중단 배포를 실현할 수 있는 거죠.
(DevOps의 오케스트레이션 대표적 도구인 쿠버네티스의 롤링 업데이트라는 기술이기도 합니다.)
캐시
캐시란 것은 사용자들이 조회했던 데이터들을 중간 prox 서버에 저장을 해두었다가
다시 그 데이터를 요청하면 서버까지 굳이 요청이 가지 않더라도 바로 응답할 수 있게 하는 기술입니다.
요기서 말하는 캐시는 리버스 프록시의 캐시인데요, 서버로 오는 요청에서 자주 반복적으로 찾을 만한 리소스들을
웹 서버에 위치시켜놓고 그에 대한 요청이 들어오면 바로 꺼내 주는 기술입니다.
이 또한 사용성을 증가시킬 수 있는 장점이죠.
이외에도 WAS와 WS를 분리시킴으로써 얻는 이득은 많습니다.
한 곳에 모든 기능을 집중시키기보다는 기능적으로, 역할적으로 분리시켜 놓는 것이
협업을 할 때에도, 유지보수를 할 때에도, 사용자에게 사용성을 증대시키는 것에도 많은 이득이 있죠.
마무리
WAS와 WS 둘 다 각각의 역할을 할 수 있지만
역할을 분리시킴으로써 각각의 할 일에 집중하게 하고, 각각이 더 잘할 수 있는 것을 전문화시켰다.
라고 정리할 수 있겠습니다.
WAS와 WS는 무조건 정적, 동적의 차이로 나누어지는 것이 아닙니다.
많은 글에서 WAS와 WS의 차이를 정적, 동적으로 나누는 것을 보고
저도 처음에 그런 줄 알았는데 다양한 글을 읽어보고 찾아봐야 하는 것이 중요하다는 것을 또다시 느꼈습니다.
밑의 얄코님의 유튜브 영상을 꼭 한번 봐보세요. 정말 이해하기 쉽게 설명을 잘 해놓으셨습니다!
링크는 아래에 첨부했습니다!
참고
'개발지식' 카테고리의 다른 글
[개발지식] Webpack과 Babel은 왜 쓰이는 건지 알고 계신가요? (0) | 2022.01.26 |
---|---|
[개발지식] 브라우저 저장소, 각각에 대해서 자세히 알고 계신가요? (0) | 2022.01.21 |
[개발지식] Client Side Rendering & Server Side Rendering 차이점에 대해서 아시나요? (0) | 2022.01.19 |
[개발지식] 브라우저 동작방식에 대해서 알고 계신가요? (0) | 2022.01.13 |
[개발지식] CORS, 잘 알고 계신가요? (0) | 2022.01.08 |