김영한님의 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 강의 내용을 정리한 것입니다.
웹 서버, 웹 애플리케이션 서버
웹
웹은 HTTP 프로토콜을 기반으로 다 동작을 한다. 즉, HTTP를 기반으로 데이터를 주고 받는다.
HTML, TEXT, 이미지, 음성, 영상, JSON, XML(API) 등등 모든 형태의 데이터를 전송할 수 있다.
서버 간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.
웹 서버(Web Server)
웹 서버는 HTTP 기반으로 동작하고, 정적 리소스(HTML, CSS, JS, 이미지, 영상)를 제공하며 기타 부가 기능을 제공한다.
ex. NginX, Apache
웹 애플리케이션 서버(WAS - Web Application Server)
웹 애플리케이션은 HTTP 기반으로 동작하고, 웹 서버의 기능을 포함한다.
웹 서버와의 차이점으로 WAS는 프로그램 코드를 실행해서 애플리케이션 로직을 수행한다.
- 동적 HTML, HTTP API(JSON)
- 서블릿, JSP, 스프링 MVC
→ 웹 서버는 서빙을 하는 것이기 때문에 특정 사용자마다 다른 화면을 보여주는 등의 기능을 할 수 없다.
WAS는 HTTP 요청이 오면 사용자에 따라 다른 화면을 보여줄 수 있다.
ex. Tomcat, Jetty, Undertow
웹 서버(Web Server) vs. 웹 애플리케이션 서버(WAS)
- 웹 서버는 정적 리소스(파일), WAS는 애플리케이션 로직으로 일반적으로 분류하지만 사실 둘의 용어도 경계도 모호하다.
- 웹 서버도 프로그램 실행하는 기능을 포함하기도 함.
- 웹 애플리케이션 서버(WAS)도 웹 서버의 기능을 제공함. - Java의 경우 서블릿 컨테이너 기능을 제공하면 WAS라고 한다.
- 서블릿 없이 자바코드를 실행하는 서버 프레임워크도 있음 - WAS는 애플리케이션 코드를 실행하는 데에 특화되어 있다.
웹 시스템 구성
1. WAS, DB
WAS와 DB만으로 시스템을 구성할 수는 있지만, 다음과 같은 단점을 가지고 있다.
- WAS가 너무 많은 역할을 담당하여 서버가 과부하될 수 있다.
- 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행하기 어려울 수 있다.
- WAS에 장애가 생기면 오류 화면도 노출되지 않는다.
2. WEB, WAS, DB
1번과 같은 문제를 해결하기 위해 정적 리소스는 웹 서버가 처리하고, 웹 서버는 애플리케이션 로직같은 동적인 처리가 필요하면 WAS에 요청을 위임하여, WAS는 중요한 애플리케이션 로직의 처리만 전담한다. 즉, 업무분담!
- 정적 리소스가 많이 사용되면 웹 서버를 증설하고, 애플리케이션 리소스가 많이 사용되면 WAS를 증설하는 등 효율적인 리소스 관리가 가능하다.
- 애플리케이션 로직이 동작하는 WAS는 잘 죽지만, 정적 리소스만 제공하는 웹 서버는 잘 죽지 않기 때문에 WAS나 DB 장애시 웹 서버가 오류 화면을 제공할 수 있다.
서블릿
서블릿 (Servlet)
: 클라이언트의 요청을 처리하고, 그 결과를 반환하는 Servlet 클래스의 구현 규칙을 지킨 자바 웹 프로그래밍 기술
클라이언트가 웹 페이지에서 전송 버튼을 누를 경우 위와 같이 웹 브라우저가 요청 HTTP 메시지를 생성한다.
웹 애플리케이션 서버(WAS)를 직접 구현할 경우 왼쪽의 로직을 전부 구현해야 하지만 서블릿을 지원하는 WAS를 사용할 경우 의미있는 비즈니스 로직만 구현하면 된다.
서블릿 특징
@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {
@Override
protected void service(HttpServletRequest request, HttpServletResponse response) {
//애플리케이션 로직
}
}- urlPatterns(/hello)의 URL이 호출되면 서블릿 코드가 실행된다.
- HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest
- HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse
- 개발자는 HTTP 스펙을 매우 편리하게 사용할 수 있다. (기본적인 HTTP 지식 필요)
HTTP 요청, 응답 흐름
- HTTP 요청시 WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출
- 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용
- 개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력
- WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성
서블릿 컨테이너
- 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 한다.
- 서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리한다.
- 서블릿 객체는 싱글톤으로 관리된다.
- 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율 → 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용한다. 따라서 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근한다.
- 공유 변수 사용 주의 ( ex. 로그인할 때 다른 사람의 계정에 접속할 수 있음)
- 서블릿 컨테이너 종료시 함께 종료
- JSP도 서블릿으로 변환 되어서 사용
- 동시 요청을 위한 멀티 쓰레드 처리 지원한다.
동시 요청 - 멀티 쓰레드
쓰레드
: 애플리케이션 코드를 순차적으로 실행하는 것
프로세스 : 프로그램 실행
Thread : 프로그램 안에서
- 쓰레드는 애플리케이션 코드를 순차적으로 실행하는 것으로 서블릿 객체를 호출한다.
- 자바 main 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행된다.
- 쓰레드가 없다면 ? → 자바 애플리케이션 실행이 불가능하다.
- 쓰레드는 한 번에 하나의 코드 라인만 실행하므로 동시 처리가 필요할 경우 쓰레드를 추가로 생성해야 한다.
요청마다 쓰레드 생성
장점
- 동시 요청을 처리할 수 있다.
- 리소스(CPU, 메모리)가 허용할 때까지 처리 가능하므로 리소스 최대 활용할 수 있다.
- 하나의 쓰레드가 지연되어도, 나머지 쓰레드는 정상 동작한다.
단점
- 쓰레드의 생성 비용은 매우 비싸므로 고객의 요청이 올 때마다 쓰레드를 생성하면, 응답 속도가 늦어진다.
- 쓰레드는 컨텍스트 스위칭 비용이 발생한다.
- 쓰레드 생성에 제한이 없어서 고객 요청이 너무 많이 오면 CPU, 메모리 임계점을 넘어서 서버가 죽을 수 있다.
쓰레드 풀
: 요청마다 쓰레드 생성의 단점을 보완해줌
쓰레드 풀 - 특징
- 필요한 쓰레드를 쓰레드 풀에 보관하고 관리한다.
- 쓰레드 풀에서 생성 가능한 쓰레드의 최대치를 관리한다. 톰캣은 최대 200개가 기본(변경 가능함)
쓰레드 풀 - 사용
- 쓰레드가 필요할 경우, 쓰레드 풀에서 이미 생성된 쓰레드를 꺼내어 사용한다.
- 사용을 종료하면 쓰레드 풀에 해당 쓰레드를 반납한다.
- 최대 쓰레드가 모두 사용 중이어서 쓰레드 풀에 쓰레드가 없을 경우, 기다리는 요청은 거절하거나 특정 숫자만큼 대기하도록 설정할 수 있다.
쓰레드 풀 - 장점
- 쓰레드가 미리 생성되어 있으므로, 쓰레드를 생성하고 종료하는 CPU 비용이 절약되고 응답 시간이 빠르다.
- 생성 가능한 쓰레드의 최대치를 정하여 너무 많은 요청이 들어와도 기존 요청을 안전하게 처리할 수 있다.
쓰레드 풀 - 실무 팁
WAS의 주요 튜닝 포인트는 최대 쓰레드(max thread) 수이다.
- 이 값을 너무 낮게 설정하면?
→ 동시 요청이 많으면, 서버 리소스는 여유롭지만, 클라이언트는 금방 응답 지연 - 이 값을 너무 높게 설정하면?
→ 동시 요청이 많으면, CPU, 메모리 리소스 임계점 초과로 서버 다운 - 장애 발생시?
→ 클라우드면 일단 서버부터 늘리고, 이후에 튜닝
→ 클라우드가 아니면 열심히 튜닝
쓰레드 풀 - 적정 숫자
- 애플리케이션 로직의 복잡도, CPU, 메모리, I/O 리소스 상황에 따라 모두 다르다.
- 최대한 실제 서비스와 유사하게 성능 테스트를 시도하는 것이 좋음
Tool : Apache AB, JMETER, nGrinder
WAS의 멀티 쓰레드 지원
- 멀티 쓰레드에 대한 부분은 WAS가 처리
- 개발자가 멀티 쓰레드 관련 코드를 고려하지 않아도 됨
- 개발자는 마치 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드를 개발
- 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용
HTML, HTTP API, CSR, SSR
정적 리소스
고정된 HTML 파일, CSS, JS, 이미지, 영상 등을 주로 웹 브라우저로 제공
HTML 페이지
동적으로 필요한 HTML 파일을 생성해서 웹 브라우저에 전달
웹 브라우저: HTML을 해석
HTTP API
- HTML이 아닌 JSON 등의 데이터를 전달
- 다양한 시스템에서 호출
- API를 통해서는 데이터만 주고 받고, UI가 필요할 경우 클라이언트에서 별도로 처리함
- UI 클라이언트 접점
- 앱 클라이언트 (iPhone, Android, PC)
- 웹 브라우저에서 Javascript를 통한 HTTP API 호출
- React, Vue.js 같은 웹 클라이언트
- 서버 to 서버
- 주문 서버 → 결제 서버
- 기업간 데이터 통신
서버사이드 렌더링 (SSR)
: 서버에서 최종 HTML을 생성해서 클라이언트에 전달
- HTML 최종 결과를 서버에서 만들어서 웹 브라우저에 전달
- 주로 정적인 화면에 사용
- 관련 기술 : JSP, Thymeleaf (→ 백엔드 개발자)
클라이언트 사이드 렌더링 (CSR)
- HTML 결과를 Javascript로 웹 브라우저에서 동적으로 생성헤서 적용
- 주로 동적인 화면에 사용, 웹 환경을 마치 앱처럼 필요한 부분부분 변경할 수 있음
예) 구글 지도, Gmail, 구글 캘린더 - 관련 기술 : React, Vue.js (→ 웹 프론트엔드 개발자)
참고
React, Vue.js를 CSR + SSR 동시에 지원하는 웹 프레임워크도 있음
SSR을 사용하더라도, 자바스크립트를 사용해서 화면 일부를 동적으로 변경 가능
'Tech > Spring | Spring Boot' 카테고리의 다른 글
| [Spring][스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술] 3. 서블릿, JSP, MVC 패턴 (1) | 2023.11.30 |
|---|---|
| [Spring][스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술] 2. 서블릿 (1) | 2023.11.27 |
| [Spring] PSA (Portable Service Abstraction) (0) | 2023.11.12 |
| [Spring] AOP (Aspect Oriented Programming) (0) | 2023.11.12 |
| [Spring] 의존성 주입 (Dependency Injection) (0) | 2023.09.22 |
댓글