모든 통신은 HTTP 기반이다.
• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML (API)
• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
Web Server
- HTTP 기반으로 작동하는 서버이다.
- 정적 리소스(HTML, CSS, JS, 이미지, 영상)를 제공하고 기타 부가기능이 있다.
- NGINX, APACHE라는것이 있다.
Web Application Server
- HTTP 기반작동
- 웹 서버 기능을 포함하고 있다
- 프로그램 코드를 실행해서 애플리케이션 로직 수행이 가능하다.
- 동적 HTML, HTTP API(JSON)
- 서블릿, JSP
- Tomcat
사실 이 둘은 경계도 용어도 되게 모호하다. 웹 서버도 프로그램 실행 기능을 포함하기도 하고, 웹 애플리케이션 서버도 웹 서버 기능을 제공한다.
자바의 경우는 서블릿 컨테이너 기능을 제공하면 WAS이다.
WAS는 어플리케이션 코드 실행에 특화되어있다.
웹 시스템 구성 WAS, DB
최소한으로 WAS와 DB만 가지고 구성이 가능하다.
대신 이러면 WAS가 너무 많은 일을 담당한다, 과부하 우려가 있다.
HTML, CSS, 이미지같은 정적 리소스들은 값이 싸다. 그냥 파일을 불러다가 보내면 되는데 어플리케이션은 코드실행과정이 들어가서 비용이 비싸진다. 따라서 정적리소스와 어플리케이션 로직을 분리해야한다.
또한 WAS에 오류가 나버리면 오류화면조차 보여줄 수 가 없다.
WEB, WAS, DB
Web Server가 정적 리소스를 처리하고
그 다음 WAS가 중요한 어플리케이션 로직만 전담해서 처리하는 역할을 하다록 구성한것이다.
이러한 방식을 구성하면 시스템 리소스를 효율적으로 구성할 수 있다. 더 많이 필요한 부분을 증가시킬 수 있기 때문이다.
또한 WAS가 죽었을 때, Web Server가 오류화면을 보여주도록 설정할 수 있다.
Servlet
서블릿은 비즈니스 로직실행과 DB 저장 요청 이 과정을 제외한 나머지 모든 과정을 자동으로 처리해준다.
- HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest
- HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse
같은 기능이 있다.
전체 흐름
HTTP 요청시
• WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출
• 개발자는 Request 객체에서 HTTP 요청 정보를 꺼내서 사용
• 개발자는 Response 객체에 HTTP 응답 정보를 입력
• WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성
서블릿 컨테이너
톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 한다.
서블릿 컨테이너는 객체를 생성 초기솨 호출 종료하는 생명주기를 싱글톤으로 관리해준다.
동시요청을 자동적으로 멀티스레드화 해준다.
동시요청 멀티스레드
쓰레드
애플리케이션 코드를 하나씩 순차적으로 실행하는것이 쓰레드이다. 쓰레드가 없다면 자바 어플리케이션 수행 자체가 불가능하다.
쓰레드는한번에 하나씩만 처리하니깐, 동시처리가 필요하다면 쓰레드를 하나 더 호출해야한다.
다중요청
만약 쓰레드를 하나만 쓴다면...
- 요청 1이 온다면, 이를 쓰레드1에 매칭해준다.
- 아직 쓰레드1이 사용중인데, 요청 2가 온다면, 쓰레드가 없어서 대기해야하고 이 과정에서 timeout이 발생할 수 있다.
멀티쓰레딩
1. 요청 1이 온다면, 이를 쓰레드1에 매칭해준다.
2. 아직 쓰레드1이 사용중인데, 요청 2가 온다면, 하나 더 만든 쓰레드에 새로 온 요청을 매칭해준다.
장점
- 동시요청 처리가능
- 리소스 한계치까지 처리 가능
- 하나의 쓰레드가 지연되어도, 정상 동작 한다
단점
- 쓰레드 생성 비용이 매우 비싸다
- 요청마다 쓰레드 생성을 하면 응답속도가 느려진다
- 컨텍스트 스위칭 비용이 발생한다
- 생성 제한이 없다
- 요청이 지속되어 리소스 임계점을 넘어가면 서버가 다운되어버린다.
쓰레드풀
이를 해결하기 위해 내부에 쓰레드풀을 둔다.
쓰레드 풀에 미리 쓰레드를 만들어두고 요청이 올 때 마다 그 안에서 쓰레드를 꺼내주는것이다.
만약 사용이 끝난 쓰레드가 있다면 이를 쓰레드 풀로 반납을 한다. 이런식으로 생성 삭제가 아닌 빌리고 반납하는 구성을 취하는것이다.
풀을 이용하면, 미리 생성해놨기에 생성비용을 줄일 수 있고 응답시간 확보가 가능하며, 서버의 한계를 미리 지정해서 서버의 안정성을 확보할 수 있는점이다.
실무 팁
- 주요 튜닝 포인트는 Max Thread
- 너무 낮으면 서버리소스는 놀고 클라이언트들은 대기한다
- 너무 높으면 서버가 다운된다.
- 장애 발생 시
- 클라우드면 일단 서버를 늘리고, 그 다음에 튜닝해야한다
- 아니면 튜닝 열심히 해라...
적정숫자를 어떻게 찾아야할까?
환경마다 다르기때문에, 실제 환경과 유사하게 테스트를 해봐야한다
HTTP API
- 주로 JSON 형태로 통신한다.
- UI 클라이언트 접점역할을 하고 서버간 통신 역할도 한다.
- 앱 클라이언트
- 웹 브라우저에서 JS로 API 호출
- React, Vue.js 같은 웹 클라이언트
- 주문 서버 -> 결제 서버 간 통신
- 기업 간 데이터 통신
Server Side Rendering
- 웹 브라우저의 요청
- 서버에서 DB 조회
- 서버에서 동적으로 HTML 생성
- 웹 브라우저에 반환
--> JSP, 타임리프 -> 백엔드 개발자
Client Side Rendering
- HTML 결과를 JS를 통해 웹 브라우저에서 동적으로 생성 사용
- 웹 환경을 마치 어플리케이션처럼 사용 가능
- 구글지도, Gmail 같은 기술
--> React, Veu.js -> 프론트앤드 개발자
