Spring MVC - 기반 지식 - 1. 웹 서버와 웹 애플리케이션 서버

시작하며

• 해당 파트는 스프링 MVC 라이브러리에 대해 알아본다.
• 그 이전에 선행적으로 알아두면 좋은 기반 지식들에 대해 간략히 알아보도록 하자.

 

 

웹 서버(Web Server)

• 현재 웹은 HTTP를 기반으로 하여 쌓아올려졌다. HTTP는 클라이언트 - 서버의 구조로 이루어지는데 이 서버의 종류 중 하나인 웹 서버에 대해 살펴본다.
• 웹 서버는 HTTP를 기반으로 동작하며 정적 리소스(static resources)를 제공하고, 기타 부가적 기능을 제공한다. 메인 기능으로는 정적 리소스를 클라이언트에게 반환하는 것이다.
  • 이때 정적 리소스에 대해 무엇인지에 대해 생각해야 할 필요가 있다.
  • 정적 리소스는 클라이언트에게서 받은 요청에 대한 리소스가 이미 만들어져 있어 해당 리소스를 이미 반환하는 경우를 말한다. 이런 경우는 보통 요청에 따라 변경이 되지 않는 말 그대로 정적인 데이터들을 말한다.
  • 예를 들자면 웹 사이트의 이미지, CSS나 영상같은 것들은 요청에 의해 거의 변하지 않는다. 따라서 클라이언트가 해당 데이터들을 요청하면 별도의 가공 없이 그대로 응답으로 반환하면 된다.
• 이러한 웹 서버는 대표적으로 APACHE(아파치), NGINX가 있다.

 

 

 

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

• 웹 어플리케이션 서버는 웹 서버와 동일하게 HTTP 기반으로 동작한다.
• 그리고 웹 서버의 기능을 포함한다. 즉 웹 애플리케이션 서버에서도 정적 리소스 제공이 가능하다.
• 하지만 다른점이 있는데 프로그램 코드를 실행하여 애플리케이션에 있는 로직을 수행하는것이 가능하다는 것이다. 애플리케이션의 로직을 수행함으로서 동적 리소스들을 반환할 수 있다.
  • 동적 리소스는 위의 정적 리소스와는 반대되는 개념으로 요청에 의해 변화될 수 있는 리소스들을 말한다.
  • 이러한 리소스들은 동적 HTML 또는 HTTP API등이 있으며 이를 활용한 것들이 서블릿, 스프링 MVC, JSP이다.
• 이러한 웹 애플리케이션 서버들은 가장 대표적으로는 우리가 사용하는 톰캣이 있다.

 

 

 

웹 시스템의 구성

Client - WAS - DB 구조

• 웹 시스템은 클라이언트가 서버에 요청을 보내고 응답을 받는 전체적인 그림이 된다. 이 시스템은 먼저 클라이언트의 요청을 받고 정적 리소스를 반환할 수 있는 동시에 동적인 리소스도 처리가 가능한 WAS가 필요할 것이다.
• 또한 여러 데이터들을 저장하고 불러올 데이터베이스 또한 필요할 것이다. 따라서 가장 기초적으로 웹 시스템을 구성한다면 다음과 같이 할 수 있다.

Client - WAS - DB 구조의 한계

• 구조를 보면 알겠지만 클라이언트의 모든 요청을 WAS에서 처리한다. 즉 정적 요청도 처리하는 동시에 동적 리소스에 대해서도 처리해야 한다.
• 즉 하나의 파츠에 너무 많은 역할을 담당하게 하고 있다. 이는 바람직하지 않고, 여러 정적 리소스 처리 요청 때문에 정작 중요한 애플리케이션 로직을 처리하지 못할 수 있다.
• 또한 WAS에 장애가 일어날 시에 이에 대한 알림(notice)을 하기 위해 오류 화면을 넘겨 주어야 하는데 정적 리소스를 넘기는 것도 WAS에서 수행하고 있기 때문에 오류 화면도 노출시키기가 불가능하다는 한계점이 존재한다.

Client - WEB - WAS - DB 구조

• 위의 한계점들은 결국 하나의 중요한 원인 떄문에 발생한다. 바로 WAS 하나에 너무 많은 역할을 요구하고 있는 것이다. 하나의 파츠는 하나의 역할만을 주어 그 역할에 모든 역량을 집중할 수 있도록 하는 것이 효율적이다.(이는 객체지향적 설계에도 적용된다.)
• 따라서 기존에 정적 리소스의 처리와 동적 리소스 처리를 모두 도맡아 하던 것을 분리하여 정적 리소스를 처리하는 파츠와 동적 리소스를 처리하는 파츠로 나누면 좋을 것 같다.
• 그런데 위에서 각 역할에 맞는 파츠들을 보았다. 바로 웹 서버이다. 정적 리소스를 처리하는 부분은 웹 서버가, 애플리케이션 로직을 수행해야 하는 경우 WAS로 요청을 넘기도록 하면 WAS는 로직을 처리하는 것만 담당하면 되기 때문이다.

• 이 구조를 사용할 경우에 위에 있는 한계점들을 해결할 수 있다.
  • 정적 리소스 처리 때문에 어플리케이션 로직이 처리되지 않을 수 있는 현상은 정적 리소스 처리는 웹 서버에서 모두 처리하도록 하고 있어 WAS 쪽에 부하가 걸리지 않으므로 이런 현상이 일어나지 않는다.
  • WAS에 장애가 발생하였을 시에도 정적 리소스를 처리하는 웹 서버측은 장애가 발생하지 않았기 때문에 에러 페이지를 띄워 클라이언트에게 문제가 발생했음을 알릴 수 있다.
• 또한 추가적인 장점을 가져가는데 각각의 부하를 측정하여 파트별로 증설해야 할 서버들을 마련할 수 있다는 것이다.
  • 만약 정적 리소스를 내려주는 웹 서버에서 부하가 많이 걸린다면 웹 서버를 추가적으로 증강하면 된다. 굳이 WAS까지 증강시켜줄 필요가 없다
  • 반대의 상황에도 WAS 서버만 증강시키면 되기 때문에 굳이 웹 서버를 증강시킬 필요가 없다. 이는 효율적으로 리소스를 관리할 수 있으며 비용 측면에서도 매우 효율적이다.