데이터를 요청하는 기기 혹은 소프트웨어를 클라이언트라고 하고 제공하는 것을 서버라고 합니다.
DBMS (database management system)
DBMS 와 클라이언트에 대해서 이해해 봅시다. DBMS 는 데이터베이스를 관리하는 시스템을 의미합니다. DBMS 가 등장하기 이전에는 파일에 데이터를 저장하고 읽어내는 기능을 일일이 개발해야 했습니다. 이런 불편함을 해결하기 위한 노력의 결과로 DBMS 가 등장하게 되었습니다. DBMS 의 최초의 개념은 IBM 에서 논문으로 등장했습니다. 최초의 구현은 Oracle 에서 하였습니다. DBMS 에는 다양한 제품들이 존재합니다. 대표적으로 mySQL, MariaDB, Oracle, postgres 등이 있습니다. DBMS가 등장하면서 개발자들은 굉장히 쉽게 데이터베이스를 관리할 수 있게 되었습니다. 마치 메모장을 쓰다가 엑셀을 쓰게 된 수준이었습니다. DBMS 는 서버 형태로 서비스를 제공하기 때문에 DBMS 에 접속해서 만들어진 제품이 많아졌었습니다. 그런데, 이러한 방식의 문제점은 클라이언트의 로직이 많아지고 클라이언트 프로그램이 커지는 문제가 발생했습니다. 프로그램 로직이 변경이 되면 클라이언트가 매번 배포되어야 한다는 문제가 있었고 대부분의 로직이 클라이언트에 포함되어 배포되기 때문에 보안의 문제도 발생하였습니다. 그래서 등장한 것이 미들웨어 입니다.
미들웨어 MiddleWare
미들웨어는 DBMS 의 등장 이후 발생한 문제점에 대응하기 위해 개발되었습니다. 클라이언트 쪽에 비즈니스 로직이 많을 경우, 클라이언트 관리(배포 등)로 인해 비용이 많이 발생 하게 되면서 미들웨어가 개발되었습니다. 미들웨어는 정확하게는 미들웨어 서버를 의미하는데 클라이언트와 DBMS 사이에 위치하게 됩니다. 기존 클라이언트가 수행하던 비즈니스 로직을 미들웨어 서버에서 동작하게 함으로써 클라이언트는 입력과 출력만 담당하도록 한 것을 의미합니다. 클라이언트는 단순히 요청만 중앙 서버(미들웨어)에 보내게 되고 중앙에 있는 서버(미들웨어)는 대부분의 로직을 수행하게 됩니다. 이때 데이터를 조작할 일이 있으면 DBMS 에게 요청하고 그 결과를 클라이언트에게 전송하면 클라이언트는 그 화면을 보여주게 됩니다. 클라이언트는 복잡한 로직이 사라지고 사용자로부터 입력만 받아서 미들웨어에게만 보내고 미들웨어가 처리한 로직의 결과만 화면에 보여주면 되도록 바뀌게 되면서 크기가 매우 작아지게 되었습니다. 프로그램 로직이 변경이 되더라도 모든 클라이언트를 다시 배포할 필요 없이 미들웨어만 변경하면 되는 장점을 가지게 되었습니다.
WAS (Web Application Server)
최초의 웹이 등장하였을 때는 정적인 웹만 사용자에게 보여주었습니다. 사용자에게 딱 변하지 않는 이미지와 문서들을 보여주는 것만으로도 충분했었습니다. 하지만 사용자들의 요청이 늘어남에 따라 웹에서 데이터를 입력하고 조회하는 등의 동적인 기능을 요구하게 되었습니다. 동적인 기능은 프로그램을 통해서 가능했습니다. 웹 서버에서 프로그래밍 기능이 들어가는 것을 CGI 라고 불렀었습니다. CGI 는 단순한 프로그램에서 사용할 때 별 문제가 없었습니다. 하지만 웹은 점점 더 복잡해져갔고 복잡한 프로그램 기능을 요구하게 되었습니다. 보통 이런 기능들은 DBMS와 연관된 경우가 많기도 했습니다. 브라우저를 클라이언트로 본다면 브라우저와 DBMS 사이에서 동작하는 미들웨어가 필요하게 되었습니다. 이러한 미들웨어를 WAS 라고 부릅니다. WAS 는 넓게 보면 미들웨어에 포함된다고 볼 수 있습니다. WAS 가 가지는 3 가지 중요한 기능이 있습니다. 첫 번째는 프로그램 실행 환경과 데이터 접속 기능을 제공한다. 두 번째는 여러 개의 트랜잭션을 관리한다. 세 번째는 업무를 처리하는 비즈니스 로직을 수행한다. 트랜잭션은 논리적인 작업단위라고 할 수 있습니다. 뒤에서 데이터베이스를 설명할 때 조금 더 자세히 설명할 예정입니다. 이 외에도 WAS 는 다양한 기능을 수행합니다. 웹 서버를 기본적으로 제공합니다. 웹 서버 따로 WAS 따로 설치하지 않고 Tomcat 이라는 WAS 만 설치하면 웹이 동작하는 이유는 이 Tomcat 이라는 WAS 가 충분한 기능을 하고 있기 때문에 따로 Apache 라는 웹 서버를 설치하지 않고 Tomcat 만 설치해서 사용했던 것입니다.
웹 서버 vs WAS
현업에서는 위와 같은 형태로 구성하는 경우가 많습니다. 웹 서버는 보통 정적인 컨텐츠를 웹 브라우저에게 전송하는 역할을 수행하고, WAS 는 프로그램의 동적인 결과를 전송하는 역할을 담당합니다. 프로그램이 동작해서 얻은 결과를 동적인 컨텐츠라고 말하기도 합니다. WAS 가 제공하는 웹 서버의 기능도 웹 서버가 제공하는 기능에 비해서 떨어지지 않습니다. 그렇다면 웹 서버가 없어도 될 까요? 사실 웹 서버 없이 WAS 만 있어도 정적인 컨텐츠와 동적인 컨텐츠 모두 제공할 수 있습니다. WAS 등장이 초창기였을 때는 WAS 내장 서버의 성능이 떨어졌었습니다. 그래서 Web Application 을 실행할 때 Apache 와 Tomcat 을 같이 설치해서 진행을 했었는데, WAS 가 계속 발전하면서 웹 서버의 역할도 잘 수행하게 되었기 때문에 웹서버를 따로 설치하지 않아도 충분해졌습니다. 그럼에도 불구하고 웹 서버가 WAS 앞 단에 있으면 좋은 점이 있습니다. 웹 서버는 WAS 보다 간단한 구조로 만들어져있습니다. 사람들이 많이 접속하는 대용량 Web Application 에 경우에는 서버가 여러 대일 수 있습니다. WAS 에서 동작하도록 만든 프로그램이 오작동을 하여 WAS 자체의 문제가 발생하는 경우도 있습니다. 이 경우 WAS 를 재시작해야 하는 문제가 발생하는데요. 이 경우 앞 단의 웹 서버에서 해당 WAS 를 이용하지 못하게 하고 WAS 를 재시작한다면 해당 웹 Application 을 사용하는 사람은 WAS 가 문제가 발생했는지 모르고 사용할 수 있게 됩니다. 이러한 처리를 장애 극복 기능 (Failover) 이라고 합니다. 대용량 Web Application 에서는 무중단으로 이용하기 위해서 사용하게 되는 중요한 기능입니다. 장애 극복 기능을 활용하기 위해서 웹 서버를 WAS 앞단에서 사용하는 경우가 많습니다.
