Web Server vs WAS(Web Application Server)
| 항목 | Web Server | WAS(Web Application Server) |
|---|---|---|
| 정의 | 정적인 파일(HTML, CSS, 이미지 등)을 제공 | 동적인 콘텐츠 생성과 데이터 처리를 제공 |
| 기능 | HTTP 프로토콜을 이용해 클라이언트에게 웹 페이지 제공 | 웹 애플리케이션의 실행 및 데이터 처리 |
| 대표 | Nginx, Apache | Tomcat, Jetty |
| 기타 | - | Java에서는 Servlet Container 기능을 제공하면 WAS라고 함 |
Web System 구성
- WAS만 사용하는 경우
- WAS가 너무 많은 역할을 담당하여 서버 과부하 발생 가능성이 높아짐
- Application 로직이 정적 리소스로 인해 수행되지 않을 수 있음
- WAS에 장애가 생기면 아무런 화면도 보여주지 않음
- 오류 페이지를 클라이언트에서 응답할 수 없음
- Web Server와 WAS를 함께 사용하는 경우 (실제 웹 시스템 구성)
- 정적 리소스는 Web Server에서 처리
- Web Server는 Application 로직이 필요한 요청만 WAS에 전달
- 실제 웹 시스템 구성의 장점
- 효율적인 리소스 관리
- 많이 사용되는 리소스의 서버를 Scale Out(수평적 확장)하기 쉬움
- 오류 화면 제공 가능
- WAS에서 오류가 발생하더라고 정적 리소스는 Web Server에서 관리하기 때문에 오류 화면을 제공할 수 있음
Servlet
HTTP 프로토콜 기반 요청(Request) 및 응답(Response)을 처리하는데 사용됨. Java에서 HttpServlet 클래스를 상속받아 구현되며, 웹 애플리케이션 개발의 핵심 기술 중 하나.
- Servlet의 역할
- 클라이언트의 요청을 처리하고 응답을 반환
- Servlet을 지원하지 않는 경우 처리해야 하는 작업
- 서버와 TCP/IP 연결
- HTTP Request Message 필요한 형태로 변환하여 읽기
- HTTP Method 및 URL 분석
- HTTP Header 분석
- HTTP Message Body 읽기 및 변환
- 분석한 결과를 통해 프로세스 실행
- 비즈니스 로직 실행
- HTTP Response Message 생성
- HTTP Start Line 생성
- Header 생성
- HTTP Message Body에 응답 데이터를 요청한 형식에 맞춰 응답
- 처리가 불가하다면 예외처리
- 응답 전달
- 연결 종료
- Servlet을 지원하는 경우 처리해야 하는 작업
- 비즈니스 로직 실행
Servlet 동작 순선
WAS는 HTTP 요청 메세지를 기반으로 새로운 Request, Response 객체 생성
WAS는 만들어진 Request, Response 객체를 서블릿 컨테이너에 넘겨주며 Servlet 객체 호출 (위 예시의 객체명은 ExampleServlet)
ExampleServlet에서 비지니스 로직 처리
응답에 필요한 정보를 개발자가 입력
WAS는 Response 객체 정보(개발자가 입력한 정보)로 HTTP 응답 메세지 생성
개발자가 하는 일
- Request 객체에 담겨져있는 HTTP 요청 정보(URL, Method, Message Body)를 통해 필요한 기능(비지니스 로직)을 수행
- 생성된 Response 객체에 HTTP 응답 정보 입력
Servlet Container
Servlet을 지원하는 WAS 내부에는 서블릿 컨테이너가 있으며, 서블릿 컨테이너는 서블릿을 초기화, 생성, 관리, 호출, 종료하는 역할을 수행
- Servlet의 생명 주기
- 서블릿 컨테이너가 생성 및 관리
- WAS가 종료될 때 함께 종료
- Servlet 객체 생성 시점
- 개발자가 직접 인스턴스화 하지 않으며, 작성된 코드에 따라 서블릿 컨테이너가 생성
- Servlet Container의 역할
- 서블릿을 초기화, 생성, 관리, 호출, 종료하는 역할 수행
- 서블릿 객체를싱글톤으로 관리
- 동시 요청에 대한 처리를 위해Multi Thread를 지원💡 싱글톤이란?
싱글톤은 객체를 하나만 생성하여 생성된 인스턴스를 공유하여 사용하는것을 의미. 특정 클래스의 인스턴스가 여러 개 생성되지 않도록 하여 자원의 낭비를 방지하고, 인스턴스를 공유함으로써 일관된 상태를 유지. 하지만, 공유 변수 사용 시 주의가 필요.
Thread
- Single Thread
- 먼저 들어온 요청의 작업이 끝날 때까지 대기했다가 다음 요청을 처리
- 먼저 들어온 요청이 지연되거나 오류 발생 시, 나머지 요청들에도 영향이 발생
- Multi Thread
- 요청마다 새로운 Thread 생성
- 동시 요청을 처리할 수 있으며, 하나의 Thread에서 문제가 발생하여도 나머지 Thread가 처리 가능
- 하지만, Thread 생성에 제한이 없고 생성 비용이 높음
- 수많은 동시 요청이 발생하면 리소스 부족으로 서버가 다운될 수 있음
Context Switching비용이 발생
- 다른 Task로 교체되는 시점마다 각 Task 수행에 필요한 정보들을 로딩하는 시간
- Thread Pool
- 미리 여러 개의 Thread를 생성
- 요청이 들어오면 Thread Pool에서 Thread를 받아서 사용
- 사용 완료된 Thread는 Thread Pool에 반납
SSR (Server Side Rendering)
서버에서 동적으로 HTML을 만들어 클라이언트에게 제공. 백엔드 개발자 영역에 속하며, Java에서는 JSP, Thymeleaf를 대표적으로 사용.
- SSR 동작 흐름
- 서버(WAS)에 HTML 요청
- 서버에서 로직을 거친후 DB 조회
- 조회 결과를 기반으로 HTML을 동적으로 생성
- 생성된 HTML을 응답
- SSR의 장점
- 서버에서 완전히 렌더링된 HTML을 반환하기 때문에 첫 페이지 로딩이 빠름
- 검색 엔진 크롤러가 완전한 HTML을 즉시 수집할 수 있어
SEO에 유리
- SEO(Search Engine Optimization) : 검색 엔진에서 상위에 노출될 수 있도록 최적화 하는 과정
- SSR의 단점
- 모든 요청에 대해 서버가 페이지를 렌더링해야 하므로, 높은 트래픽 상황에서 서버의 부하가 크게 증가할 수 있음
- 첫 페이지 이외의 페이지들도 렌더링 후 반환되기 때문에 속도가 느림
CSR (Client Side Rendering)
웹 브라우저에서 자바스크립트를 사용해 동적으로 HTML을 생성해서 적용하는 기술로 웹을 모바일 앱 처럼 부분 부분 변경할 수 있게 해줌. 프론트엔드 개발자 영역에 속하며, React, Vue를 대표적으로 사용.
- CSR 동작 흐름
- HTML을 요청하여, 빈 HTML과 JS가 존재하는 주소 링크를 응답 받음
- 자바 스크립트(클라이언트 로직, 렌더링 포함)를 요청
- HTTP API 요청을 통해 응답받은 데이터로 HTML을 동적으로 그림
- CSR의 장점
- 클라이언트 측에서 렌더링하므로 사용자 인터랙션에 빠르게 반응할 수 있음
- 초기 로딩 이후에는 서버와의 통신 없이 빠르게 페이지 간 전환이 가능
- CSR의 단점
- 초기 로딩시 필요한 모든 자바 스크립트 파일을 다운로드하고 실행해야 하기 때문에 로딩이 느림
- 검색 엔진 크롤러가 자바 스크립트를 제대로 실행하지 못하면 SEO에 불리할 수 있음
