Notice
Recent Posts
Recent Comments
Link
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Archives
Today
Total
관리 메뉴

참새의 이야기

[MVC1] 웹 애플리케이션에 대한 이해 본문

Spring

[MVC1] 웹 애플리케이션에 대한 이해

참새짹짹! 2023. 7. 14. 15:51

웹 서버와 웹 애플리케이션 서버의 차이

지금껏 서버라고 하면 모두 같은 서버인 줄 알았다.

스프링 MVC 패턴에 대한 공부를 하면서 웹 서버의 작동 방식에 대한 이해를 높일 수 있었다.

웹 서버

웹 서버는 정적인 resource를 제공한다.

정적인 resource라고 하면 HTML, CSS, JS나 이미지, 영상 같은 것을 말한다.

HTTP request가 오면 이미 있는 것들을 response로 보내주기만 한다.

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

그렇다면 웹 애플리케이션은 무엇일까?

웹 애플리케이션은 웹 서버의 기능도 가능하지만 동적인 resource 제공을 맡는다.

database와 connection을 가지고 있으며, data를 가져와 response를 보내줄 수 있다면 웹 애플리케이션 서버이다.

굳이 둘을 구분하여 사용하는 이유는 무엇인가

WAS는 웹 서버의 역할도 충분히 소화할 수 있다.

그렇다면 WAS로 모든 request를 처리하면 될 텐데 왜 굳이 웹 서버와 구분하여 사용하는 것일까?

  1. WAS에 너무 큰 부담이 주어진다.
    정적 리소스와 동적 리소스를 모두 웹 애플리케이션 서버에서 처리하려 하면 서버의 과부하가 일어날 수 있다.
  2. WAS의 과부하로 인해 장애가 발생하면 오류 발생을 알리는 화면조차 보낼 수 없다.
    웹 서버를 같이 사용한다면 WAS의 장애로 인해 동적 리소스의 응답이 어려운 경우 오류 화면이라도 반환할 수 있다.
  3. 리소스를 효율적으로 관리할 수 있다.
    정적 리소스와 동적 리소스의 양에 따라 웹 서버와 WAS의 비율을 조절할 수 있다.

서블릿

서버가 해야 하는 일은 정말 많다.

  • TCP/IP 연결 대기, 소켓 연결
  • HTTP request의 parse
  • 비즈니스 로직 실행
  • TCP/IP에 응답 전달, 소켓 close

이 많은 일을 직접 구현한다면 효율적이지 못하다.

비즈니스 로직만을 개발자가 구현한다면 훨씬 편리한 개발이 가능할 것이다.

즉, 서블릿은 개발자가 request와 response에만 집중할 수 있도록 돕는 기술이다.

웹 애플리케이션 서버 안의 서블릿 컨테이너로 request와 response가 들어오면 request에 맞는 response를 반환한다.

개발자는 Request객체에서 요청 정보를 편리하게 꺼내 쓰고 Response객체를 통해 응답을 편리하게 입력한다.

서블릿 특징

  • 싱글톤으로 관리할 수 있다.
    • 서블릿 객체를 하나만 최초 실행 시점에 생성하고 재활용한다.
    • 모든 request에 하나의 서블릿 객체를 사용하므로, 공유 변수에 대한 주의가 필요하다.
  • 서블릿 컨테이너는 서블릿 객체의 생명주기를 관리한다.
  • JSP도 서블릿으로 변환되어서 사용된다.
  • 동시 요청을 위한 멀티 스레드 처리를 지원한다.

동시 요청 - 멀티 스레드

서블릿 객체를 호출하는 것은 스레드이다.

스레드가 애플리케이션 코드를 호출하여 순차적으로 실행하는데, 한 번에 하나의 코드 라인만 실행하게 된다.

client로부터 요청이 오면 스레드를 할당한다.

스레드는 서블릿을 호출하여 애플리케이션 로직이 실행되는 것이다.

다중 요청

하나의 요청을 처리하던 중 지연이 일어난다면 다른 요청에 대한 응답이 늦어질 것이다.

스레드가 하나라면 두 요청 모두 처리가 불가능하다.

이러한 상황을 방지하기 위해 스레드를 여러 개 생성하면 된다.

각 요청마다 스레드를 새로 만들어 요청을 처리하는 것이다.

이때 장단점이 있다.

장점

  • 동시 요청을 처리
  • CPU와 메모리가 허용하는 선에서 아주 많은 처리가 가능
  • 하나의 요청에 대한 응답이 지연되어도 나머지는 정상 동작한다.

단점

  • 스레드의 생성 비용이 비싸다.
    • 요청마다 생성하면 실행 속도가 너무 느려진다.
  • 컨텍스트 스위칭 비용이 발생한다.
  • 스레드 생성에 제한이 없다.
    • 이는 언젠가 CPU와 메모리의 한계를 넘어설 수도 있음을 의미한다.

스레드 풀

스레드 풀에 놀고 있는 스레드가 있다면 요청이 왔을 때 스레드를 가져다 쓴다.

사용 후에 다시 스레드 풀로 반환한다.

특징

  • 필요한 스레드를 스레드 풀에 보관하고 관리
  • 생성가능한 최대치의 스레드를 풀에서 관리
  • 최대 스레드가 모두 사용 중이라면 특정 개수만큼만 대기하도록 설정.

장점

  • 스레드의 생성, 종료 비용이 절약된다.
  • 최대 생성량이 있으므로 기존 요청을 안전하게 처리할 수 있다.

reference

이 글은 김영한님의 '스프링 MVC 1편'을 듣고 작성했습니다.

'Spring' 카테고리의 다른 글

[MVC1] 스프링 MVC Response  (0) 2023.08.04
[MVC1] 스프링 MVC Request  (4) 2023.08.04
[MVC1] Slf4j를 사용한 logging  (0) 2023.08.03
[MVC1] 스프링 MVC 활용  (0) 2023.08.02
[MVC1] MVC 프레임워크의 구성  (0) 2023.08.02