개인 프로젝트를 시작하고 다른 CS 지식을 공부하면서 스프링과 관련된 지식 풀을 넓힐 필요성을 느꼈다. 기존에도 들어봤었던 MVC 1편 강의지만 더 높아진 내 스프링 이해도를 바탕으로 강의를 빠르게 듣고 CS 기본지식 시리즈에 Spring 요약편을 올려볼 계획이다.
해당 내용은 김영한의 "스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술" 강의를 바탕으로 작성한다.
웹 애플리케이션 이해
웹 서버, 웹 애플리케이션 서버
우리가 흔히 웹 서버라는 표현을 할때 그저 하나의 서버로만 생각하는 경우가 있지만 사실 웹서버와 웹 애플리케이션 서버는 다르게 구분되어야 한다.
웹 서버:
흔하게 생각하는 웹서버 구조이다. 특징으로는 아래와 같다.
- HTTP 기반으로 동작
- 정적 파일 제공 (EX: HTML, CSS, JS, 이미지, 영상 등)
- NGINX, APACHE 등이 존재한다
웹 애플리케이션 서버:
웹서버와는 다르게 구분되는 웹 애플리케이션 서버고 특징은 아래와 같다.
- HTTP 기반으로 동작
- 웹 서버 기능 포함+ (정적 리소스 제공 가능)
- 프로그램 코드를 통해 애플리케이션 로직 수행
- 동적 HTML (타임리프), HTTP API (JSON)
- 서블릿, 스프링 MVC
- 톰캣 (TOMCAT) 등이 존재한다
차이점을 종합 하자면은,
- 웹 서버는 (정적) 파일, WAS는 애플리케이션 로직을 담당한다.
- 다만, 웹 서버도 프로그램 구현이 가능하고, WAS도 웹 서버의 기능 구현가능
- 자바는 서블릿 컨테이너 기능을 제공하면 WAS
- WAS 는 애플리케이션 코드를 실행하는데 특화
경계가 상당히 애매해서 둘의 차이점이 헷갈릴 수도 있다. 웹 시스템은 사실 WAS 와 DB 만으로도 구현이 가능하다, 정적 리소스 로직 모두 제공하기 떄문이다. 다만, 이런 식의 설계는 아래와 같은 문제점이 있다.
- WAS가 너무 많은 역활을 담당하게 되고, 서버 과부하가 우려된다
- 애플리케이션 로직은 비싸지만 가벼운 정적 리소스 때문에 수행에 어려움이 있을수 있다.
- WAS 장애시 오류 화면도 노출이 불가능하다.
이를 해결하고자 아래와 같은 설계가 나올 수 있는것이다.
해결 방법:
- 정적 리소스는 웹 서버가 처리해준다.
- 웹 서버는 동적인 처리가 필요하다면 WAS에 요청을 위임
- WAS는 중요한 애플리케이션 로직 처리 전담
이로인해 우리는 효율적으로 리소스 관리가 가능해진다.
앞서 설명했떤 WAS 하나만으로 사용하는 웹 애플리케이션의 문제를 전부 해결했다.
서블릿
서블릿
WAS 서버를 설계한다고 생각했을때 처리해야하는 과정들이 굉장히 많다. 앞서 네트워크 기초 강의에서 배웠듯이 HTTP의 요청과 응답 과정을 처리하기 위해서는 TCP/IP 3way handshake 부터 시작해서 HTTP 바디내용 파싱까지 할게 굉장히 많지만 서블릿은 이 모든 과정을 지원해주고 오로지
비즈니스 로직 실행 만 개발자가 집중할 수 있도록 해준다.
위와 같이 urlPatterns 에 "/hello"의 URL이 호출이 된다면 서블릿 코드가 실행된다.
- HttpServletResponse -> HTTP 응답 정보를 편리하게 사용 가능
- HttpServletRequest -> HTTP 요청 정보를 편리하게 사용 가능
이로서 개발자는 HTTP 스팩을 매우 편리하게 사용 가능하다.
굉장히 직관적으로 나와있는 그림이다. HTTP 요청시 Request 와 Response 객체를 새로 만들어서 서블릿 객체를 호출 시킨다.
개발자는 Request 객체를 사용해 HTTP 요청 정보를 손쉽게 사용할 수 있고 Response 객체를 사용해 HTTP 응답 정보를 편리하게 입력시킬 수 있다. WAS는 결과적으로 Response 객체에 담긴 내용으로 HTTP 응답 정보를 생성한다.
그림에서 서블릿 컨테이너라는 정의에 의문이 갈 수 도있지만 간단한 정의로 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 부른다.
강의에서 나와있었던 특징들이지만 가장 중요한것은 싱글톤으로 관리 된다는 점과, 동시 요청을 위한 멀티 쓰레드 처리 지원인거 같다.
동시 요청 - 멀티 쓰레드
동시 요청 - 멀티 쓰레드
쓰레드 (Thread) 와 관련된 주제는 CS 기본지식 정리편에서 OS 주제와 함께 다룰 계획이었지만 강의에서 먼저 나오게 되서 굉장히 반가웠다.
쓰레드와 관련된 강의는 따로 학습을 더 할것이지만 위 그림에서 서블릿이 호출되지만 어떻게 호출 되는지와 관련해서는 내용이 없었다.
그리고 이 서블릿을 호출하는것이 우리의 주제인 쓰레드이다.
쓰레드는 강의에서 나온 설명처럼 굉장히 중요한 역활을 담당하고 있다. 쓰레드가 없다면 자바 애플리케이션 자체가 실행이 불가능할 정도이다. 다만, 쓰레드의 특징은 하나의 쓰레드는 하나의 코드 라인만 수행하고 동시 처리가 필요한 상황에선느 쓰레드를 추가로 생성해야한다.
쓰레드를 사용하는데는 여러가지 전략이 있는데 장단점이 확실하다.
단일/다중 요청 - 쓰레드 하나 사용
단일/다중 요청 - 쓰레드 하나 사용
앞서 말했듯이 쓰레드 하나는 하나의 코드 라인만 수행한다. 그렇기에 단일 요청인 상황에서는 하나의 쓰레드가 나의 요청을 모두 처리 할 수 있기에 문제가 안된다.
그렇지만 다중 요청일때는 얘기가 다르다. 결국 두번쨰 요청은 다른 하나의 쓰레드를 기다려야 하기때문에 이 시간은 훨씬 길어질것이다.
솔루션1 - 요청마다 쓰레드 생성
솔루션1 - 요청마다 쓰레드 생성
단일 쓰레드를 사용하는 문제점의 가장 빠른 솔루션은 사실 요청마다 쓰레드를 생성하는것이지만 이것 또한 장단점이 있고 아래와 같다.
중요하게 생각해야 할 점은 당장 동시 요청의 문제는 해결이 되도 쓰레드 생성 자체의 비용이 매우 비싸고 제한이 없기때문에 늘어나는 요청마다 서버가 죽을 수 도있다. 추가적으로 컨텍스트 스위칭 비용또한 발생하는데 이것은 굉장히 비싼 값이고 CPU 가 여러 쓰레드를 굉장히 빠른시간안에 처리하는것을 의미한다. (추후 CS 지식 시리즈에서 커버할 예정)
솔루션2 - 쓰레드 풀
솔루션2 - 쓰레드 풀
쓰레드풀은 앞서 설명한 매번 쓰레드를 생성하는 과정의 단점을 보안했다고 생각하면된다. 미리 쓰레드를 만들고 풀 안에 저장해놓고 연결이 필요한 하나씩 꺼내고 끝나면은 돌려받는 구조이다. 그리고 풀안에 있는 쓰레드 보다 많은 요청이 들어온다면 대기할수도 있고 거절할수도 있다.
장단점은 아래와 같다.
결국 쓰레드 풀은 최적화가 가장 중요하고 WAS 서버의 튜닝 포인트는 최대쓰레드 (max thread) 수라고 강의에서 설명했다.
튜닝된 결과에 따라서 위와 같은 일들이 있을 수 있고 항상 조심해야 한다.
결론
서블릿의 특징은 개발자가 HTTP 메서드를 접근하는데 굉장한 편리함을 주고 있다. 그리고 큰 장점 중 하나는 멀티 쓰레드 코드를 신경쓰지 않아도 WAS 가 처리해주고 있다는 점이다.
주의 해야할점으로는 멀티 쓰레드 환경이므로 싱글톤 객체는 주의해서 사용하라고 적혀있다.
