[스프링 MVC 1편] 웹 애플리케이션 이해 정리

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

 

✔ 서블릿 (Servlet)

 

→ 의미 있는 비즈니스 로직을 제외한 모든 기능을 지원해준다!

→ TCP/IP연결, HTTP 요청 파싱, 응답 ...

 

@WebServlet(name = "helloServlet", url = "/hello")
public class HelloServlet extends HttpServlet {
    @Override
    protected void service(HttpServletRequest request, 
    				HttpServletResponse response) {
        //애플리케이션 로직
    }
}

→ http://localhost:8080/hello 의 URL이 호출되면 서블릿 코드(service)가 실행

→ 개발자는 HttpServletRequest 객체에서 Http 요청정보를 꺼내서 사용

→ 개발자는 HttpServletResponse 객체에서 Http 응답 정보를 저장

 

✔ 서블릿 컨테이너

 

= 서블릿을 지원하는 WAS

→ 서블릿 객체를 생성 + 호출 + 초기화 + 종료 + 생명주기 관리

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

→ 동시 요청을 위한 멀티 쓰레드 처리를 지원

 

싱글톤 (Singleton) ❓

고객의 요청이 올 때마다 계속 객체 생성을 하면 비효율적이므로 (고객마다 요청이 다름)
최초 로딩 시점에 서블릿 객체를 미리 만들고 계속 재활용
공유 변수 사용 주의

 

✔ 동시 요청 - 멀티쓰레드

 

쓰레드 ♻ 

 

→ 애플리케이션 코드를 하나하나 순차적으로 실행하는 것이 쓰레드!

→ 쓰레드가 서블릿을 호출해준다!

 

요청마다 쓰레드를 생성한다면 ❓

 

- 동시 요청 처리 가능 → 리소스가 허용할 때까지 처리 가능

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

 

하지만 ❗❗

 

우리 눈에는 쓰레드가 하나가 다 처리하는 것처럼 보이지만.. 여러개의 쓰레드가 매우 빠르게 전환되면서 요청을 처리해주는 것!

→ 그러므로 요청마다 쓰레드를 생성하면 컨텍스트 스위칭 비용이 발생.

→ 쓰레드 생성에 제한이 없기 때문에 고객 요청이 너무 많이 오면 cpu나 메모리의 한계로 서버가 죽을 수 있다! 

 

쓰레드 풀을 쓰자! 🏖 

 

 

쓰레드 풀 안에 미리 쓰레드를 여러개 만들어서 보관 (생성 가능한 쓰레드의 최대치를 관리)

→ 요청이 들어오면 쓰레드풀에서 꺼내서 가져다 쓰자!

→ 사용을 하고 나면 쓰레드를 죽이는 것이 아니라 반납

 

만약 쓰레드 풀 안의 쓰레드가 다 실행 중이라면..?

→ 쓰레드 대기 또는 거절 가능

 

실무 팁 ✨

 

WAS의 주요 튜닝 포인트는 최대 쓰레드 수

 

낮게 설정하면?

→ 동시 요청이 많을 때 클라이언트는 응답지연을 겪음 (but 서버 리소스는 적게 사용 중...)

 

높게 설정하면?

→ 동시 요청이 많을 때 서버 리소스 임계점 초과로 서버 다운

→ ex) 쓰레드를 만개로 설정할래! → 만개의 요청을 한 번에 받아들임 → 서버 다운

 

그럼 적정 숫자를 어떻게 찾나요?

→ 애플리케이션 로직의 복잡도, CPU, 메모리 등에 따라 모두 다름.. 최적의 해는 바로 알 수 없다!

→ 성능 테스트를 하는 게 답ㅎ

 

핵심

 

어차피 멀티 쓰레드는 WAS가 처리하므로 개발자가 멀티쓰레드 관련 코드는 신경쓰지 않아도 됨!

→ 하지만 어쨌든 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용하자

 

 

✔ HTML, HTTP API, CSR, SSR

 

백엔드 개발자가 서비스를 제공할 때 고민해야 할 포인트 3가지 ✨

 

1. 정적 리소스 어떻게 제공할 거야?

2. 동적으로 제공되는 Html 페이지 어떻게 제공할 거야?

3. HTTP API 어떻게 제공할 거야?

 

 

1 ) 정적 리소스

 

: 고정된 HTML 파일, CSS 등을 제공

웹브라우저에서 /hello.html을 요청하면 서버에서 폴더에 있는 이미 생성된 리소스를 단지 제공할 뿐

 

 

2 ) HTML

 

 

: WAS가 DB에서 주문 정보를 조회한 후에 (JSP, 타임리프를 이용해) 동적으로 HTML을 생성하여 웹브라우저에 내려줌

 

 

3 ) HTTP API

 

 

: HTML이 아니라 데이터를 전달 → DB에서 주문정보를 조회한 후에 JSON 형태의 정보를 웹브라우저에 내려줌

: 다양한 시스템에서 호출될 때 사용함 (앱, 웹, 서버 to 서버)

 

SSR - 서버 사이드 렌더링

: 서버에서 최종 HTML을 생성해서 클라이언트에 전달

→ 서버에서 렌더링하고 웹브라우저는 단순히 생성된 HTML을 보여주기만 함

 

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

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

→ 웹 환경을 앱 처럼 필요한 부분만 변경할 수 있음

 

 

그렇다면 어디까지 알아야하나요...? 🤔

 

1. 백엔드 개발자는 서버 사이드 렌더링 기술 학습이 필수! → 타임리프를 공부하자

2. 백엔드 개발자는 서버, DB, 인프라 등의 수많은 백엔드 기술을 공부하되 웹 프론트엔드 기술 학습은 옵션 (리액트가 점유율이 높다)