웹 서버, 웹 애플리케이션 서버
웹 : 웹은 HTTP 통신을 기반으로 통신한다.
모든 것이 HTTP이다.
HTTP 메시지에 모든 것을 담아 전송한다.
1. HTML, TEXT
2. IMAGE, 음성, 영상, 파일
3. JSON, XML(API)
4. 서버간의 데이터를 주고 받을때도 대부분 HTTP 사용
--> 거의 모든 형태의 데이터가 전송 가능하다.
웹 서버(Web Server)
- HTTP 기반으로 동작한다.
- 정적 리소스(파일)를 제공하고, 기타 부가 기능이 있다.
- 정적(파일) HTML, CSS, JS, 이미지, 영상 등이 정적 파일이다.
- ex)NGINX, APACHE
웹 애플리케이션 서버(WAS - Web Application Server)
- HTTP 기반으로 동작한다.
- 위의 웹 서버 기능 포함 + 정적 리소스 제공 가능
- 프로그램 코드를 실행해서 애플리케이션 로직을 실행하는 것이 가장 큰 차이점이다.
- 동적 HTML, HTTP API(JSON)
- 서블릿, JSP, 스프링 MVC
ex) 톰캣, 제티 등
웹 서버, 웹 애플리케이션 서버의 차이
- 웹 서버는 정적 리소스(파일), WAS는 애플리케이션 로직
- 사실은 둘의 용어도 경계도 모호하다.
- 웹 서버도 프로그램을 실행하는 기능을 포함하기도 함
- 웹 애플리케이션 서버도 웹 서버의 기능을 제공한다.
- 자바는 서블릿 컨테이너 기능을 제공하면 WAS이다.
- 서블릿 없이 자바 코드를 실행하는 서버 프레임워크도 있음
- WAS는 애플리케이션 코드를 실행하는데 더 특화되어있다.
웹 시스템 구성 - WAS, DB
WAS, DB 만으로 시스템 구성 가능하다.
하지만 WAS가 너무 많은 역할을 담당하면, 서버 과부하의 우려가 있다. 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있고, WAS 장애시 오류 화면도 노출 불가능하다.
이 문제를 다음과 같이 역할을 나누어 해결한다.
정적 리소스를 처리하는 웹서버를 앞에 두고, 동적인 로직이 필요하게 되면 WAS가 처리하게 되는 방식이다.
WAS는 중요한 애플리케이션 로직 처리를 전담하게 되며 부담이 줄게 되었다.
위처럼 구성하게 되면 효율적인 리소스 관리가 가능하다.
만약 정적 리소스가 많이 사용되면 Web Server를 증설하면 되고, 애플리케이션 리소스가 많이 사용되면 WAS를 증설하면 된다.
정적 리소스만 제공하는 웹 서버는 잘 죽지 않는다. 애플리케이션 로직이 동작하는 WAS 서버는 잘 죽기 때문에 WAS나 DB에 장애가 나면 WEB Server가 오류 화면을 제공할 수 있는 장점도 있다.
서블릿
HTML Form 데이터 전송
POST 전송- 저장
HTML Form 데이터를 POST로 전송하여 저장한다고 가정하자.
전송 버튼을 누르게 되면 웹 브라우저가 요청 HTTP 메시지를 만들게 된다.
만약 웹 애플리케이션 서버를 직접 구현해야 한다면 어떤 일을 처리해야 할까?
정말 많은 업무를 WAS에서 처리를 해야할 것이다.
WAS에서 처리해야하는 의미있는 비즈니스 로직은 적으나 그 전후 단계가 너무 많아지게 된다.
--> 이를 해결하기 위해 '서블릿'이 등장하였다.
서블릿은 위 그림의 초록색 부분을 제외한 모든 부분을 지원해준다.
즉 서블릿은 위의 의미있는 비즈니스 로직을 제외한 모든 일을 자동화로 처리한다.
서블릿의 생김새와 특징은 다음과 같다.
- urlPatters(/hello)의 URL이 호출되면 서블릿 코드가 실행된다.
- HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest
- HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse
- 개발자는 HTTP 스펙을 매우 편리하게 사용할 수 있게 된다.
전체 흐름은 다음과 같다
1. 웹 브라우저에서 /hello를 요청한다.
2. WAS에서 요청 메시지를 기반으로 request, response 객체를 새로 만든다.
3. 서블릿 컨테이너에 helloServlet에 request, response를 파라미터로 넘겨서 실행을 해준다.
4. helloServlet이 끝나고 리턴을 하면 이전에 만들었던 response 객체 정보로 HTTP 응답을 생성한다.
5. 웹 브라우저에 응답 메시지를 전달한다.
-HTTP 요청 시
- WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체를 호출한다.
- 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용한다.
- 개발자는 Response 객체에서 HTTP 응답 정보를 편리하게 입력한다.
- WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성한다.
WAS 안에는 서블릿을 지원하는 서블릿 컨테이너가 있다.
서블릿이 여러개 있으면 여러개가 들어가게 된다.
서블릿 컨테이너
- 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너 라고 한다.
- 서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리
- 서블릿 객체는 싱글톤으로 관리한다.
- 고객의 요청이 올 때마다 계속 객체를 생성하는 것은 비효율적이다.
- 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용
- 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근
- 공유 변수 사용 주의
- 서블릿 컨테이너 종료시 함께 종류
- JSP도 서블릿으로 변환 되어서 사용
- 동시 요청을 위한 멀티 쓰레드 처리 지원
동시 요청 - 멀티 쓰레드
웹 브라우저에서 WAS에 요청을 하면 자연스레 응답을 할 것이다.
요청 -> TCP/IP 커넥션 연결 -> 서블릿 호출
그런데 서블릿 객체를 누가 호출할까?
--> 서블릿 객체를 호출하는 것은 '쓰레드' 이다
쓰레드
- 애플리케이션 코드를 하나하나 순차적으로 실행하는 것은 쓰레드이다.
- 자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행된다.
- 쓰레드가 없다면 자바 애플리케이션 실행이 불가능하다.
- 쓰레드는 한번에 하나의 코드 라인만 수행한다.
- 동시 처리가 필요하면 쓰레드를 추가로 생성한다.
쓰레드가 하나 있다고 가정해보자.
요청이 하나 오면TCP/IP커넥션에서 쓰레드 한개를 할당해준다.
그리고 이 쓰레드를 가지고 서블릿을 실행한다.
이후 응답을 한 이후 쓰레드는 다시 휴식에 들어간다.
만약 다중 요청이 일어나면 어떻게 될까?
요청1이 와서 쓰레드가 요청을 처리중인 상태일때 요청 2가 들어오는 것이다.
이렇게 되면 둘 다 처리가 지연되면서 요청 두개가 죽어버린다.
위 문제의 해결방법은 요청마다 쓰레드가 생성되게 하는 것이다.
새로 쓰레드를 만들었기 때문에 서블릿을 호출하고 응답을 받은 뒤 종료되면 쓰레드를 날리면 된다.
요청마다 쓰레드 생성의 장단점
장점
- `동시 요청을 처리할 수 있다.
- 리소스(CPU, 메모리)가 허용할 때 까지 처리 가능
- 하나의 쓰레드가 지연 되어도, 나머지 쓰레드는 정상 동작한다.
단점
- 쓰레드 생성 비용은 매우 비싸다.
- 고객의 요청이 올 떄마다 쓰레드를 생성하면, 응답 속도가 늦어진다.
- 쓰레드는 컨텍스트 스위칭 비용이 발생한다.
- 쓰레드 생성에 제한이 없다.
- 고객 요청이 너무 많이 오면, CPU, 메모리 임계점을 넘어서 서버가 죽을 수 있다.
--> 쓰레드 생성할시에 응답 속도가 늦어지고, 서버가 죽는 경우를 방지하기 위해 보통 WAS들은 다음과 같이 구현이 되어있다.
내부에 '쓰레드 풀'을 사용하는 방법이다. 풀 안에 쓰레드를 미리 만들어놓는다.
요청이 들어오면 쓰레드 풀에서 쓰레드를 달라고 요청한다.
쓰레드의 사용이 다 끝나면 쓰레드 풀에 반납을 하게 된다.
만약 쓰레드 풀의 갯수를 초과하는 요청이 들어오게 되면, 나머지 요청들은 쓰레드 풀에 쓰레드가 없기 때문에 쓰레드를 대기하거나, 거절할 수 있다.
쓰레드 풀
요청마다 쓰레드 생성의 단점을 보완
특징
- 필요한 쓰레드를 쓰레드 풀에 보관하고 관리한다.
- 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다. 톰캣은 최대 200개 기본 설정(변경 가능)
사용
- 쓰레드가 필요하면, 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내서 사용한다.
- 사용을 종료하면 쓰레드 풀에 해당 쓰레드를 반납한다.
- 최대 쓰레드가 모두 사용중이어서 쓰레드 풀에 쓰레드가 없으면, 기다리는 요청을 거절하건, 특정 숫자만큼 대기하도 록 설정 할 수 있다.
장점
- 쓰레드가 미리 생성되어 있으므로, 쓰레드를 생성하고 종료하는 비용(CPU)이 절약되고, 응답시간이 빠르다.
- 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있다.
쓰레드 풀의 실무 팁
- WAS의 주요 튜닝 포인트는 최대 쓰레드(max thread)수이다.
- 이 값을 너무 낮게 설정하면?
- 동시 요청이 많으면, 서버 리소스는 여유롭지만, 클라이언트는 금방 응답 지연이 걸릴 것이다.
- 이 값을 너무 높게 설정하면?
- 동시 요청이 너무 많아지게 되며, CPU, 메모리 리소스 임계점 초과로 서버가 다운될 것이다.
- 장애 발생시 해결법
1. 클라우드면 일단 서버부터 늘리고, 이후에 튜닝한다.
2. 클라우드가 아니면 열심히 튜닝한다
쓰레드 풀의 적정 숫자를 찾는 방법은 성능 테스트를 통해 찾아야 한다.
성능 테스트
- 최대한 실제 서비스와 유사하게 성능 테스트를 시도한다.
- 툴 : 아파치 ab, 제이미터, nGrinder
WAS의 멀티 쓰레드 지원
- 멀티 쓰레드에 대한 부분은 WAS가 처리한다.
- 개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 된다.
- 개발자는 마치 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드를 개발한다.
- 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용해야 한다.
HTML, HTTP API, CSR, SSR
정적 리소스
- 고정된 HTML 파일, CSS, JS, 이미지, 영상 등을 제공한다.
- 주로 웹 브라우저 이다.
HTML 페이지
- 동적으로 필요한 HTML 파일을 생성해서 전달한다.
- 웹 브라우저 : HTML 해석
HTTP API
- HTML이 아니라 데이터를 전달한다.
- 주로 JSON 형식을 사용
- 다양한 시스템에서 호출
HTTP API는 데이터만 주고 받기 때문에 웹 브라우저처럼 화면을 보여야 하는 경우에는 적절치 않을 수 있다.
HTTP API는 다양한 시스템에서 호출한다.
데이터만 주고 받는데, 만약 UI 화면이 필요하면, 클라이언트가 별도의 처리를 한다.
앱, 웹 클라이언트, 서버 to 서버
HTTP API
다양한 시스템 연동
- 주로 JSON 형태로 데이터를 통신한다.
- UI 클라이언트 접점
- 앱 클라이언트(아이폰, 안드로이드, PC 앱)
- 웹 브라우저에서 자바스크립트를 통한 HTTP API 호출
- React, Vue.js 같은 웹 클라이언트
- 서버 to 서버
- 주문 서버 -> 결제 서버
- 기업간 데이터 통신
백엔드 개발자가 고민해야 하는 세가지
1. 정적 리소스를 어떻게 제공할지
2. HTML 페이지를 어떻게 제공할지
3. HTTP API를 어떻게 제공할지
서버 사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR)
SSR - 서버 사이드 렌더링
- 서버에서 최종 HTML을 생성해서 클라이언트에 전달한다.
- 주로 정적인 화면에 사용한다.
- 관련기술 : JSP, 타임리프 -> 백엔드 개발자
CSR - 클라이언트 사이드 렌더링
- HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용한다.
- 주로 동적인 화면에 사용한다, 웹 환경을 마치 앱처럼 필요한 부분 부분 변경할 수 있다.
- 예)구글 지도, Gmail, 구글 캘린더
- 관련 기술 : React, Vue.js -> 웹 프론트엔드 개발자
백엔드 개발자 입장에서 UI 기술
백엔드 - 서버 사이드 렌더링 기술
- JSP, 파임리프
- 화면이 정적이고, 복잡하지 않을 때 사용
- 백엔드 개발자는 서버 사이드 렌더링 기술 학습이 필수이다.
웹 프론트엔드 - 클라이언트 사이드 렌더링 기술
- React, Vue.js
- 복잡하고 동적인 UI 사용
- 웹 프론트엔드 개발자의 전문 분야
백엔드 개발자의 웹 프론트엔드 기술 학습은 옵션이다.
백엔드 개발자는 서버, DB, 인프라 등등 수 많은 백엔드 기술을 공부해야 한다.
웹 프론트엔드도 깊이있게 잘 하려면 오랜 시간의 숙련 기간이 필요하다.
자바 백엔드 웹 기술의 역사
과거 기술
- 서블릿 - 1997
- HTML 생성이 어려움
- JSP - 1999
- HTML 생성은 편리하지만, 비즈니스 로직까지 너무 많은 역할을 담당한다.
- 서블릿, JSP 조합 MVC 패턴 사용
- 모델, 뷰 컨트롤러로 역할을 나누어 개발한다.
- MVC 프레임워크 춘추 전국 시대 - 2000년 초 ~ 2010년 초
- MVC 패턴의 자동화, 복잡한 웹 기술을 편리하게 사용할 수 있는 다양한 기능을 지원
- 스트럿츠, 웹워크, 스프링 MVC(과거 버전)
현재 사용 기술
- 애노테이션 기반의 스프링 MVC 등장
- @Controller
- MVC 프레임워크의 춘추 전국 시대 마무리
- 스프링 부트의 등장
- 스프링 부트는 서버를 내장
- 과거에는 서버에 WAS를 직접 설치하고, 소스는 War 파일을 만들어서 설치한 WAS에 배포
- 스프링 부트는 빌드 결과(Jar)에 WAS 서버 포함 -> 빌드 배포 단순화
최신 기술 - 스프링 웹 기술의 분화
- Web Servlet - Spring MVC
- Web Reactive - Spring WebFlux
WebFlux의 특징
1. 비동기 넌블러킹 처리
2. 최소 쓰레드로 최대 성능 - 쓰레드 컨텍스트 스위칭 비용 효율화
3. 함수형 스타일로 개발 - 동시처리 코드 효율화
4. 서블릿 기술 사용 X
단점
1. 웹 플럭스는 기술적 난이도가 매우 높음
2. 아직은 RDB 지원 부족
3. 일반 MVC 쓰레드 모델도 충분히 빠르다.
4. 실무에서는 아직 많이 사용하지는 않음
자바 백엔드 웹 기술의 역사
HTML을 편리하게 생성하는 뷰 기능
1. JSP
- 속도가 느림, 기능이 부족함
2. 프리마서(Freemarker), Velocity(벨로시티)
- 속도 문제 해결, 다양한 기능
3. 타임리프(Thymeleaf)
- 네추럴 템플릿 : HTML의 모양을 유지하면서 뷰 템플릿 적용 가능
- 스프링 MVC와 강력한 기능 통합
- 최선의 선택, 단 성능은 프리마커, 벨로시티가 더 빠름
'공부 > Spring' 카테고리의 다른 글
| 서블릿, JSP, MVC 패턴 (0) | 2025.03.12 |
|---|---|
| 서블릿(Servlet) (0) | 2025.03.11 |
| 빈 스코프 (0) | 2024.11.08 |
| bean 생명주기 콜백 (0) | 2024.11.06 |
| 의존관계 자동 주입 (9) | 2024.11.05 |