[Spring] 웹 애플리케이션 이해

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

---

웹 서버(Web Server)

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

 

웹 애플리케이션 서버(WAS - Web Application Server)

• HTTP 기반 동작
• 웹 서버 기능 포함 + 정적 리소스 제공 가능
• 프로그램 코드를 실행해서 애플리케이션 로직 수행 (ws와 차이❗️) -사용자마다 다르게 보여주기 가능
  • 동적 HTML 생성 가능, HTTP API(JSON) 가능
  • WAS 에서 서블릿, JSP, 스프링 MVC 동작 가능
• ex) 톰캣(Tomcat) Jetty, Undertow

 

WS 와 WAS 차이

• 웹 서버는 정적 리소스(파일), WAS는 애플리케이션 로직 실행하는 서버
• 자바는 서브릿 컨테이너 기능을 제공하면 WAS
• WAS 는 애플리케이션 코드를 실행하는데 더 특화

 

웹 시스템 구성

1. WAS, DB

• WAS, DB 만으로 시스템 구성 가능
• WAS 정적 리소스, 애플리케이션 로직 모두 제공 가능
• 애플리케이션 로직에서 데이터베이스 조회해 필요한 html을 동적으로 만들어 낼 수 있음
• But❗️ WAS가 너무 많은 역할을 담당 ➡︎ 서버 과부하 우려
• 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있음
• `WAS` 장애시 오류 화면조차도 노출 불가능

 

2. WEB, WAS, DB (일반적)

웹서버를 앞에둬 정적 리소스 먼저 다 처리.

애플리케이션 로직같은 동적인 처리가 필요한 경우 WAS 에 요청 넘김

WAS는 중요한 애플리케이션 로직 처리 전담

DB 조회해 가져온 데이터 다시 내려줌

 

➡︎ 효율적 리소스 관리 가능

정적 리소스가 많이 사용되면 Web 서버 증설

애플리케이션 리소스가 많이 사용되면 WAS 증설

 

➡︎ 오류 화면 제공 가능

 

WAS 서버는 잘죽는 반면, 정적 리소스만 제공하는 웹 서버는 잘 죽지 않음

WAS , DB 장애시 WEB 서버가 오류 화면 제공 가능

 

 

서블릿

---

Java에서 웹 요청을 처리하고 동적 콘텐츠를 생성하는 서버 측 프로그램

HTTP 요청 메시지를 해석하고, 필요한 로직을 수행한 후 HTTP 응답 메시지를 생성하는 과정을 도움

 

예를들어, 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 요청, 응답 흐름

---

1. 클라이언트 'localhost:8080/hello' 요청 보냄

2. 웹 서버(WAS)가 Request, Response 객체 생성 후, 서블릿 객체(서블릿 컨테이너가 자동 생성) 호출

3. 개발자는 Request 객체에서 HTTP 요청 정보를 읽고, Response 객체에 HTTP 응답 데이터를 작성

4. WAS는 Response 객체의 내용을 기반으로 최종 HTTP 응답을 생성

5. 클라이언트에 응답 반환

 

* my. 서블릿의 HTTP 요청 처리 흐름

1. 클라이언트 요청 전송
2. WAS(Tomcat) 처리 
   1. WAS(예: Tomcat)가 TCP/IP 연결 생성
   2. WAS 내부의 쓰레드 풀(Thread Pool)에서 작업할 쓰레드 하나를 할당
3. 웹 서버(WAS) 할당된 쓰레드가 Request, Response 객체 생성 후, 서블릿 호출
4. 서블릿에서 요청 처리 및 응답 데이터 작성(Request, Response 객체 사용)
5. WAS는 Response 객체의 내용을 기반으로 최종 HTTP 응답을 생성
6. 클라이언트에 응답 반환

 

 

서블릿 컨테이너

---

톰캣처럼 서블릿 지원하는 WAS

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

 

동시 요청 - 멀티 쓰레드

---

요청 들어오면 WAS가 TCP/IP 연결 생성하고 누군가 서블릿 호출함. 누가?

 

쓰레드

프로세스 내에서 실행되는 최소 실행 단위로, 애플리케이션 코드의 명령을 순차적으로 실행하며, 하나의 프로세스가 여러 작업을 동시에 수행할 수 있도록 돕는 실행 흐름

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

 

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

요청이오면 쓰레드를 할당.
할당된 쓰레드를 통해 서블릿 실행

응답 처리 완료하면 휴식을 하게됨

 

2. 다중 요청 - 쓰레드 하나 사용

만약 요청1 처리 지연되는 중에 요청2가 들어오면, 대기 하게됨

이러면 기다리다 결국 둘다 timeout 오류가 발생할 수 있음.

 

3. 요청 마다 쓰레드 생성

요청 마다 신규 쓰레드 생성해 해결

 

장점

동시 요청 처리 가능

리소스(CPU, 메모리)가 허용할 때 까지 처리 가능

하나의 쓰레드가 지연 되어도, 나머지 쓰레드는 정상 동작

단점

쓰레드 생성 비용 매우 비쌈

고객의 요청이 올 때마다 쓰레드를 생성하면, 응답 속도 늦어짐

쓰레드는 컨텍스트 스위칭 비용이 발생함 (CPU가 실행할 작업(쓰레드 또는 프로세스)을 전환하는 과정)

쓰레드 생성에 제한이 없음.

고객 요청이 너무 많이 오면, CPU, 메모리 임계점을 넘어서 서버가 죽을 수 있음

 

4. 쓰레드 풀

 

사용

• 쓰레드가 필요하면, 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내서 사용
• 사용을 종료하면 쓰레드 풀에 해당 쓰레드를 반납
• 최대 쓰레드가 모두 사용중이어서 쓰레드 풀에 쓰레드가 없다면? 
  • 기다리는 요청을 거절하거나 특정 숫자만큼만 대기하도록 설정 가능

특징

• 필요한 쓰레드 쓰레드 풀에 보관,관리
• 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리함. 톰캣은 최대 200개 기본 설정 (변경 가능)

장점

• 쓰레드가 미리 생성되어 있어, 쓰레드를 생성하고 종료하는 비용(CPU)이 절약되고, 응답 시간이 빠름
• 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리 가능

🌿 쓰레드 풀 실무 팁

• WAS 의 주요 튜닝 포인트는 최대 쓰레드(max thread) 수
• 이 값을 너무 낮게 설정하면? - 동시 요청이 많으면, 서버 리소스는 여유롭지만, 클라이언트는 금방 응답 지연
  • ex) 최대 쓰레드 10개 설정, 100개 요청, 90개 대기, cpu 5% 사용
• 이 값을 너무 높게 설정할 시? - 동시 요청이 많으면, CPU, 메모리 리소스 임계점 초과로 서버 다운된다.
• 장애 발생시?
  • 클라우드면 일단 서버부터 늘리고, 이후에 튜닝
  • 클라우드가  아니면 열심히 튜닝

🌿 쓰레드 풀 - 쓰레드 풀의 적정 숫자

• 적정 숫자는 어떻게 찾을까?
• 애플리케이션 로직의 복잡도, CPU, 메모리, IO 리소스 상황에 따라 모두 다름.
• 성능 테스트
  • 최대한 실제 서비스와 유사하게 성능 테스트 시도
  • 툴: 아파치 ab, 제이미터, nGrinder(추천)

 

🌿WAS 의 멀티 쓰레드 지원

• 멀티 쓰레드에 대한 부분은 WAS가 처리
• 개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 됨!
• 개발자는 마치 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드를 개발
• 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용

 

HTML, HTTP API, CSR, SSR

---

1. 정적 리소스

고정된 HTML 파일, CSS, JS, 이미지, 영상 등 제공

주로 웹 브라우저에서 사용

 

2. HTML 페이지

동적으로 필요한 HTML 파일을 생성해 전달 (JSP,타임리프)

웹 브라우저 -> HTML 해석

 

3. HTTP API

HTML이 아니라 데이터를 전달

주로 JSON 형식 사용

다양한 시스템에서 호출

데이터만 주고 받음

UI 화면이 필요하면, 클라이언트가 별도 처리

앱, 웹 클라이언트, 서버 to 서버

 

HTTP API - 다양항 시스템 연동

주로 JSON 형태로 데이터 통신
UI 클라이언트 접점

• 앱 클라이언트(아이폰, 안드로이드, PC 앱)
• 웹 브라우저에서 자바스크립트를 통한 HTTP API 호출할 수 있다.
• React, Vue.js 같은 웹 클라이언트

서버 to 서버

• 주문 서버 → 결제 서버
• 기업간 데이터 통신

 

4. 서버사이드 렌더링, 클라이언트 사이드 렌더링

SSR - 서버 사이드 렌더링

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

CSR - 클라이언트 사이드 렌더링

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

 

*참고 

React, Vue.js 를 사용하더라도, CSR + SSR 동시에 지원하는 웹 프레임워크도 있음

SSR 을 사용하더라도, 자바스크립트를 사용해서 화면 일부를 동적으로 변경 가능

 

자바 백엔드 웹  기술

---

• 과거에는 서버에 WAS를 직접 설치하고, 소스는 War 파일을 만들어서 설치한 WAS에 배포
• 스프링 부트는 빌드 결과(Jar)에 WAS 서버를 넣음 → 빌드 배포 단순화

최신 기술 - 스프링 웹 기술의 분화

• Web Servlet - Spring MVC
• Web Reactive - Spring WebFlux

최신 기술 - 스프링 웹 플럭스(WebFlux)

특징

• 비동기 넌 블러킹 처리
• 최소 쓰레드로 최대 성능 - 쓰레드 컨텍스트 스위칭 비용 효율화
• 함수형 스타일로 개발 - 동시처리 코드 효율화
• 서블릿 기술 사용하지 않음

그런데

• 웹 플럭스는 기술적 난이도 매우 높음
• 아직은 RDB 지원 부족
• 일반 MVC의 쓰레드 모델도 충분히 빠름
• 실무에서 아직 많이 사용하지는 않음 (전체 1% 이하)

자바 뷰 템플릿 역사 - HTML을 편리하게 생성하는 뷰 기능

• JSP : 속도 느림, 기능 부족
• 프리마커(Freemarker), Velocity(벨로시티) : 속도 문제 해결, 다양한 기능
• 타임리프(Thymeleaf)
  • 내추럴 템플릿: HTML의 모양을 유지하면서 뷰 템플릿 적용 가능하다.
  • 스프링 MVC와 강력한 기능 통합
  • 타임리프는 최선의 선택, 단 성능은 프리마커, 벨로시티가 더 빠르다.