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

😉 : ‘스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술’ 공부 기록 입니다.
이미지 출처 : 스프링 MVC 1편 강의자료 (문제 시, 이미지는 삭제될 수 있습니다.)

웹 세상에서는 모든 것들이 다 HTTP를 기반으로 데이터를 주고 받습니다. HTTP는 HTML, TEXT, IMAGE, 음성, 영상 파일 등 거의 모든 형태의 데이터들을 전송할 수 있고, 서버간에 데이터를 주고 받을 때에도 대부분 HTTP를 사용합니다.

웹 서버 (Web Server)

웹 서버는 HTTP 기반으로 동작합니다. HTML, CSS, JS, 이미지, 영상 등의 정적 리소스를 제공하며, 캐싱, 리다이렉션 등의 기타 부가기능을 제공하기도 합니다.
대표적으로 NGINX, APACHE가 있습니다.

웹 애플리케이션 서버 (WAS - Web Application Server)

WAS 또한 HTTP 기반으로 동작합니다.
웹 서버처럼 정적 리소스를 제공할 수 있고, 더 나아가 프로그램 코드를 실행해서 애플리케이션 로직을 수행할 수 있습니다. 즉, 사용자에 따라 동적으로 화면을 보여줄 수 있다는게 특징입니다. 대표적으로 톰캣 Jetty, Undertow가 있습니다.

위의 두 개념을 완벽하게 분리하기는 어렵습니다. 웹 서버도 프로그램을 실행하는 기능을 포함하기도 하고, WAS로 웹 서버의 기능을 제공하기 때문입니다. 단지 WAS는 애플리케이션 코드를 실행하는데 더 특화되었다고 볼 수 있습니다.

웹 시스템 구성 : WAS, DB

WAS와 DB만으로도 시스템을 구성할 수 있습니다. WAS는 정적 리소스, 애플리케이션 로직 모두 제공 가능하기 때문입니다. 하지만 이 경우 WAS가 너무 많은 역할을 담당하여 서버 과부하 가능성이 있습니다. 또한, 단순하게 정적 리소스만을 제공하는 작업 때문에 비싼 애플리케이션 로직 수행이 어려울 수 있습니다. 제일 중요한 부분은, 만약 WAS 서버에 과부하가 발생하여 장애가 났다고 하더라도 정적 리소스인 오류 화면조차 노출할 수 없다는 점입니다.

웹 시스템 구성 : WEB, WAS, DB

위의 시스템의 단점을 극복하기 위해 보통은 이렇게 세 단계로 웹 시스템을 구성합니다. 제일 앞 부분에 웹 서버가 위치하여 정적 리소스를 처리합니다. 만약 애플리케이션 로직이 필요한 요청이라면, 웹 서버는 WAS에 요청을 위임합니다. 이를 통해 WAS는 중요한 애플리케이션 로직 처리만 할 수 있어, 첫 번째 시스템 구성에 비해 서버 과부하 가능성이 줄어들게 되었습니다. 또한, 효율적인 리소스 관리가 가능해졌습니다. 정적 리소스 요청이 많이 들어온다면 웹 서버를 증설하고, 애플리케이션 리소스가 많이 사용된다면 WAS를 증설하면 됩니다. 그리고 WAS 서버 장애 시에도 웹 서버를 통해 정적 리소스인 오류 화면을 노출 할 수 있어, 위의 시스템의 가장 중요한 단점을 극복 할 수 있습니다.

+ SSR, CSR이란?

서버가 제공하는 리소스 관련된 부분을 보다보면 SSR, CSR이라는 단어를 마주치는 경우가 있습니다. SSR은 서버 사이드 렌더링으로 최종 HTML을 서버에서 만들어서 웹 브라우저에 전달하는 것을 말합니다. 주로 정적인 화면에 사용하고, 예시로는 타임리프가 있습니다.

서버사이드 렌더링

CSR은 클라이언트 사이드 렌더링으로 HTML 결과를 웹 브라우저에서 동적으로 생성해서 적용하는 것을 말합니다. 주로 동적인 화면에서 사용합니다. 예시로는 React, Vue.js 등이 있습니다. 클라이언트 사이드 렌더링