Web Server & WAS

Web Server

웹 브라우저를 실행한 후 주소 입력창에 URL 주소를 입력하면, 그 URL주소에 해당하는 결과물이 화면에 보입니다. 우리가 현실에서 주소를 보고 집을 찾아가는 것처럼, 웹 브라우저는 URL 주소에 해당하는 웹서버(Web Server)에 연결하고, 해당 주소에서 볼 수 있는 내용을 읽어 들여 보여주게 됩니다.

웹 서버는 소프트웨어(Software)를 보통 말하지만, 웹 서버 소프트웨어가 동작하는 물리적인 단위의 컴퓨터를 말하는 경우도 있습니다. 웹 서버의 가장 중요한 기능은 클라이언트(Client)가 요청하는 HTML 문서나 각종 리소스(Resource)를 전달하는 것입니다.

웹 브라우저나 웹 크롤러가 요청하는 리소스는 주로 컴퓨터에 저장된 정적(static)인 (i.e. 이미지, HTML파일, CSS파일) 데이터 이지만, 웹 서버에서 만들어진 동적인 결과물이 반환되는 경우도 있습니다. 이러한 정보는 웹 소프트웨어에서 HTTP 프로토콜을 사용하여 전송 됩니다.

동작과정

1) 웹 브라우저가 www.naver.com이라는 웹서버로 접속 → 해당 주소 기본 HTML 요청
2) 웹 서버는 사용자가 요청한 HTML 문서를 웹 브라우저에게 전달
3) 웹 브라우저는 전송받은 HTML 문서를 알맞게 보여주기 위해 필요한 이미지, CSS, JS 리소스들에 URL을 추출
4) 해당 URL 맞은편에 있는 웹서버에게 동시에 여러 개의 리소스 요청
5) 웹 서버는 동시에 요청받은 결과(이미지, CSS, JS)를 다시 브라우저에게 전송
6) 웹 브라우저는 아까 해석했던 HTML과 다시 요청한 여러개의 응답을 하나로 합쳐서 화면에 렌더링

종류

가장 많이 사용하는 웹 서버는 Apache, Nginx, Microsoft IIS 등이 있습니다. Apache웹 서버는 Apache Software Foundation에서 개발한 웹서버로 오픈소스 소프트웨어(Open-source Software)이며, 거의 대부분 운영체제에서 설치 및 사용을 할 수 있습니다. Nginx는 차세대 웹서버로 불리며 더 적은 자원으로 더 빠르게 데이터를 서비스하는 것을 목적으로 만들어진 서버이며 Apache웹 서버와 마찬가지로 오픈소스 소프트웨어입니다.

Web Application Server

DBMS(Database Management System)

DBMS는 데이터베이스를 관리하는 시스템으로, 다수의 사용자가 데이터베이스 내의 데이터에 접근할 수 있도록 해주는 소프트웨어입니다. DBMS가 등장하기 이전에는 개발자들이 파일의 데이터를 저장하고 읽어들이는 기능을 모두 구현해야 했습니다.

DBMS가 등장하면서 개발자들은 상대적으로 굉장히 쉽게 데이터를 관리할 수 있게 되었는데, 대표적인 DBMS로는 MySQL, MariaDB, Oracle, PostgreSQL 등이 있습니다. 

DBMS는 보통 서버 형태로 서비스를 제공하기 때문에, 이러한 DBMS에 접속해서 동작하는 클라이언트 프로그램이 한 때 많이 만들어졌습니다. 하지만 이런 식으로 DBMS를 클라이언트가 직접 연결하여 사용하게 되면, 클라이언트 프로그램의 크기가 커지고, 데이터 접근에 관련된 로직이 클라이언트에 포함되어 배포가 되기 때문에 보안이 나쁘다는 문제점을 가지고 있었습니다.

이러한 문제점들을 해결하기 위하여 등장한 것이 미들웨어라는 개념 입니다.

Middleware Server

클라이언트 쪽에 비즈니스 로직이 많을 경우, 클라이언트 관리(배포 등)로 인해 비용이 많이 발생하는 문제가 있습니다. 비즈니스 로직을 클라이언트와 DBMS사이의 미들웨어 서버에서 동작하도록 함으로써 클라이언트는 입력과 출력만 담당하도록 합니다. 

미들웨어 서버 역시 데이터를 조작할 일이 있으면 DBMS에게 부탁을 하게 되고, 받은 결과를 다시 클라이언트에게 전송하는 식 입니다. 클라이언트는 복잡한 로직이 사라지고 단순히 미들웨어에게 요청하고 결과만 보여주면 되기 때문에 크기가 프로그램이 간단해 지게 됩니다. 

또한, 프로그램의 로직이 변경된다 하더라도 모든 클라이언트를 다시 배포할 필요가 없이 중앙의 미들웨어 서버만 변경하면 되는 장점을 가지게 됩니다.

WAS(Web Application Server)

최초의 웹이 등장했을 때는 웹 브라우저는 정적인 데이터만 보여주었습니다. 웹 서비스가 점점 발전하면서, 데이터를 입력하고 조회하는 등의 동적인 기능을 요구하게 되었고, 이러한 기능은 프로그래밍을 통해서 가능하게 되었습니다.

웹 서버에서 프로그래밍 기능이 들어가는 방식을 CGI(Common Gateway Interface)라고 불렀습니다. CGI는 단순한 프로그래밍시에는 별 문제가 없었지만, 규모가 더 커지면서 더 복잡한 프로그래밍 기능을 요구하게 되었습니다.

보통 이러한 복잡성은 대부분 DBMS와 연관된 경우가 굉장히 많았는데, 이는 필연적으로 클라이언트(브라우저)와 DBMS 사이에서 동작하는 미들웨어 서버에 필요성을 대두 시키게 됩니다. 이러한 복잡한 프로그래밍을 담당하는 미들웨어 서버를 WAS라고 합니다.

WAS의 기능 중 첫 번째는 프로그램 실행 환경과 데이터베이스 접속 기능을 제공하는 것이고, 두번 째는 여러개의 Transaction을 관리하는 것, 마지막으로는 전체 어플리케이션에 비즈니스 로직을 담당한다는 것 입니다.

WAS도 보통 자체적으로 웹 서버 기능을 내장하고 있습니다. 현재는 WAS가 가지고 있는 웹 서버도 정적인 콘텐츠를 처리하는 데 있어서 성능상 큰 차이가 없습니다. Tomcat이라는 WAS하나만 설치를 하더라도 Tomcat이 가지고 있는 웹 서버가 충분한 기능을 하기 때문에, 굳이 Apache 같은 웹 서버를 같이 설치하지 않아도 웹서비스를 제공할 수 있습니다.

WAS 등장 초창기에는 WAS에 내장된 웹 서버가 성능이 좀 떨어졌었지만, 현재는 충분히 성능이 괜찮기 때문에 WAS만으로도 서비스 제공은 가능합니다. 그럼에도 불구하고, 웹 서버가 WAS 앞단에 있으면 좋은 이유가 있습니다.

WAS에서 동작하는 프로그램이 오작동하는 경우 WAS를 재시작해야 하는 경우가 생길 수 있는데, 문제가 있는 WAS를 재시작 할때, 앞단의 웹서버에서 먼저 해당 WAS를 이용하지 못하도록 하고, WAS를 재시작한다면 해당 웹 어플리케이션을 사용하는 사람은 문제 없이 사용할 수 있게 됩니다. 대용량 웹 어플리케이션에서 무중단 운영을 위해서는 필수적인 요소라고 할 수 있습니다.

규모가 커질수록 웹 서버와 WAS를 분리하는데 이는 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성을 위해서 입니다. 이러한 구성도에서 웹 서버는 보통 정적인 콘텐츠를 웹 브라우저에게 전송하는 역할을 하고, WAS는 프로그램의 동적인 결과를 웹 브라우저에게 전송하는 역할을 하게 됩니다.