Skip to content

Latest commit

 

History

History
226 lines (163 loc) · 8.47 KB

1 자바 백엔드 웹 기술 역사.md

File metadata and controls

226 lines (163 loc) · 8.47 KB
Raw

1. 자바 백엔드 웹 기술 역사

1.1 웹 서버 & 웹 애플리케이션 서버

1. 웹 서버 (WEB)

  • HTTP 기반
  • 정적 리소스 제공
  • ex) APACHE, NGINX

2. 웹 애플리케이션 서버 (WAS)

  • HTTP 기반
  • 웹 서버 기능 + 애플리케이션 로직 수행
  • ex) Tomcat, Jetty, Undertow

3. 웹 시스템 구성

  1. WAS, DB
  • WAS가 정적 리소스, 애플리케이션 로직을 모두 제공할 수 있기 때문에 2가지만으로도 웹 시스템 구성할 수 있음
  • 단점
    1. WAS가 너무 많은 역할을 담당
    2. 애플리케이션 로직이 정적 리소스때문에 수행이 어려울 수 있음
    3. WAS 장애 시 오류 화면도 띄울 수 없음
  1. WEB, WAS, DB
  • 웹 서버를 사용해 정적 리소스를 따로 제공
  • 동적인 처리가 필요하면 WAS가 애플리케이션 로직 작동
  • 장점

    1. WAS가 중요한 애플리케이션 로직만 처리함

    2. 리소스를 효율적으로 관리할 수 있음

      • 정적 리소스가 많으면 웹 서버를 증설하고, 애플리케이션 리소스가 많이 사용되면 WAS를 증설함

    3. 웹 서버는 잘 죽지 않고 WAS는 잘 죽음

      → WAS 장애 시 웹 서버가 오류화면을 제공할 수 있음

1.2 서블릿

서버의 비지니스 로직을 제외한 나머지 작업을 대신 해줌

1. 서버에서 처리하는 업무

  • 비지니스 로직 외에 처리해야할 일이 매우 많음

    ex) 서버 TCP/IP 연결 대기, HTTP 요청 메시지 파싱, 응답 메시지 생성 등

  • 서블릿을 지원하는 WAS 사용 시 비지니스 로직을 제외한 나머지 작업을 서블릿이 대신 해줌

    • 개발자는 비지니스 로직만 짜면 됨

2. 서블릿

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {

	@Override
	protected void service(HttpServletRequest request, HttpServletResponse response){
	}
}
  • /hello URL이 호출되면 서블릿 코드가 실행됨
  • HTTP 요청과 응답을 편리하게 사용할 수 있게 해주는 HttpServletRequest과 HttpServletResponse
    • 개발자가 HTTP를 편리하게 사용할 수 있음
  • HTTP 요청 & 응답 과정

    1. HTTP 요청

    2. WAS가 request, response 객체를 만들어서 서블릿 객체를 호출

    3. 개발자가 request 객체에 HTTP 요청 정보를 편리하게 꺼내서 사용

    4. 개발자가 response 객체에 HTTP 응답 정보를 편리하게 입력

    5. WAS는 response 객체에 담겨있는 내용으로 HTTP 응답 메시지를 생성

      Untitled

3. 서블릿 컨테이너

  • 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함
  • 서블릿 객체의 생명주기를 관리함
  • 서블릿 객체는 싱글톤으로 관리됨
    • 최초 로딩 시 1개의 서블릿 객체를 만들어 놓음
    • 여러 고객이 요청 시 동일한 서블릿 객체에 접근
    • 공유 변수 사용에 주의해야 함
  • JSP도 서블릿으로 변환되어 사용됨
  • 동시 요청을 위해 멀티 쓰레드 지원

1.3 동시 요청 - 멀티 쓰레드

1. 쓰레드

  • main 메소드 실행

    → main이라는 이름의 쓰레드가 실행됨

  • 동시 처리가 필요한 경우 쓰레드를 추가로 생성해야 함

2. 단일 쓰레드

  • 고객의 요청으로 하나의 쓰레드가 사용되고 있을 경우
    • 쓰레드가 서블릿 객체를 사용해 응답을 받고 쓰레드를 반환 함
  • 먼저 들어온 요청의 처리가 끝나지 않은 상태에서 추가 요청이 들어오는 경우

    • 다른 고객은 먼저 들어온 고객의 요청이 끝나서 쓰레드가 반환될 때까지 대기해야 함

      → 처리 지연

    • 이 때 먼저 들어온 요청에 오류가 생기면?

      • 이 후에 들어오는 요청들도 처리되지 못하고 무한 대기하게 됨

3. 요청마다 쓰레드 생성

  • 장점

    • 동시 요청을 처리할 수 있음
    • 하나의 쓰레드가 지연되어도 나머지 쓰레드는 정상 작동함

  • 단점

    • 쓰레드 생성 비용이 들어감

    • 쓰레드 컨텍스트 스위칭 비용이 들어감

    • 쓰레드 생성 제한이 없음

      → 요청이 매우 많은 경우 서버가 죽을 수 있음

    ⇒ 이런 단점들을 해결하기 위해 쓰레드 풀 사용

4. 쓰레드 풀

  • 생성 가능한 쓰레드의 최대치만큼 미리 생성해 쓰레드 풀에 보관하고 관리함
  • 쓰레드가 필요한 경우 쓰레드 풀에서 꺼내서 사용하고 종료되면 쓰레드를 다시 반납함
  • 쓰레드 풀의 모든 쓰레드가 사용 중이라면 요청을 거절하거나 대기하도록 설정할 수 있음
  • 장점
    • 쓰레드를 미리 생성해서 보관
      • 쓰레드 생성, 종료 비용을 절약
      • 응답 시간이 빠름
    • 생성 가능한 쓰레드의 최대치가 존재
      • 여러 요청이 들어와도 안전하게 처리할 수 있음
  • WAS 주요 튜닝 포인트 = 최대 쓰레드 수 설정
    • 톰캣은 최대 200개
    • 성능 테스트를 통해 적절한 최대 쓰레드를 정해야 함
      • 너무 낮게 설정하면?
        • 동시 처리하는 요청의 수가 적다는 뜻
        • 서버 리소스는 여유롭지만 요청이 조금만 많아져도 금방 응답이 지연됨
      • 너무 높게 설정하면?
        • 동시 요청이 너무 많아 CPU, 메모리 리소스 임계점 초과 시 서버가 다운될 수 있음
          • 클라우드면 장애 발생 시 일단 서버를 늘리고 이후에 튜닝함
      • 실제 서비스 환경과 유사하게 세팅하여 성능 테스트를 해야 함
        • 툴 → 아파치 ab, 제이미터, nGrinder

5. WAS

  • 멀티 쓰레드 지원
  • 개발자는 복잡한 멀티 쓰레드 관련 코드를 신경 쓰지 않아도 됨
    • WAS가 처리해 줌
  • 개발자는 싱글 쓰레드 프로그래밍을 하듯이 편하게 개발하면 됨
    • 싱글톤 객체의 공유 변수는 주의해야 함

WAS = 서블릿 컨테이너 → 멀티쓰레드 지원

1.4 HTML, HTTP API, CSR, SSR

1. 정적 리소스

  • 고정 HTML 파일, CSS, JS, 이미지 등

2. HTML

  • WAS는 동적으로 필요한 HTML 파일을 생성해서 전달해 줄 수 있음

3. HTTP API

  • HTML이 아니라 데이터만 주고 받음 (주로 JSON)
  • UI 화면이 필요하면 클라이언트가 별도로 처리
  • 웹 뿐만 아니라 다양한 시스템에서 호출함
    1. 웹 ↔ 서버
    2. 서버 ↔ 서버
    3. 앱 ↔ 서버

4. SSR & CSR

  • SSR (Server Side Rendering)
    • HTML 최종 결과를 서버에서 만들어 웹 브라우저에 전달함
    • 주로 정적인 화면에 사용
      • JSP, 타임리프 → 백엔드
  • CSR (Client Side Rendering)
    • HTML 최종 결과를 JS를 사용해 웹 브라우저에서 동적으로 생성해 적용
    • 주로 동적인 화면에 사용
      • React, Vue.js → 프론트

1.5 자바 웹 기술 역사

1. 과거 기술

서블릿 → JSP → 서블릿 & JSP 조합 MVC → 다양한 MVC

2. 현재 사용 기술

  • 어노테이션 기반의 스프링 MVC
  • 스프링 부트
    • 빌드 결과(Jar)에 WAS 포함 → 빌드 배포 단순화

3. 최신 기술

  • Web Servlet → Spring MVC
  • Web Reactive → Spring WebFlux

    • 비동기 넌 블러킹 처리

    • 최소 쓰레드로 최대 성능

      • ex) 4코어 CPU → 4~5 쓰레드 → 쓰레드 컨텍스트 스위칭 비용 최소화

    • 함수형 스타일로 개발

    • 서블릿 기술 사용 x

    • 단점

      • 난이도 높음, RDB 지원 부족, 아직 많이 사용 x

      ⇒ 아직까진 Spring MVC도 충분히 빠르다.

4. 자바 뷰 템플릿 (템플릿 엔진) 역사

  1. JSP
    • 속도 느림
    • 기능 부족
  2. 프리마커, 벨로시티
    • 속도 빠름
  3. 타임리프(Thymleaf)
    • HTML 모양 유지하면서 뷰 템플릿 적용
    • 스프링 MVC와 강력한 기능 통합