웹 애플리케이션 이해

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

웹 서버

• HTTP 기반 동작
• 정적 리소스(HTML, CSS, JS, 이미지, 영상) 제공
• 예) NGINX, APACHE

웹 어플리케이션 서버

• HTTP 기반 동작
• 웹 서버 기능 포함(정적 리소스 제공)
• 프로그램 코드 실행해 애플리케이션 로직 수행
  • 동적 HTML, HTTP API(JSON)
  • 서블릿, JSP, 스프링 MVC
• 예) 톰캣(Tomcat), Jetty, Undertow

 

웹 서버와 웹 애플리케이션 서버의 차이

• 웹 서버는 정적 리소스(파일), WAS는 애플리케이션 로직
• 웹 서버도 프로그램 실행 기능 포함하기도 함
• WAS도 웹 서버의 기능 제공
• 자바는 서블릿 컨테이너 기능 제공 = WAS
• WAS는 애플리케이션 코드를 실행하는데 특화

웹 시스템 구성

WAS가 너무 많은 일을 하니까 일을 나눠주기 위해 WS에서 정적 리소스 처리를 맡음.

정적 리소스 처리량이 많으면 WS를 증설, 동적 리소스 처리량이 많으면 WAS 증설

 

서블릿

서버에서 처리해야 하는 업무 = 백엔드 개발자가 구현해야 하는 업무

직접 처리하자니 반복되는 작업이 너무 많음(HTTP Header생성 등)

서블릿이 그 작업들을 자동으로 해주니 개발자는 비즈니스 로직에만 집중하면 된다.

 

서블릿의 특징

• urlPattern(/hello)의 URL이 호출되면 서블릿 코드가 실행됨
• HTTP 요청 정보 편리 사용 = HttpServletRequest
• HTTP 응답 정보 편리 제공 = HttpServletResponse
• => 개발자는 HTTP 스펙을 편리하게 사용

HTTP 요청시

• WAS: Request, Response 객체 생성, 서블릿 객체 호출
• 개발자: Request 객체에서 HTTP 요청 정보 꺼내 사용
• 개발자: Response 객체에 HTTP 응답 정보 입력
• WAS: Response 객체에 담겨있는 내용으로 HTTP 응답 정보 생성

서블릿 컨테이너

• 서블릿 지원하는 WAS = 서블릿 컨테이너
• 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리
• 서블릿 객체는 싱글톤으로 관리
• 최초 로딩 시점에 서블릿 객체 미리 만들어두고 재활용
• 공유 변수 사용 주의
• 서블릿 컨테이너 종료시 함께 종료
• JSP도 서블릿으로 변환되어 사용
• 동시 요청 위한 멀티쓰레드 처리 지원

쓰레드

• 서블릿을 실행하는 주체
• 애플리케이션 코드를 하나하나 순차적으로 실행(한번에 하나의 코드 라인)
• 자바 메인 메서드 처음 실행하면 main이라는 이름의 쓰레드 실행
• 쓰레드 없으면 자바 애플리케이션 실행 불가능
• 동시 처리가 필요하면 쓰레드 추가 생성

요청마다 쓰레드 생성의 장단점

• 장점
  • 동시 요청 처리 가능
  • 리소스(CPU, 메모리)가 허용할 때까지 처리 가능
  • 하나의 쓰레드가 지연되어도 나머지 쓰레드 정상 동작
• 단점
  • 쓰레드 생성 비용 매우 비쌈(응답 속도 느려짐)
  • 쓰레드는 컨텍스트 스위칭 비용 발생
  • 쓰레드 생성에 제한 없음(리소스 초과돼 서버 죽을 수도 있음)

쓰레드 풀

• 특징
  • 필요한 쓰레드를 쓰레드 풀에 보관하고 관리
  • 생성 가능한 쓰레드의 최대치 관리. 톰캣은 기본 최대 200개 설정. 변경 가능
• 사용
  • 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내 사용
  • 사용 종료하면 쓰레드 풀에 쓰레드 반납
  • 기다리는 쓰레드 요청은 거절하거나 특정 숫자만큼 대기하도록 설정 가능
• 장점
  • 쓰레드를 생성하고 종료하는 비용(CPU)이 절약되고, 응답 시간 빠름
  • 너무 많은 요청이 들어와도 서버가 죽을 염려 없이 기존 요청들을 안전하게 처리 가능
• 최대 쓰레드 수(WAS의 주요 튜닝 포인트)
  • 낮게 설정 -> 클라이언트 응답 지연
  • 높게 설정 -> CPU, 메모리 리소스 임계점 초과로 서버 다운
  • 장애 발생시 -> 클라우드면 서버 증설, 이후 튜닝 / 클라우드 아니면 튜닝
• 적정 숫자
  • 성능 테스트(아파치 ab, 제이미터, nGrinder)

서버사이드 렌더링(SSR)과 클라이언트 사이드 렌더링(CSR)

SSR - 서버 사이드 렌더링

• HTML 최종 결과를 서버에서 다 만들어서 웹 브라우저에 전달
• 정적인 화면에 주로 사용
• JSP, 타임리프 -> 백엔드 개발자가 다룸(할 줄 알아야 함)

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

• HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용
• 동적인 화면에 주로 사용(웹 환경을 앱처럼 필요한 부분만 변경 가능)
• 복잡하고 동적인 UI 사용
• 예) 구글지도, Gmail, 구글 캘린더
• React, Vue.js -> 웹 프론트엔드 개발자가 다룸

자바 뷰 템플릿 역사

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