1.1 웹 서버 & 웹 애플리케이션 서버
1. 웹 서버 (WEB)
- HTTP 기반
정적 리소스
제공
- ex) APACHE, NGINX
2. 웹 애플리케이션 서버 (WAS)
- HTTP 기반
- 웹 서버 기능 +
애플리케이션 로직 수행
- ex) Tomcat, Jetty, Undertow
3. 웹 시스템 구성
WAS, DB
WAS
가 정적 리소스, 애플리케이션 로직을 모두 제공할 수 있기 때문에 2가지만으로도 웹 시스템 구성할 수 있음
- 단점
- WAS가 너무 많은 역할을 담당
- 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있음
- WAS 장애 시 오류 화면도 띄울 수 없음
WEB, WAS, DB
- 웹 서버를 사용해 정적 리소스를 따로 제공
- 동적인 처리가 필요하면 WAS가 애플리케이션 로직 작동
- 장점
-
WAS
가 중요한 애플리케이션 로직만 처리함
-
리소스를 효율적으로 관리할 수 있음
- 정적 리소스가 많으면 웹 서버를 증설하고, 애플리케이션 리소스가 많이 사용되면 WAS를 증설함
-
웹 서버는 잘 죽지 않고 WAS는 잘 죽음
→ WAS 장애 시 웹 서버가 오류화면을 제공할 수 있음
1.2 서블릿
서버의 비지니스 로직을 제외한 나머지 작업을 대신 해줌
1. 서버에서 처리하는 업무
- 비지니스 로직 외에 처리해야할 일이 매우 많음 ex) 서버 TCP/IP 연결 대기, HTTP 요청 메시지 파싱, 응답 메시지 생성 등
- 서블릿을 지원하는 WAS 사용 시 비지니스 로직을 제외한 나머지 작업을
서블릿
이 대신 해줌
2. 서블릿
@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {
@Override
protected void service(HttpServletRequest request,
HttpServletResponse response){
}
}
- /hello URL이 호출되면 서블릿 코드가 실행됨
- HTTP 요청과 응답을 편리하게 사용할 수 있게 해주는
HttpServletRequest
과 HttpServletResponse
- HTTP 요청 & 응답 과정
-
HTTP 요청
-
WAS
가 request, response 객체를 만들어서 서블릿 객체를 호출
-
개발자가 request 객체에 HTTP 요청 정보를 편리하게 꺼내서 사용
-
개발자가 response 객체에 HTTP 응답 정보를 편리하게 입력
-
WAS는 response 객체에 담겨있는 내용으로 HTTP 응답 메시지를 생성
3. 서블릿 컨테이너
- 톰캣처럼
서블릿을 지원하는 WAS
를 서블릿 컨테이너라고 함
역할
- 서블릿 객체의
생명주기 관리
- 서블릿 객체는 싱글톤으로 관리됨
- 최초 로딩 시 1개의 서블릿 객체를 만들어 놓음
- 여러 고객이 요청 시 동일한 서블릿 객체에 접근
- 공유 변수 사용에 주의해야 함
- JSP도 서블릿으로 변환되어 사용됨
- 동시 요청을 위해
멀티 쓰레드
지원
1.3 동시 요청 - 멀티 쓰레드
1. 쓰레드
- main 메소드 실행 → main이라는 이름의 쓰레드가 실행됨
- 동시 처리가 필요한 경우 쓰레드를 추가로 생성해야 함
2. 단일 쓰레드
- 고객의 요청으로 하나의 쓰레드가 사용되고 있을 경우
- 쓰레드가 서블릿 객체를 사용해 응답을 받고 쓰레드를 반환 함
- 먼저 들어온 요청의 처리가 끝나지 않은 상태에서 추가 요청이 들어오는 경우
- 다른 고객은 먼저 들어온 고객의 요청이 끝나서 쓰레드가 반환될 때까지 대기해야 함 → 처리 지연
- 이 때 먼저 들어온 요청에 오류가 생기면?
- 이 후에 들어오는 요청들도 처리되지 못하고 무한 대기하게 됨
3. 요청마다 쓰레드 생성
- 장점
- 동시 요청을 처리할 수 있음
- 하나의 쓰레드가 지연되어도 나머지 쓰레드는 정상 작동함
- 단점
4. 쓰레드 풀
- 생성 가능한
쓰레드의 최대치
만큼 미리 생성
해 쓰레드 풀에 보관하고 관리함
- 쓰레드가 필요한 경우 쓰레드 풀에서 꺼내서 사용하고 종료되면 쓰레드를 다시 반납함
- 쓰레드 풀의 모든 쓰레드가 사용 중이라면 요청을 거절하거나 대기하도록 설정할 수 있음
장점
- 쓰레드를 미리 생성해서 보관
- 쓰레드 생성, 종료 비용을 절약
- 응답 시간이 빠름
- 생성 가능한 쓰레드의 최대치가 존재
- 여러 요청이 들어와도 안전하게 처리할 수 있음
- WAS 주요 튜닝 포인트 =
최대 쓰레드 수 설정
- 톰캣은 최대 200개
- 성능 테스트를 통해 적절한 최대 쓰레드를 정해야 함
- 너무 낮게 설정하면?
- 동시 처리하는 요청의 수가 적다는 뜻
- 서버 리소스는 여유롭지만 요청이 조금만 많아져도 금방 응답이 지연됨
- 너무 높게 설정하면?
- 동시 요청이 너무 많아 CPU, 메모리 리소스 임계점 초과 시 서버가 다운될 수 있음
- 클라우드면 장애 발생 시 일단 서버를 늘리고 이후에 튜닝함
- 실제 서비스 환경과 유사하게 세팅하여 성능 테스트를 해야 함
- 툴 → 아파치 ab, 제이미터, nGrinder
💡 참고
Spring Boot - Thread Pool을 관리하는 방법! (Spring Boot에서의 Thread 기본 원리) [ThreadPoolExecutor]
5. WAS
- 멀티 쓰레드 지원
개발자
는 복잡한 멀티 쓰레드 관련 코드를 신경 쓰지 않아도 됨
- 개발자는 싱글 쓰레드 프로그래밍을 하듯이 편하게 개발하면 됨
💡 WAS = 서블릿 컨테이너 → 멀티쓰레드 지원
1.4 HTML, HTTP API, CSR, SSR
1. 정적 리소스
- 고정 HTML 파일, CSS, JS, 이미지 등
2. HTML
- WAS는 동적으로 필요한 HTML 파일을 생성해서 전달해 줄 수 있음
3. HTTP API
- HTML이 아니라 데이터만 주고 받음 (주로 JSON)
- UI 화면이 필요하면 클라이언트가 별도로 처리
- 웹 뿐만 아니라 다양한 시스템에서 호출함
- 웹 ↔ 서버
- 서버 ↔ 서버
- 앱 ↔ 서버
4. SSR & CSR
SSR
(Server Side Rendering)
- HTML 최종 결과를 서버에서 만들어 웹 브라우저에 전달함
- 주로
정적인 화면
에 사용
CSR
(Client Side Rendering)
- HTML 최종 결과를 JS를 사용해 웹 브라우저에서 동적으로 생성해 적용
- 주로
동적인 화면
에 사용
1.5 자바 웹 기술 역사
1. 과거 기술
서블릿 → JSP → 서블릿 & JSP 조합 MVC → 다양한 MVC
2. 현재 사용 기술
- 어노테이션 기반의
스프링 MVC
- 스프링 부트
- 빌드 결과(Jar)에 WAS 포함 → 빌드 배포 단순화
3. 최신 기술
- Web Servlet → Spring MVC
- Web Reactive → Spring WebFlux
- 비동기 넌 블러킹 처리
- 최소 쓰레드로 최대 성능
- ex) 4코어 CPU → 4~5 쓰레드 → 쓰레드 컨텍스트 스위칭 비용 최소화
- 함수형 스타일로 개발
- 서블릿 기술 사용 x
- 단점
-
난이도 높음, RDB 지원 부족, 아직 많이 사용 x
⇒ 아직까진 Spring MVC도 충분히 빠르다.
4. 자바 뷰 템플릿 (템플릿 엔진) 역사
- JSP
- 프리마커, 벨로시티
타임리프(Thymleaf)
- HTML 모양 유지하면서 뷰 템플릿 적용
스프링 MVC와 강력한 기능 통합