[Spring MVC 1편] 1. 웹 애플리케이션 이해 - 웹 서버, 웹 애플리케이션 서버

 

본 내용은 인프런 사이트에서
김영한 선생님의 "스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술" 강의 내용을 정리한 것입니다.

 

 

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

💡 웹 - HTTP 기반

 

웹 브라우저(클라이언트)에서 URL을 입력하면 인터넷을 통해 서버에 접근하고, 서버에서는 HTML을 만들어 클라이언트에게 전달해 우리에게 화면을 띄워준다. 이러한 과정은 전부 HTTP 프로토콜을 기반으로 동작하게 된다.

 

💡 모든 것이 HTTP

HTTP 메세지에 모든 것(거의 모든 형태)을 전송할 수 있다.

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML (API)
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

 

💡 웹 서버 (Web Server)

• HTTP 기반으로 동작하는 서버이고, 정적 리소스와 기타 부가기능을 제공한다.
• 정적 리소스: HTML, CSS, JS, 이미지, 영상
• ex. NGINX, APACHE

 

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

• HTTP 기반으로 동작하는 서버이고, 웹 서버 기능을 포함하고 있다.
• 프로그램 코드를 실행해서 애플리케이션 로직을 수행한다. (*웹 서버와의 큰 차이)
  • 동적 HTML, HTTP API(JSON)
  • 서블릿, JSP, 스프링 MVC
• ex. 톰캣(Tomcat) Jetty, Undertow

 

💡 Web Server  vs  WAS

• 웹 서버는 정적 리소스(파일), WAS는 애플리케이션 로직으로 분류하지만 사실은 둘의 용어도, 경계도 모호하다.
  • Web Server도 프로그램을 실행하는 기능을 포함하기도 함.
  • WAS도 웹 서버의 기능을 제공함.
• 결과적으로! WAS는 애플리케이션 코드를 실행하는데 더 특화되어 있다라고 생각하면 된다.

 

💡 웹 시스템 구성

Q. 실무에서 용도가 어떻게 나눠지지?

 

1. WAS, DB

 

최소한으로 WAS(*정적리소스, 애플리케이션 로직 모두 제공하기 때문)와 DB만으로 시스템을 구성할 수 있지만 단점이 존재한다.

• WAS가 너무 많은 역할을 담당하여 서버가 과부하 될 수 있다.
• 가장 비싼 애플리케이션 로직이 정적 리소스기 때문에 수행하기 어려울 수 있다.
• WAS에 장애가 생기면 오류 화면도 노출이 불가능하다.

 

2. WEB, WAS, DB

 

위의 단점을 보완하기 위해 일반적으로 WEB, WAS, DB로 시스템을 구성한다.

정적 리소스는 Web Server에서 처리하고, 애플리케이션 로직(동적 처리) 처리가 필요하면 WAS에 요청을 위임하여 WAS는 중요한 애플리케이션 로직 처리만 전담한다.

 

이러한 시스템 구성은 다음과 같은 장점을 가진다.

• 효율적인 리소스 관리가 가능하다.
  • 정적 리소스가 많이 사용되면 Web 서버 증설
  • 애플리케이션 리소스가 많이 사용되면 WAS 증설
• 정적 리소스만 제공하는 웹 서버는 잘 죽지 않기 때문에 WAS, DB 장애시 Web Server가 오류 화면을 제공할 수 있다.
  • 애플리케이션 로직이 동작하는 WAS 서버는 잘 죽음
  • ex. 개발자가 로직을 잘못 짠 경우, DB가 죽은 경우 등 여러가지 이유 존재

 

*추가

만약, API 서버만 제공하게 되면? (화면을 제공하지 않고 API로 데이터만 제공)

→ Web Server가 없이 WAS만 구축해도 괜찮다.