[스프링 MVC 1] 웹 애플리케이션의 이해 (1)

웹서버

• 정적 리소스 제공
• 정적 HTML, CSS, 이미지, 영상
• 예) NGINX, APACHE

하지만 콘텐츠의 크기가 수백 메가바이트 같이 매우 큰 경우나 다수의 클라이언트가 동시에 이를 요청했을 때 웹서버는 '네트워크 대역폭', '라우터 대역폭', '케이블 대역폭' 각종 제한에 도달하게 된다. 이렇게 제한에 걸려버리면 웹서버는 일반 요청도 처리할 수 없는 '마비'상태가 된다.

 

콘텐츠 크기가 크거나 요청이 많아서 웹서버에 제한이 걸릴 때 해결방법

• 로드밸런서로 다수의 웹서버를 사용하는 방법이 있고 콘텐츠 추가에 대응하기 위해 네트워크 대역이 높은 '미디어 콘텐츠 서버'를 따로 둔다.
• 거리가 멀면 콘텐츠의 전송 속도가 느려지므로 클라이언트와 서버 사이에 콘텐츠 서버를 배치하여 트래픽을 분산시킬 수 있다.
  • 하지만 각 위치마다 서버를 두고 파일을 동기화하는 작업은 쉽지않으며 비용이 많이 발생한다.
• CDN(Content Delivery Network)서비스는 여러 위치의 오리진 서버를 관리하는 것을 대신해주며 콘텐츠를 대신 제공해준다. 트래픽 증가에도 쉽게 대응할 수 있다.

 WAS

• WAS = Web server(정적 리소스 제공 가능) + Web Container(동적 리소스 제공)
• 분산 트랜잭션, 보안, 메시징, 쓰레드 처리 등 주로 기능을 처리하는 환경에서 DB와 함께 사용
• Tomcat, Jeus, JBoss

톰켓은 WAS로 자바코드를 이용해 HTML페이지를 '동적'으로 생성해주는 프로그램이다.

 

WAS는 웹서버와 웹 컨테이너 둘 모두의 역할을 할 수 있다. 하지만 이는 너무 많은 역할로 인해 서버 과부하가 발생할 수 있다.

WAS가 정적리소스도 제공하므로 WAS장애시 오류 페이지도 노출하지 못함

 

역할을 나눠 가지도록 해보자. [WEB - WAS - DB]

WebServer와 WAS를 나누어 구성하면 WAS나 DB가 죽어도 정적리소스는 제공할 수 있다. 또한 정적리소스가 요청이 많다면 WebServer를 늘리고 동적요청이 많다면 WAS만 늘리면 유연한 증설이 가능하다.

 

서블릿

먼저 요청을 받았을 때 서버에서 처리해야 하는 업무에 대해서 알아보자. 

 

요청 시 처리 과정

• 서버 TCP/IP 연결대기 - 소켓 연결
• HTTP 요청 메시지를 파싱해서 읽기
• Content-type 확인하고 HTTP 메시지 바디 내용 파싱
  • urlencoded인지 json인지 등
• 비즈니스 로직 실행
  • 데이터베이스 실행
• HTTP 응답 메시지 생성시작
  • HTTP 시작 라인 생성, Header 생성
  • 메시지 바디에 결과를 입력
• TCP/IP에 응답 전달 - 소켓 종료

여기서 보라색으로 칠한 부분이 개발자가 작성하는 비즈니스 로직 부분이고 이외의 나머지 부분이 서블릿이 지원하는 WAS의 영역이다.

이처럼 WAS를 사용하면 개발자의 수고를 덜고 더욱 핵심로직에 집중할 수 있다.

 

HTTP 요청 시 생성되는 객체

• WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출

개발자는 이 두 객체를 이용해 요청과 응답정보를 편하게 사용하고 만들 수 있따.

 

서블릿 컨테이너

서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함. -> ex) 톰캣

• 서블릿 컨테이너는 서블릿 객체의 생성, 초기화, 호출, 종료를 관리
• 서블릿 객체는 싱글톤으로 관리
• 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 요청시에 할당해서 사용함

 

동시요청 - 멀티쓰레드

요청이 오면 서블릿 객체를 누가 호출하는가?

정답 : 쓰레드

 

WAS가 멀티쓰레드에 대한 부분을 처리하므로 개발자는 편리하게 개발할 수 있다.

쓰레드란?

• 자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행
• 코드를 순차적으로 실행하는 쓰레드
• 쓰레드하나는 한번에 하나의 코드 라인만 수행
• 동시처리가 필요하면 쓰레드를 추가로 생성

요청이 하나면 요청 시 쓰레드 하나 할당해서 요청처리를 진행한다.

• 요청이 둘일 때 '처리 지연' 상황에서는 어떻게 할까?
  • 쓰레드가 하나라면 이후의 요청은 타임아웃이 난다.
  ⇒ 문제 해결을 위해 요청마다 '신규 쓰레드'를 생성하자!

하지만 요청마다 쓰레드 생성에는 단점이 있다.

• 쓰레드 생성 비용이 매우 비싸다 (CPU, 메모리)
• 올때마다 생성하면 **'응답 속도'**가 늦어진다.
• 쓰레드가 많아질수록 '컨텍스트 스위칭' 비용이 발생한다.
• 쓰레드 생성 제한이 없다. 요청을 무제한으로 받는다. (CPU, 메모리 임계점을 넘으면 서버가 죽는다)

→ 문제점 : 컨텍스트스위칭으로 인한 속도 저하 및 자원 사용량 증가, 응답속도, 자원부족문제

 

이를 WAS는 어떻게 해결했을까?

-> 쓰레드풀!

 

쓰레드풀 특징

• 필요한 쓰레드를 쓰레드 풀에 보관하여 관리하며 쓰레드의 최대치가 있다.
• 쓰레드 필요 시 쓰레드 풀에서 쓰레드는 꺼내어 사용한다.
• 생성된 쓰레드가 모두 사용중이라면 '요청을 거절하거나 대기시킨다'

미리 생성된 쓰레드를 사용하므로 생성/종료 비용이 들지않고 생성된 쓰레드를 사용하므로 응답시간이 빠르다.

설정된 최대치가 있어 많은 요청이 들어와도 안전하게 처리가 가능하다. (자원 부족 예방 가능)

-> 상황에 맞게 최대치를 설정해야 한다. (요청수, CPU, IO, 메모리)

 

[해당 글은 노션에 정리했던 글을 다시 한번 정리했습니다]

https://complex-hospital-a54.notion.site/7891606679754b9da67b905e87d5b9ce

웹 애플리케이션의 이해