[부스트코스] 웹 프로그래밍을 위한 중요한 용어와 WAS

웹 프로그래밍을 공부하기 전에 몇 가지 중요 용어에 대한 이해가 필요하다.

 

클라이언트 / 서버 구조

클라이언트(Client)는 서비스(Service)를 제공하는 서버(Server)에게 정보를 요청하여 응답 받은 결과를 사용

서비스를 제공하는 것을 서버, 서버에게 서비스를 요청해서 그 결과를 보여주는 것을 클라이언트이다.

웹 서버 - 웹 브라우저가 대표적으로 서버 - 클라이언트의 관계이다.

 

 

DBMS(DataBase Management System)

다수의 사용자들이 데이터베이스 내의 데이터를 접근할 수 있도록 해주는 소프트웨어

DBMS가 등장하기 이전에는 개발자들이 파일의 데이터를 저장하고 읽어들이는 등의 기능을 모두 구현해야 했다.

이러한 불편함을 해결하기 위한 여러 가지 노력의 결과로 DBMS라는 소프트웨어가 등장 한 것이다.

 

대표적으로 MySQL, MariaDB, Oracle, PostgreSQL 등이 있고, 이로 인해 개발자들은 상대적으로 굉장히 쉽게 데이터를 관리할 수 있게 되었다.

 

DBMS는 보통 서버 형태로 서비스를 제공하기 때문에 DBMS에 접속해서 동작하는 클라이언트 프로그램이 한 때 많이 만들어졌다.

그런데 이러한 방식의 문제점은 클라이언트의 로직이 많아지고 클라이언트 프로그램의 크기가 커지는 다는 것이었다.

 

프로그램 로직이 변경 되면 클라이언트가 매번 배포되어야 하고, 대부분의 로직이 클라이언트에 포함되어 배포 되기 때문에 보안이 나쁘다는 문제점이 있었다.

 

그래서 등장한 것이 미들웨어다.

 

미들웨어(MiddleWare)

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

미들웨어는 클라이언트와 DBMS 사이에 또 다른 서버를 두는 방식이다.

 

- 클라이언트는 단순히 중앙의 서버에게 요청만 보내고

- 미들웨어에서는 대부분의 로직을 수행한다.

- 데이터 조작할 일이 있으면 DBMS을 이용하고

- 결과를 클라이언트에게 보여준다.

 

 

미들웨어가 가져온 이점

- 클라이언트의 복잡한 로직이 사라지고 사용자로부터 입력만 받아서 미들웨어에게만 보내고 결과를 받는 역할만 수행하면 되기 때문에 크기가 작아진다.

- 프로그램 로직이 변경되어도 모든 클라이어트를 다시 배포하지 않고 중앙의 미들웨어만 변경하면 된다.

 

 

WAS(Web Application Server)

일종의 미들웨어로 웹 클라이언트(보통 웹 브라우저)의 요청 중 보통 웹 애플리케이션이 동작하도록 지원하는 목적을 가짐.

 

WAS의 등장 배경

- 최초의 웹이 등장했을 때는 웹 브라우저는 정적인 데이터만 보여주었음

- 웹이 널리 사용되면서 사용자들의 요구사항이 늘어남

- 웹에서 데이터를 입력하고 조회하는 등의 동적인 기능 요구

- 동적인 기능은 프로그래밍을 통해서 가능했는데 점점 복잡한 프로그래밍적인 요구하게 됨. 보통 DBMS와 연관된 경우가 많았음

- 브라우저를 클라이언트라고 본다면 브라우저와 DBMS 사이에서 동작하는 미들웨어가 필요하게 된 것임.

- 이러한 미들웨어를 WAS라고 함

 

WAS가 가지는 중요한 기본 기능 세 가지

첫 번째, 프로그램 실행 환경과 데이터베이스 접속 기능을 제공

 

두 번째, 여러 개의 트랜잭션을 관리

      *트랜잭션은 논리적인 작업 단위

 

세 번째, 업무를 처리하는 비즈니스 로직을 수행

 

그 외에 다양한 기능을 제공. 웹 서버의 기능도 기본적으로 제공

 

WAS가 웹 서버의 기능도 제공한다면 WAS만 사용해도 되는 건가? YES!!

웹 서버 따로 WAS 따로 설치하지 않아도 톰캣이라는 WAS만 설치하고 이용 가능한 이유는 톰캣이 가지고 있는 웹 서버가 충분한 기능을 하고 있기 때문에 굳이 따로 Apache 같은 웹 서버를 같이 설치하지 않아도 됨.

 

웹 서버 vs WAS

• WAS도 보통 자체적으로 웹 서버 기능을 내장하고 있습니다.
• 현재는 WAS가 가지고 있는 웹 서버도 정적인 콘텐츠를 처리하는 데 있어서 성능상 큰 차이가 없습니다.
• 규모가 커질수록 웹 서버와 WAS를 분리합니다.
• 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성을 위해 웹서버와 WAS를 대체로 분리합니다.

웹 서버는 보통 정적인 콘텐츠를 웹 브라우저에게 전송하는 역할

WAS는 프로그램의 동적인 결과를 웹 브라우저에게 전송하는 역할을 담당

 

WAS 등장 초기에는 WAS에 내장된 웹 서버 성능이 떨어져서 같이 사용해야 했는데, 최근에는 웹 서버 없이 WAS만 있어도 정적인 콘텐츠와 동적인 콘텐츠를 제공할 수 있긴 함.

 

그럼에도 불구하고 웹 서버가 WAS 앞단에 있으면 좋은 이유?

- 웹 서버는 상대적으로 WAS보다 간단한 구조로 만들어져 있기 때문

 

WAS에서 동작하도록 개발자가 만든 프로그램이 오작동해 WAS 자체에 문제가 발생하는 경우 WAS를 재시작 해야한다.

(여러 대의 서버를 사용하는 대용량 웹 애플리케이션에서) 문제가 있는 WAS를 재시작할 때, 앞단의 웹 서버에서 먼저 해당 WAS를 이용하지 못하도록 하고, WAS를 재시작한다면 해당 웹 애플리케이션을 사용하는 사람은 WAS의 문제가 발생하였는지를 모르고 이용할 수 있다.

이러한 처리를 장애 극복 기능이라고 한다.

대용량 웹 애플리케이션에는 무중단으로 운영하기 위해서 상당히 중요한 기능으로 이러한 기능 때문에 보통 웹 서버가 WAS 앞단에서 동작하도록 하는 경우가 많다.

 

 

[관련 부스트코스 강의 링크] https://www.edwith.org/boostcourse-web/lecture/16666/