웹 애플리케이션 이해

Single Ko·2023년 5월 30일
0

Spring 강의 정리

목록 보기
8/31

들어가기 전에 ...

  • HTTP
  • 서버 개발의 발전이 20년이 넘음...
  • Spring MVC의 발전(필요한 기능의 거의 모든 것을 제공)

이런 것들을 이해해야되서 어렵다.

Web Server, WAS(Web Application Server)


웹 서버(Web Server)

  • HTTP 기반으로 동작
  • 정적 리소스 제공, 기타 부가기능
  • 정적(파일) HTML, CSS, JS , 이미지, 영상
  • 예) NGINX, APACH

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

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

차이점

  • 웹 서버는 정적 리소스, WAS는 애플리케이션 로직
  • 사실 둘의 용어도 경계도 모호
    • 웹 서버도 프로그램을 실행하는 기능을 포함
    • 웹 애플리케이션 서버도 웹 서버의 기능을 제공함
  • 자바는 서블릿 컨테이너 기능을 제공하면 WAS
    • 서블릿 없이 자바코드를 실행하는 서버 프레임워크도 있음
  • WAS는 애플리케이션 코드를 실행하는데 더 특화

웹 시스템 구성

  • WAS, DB로만 구성시

    1. WAS는 정적 리소스, 애플리케이션 로직 모두 제공.
    2. WAS가 너무 많은 역할을 담당. 서버 과부화 우려
    3. 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있음.
    4. WAS 장애시 오류 화면도 노출 불가능
  • WS, WAS, DB

    1. 정적 리소스는 웹 서버가 처리
    2. 웹 서버는 애플리케이션 로직같은 동적인 처리가 필요하면 WAS에 요청 위임
    3. WAS는 중요한 애플리케이션 로직 처리 담당.
    4. 효율적인 리소스 관리 가능 - (정적 리소스 많이 사용되면 Web서버증설, 애플리케이션 리소스 많이 사용되면 WAS 증설)
    5. 정적 리소스 제공하는 웹서버는 잘 죽지않음(WAS서버는 상대적으로 잘 죽음)
    6. WAS, DB 장애시 Web Server가 오류화면 제공 가능
  • API로 데이터만 제공할때는 WAS서버만 구축해도 충분함

서블릿


  • 개발자가 의미있는 비지니스 로직에 집중할수 있도록 서버 연결, HTTP 메시지 바디, Content Type, 응답, 요청 메시지 파싱등을 해주는 것.
 @WebServlet(name ="helloServlet", urlPatterns = "/hello")
 public class HelloServlet extends HttpServlet {
 	@Override
    protected void service(HttpServletRequest request, HttpServletResponse response) {
    	// 애플리케이션 로직
    }
 }
  • HTTP 요청, 응답 흐름.
    1. WAS는 Request,Response 객체를 만들어 서블릿 객체 호출
    2. Request 객체에서 HTTP 요청 정보를 편리하게 사용가능
    3. Response 객체에 HTTP 응답 정보를 편리하게 입력 가능
    4. WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성
  • 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함
  • 서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리
  • 서블릿 객체는 싱글톤으로 관리
  • 동시 요청을 위한 멀티 쓰레드 처리 지원

동시요청 - 멀티 쓰레드

쓰레드

  • 애플리케이션 코드를 하나하나 순차적으로 실행하는 것은 쓰레드
  • 쓰레드가 없다면 자바 애플리케이션 실행이 불가능
  • 쓰레드는 한번에 하나의 코드 라인만 수행
  • 동시 처리가 필요하면 쓰레드를 추가로 생성

쓰레드의 생성

  • 쓰레드 생성비용이 매우 비쌈.(요청이 올때마다 생성시 응답속도가 느려짐)
  • 쓰레드는 컨텍스트 스위칭 비용 발생
  • 쓰레드 생성에 제한이 없음(고객의 요청이 너무 많이 오면 CPU,메모리 임계점을 넘어 서버가 죽음)

쓰레드 풀

  • 필요할때 마다 쓰레드를 생성해놓는 것은 매우 비효율적

  • WAS는 보통 쓰레드 풀을 사용한다.

  • 미리 쓰레드를 일정 갯수를 생성해 놓는다. 쓰레드 풀에 생성가능한 쓰레드의 최대치를 관리
    (톰켓은 최대 200개 기본 설정, 변경가능)

  • 사용 방법

    1. 쓰레드가 필요하면, 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내서 사용
    2. 사용을 종료하면 쓰레드 풀에 해당 쓰레드를 반납.
    3. 쓰레드 풀의 쓰레드가 모두 사용 중이면? -> 기다리는 요청은 거절하거나 일정 수만큼 대기하게함
  • 장점

    1. 쓰레드 생성, 종료 비용이 절약되고 응답 시간이 빨라짐
    2. 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리 가능
    1. WAS의 주요 튜닝 포인트는 최대 쓰레드(Max thread)수( 너무 낮게 설정 ->서버 리소스는 여유롭지만 클라이언트는 금방 응답 지연, 높게 설정시 -> CPU, 메모리 리소스 임계점 초과)
    2. 요즘은 클라우드를 많이씀.
      클라우드면?서버부터 늘리고 튜닝,
      클라우드가 아니면? - 열심히 서버 튜닝..
    3. 성능 테스트를 시도.. (artillery, ngrider등이 있다)

핵심

  • 멀티 쓰레드에 대한 부분은 WAS가 처리
  • 개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 됨.(개발자는 그냥 싱글 쓰레드 프로그래밍을 하듯 소스 코드 개발 가능)
  • 싱글톤 객체의 공유문제는 주의해야 한다.

정적 리소스(HTML, CSS, JS, Img 등...)


  • 정적 HTML - 웹서버
  • 동적 HTML(JSP, 타임리프) - WAS
  • HTTP API - JSON형식(HTML이 아닌 데이터 전달), 다양한 시스템에서 호출(서버 to 서버, 웹,앱 클라이언트 to 서버)

백엔드 개발자는 보통 이 세가지 방식에 대해 고민해야 된다. HTTP를 통해 주고받는 방식이 주로 위 3가지.

SSR - 서버 사이드 렌더링

  • 서버에서 최종 HMTL을 생성해서 클라이언트에 전달
  • 주로 JSP, 타임리프 등이 있음
  • 주로 정적인 화면에 사용

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

  • HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용
  • 동적인 화면에서 주로 사용. 웹 환경을 마치 앱처럼 필요한 부분부분 변경 가능
  • 웹 프론트엔드 개발자(React,vue 등..)영역

자바의 뷰 템플릿

  • JSP : 속도 느림, 기능 부족
  • Freemarker, Velocity : 속도 문제 해결, 다양한 기능
  • 타임리프(Thymeleaf) : 네츄럴 템플릿(HTML 모양을 유지하며 뷰 템플릿 적용), 스프링 MVC와 강력한 기능 통합

참고 : 본 글은 김영한님의 스프링 강의를 정리한 것이다.

profile
공부 정리 블로그

0개의 댓글