웹 애플리캐이션

웹 - HTTP 기반

클라이언트와 서버가 요청/응답을 주고 받을 때 HTTP를 통해서 주고 받는다.

HTTP 메시지에 모든 것을 전송

 

웹서버

HTTP를 기반으로 동작하는 서버

정적 리소스 제공, 기타 부가기능

 

웹 시스템 구성 - WAS, DB

이미지 제공하는 로직보다 애플리케이션은 복잡하기 때문에 비싸다

WAS만으로 구성을 하면 장애가 나면 웹으로 접근조차 안되기 때문에 오류 화면 조차도 노출이 불가능하다.

보통은 웹서버가 정적인 부분을 처리하고 동적인 로직이 필요하면 WAS가 처리를 하는 식으로 구성

시스템 리소스를 효율적으로 쓸 수 있다.

정적 리소스만 제공하는 웹 서버는 잘 죽지 않음(계산하는 로직이 잘 들어가지 않음)

여러가지 이유로 WAS는 죽을 수 있다.

API만 제공하게 되면 굳이 WEB서버 필요 없음

 

서블릿

회원가입 폼에서 POST로 저장하려 할 때, 웹 브라우저가 요청 HTTP 메시지를 만들어서 서버로 보낸다.

 

만약 웹애플리케이션 서버를 밑바닥부터 만들게 되면 HTTP 메시지를 풀어 헤쳐야 된다.

기본적으로 TCP/IP로 통신하기 때문에 소켓으로 직접 연결을 하고 HTTP 요청 메시지는 단순 TEXT기 때문에 파싱을 해서 전송 방식을 읽고 데이터를 파싱한다. 로직을 찾아서 실행하여 HTTP 메시지를 직접 생성하여 보내줘야 된다.

비즈니스 로직은 디비에 저장하면 끝인데 너무 길어 지기 때문에 서블릿이 비즈니스 로직 이외에 것을 지원해준다.

 

기본적인 HTTP 스팩은 아는 것이 필수

 

웹 브라우저에서 먼저 요청을 하면 WAS서버에서 요청 메시지를 기반으로 request/response객체를 만들어서 서블릿 컨테이너로 실행으로 넘기고 reponse를 뒤져 응답메시지를 만들어서 웹브라우저로 전달한다.

 

서블릿 컨테이너

서블릿 객체를 직접 생성하는게 아니라 코드만 만들면 서블릿을 WAS안에 서블릿컨터이너가 서블릿 객체를 자동으로 생성하고 호출 해준다.(생명주기에 맞춰)

 

 서블릿 객체는 싱글톤으로 관리

객체를 하나만 생성해두고 공유해서 쓴다. 

request/response 객체는 요청이 올때 마다 바꾸는게 맞다.(유저마다 정보가 다르기 때문)

하지만 서블릿 객체를 여러번 생성할 필요는 없다.

공유 변수 사용을 주의해야 한다.(싱글톤을 사용할때)

동시 요청을 위한 멀티 쓰레드 처리 지원(WAS가 자동으로 해결해줌)

 

멀티쓰레드

백엔드 개발자는 멀티 쓰레드가 정말 중요하다.

웹 브라우저에서 서버로 요청을 하면 TCP/IP 연결이되고 서블릿을 호출해준다.

서블릿을 호출하는 것이 쓰레드이다.

애플리케이션 코드를 하나하나 실행하는 것이 쓰레드이다.

프로세스는 프로그램 실행 쓰레드는 프로그램안에서 나뉘는 것

main메서드를 실행하면 main이라는 쓰레드가 실행되는 것

쓰레드가 없으면 자바 애플리케이션 자체가 실행이 불가

쓰레드는 한번에 하나의 코드라인만 수행

동시 처리가 필요하면 쓰레드를 추가로 생성 필요

 

요청이 오면 쓰레드를 할당을 하고 쓰레드를 가지고 서블릿을 실행 응답을 하고 나면 쓰레드가 휴식을 한다.

다중 요청이 올 때, 쓰레드가 요청이 처리 지연 중이라면 쓰레드가 하나이면 쓰레드 대기가 일어나서 클라이언트가 둘다 죽게 된다.

이걸 해결하는 방법으로 요청이 올때마다 쓰레드를 하나 그냥 생성하면 된다.

 

청이 올때마다 쓰레드를 하게 되면

• 장점

1. 동시 요청을 처리할 수 있다.

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

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

 

• 단점

1. 쓰레드는 생성 비용은 매우 비싸다.

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

3. 쓰레드는 컨텍스트 스위칭 비용이 발생한다.

4. 쓰레드 생성에 제한이 없다. 

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

 

쓰레드 풀

요청이 오면 쓰레드 풀에게 요청을 하고 미리 만들어진 놀고있는 쓰레드를 주고 끝나면 쓰레드 풀에 반납

쓰레드 풀에 쓰레드가 없으면 거절,대기 할 수 있다.

 

• 특징

1. 필요한 쓰레드를 쓰레드 풀에 보관하고 관리한다. 

2. 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다. 톰캣은 최대 200개 기본 설정 (변경 가능)

 

• 사용

1. 쓰레드가 필요하면, 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내서 사용한다.

2. 사용을 종료하면 쓰레드 풀에 해당 쓰레드를 반납한다. 

3. 최대 쓰레드가 모두 사용중이어서 쓰레드 풀에 쓰레드가 없으면? 

기다리는 요청은 거절하거나 특정 숫자만큼만 대기하도록 설정할 수 있다.

 

• 장점 

1. 쓰레드가 미리 생성되어 있으므로, 쓰레드를 생성하고 종료하는 비용(CPU)이 절약되고, 응답 시간이 빠르다. 

2. 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있다.

 

실무 팁

• WAS의 주요 튜닝 포인트는 최대 쓰레드(max thread) 수이다.

• 이 값을 너무 낮게 설정하면?

1. 동시 요청이 많으면, 서버 리소스는 여유롭지만, 클라이언트는 금방 응답 지연

• 이 값을 너무 높게 설정하면? 

1. 동시 요청이 많으면, CPU, 메모리 리소스 임계점 초과로 서버 다운

• 장애 발생시?

1. 클라우드면 일단 서버부터 늘리고, 이후에 튜닝 

2. 클라우드가 아니면 열심히 튜닝

 

• 적정 숫자는 어떻게 찾나요?

1. 애플리케이션 로직의 복잡도, CPU, 메모리, IO 리소스 상황에 따라 모두 다름

2. 성능 테스트

최대한 실제 서비스와 유사하게 성능 테스트 시도

툴: 아파치 ab, 제이미터, nGrinder

 

• 멀티 쓰레드에 대한 부분은 WAS가 처리

• 개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 됨

• 개발자는 마치 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드를 개발

• 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용

 

HTML, HTTP API, CSR, SSR

정적 리소스를 제공할 때 보통 고정 된 파일을 제공하면 된다.

 

HTML 페이지

요청을 받으면 동적으로 HTML을 생성해서 전달

 

HTTP API

HTML을 전달하는게 아닌 데이타를 전달 할 때 웹 브라우저가 JSON의 형태의 데이터를 받으면 해석을 못함

HTML 랜더링 할 떄 쓰는것이 아닌 다양한 시스템에서 호출

데이터만 주고 받음, UI 화면이 필요하면, 클라이언트가 별도 처리

앱 클라이언트, 웹 클라이언트 자바스크립트, 서버 to 서버 등으로 받을 수 있다.

 

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

• SSR - 서버 사이드 렌더링

1. HTML 최종 결과를 서버에서 만들어서 웹 브라우저에 전달 

2. 주로 정적인 화면에 사용 

3. 관련기술: JSP, 타임리프 -> 백엔드 개발자

 

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

웹 브라우저는 서버에 먼저 요청을 하는 건 SSR과 같다.

아무것도 없는 HTML와 자바스크립트 링크를 내려 줌

자바스크립트를 서버에 요청 함(클라이언트 로직, HTML 렌더링 코드)

HTTP API로 데이터 요청(JSON 데이터 받음)

1. HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용 

2. 주로 동적인 화면에 사용, 웹 환경을 마치 앱 처럼 필요한 부분부분 변경할 수 있음 

3. 예) 구글 지도, Gmail, 구글 캘린더 

4. 관련기술: React, Vue.js -> 웹 프론트엔드 개발자

 

• 참고 

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

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

 

어디까지 알아야 하나요?

백엔드 개발자 입장에서 UI 기술

 

• 백엔드 - 서버 사이드 렌더링 기술 

1. JSP, 타임리프 

2. 화면이 정적이고, 복잡하지 않을 때 사용 

3. 백엔드 개발자는 서버 사이드 렌더링 기술 학습 필수

 

• 웹 프론트엔드 - 클라이언트 사이드 렌더링 기술 

1. React, Vue.js 

2. 복잡하고 동적인 UI 사용

3. 웹 프론트엔드 개발자의 전문 분야

 

• 선택과 집중 

1. 백엔드 개발자의 웹 프론트엔드 기술 학습은 옵션 

2. 백엔드 개발자는 서버, DB, 인프라 등등 수 많은 백엔드 기술을 공부해야 한다. 

3. 웹 프론트엔드도 깊이있게 잘 하려면 숙련에 오랜 시간이 필요하다.

 

 

자바 백엔드 웹 기술 역사

• 서블릿 - 1997

-  HTML 생성이 어려움

 

• JSP - 1999 

- HTML 생성은 편리하지만, 비즈니스 로직까지 너무 많은 역할 담당

 

• 서블릿, JSP 조합 MVC 패턴 사용 

- 모델, 뷰 컨트롤러로 역할을 나누어 개발

 

• MVC 프레임워크 춘추 전국 시대 - 2000년 초 ~ 2010년 초 

- MVC 패턴 자동화, 복잡한 웹 기술을 편리하게 사용할 수 있는 다양한 기능 지원

- 스트럿츠, 웹워크, 스프링 MVC(과거 버전)

 

현재 사용 기술

• 애노테이션 기반의 스프링 MVC 등장 

- @Controller 

- MVC 프레임워크의 춘추 전국 시대 마무리

 

• 스프링 부트의 등장 

- 스프링 부트는 서버를 내장 

- 과거에는 서버에 WAS를 직접 설치하고, 소스는 War 파일을 만들어서 설치한 WAS에 배포 

- 스프링 부트는 빌드 결과(Jar)에 WAS 서버 포함 -> 빌드 배포 단순화

 

 

스프링 웹 기술의 분화

• Web Servlet - Spring MVC

spring MVC는 기본적으로 서블릿 기반으로 동작하는데, 서블릿 위에서 spring MVC를 올려서 사용

멀티쓰레드 등을 지원

 

• Web Reactive - Spring WebFlux

• 특징 

1. 비동기 넌 블러킹 처리 

2. 최소 쓰레드로 최대 성능 - 쓰레드 컨텍스트 스위칭 비용 효율화(코어 수에 맞춤)

3. 함수형 스타일로 개발 - 동시처리 코드 효율화 

4. 서블릿 기술 사용X

• 그런데 

1. 웹 플럭스는 기술적 난이도 매우 높음 

2. 아직은 RDB 지원 부족 

3. 일반 MVC의 쓰레드 모델도 충분히 빠르다. 

4. 실무에서 아직 많이 사용하지는 않음 (전체 1% 이하)

 

자바 뷰 템플릿

HTML을 편리하게 생성하는 뷰 기능

HTML을 백엔드에서 동적으로 생성하는 것

 

• JSP 

- 속도 느림, 기능 부족

 

• 프리마커(Freemarker), Velocity(벨로시티) 

- 속도 문제 해결, 다양한 기능

 

• 타임리프(Thymeleaf) 

- 내추럴 템플릿: HTML의 모양을 유지하면서 뷰 템플릿 적용 가능 

- 스프링 MVC와 강력한 기능 통합 

- 최선의 선택, 단 성능은 프리마커, 벨로시티가 더 빠름