웹서버, 웹 애플리케이션 서버

서버라는 것은 요청이 들어오면 그에 대한 응답을 해준다라는 것은 알고 있지만 보통 프로젝트를 진행하면서 WAS에 서버 코드를 올렸었는데 WAS 가 무엇인지도 정확히 모르면서 사용을 하고 있어 정리하였습니다.

 

웹서버

우리가 브라우저에 접속해서 www.google.com  을 입력하면 어떻게 될까요?

구글의 서버에 HTTP 통신으로 구글 서버에 있는 컴포넌트 파일(HTML, JS, CSS..)을 요청을 통해서 가져옵니다.

그러면 우리의 브라우저는 가져온 컴포넌트 파일을 이용해서 화면을 띄우게 됩니다.

 

사실 우리 컴퓨터도 서버가 될 수 있습니다.

아파치 HTTP 서버를 이용해서 우리 컴퓨터의 어느 폴더에 HTML, CSS, JS 등과 같은 파일들을 넣어두고 폴더를 세상 사람들에게 공개를 하면 HTTP 통신을 통해서 우리 폴더의 컴포넌트 파일들을 들고 가도록 하면 됩니다.

이렇게 우리는 이미 정해진 양식의 템플릿을 HTTP 통신으로 주고받을 수 있습니다.

이것을 보통 "정적이다" 라고 표현합니다.

그 안의 내용물이 바뀌지 않고 만들어놓은 그 상태 그대로 전달하고 읽는 것이죠.

 

하지만 현실의 많은 웹사이트들은 정적인 콘텐츠뿐만 아니라 데이터베이스에서 데이터를 들고 와서 HTML 템플릿을 채우고 있습니다.

또는 새로운 게시글을 쓰거나, 삭제, 편집과 같은 데이터베이스를 조작하는 많은 일을 웹사이트에서 수행합니다.

당장의 이 블로그만 해도 만들어진 HTML 템플릿에 데이터베이스에서 받은 데이터로 HTML을 채워 우리에게 보여줍니다.

이 경우 "동적이다" 라고 표현합니다.

 

HTML, CSS, JS 뿐만 아니라 동적인 콘텐츠를 제공하기 위해서 Apache의 모듈을 이용해 웹 서버에 요청이 들어오면, PHP에 적힌 코드대로 MySQL의 안에 있는 데이터를 가져와서 Apache 가 요리를 해주는 그런 방식, Apache + PHP + MySQL을 이용해서 사용자에게 동적인 콘텐츠를 많이 제공했다고 합니다.

 

그러면 웹 서버는 위와 같은 역할을 한다는 것을 대충은 알겠는데 그럼 웹 애플리케이션 서버(WAS) 는 무엇일까요?

웹과 서버 사이에 애플리케이션이 들어갔습니다. 무언가 동작하는 프로그램이 있다는 뜻으로 유추할 수 있습니다.

서버로 요청이 들어오면 단순히 뭘 갖다 주는 것이 아니라 뭔가 프로그래밍된 걸 더 한다 는 의미입니다.

웹 서버도 단순히 PHP 같은 간단한 작업들은 할 수 있지만, 스프링 같은 것들은 조금 더 전문적인 웹앱 서버(WAS)의 힘을 빌려야 합니다.

공통적인 것은 프로그래밍 언어마다 WAS라고 부르진 않지만 WAS의 역할을 하는 친구들이 웹 서버 뒤에서 일을 하고 있는 것입니다.

 

정적, 동적으로 WAS, WS를 구분?

 

여러 페이지를 조사해 본 결과 정적 vs 동적으로 웹 서버와 웹앱 서버를 많이 나워서 설명합니다.

WAS는 동적이고, WS는 정적이다라고 단정 지어 설명합니다.

이것은 정확하게 말하면 틀린 설명입니다.

 

현재 많은 프로젝트가 WAS 는 동적 콘텐츠를 제공하고 WS 는 정적 콘텐츠를 제공하도록 설계를 합니다.

웹 서버가 정적인 콘텐츠만 제공할 수 있어서 또는 웹앱 서버는 동적인 콘텐츠만 제공할 수 있어서 그런 것은 아닙니다.

웹 서버도 위의 설명과 같이 동적인 콘텐츠를 제공을 할 수 있고, 웹앱 서버 또한 정적인 콘텐츠를 제공할 수 있습니다.

하지만 굳이 WS, WAS를 분리해서 개발하는 것은 이 설계가 장점이 많고 구조적으로 이득이 많아 하는 것입니다.

 

많은 프로젝트에서 웹서버(WS)를 앞단에 둬서 요청을 맞이하고, 웹앱 서버(WAS)를 그 뒤에 두어 요청을 처리하고 있습니다.

이 구조의 장점은 무엇일까요?

 

WAS, WS를 분리시키는 이유

 

리버스 프록시

프록시는 중간서버, 중개자라고 말합니다.

보통은 프록시를 통해 사용자들이 정보를 감출 수 있게 하지만 리버스 프록시는 반대입니다.

들어오는 요청들로부터 서버의 정보를 감출 수 있습니다.

서버라는 큰 집의 주소만 사용자들에게 공개하고, 집의 내부는 감추는 것입니다.

정적 리소스들은 어디에 있는지, 동적요소들은 어디에서 제공되는지, 서비스가 몇 번 포트로 돌아가는지, 서버 내부적으로 파일들이 어느 폴더에 들어가 있는지와 같은 정보들을 드러내지 않게 합니다.

 

아파치나 Nginx 와 같은 웹 서버인 앞단의 친구들이 대신 자원을 가져오고 자원을 사용자들에게 보내줍니다.

이렇게 역할을 분리시킴으로써 보안을 강화시킬 수 있습니다.

 

로드밸런싱

프로젝트가 점점 커져 웹사이트에 들어오는 요청이 많아지면 하나의 웹앱 서버에 모든 요청에 대한 처리를 맡기면 서버의 성능이 떨어지게 됩니다.

 

그래서 하나의 웹앱서버에 모든 요청을 보내지 않고, 한 프로젝트에 웹앱 서버를 여러 개를 두어 처리를 분산시킬 수 있습니다.

그러면 자연스럽게 속도 증가와 같은 성능 향상을 할 수 있는 것입니다.

 

또한 지속성과 관련된 이점을 얻을 수 있습니다.

만약 프로젝트가 업데이트가 되어서 동적 부분, 즉 WAS까지 업데이트를 해주어야 하는 경우에는 구동시키고 있는 WAS를 멈추고 업데이트를 해야 합니다.

아주 잠깐의 시간이지만 만약 사용자가 업데이트를 하는 도중에 접근을 하려고 하면 사용자는 에러를 맞게 됩니다.

그러면 사용성이 떨어지고 고객은 떠나겠죠.

그래서 하나하나의 WAS 를 업데이트시키면서, 업데이트 중인 WAS는 웹서버(WS)가 요청을 보내지 않도록 합니다.

이렇게 무중단 배포를 실현할 수 있는 것이죠.

 

캐시

캐시란 것은 사용자들이 조회했던 데이터들을 중간 서버에 저장을 해두었다가 다시 그 데이터를 요청하면 서버까지 굳이 요청이 가지 않더라도 바로 응답할 수 있게 하는 기술입니다.

여기서 말하는 캐시는 리버스 프록시 캐시입니다. 서버로 오는 요청에서 자주 반복적으로 찾을 만한 리소스들을 웹 서버에 위치시켜 놓고 그에 대한 요청이 들어오면 바로 꺼내 주는 기술입니다.

이 또한 사용성을 증가시길 수 있는 장점이 있습니다.

 

결론

WAS 와 WS 둘다 각각의 역할을 할 수 있지만 역할을 분리시킴으로써 각각의 할 일에 집중하게 하고, 각각이 더 잘할 수 있는 것을 전문화시켰다. 라고 정리할 수 있습니다.

 

WAS 와 WS 는 무조건 정적, 동적의 차이로 나누어지는 것은 아닙니다.