스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 (김영한) 강의 수강 후 정리한 자료입니다.

❗웹 애플리케이션에 대해 이해해 보자❗

✨ 웹 서버, 웹 애플리케이션 서버

웹은 HTTP 기반으로 통신한다. 클라이언트 <-> 인터넷 <-> 서버에서 HTTP 기반으로 모두 통신하는 것이다.

웹 서버

  • HTTP 기반으로 동작
  • 정적 리소스 제공, 기타 부가 기능
  • 정적(파일) HTML, CSS, JS, 이미지, 영상

ex) NGINX, APACHE

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

  • HTTP 기반으로 동작
  • 웹 서버 기능 포함 + 정적 리소스 제공 가능
  • 프로그램 코드를 실행해 애플리케이션 로직 수행
    • 동적 HTML, HTTP API (JSON)
    • 서블릿, JSP, 스프링 MVC

ex) Tomcat, Jetty, Undertow

웹 서버는 정적 리소스만 제공 가능하기 때문에 사용자에 따라 다른 웹 서버를 맞춤 제공하지는 못함 (동적 HTML)

웹 서버 vs 웹 애플리케이션 서버

: 웹 서버는 정적 리소스 파일 제공, WAS는 애플리케이션 로직

그러나 둘의 용어도, 경계도 모호하긴 하다.

웹 시스템 구성

WAS, DB만으로 시스템 구성 가능

  • 그러나 WAS 하나만으로 운영하게 되면 WAS가 너무 많은 역할을 담당해 서버 과부하가 우려됨.
  • 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있음
  • WAS 장애 시 오류 화면도 노출 불가능

그렇기 때문에 웹 서버와 WAS, DB를 함께 사용한다.

  • 정적 리소스는 웹 서버가 처리
  • 웹 서버는 애플리케이션 로직 같은 동적인 처리가 필요하면 WAS에 요청을 위임
  • WAS는 중요한 애플리케이션 로직 처리 전담
  • 또한 효율적으로 리소스를 관리할 수 있다.
    • 정적 리소스가 많이 사용되면 WEB 서버 증설
    • 애플리케이션 리소스가 많이 사용되면 WAS 증설
  • WAS, DB 장애 시 WEB 서버가 오류 화면 제공 가능

✨ 서블릿

  • 의미 있는 비즈니스 로직 (DB에 저장) 제외 HTTP 파싱, TCP/IP에 응답 전달 등 번거로운 작업을 대신 수행해 준다.
@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {
    @Override
    protected void service (HttpServletRequest request, HttpServletResponse response) {
        // 애플리케이션 로직
    }
}
  • urlPatterns(/hellp\o)의 URL이 호출되면 서블릿 코드 실행
  • HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest
  • HTTP 응답 정보를 편리하게 제공할 수 있는 httpServletResponse
  • 개발자는 HTTP 스펙을 매우 편리하게 사용할 수 있다.

서블릿

: HTTP 요청, 응답 흐름

  1. 웹 브라우저에서 URL으로 요청
  2. WAS에서 HTTP 요청 메시지를 기반으로 request, response 객체 생성 -> 서블릿 객체 호출
  3. 서블릿 컨테이너에서 WAS에서 받은 request, response 객체를 실행
  4. WAS에서 Response 객체 정보로 HTTP 응답 생성
  5. 웹 브라우저에 응답 메시지 전달

서블릿 컨테이너

  • WAS 안에 서블릿 컨테이너 존재
  • 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 한다.
  • 서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리
  • 서블릿 객체는 싱글톤으로 관리
    • 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율
    • 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용
    • 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근
    • 공유 변수 사용 주의
    • 서블릿 컨테이너 종료 시 함께 종료 (WAS가 서블릿의 생명 주기를 관리해줌)
  • JSP도 서블릿으로 변환되어 사용
  • 동시 요청을 위한 멀티 쓰레드 처리 지원

(요청과 응답이 다르기 때문에 request, response 객체는 요청이 올 때마다 항상 새로 생성됨)

✨ 동시 요청 - 멀티 쓰레드

요청을 하면 TCP/IP가 연결되고 servlet이 호출된다.

그런데 여기서 servlet 객체를 누가 호출할까? 바로 “쓰레드”가 이러한 servlet 객체를 호출한다.

쓰레드

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

cf) 프로세스는 프로그램을 실행하는 것, 쓰레드는 프로그램 안 여러 개 존재

단일 요청 - 쓰레드 하나 사용

  • TCP/IP가 연결된 후 쓰레드 할당, 쓰레드에서 servlet을 요청한다
  • 그런데 요청이 여러 개 들어오면? 쓰레드는 하나이고, 다른 요청을 처리 중이므로 처리가 지연된다.

요청마다 쓰레드를 생성하면 이러한 문제를 해결할 수 있다.

요청 시 스레드 생성 - 장점

  • 동시 요청 처리
  • 리소스(CPU, 메모리)가 허용할 때까지 처리가 가능하다
  • 하나의 쓰레드가 지연되어도, 나머지 쓰레드는 정상 작동한다.

요청 시 쓰레드 생성 - 단점

  • 생성 비용이 매우 비싸다.
    -> 뿐만 아니라, 고객의 요청이 올 때마다 쓰레드를 생성하면, 응답 속도가 늦어진다.
  • 쓰레드는 컨텍스트 스위칭 비용이 발생한다.
    cf) 컨텍스트 스위칭 비용 : CPU 내 코어는 쓰레드를 동시에 돌릴 수 없다. 따라서 코어에서 쓰레드를 전환할 때 발생하는 비용을 컨텍스트 스위칭 비용이라고 한다.
  • 쓰레드는 생성에 제한이 없어, CPU, 메모리 임계점을 넘어서면 서버가 죽을 수도 있다.

이러한 단점을 해결하기 위해 WAS는 대부분 쓰레드 풀을 갖고 있다.

쓰레드 풀

과정

  1. 클라이언트가 쓰레드 풀에 요청을 보냄.
  2. 쓰레드 풀에서 사용하지 않고 대기 중인 쓰레드를 지정해 줌.
  3. 사용이 끝난 후 쓰레드 풀에 쓰레드를 다시 되돌려 줌.

이렇게 쓰레드 풀을 사용하게 되면 미리 만들어 놓고 가져다 쓰기 때문에 삭제 후 생성을 하지 않아도 되며, 생성에 제한을 둘 수도 있다. (미리 만들어 놓기 때문에)

특징

  • 필요한 쓰레드를 쓰레드 풀에 보관하고 관리한다.
  • 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다.
  • 최대 쓰레드가 모두 사용중이어서 쓰레드 풀에 쓰레드가 없으면 기다리는 요청은 거절하거나 특정 숫자만큼 대기하도록 설정할 수 있다.
  • 아파치 ab, 제이미터, nGrinder 등으로 최대한 실제 서비스와 유사하게 성능 테스트를 시도해야 한다.

따라서, WAS가 멀티 스레드를 지원해주므로, 개발자는 멀티 쓰레드 관련 코드를 신경쓰지 않아도 된다. 하지만 멀티 쓰레드 환경이므로 싱글톤 객체는 주의해서 사용해야 한다.

✨ HTML, HTTP API, CSR, SSR

SSR

: 서버 사이드 렌더링 (서버에서 HTML 만듦)

  • HTML 최종 결과를 서버에서 만들어서 웹 브라우저에 전달
  • 주로 정적인 화면에 사용
  • 관련 기술 : JSP, 타임리프 -> 백엔드 개발자

CSR

: 클라이언트 사이드 렌더링 (클라이언트에서 HTML 만듦)

  • HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용
  • 주로 동적인 화면에 사용, 웹 환경을 마치 앱처럼 필요한 부분부분 변경할 수 있음
    ex) 구글 지도, Gmail, 구글 캘린더
  • 관련 기술 : React, Vue.js -> 웹 프론트엔드 개발자

참고로, CSR + SSR을 동시에 지웒나느 웹 프레임워크도 있을 뿐더러, SSR을 사용하더라도 자바스크립트를 사용해 화면 일부를 동적으로 변경할 수 있다.

카테고리:

업데이트: