[Spring MVC] 웹 애플리케이션

웹 애플리케이션

웹 서버

• HTTP를 기반으로 동작하는 서버
• 정적 리소스(HTML, CSS, JS)를 제공하고, 기타 부가기능을 제공한다.
  • 클라이언트 (HTTP 요청) → 웹 서버 (HTTP 응답)
• ex_) NGINX, APACHE

웹 애플리케이션 서버 (WAS)

• HTTP를 기반으로 동작하는 서버
• 웹 서버 기능을 포함하며 프로그램 코드를 실행하여 애플리케이션 로직을 수행한다.
  • 클라이언트 (HTTP 요청) → WAS (HTTP 응답)
• 동적 HTML, HTTP API(JSON), Servlet, JSP, SpringMVC
• ex_) Tomcat, Jetty, Undertow

차이점

• 웹 서버는 정적 리소스, WAS는 애플리케이션 로직을 실행하는 서버이다.
• 사실은 둘의 용어도 경계도 모호하기에 굳이 나누자면
  WAS는 애플리케이션 코드를 실행하는데 더 특화되어 있다고 생각하면 된다.

웹 시스템 구성

• 웹 시스템은 WAS, DB 만으로도 구성이 가능하다.
  • 클라이언트 → WAS → DB
• WAS는 정적 리소스, 애플리케이션 로직 모두 제공이 가능하기 때문.
  • 하지만 WAS에 모든 부담을 몰아주게되면 과부하 될 우려가 생긴다.
  • 만약에 장애가 생긴다면 오류화면도 나타낼 수 없게 된다.

⇒ 이를 해결하기 위해서는 적절한 분리가 필요하다.

• 클라이언트 → 웹 서버 → WAS → DB
  • 정적 리소스만 제공하는 웹 서버는 잘 죽지 않고, 애플리케이션 로직이 동작하는 WAS 서버는 죽을 이유가 많다.
  • 위 처럼 시스템을 구성하게되면 WAS, DB 장애가 발생하더라도 WEB 서버가 오류 화면을 제공할 수 있다.

시스템을 구성하고 나서 클라이언트가 요청을 보내면 WAS 서버는 응답을 하게된다.

이때의 순서도를 정리해보자면 다음과 같다.

• 서버 TCP/IP 연결 대기, 소켓 연결
• HTTP 요청 메시지를 파싱해서 읽기
• POST 방식, /save URL 인지
• Content-Type 확인
• HTTP 메시지 바디 내용 파싱
  • 바디 내용(데이터)을 사용할 수 있게 파싱
• 저장 프로세스 실행
• 비즈니스 로직 실행
  • DB에 저장 요청
• HTTP 응답 메시지 생성 시작
  • HTTP 시작 라인 생성
  • Header 생성
  • 메시지 바디에 HTML 생성에서 입력
  • TCP/IP에 응답 전달, 소켓 종료

위 내용 중 Bold 처리한 부분 (비즈니스 로직) 말고는 웹 요청, 응답에 대한 일들이다.

이 내용들은 공통적인 부분이기에 개발할 때 마다 구현하기에는 부담이 있는 요소들이다.

이를 모든 일들을 지원해주기 위해 있는 것이 서블릿이다.

서블릿 (Servlet)

• HTTP 스펙을 모두 지원해주는 요소이다.
  • HttpServletRequest - 요청 정보 편리하게 제공 할 수 있음
  • HttpServletResponse - 응답 정보 편리하게 제공 할 수 있음서블릿을 사용하면 편리하게 HTTP 스펙을 이용할 수 있게 된다.

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {

    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) {
        // 애플리케이션 로직
    }
}

• 클라이언트는 HTTP 요청을 보내게된다.
• WAS는 Requset, Response 객체를 새로 만들어서 서블릿 객체를 호출한다.
• 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내 사용한다.
• 그렇게 가공한 데이터를 Response 객체에 HTTP 응답 정보로 편리하게 입력한다.
• WAS는 Response 객체를 바탕으로 HTTP 응답정보를 생성하게 된다.

서블릿 컨테이너

• 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 한다.
• 객체의 생성, 초기화, 호출, 종료하는 생명주기를 관리해준다.
• 서블릿 객체는 싱글톤으로 관리된다.
  • 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율적이기 때문에,
    최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용하는 것이다.
  • 공유 변수 사용에 주의 해야한다.
    • 싱글톤 (같은 객체)를 사용하기 때문에 공유되는 변수, 파라미터를 사용하게 되면 여러가지 문제가 발생할 수 있다.
  • 서블릿 컨테이너가 종료될 대 싱글톤 객체도 함께 종료된다.
• 동시 요청을 위한 멀티 쓰레드 처리를 지원한다.
  • 개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 되며
    마치 싱글 쓰레드 프로그래밍 하듯이 편리하게 소스 코드를 개발할 수 있다.
  • 싱글톤 객체만 주의해서 사용하면 된다.

멀티 쓰레드

• 쓰레드?
  • 애플리케이션 코드를 하나하나 순차적으로 실행하는 것
    • ex_) main() 메서드의 경우도 main이라는 이름의 쓰레드가 실행한다.
  • 쓰레드가 없다면 자바 애플리케이션 실행이 불가능 하며
    그렇기에 동시 처리가 필요하면 쓰레드를 추가로 생성해주어야만 한다.
  • 장점
    • 동시 요청을 처리할 수 있다.
    • 리소스가 허용할 때 까지 처리가능
    • 하나의 쓰레드가 지연되어도, 나머지 쓰레드는 정상 작동한다.
  • 단점
    • 쓰레드 생성 비용이 매우 비싸다.
      • 쓰레드가 너무 많아지면 응답 속도가 늦어진다.
    • 쓰레드는 컨텍스트 스위칭 비용이 발생한다.
    • 쓰레드는 생성에 제한이 없다.
      • 요청이 너무 많으면 CPU, 메모리가 임계점을 넘어 서버가 다운될 수 있다.⇒ 이런 단점을 보완할 수 있다.
• 쓰레드 풀
  • 필요한 쓰레드를 쓰레드 풀에 보관하고 관리한다.
  • 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리할 수 있다.
    (톰캣은 최대 200개가 기본 설정이며 변경이 가능하다.)
  • 사용
    • 쓰레드 요청이 들어오면 이미 생성되어있는 쓰레드를 쓰레드 풀에서 가져와 사용한다.
    • 사용이 종료되면 쓰레드 풀에 해당 쓰레드를 반납하는 방식으로 사용된다.
    • 쓰레드가 모두 사용 중이라면 요청을 거절하거나
      특정 숫자의 요청만큼 대기하게끔 설정 할 수 있다.
  • 장점
    • 쓰레드가 미리 생성되어 있으므로, 쓰레드를 생성하고 종료하는 비용이 절약되고, 응답 시간이 빠르다.
    • 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있다.
  • [성능 튜닝] 그만큼 최대 쓰레드의 수를 알맞게 잘 설정해야한다.
    • 너무 적게 혹은 너무 크게 설정해도 문제가 될 수 있으므로 성능 테스트를 꼭 해보고 결정해야 한다.

 

참고 - 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1