Web Server와 Web Application Server

배경

wanted에서 진행하는 스터디를 하면서 사전 과제를 다음과 같은 구조로 구현했었다.

해당 부분에서 더 개선할게 없는지 찾아보던 중 web server를 사용하면 고가용성을 얻을 수 있다는 글을 읽고 내가 구현한게 web server가 아닌가? 생각하게 되었고, 용어를 확실하게 알고 있기 위해 공부를 하게 되었다.

Web Server

• 웹 서버는 클라이언트로부터 HTTP(HyperText Transfer Protocol) 요청을 받아들이고, 해당 요청에 따라 정적 컨텐츠를 제공한다.
• 여기서 말하는 정적 컨텐츠란 이미지나 스타일 같이 어느 조건에서나 동일한 컨텐츠를 말한다.
  • 특히 이미지 같은 정적 컨텐츠는 응답으로 한번에 보내지는게 아니라 클라이언트가 HTML을 받고 필요한 이미지들을 서버에 요청해서 받아오는 것.

    대표적인 웹 서버의 기능

    • 저장된 웹 리소스를 클라이언트로 전달
    • 클라이언트로부터 콘텐츠를 저장하거나 처리
    • 동적인 요청이 들어오면 WAS에 요청
    • 대표적인 예로 Apache, Ngnix 등

Web Application Server

• 웹 애플리케이션 서버는 대부분 웹 서버를 내장하여 클라이언트로부터 HTTP요청을 받아 HTTP응답을 할 수 있다.
• 하지만 웹 서버와 다르게 DB에 있는 데이터 조회나 비즈니스 로직을 통해 동적 컨텐츠를 제공할 수 있다.

  대표적인 웹 애플리케이션 서버의 기능

  • 웹 서버와 동일하게 HTTP 기반으로 동작
  • 동적 컨텐츠 생성과 비즈니스 로직 처리
  • 데이터베이스 연동 및 트랜잭션 처리
  • 대표적인 예로 Tomcat, Wildfly, WebShpere 등

개발한 구조에 적용하기

• 주로 사용하고 있는 Spring Boot에 맞게 구조를 표현했다.
• 웹 애플리케이션 서버로 잘 알려진 Tomcat은 웹 서버의 역할도 수행할 수 있어 정적 컨텐츠를 처리할 수도 있다.
• 또한 Tomcat의 메인 기능인 서블릿 컨테이너역할로 서블릿의 라이프 사이클을 관리한다.
  • 관리되는 dispatcher servlet은 프론트 컨트롤러로 컨트롤러들을 관리하는데 Spring 구조에서 따로 다룬다.
• tomcat이 thread-pool을 관리하며 요청에 스레드를 할당해서 응답들을 처리한다.

주요 차이점 비교

	Web Server	Web Application Server
주 역할	컨텐츠 제공	비즈니스 로직 처리
다루는 컨텐츠	정적 컨텐츠 처리	동적, 정적 컨텐츠 제공
데이터베이스 연동 및 트랜잭션	X	O

🤔그럼 WAS만 사용해도 되는거 아닌가?

• 비교 내용을 보면 웹 애플리케이션 서버가 웹 서버의 기능을 대부분 포함하고 있기 때문에 웹 애플리케이션 서버만 사용해도 괜찮지 않을까?라고 생각할 수 있다.
• 몰론 가능은 하지만 웹 애플리케이션 서버와 웹 서버를 같이 사용했을 때 얻을 수 있는 이점이 있다.

이점 1. 책임 분할을 통한 성능 개선

• 웹 서버는 주로 정적 컨텐츠를 처리하고 웹 애플리케이션 서버는 주로 동적 컨텐츠를 처리한다고 앞에서 설명했다.

• 좌측의 코드는 웹 서버 중 하나인 nginx의 설정파일로 location에 따라 정적 컨텐츠를 제공할 위치를 지정하고 있다.

• 만약 단일 웹 애플리케이션 서버에서 모든 작업을 처리하게 되면 부하가 생기면서 장애가 생길 수 있다. 그래서 정적인 컨텐츠는 웹 서버가, 비즈니스 로직은 웹 애플리케이션 서버가 처리할 수 있도록 하여 웹 애플리케이션 서버에 부담을 줄여 성능을 개선을 기대할 수 있다.

이점 2. 로드밸런싱

• 서비스를 운영하면 대부분 비즈니스 로직을 처리하는 데에 리소스를 많이 사용한다.

• 만약 사용자들이 몰리게 되면 하나의 웹 애플리케이션 서버로는 감당할 수 없어 scale-out이 필요할 것이다.

• 이때 로드밸런싱 기능을 사용하여 사용자들은 하나의 주소로 접근하지만 여러 서버가 나누어 처리할 수 있도록 한다.

• nginx는 로드 밸런싱을 통해 여러 대의 서버에 들어오는 트래픽을 균등하게 분산시킬 수 있다.

• 좌측 코드는 upstream에 backend라는 그룹으로 서버들을 등록해두고 location에 proxy_pass를 설정하여 로드밸런싱하는 예시

• 또한 이 방법을 사용하면 클라이언트에게 웹 애플리케이션 서버의 위치를 알려주지 않기 때문에 웹 어플리케이션 서버에 직접적인 접근을 막아 보안성을 높일 수 있습니다.

이점 3. health check

• 웹 애플리케이션 서버를 scale-out하여 운영했을 때 여러 웹 애플리케이션 서버들 중 하나가 down이 된다면 해당 서버에 접근을 막아야 한다.
• 현재 ngnix 설정 파일에서는 health_check 지시문을 사용하여 백엔드 서버 그룹인 backend에서 헬스 체크를 활성화한다.

  코드 설정
  interval=10s: 서버의 헬스 체크 간격을 10초로 설정합니다.
  fails=3: 백엔드 서버가 연속으로 3번 헬스 체크에 실패하면 해당 서버를 다운 상태로 표시합니다.
  passes=2: 다운된 서버가 연속으로 2번 헬스 체크에 성공하면 해당 서버를 다시 업 상태로 표시합니다.

  • 이렇게 설정하면 nginx는 주기적으로 백엔드 서버의 상태를 모니터링하며, 일정 횟수의 실패나 성공에 따라 백엔드 서버의 상태를 변경한다.

이점들 외에도 ngnix는 요청에 따른 응답 결과를 잠시동안 저장할 수 있는 캐싱 역할도 하고, https 통신 설정을 통해 보안성을 높일 수도 있다.

출처

• https://www.youtube.com/watch?v=mcnJcjbfjrs