• [인프런 김영한 로드맵4]스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술(1)

    2022. 5. 12.

    by. 웰시코더

    반응형

    -인프런 김영한 강사님의 스프링 MVC 1편 강의를 정리한다.

    -웹 애플리케이션에 대한 이해와 웹서버, WAS, 서블릿, 멀티쓰레드 처리 등에 대해 Intro 학습을 한다.

    -추후 모든 소스는 깃허브에서 관리한다.(https://github.com/coderahn/Spring-Lecture4)


    신청만 해두고 미루고 미루다가 다시 시작했다. 로드맵3을 작성 안 했는데 HTTP 강의 수강한 거 얼른 정리할 예정이다.

     

    1.웹 애플리케이션의 이해

     

     

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

     

    웹에서 모든 형태의 데이터는 현재 HTTP 형식으로 전달된다. 서버끼리 데이터 주고받을 때도 HTTP로 통신한다. 웹 애플리케이션 통신은 웹서버와 웹 애플리케이션 서버를 통하여 통신한다.

     

    1)웹서버

    • HTTP기반 동작이며 정적리소스(HTML,CSS,JS,이미지,영상), 기타 부가기능을 제공한다.
    • nginx, apache

     

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

    • WAS라고 한다. HTTP기반 동작이며 웹서버 기능을 포함한다.
    • 프로그램 코드를 실행시켜 애플리케이션 로직 수행을 한다. 동적 HTML, HTTP API(JSON), 서블릿, JSP, 스프링 MVC 등은 모두 WAS에서 동작한다.
    • 톰캣, jetty

     

    3)웹 시스템 구성

    • 웹서버, WAS, DB로 구성되나 WAS가 웹서버도 포함하는 경우도 많음
    • WAS만 사용시 WAS에서 장애가 나면 오류화면조차 노출 불가능. WAS가 너무 많은 역할을 담당하여 부하가 걸릴 수 있다.
    • 정적리소스는 웹서버가 처리하고 동적로직은 WAS가 처리하는 식으로 분리하여 많이 사용한다. 
    • 나눠 사용할 경우 리소스 관리가 효율적이다. 정적 리소스가 많이 사용되면 WEB서버를 증설하고 동적리소스가 많이 사용되면 WAS를 증설하면 된다.

     

    2.서블릿

     

    서블릿이 무엇이며 왜 탄생했는지 알아보려고 한다.

     

    1)WAS가 없다면..

    • form전송의 기본 Content-type은 application/x-www-form-urlencoded
    • form전송시 WAS가 없다면..?(회원 저장 예시)
      • TCP/IP 연결 대기, 소켓 연결
      • HTTP 요청 파싱해서 읽기
      • POST, GET방식 등 인지하고  요청URL(/save) 인지
      • Content-Type 확인
      • HTTP 메세지 바디 내용 파싱(username, age 등 데이터 사용할 수 있게)
      • 저장프로세스 실행(save)
      • 비지니스 로직 실행 -> DB저장요청
      • HTTP RES 메세지 생성 시작 : HTTP 시작라인 생성, Header생성, 메시지 바디에 HTML 생성해서 입력
      • TCP/IP 응답전달, 소켓종료
    • 위에 저것을 다 구현하면 힘들다.
    • 이런 이유로 서블릿이 탄생하였다. 서블릿은 위의 저장프로세스 실행을 제외한 모든 것을 처리해준다.

     

    2)서블릿 특징

    • urlPatterns="/hello"면 브라우저에서 서버로 요청시 /hello가 붙은 코드가 실행
    • 순서 : /hello요청 -> HTTP요청기반 request, response 객체 생성 -> 서블릿컨테이너 helloServlet 실행 -> 종료때 response 담아서 hello world 반환

     

    3)서블릿 컨테이너

    • WAS 안에 존재
    • 서블릿 컨테이너가 서블릿 객체를 생성해주고 호출해줌
    • 서블릿 생명주기도 관리
    • 톰캣처럼 서블릿 지원하는 WAS
    • 서블릿 객체는 싱글톤으로 관리
      • 요청마다 생성하면 비효율적
      • 최초 로딩시점에 미리 만들어 재활용
      • 모든 고객요청은 동일한 서블릿 객체 인스턴스 접근
      • 공유변수 사용시 주의
      • 서블릿컨테이너 종료시 서블릿 객체들도 종료
      • request, response 객체는 항상 새로 생성
    • JSP도 서블릿으로 변환되어 사용됨
    • WAS는 동시요청을 위한 멀티쓰레드 처리를 지원

     

     

    3.동시요청 - 멀티쓰레드

     

    쓰레드란 자바코드 한줄한줄 해석할 수 있는 단위이다. 단일 쓰레드와 멀티 쓰레드를 비교해보자.

     

    1)단일쓰레드인 경우

    • request가 오면 WAS는 서블릿 수행을 위한 쓰레드 1개를 할당
    • 이때 다른 요청이오면?쓰레드가 1개라서 지연문제 발생

     

    2)멀티쓰레드인 경우

    • 추가 요청이 올 때 쓰레드를 또 생성해서 서블릿 수행
    • 장점 : 동시요청 처리가 가능하며 리소스 허용시까지 처리가 가능
    • 단점 : 쓰레드 생성비용이 비싸며 쓰레드 컨텍스트 스위칭 비용이 발생한다. 코어가 1개인 경우 쓰레드를 2개 왔다갔다 할 것이다. 또한 쓰레드 생성에 제한이 없으면 고객 요청이 1만개 올 때 서버가 죽을 것이다.

     

    3)쓰레드 풀

    • 쓰레드 생성에 대한 문제를 해결, 보완해준다.
    • 쓰레드 풀에 쓰레드를 미리 만들어놔서 요청이 오면 만들어 둔 쓰레드를 준다.
    • 200개를 셋팅하고 250개 요청이 들어오면 쓰레드풀 설정으로 대기, 거절 등 가능
    • 톰캣은 최대 200개가 기본 설정

     

    4)실무팁

    • WAS의 주요 튜닝포인트는 max thread 설정
    • 너무 낮게 설정하면 클라이언트 응답 지연, 너무 높게 설정하면 동시 요청이 많아질 때 CPU와 메모리 리소스 임계점 초과로 서버 다운
    • 장애발생시 클라우드면 일단 서버부터 늘리고 튜닝 / 클라우드가 아니면 열심히 튜닝
    • 쓰레드 풀 적정 숫자는 성능테스트를 해보는 것이 가장 좋다. 아파치나 jMeter, nGrinder 등이 있다.
    • WAS는 멀티 쓰레드를 지원한다!
      • 개발자가 멀티 쓰레드 관련 코드를 신경쓸 필요가 없다.
      • 싱글 쓰레드 프로그래밍 하듯이 소스코드를 개발해도 된다.
      • 멀티쓰레드 환경이기 때문에 싱글톤 객체(서블릿, 스프링 빈)를 주의해서 사용해야 한다. 멤버변수가 공유되기 때문..

     

    4)HTML, HTTP API, CSR, SSR

     

    각종 용어 등에 대해 정리한다.

     

    1)HTTP API

    • HTML이 아니라 데이터를 전달
    • 주로 JSON형식 데이터 통신을 하며 다양한 시스템에서 호출
    • UI 클라이언트의 접점이다. 앱클라이언트(아이폰, 안드로이드, PC APP)가 대표적이다.
    • UI 클라이언트 사용시 js 통한 http API 호출하는 식으로 많이 사용되며 React, Vue가 대표적이다.
    • 서버 to 서버 통신시에도 많이 사용한다.
      • 주문서버 -> 결제서버
      • 기업간 데이터 통신

     

    2)서버사이드 랜더링(SSR)

    • 서버에서 최종 HTML을 생성해서 클라이언트에 전달한다.

     

    3)클라이언트 사이드 랜더링(CSR)

    • HTML 결과를 자바스크립트를 사용해 웹브라우저에서 동적으로 생성해서 적용한다.
    • 동적인 화면에서 사용하며 웹 환경을 앱처럼 필요한 부분부분 변경 가능하다.
    • 구글지도나 Gmail이 대표적이며 React, Vue에서 사용한다.
    • SSR+CSR도 가능

     

    5)자바 백엔드 웹 기술 역사
     
    자바 백엔드 기술을 시간순으로 살펴본다.

     

    1)과거기술

    • 서블릿(1997) :서블릿으로는 HTML 동적 생성의 어려움이 있었음
    • JSP(1999) : HTML 생성은 편하지만 비지니스 로직까지 너무 많은 역할이 묵여있음
    • 서블릿, JSP 조합의 MVC 패턴 사용 : 모델, 뷰, 컨트롤러로 역할 나누어 개발
    • MVC 프레임워크 춘추전국시대(2000년초~2010년초) : MVC 패턴 자동화, 복잡한 웹기술을 편리하게 사용할 수 있는 다양한 기능 지원(스트럿츠, 웹워크, 스프링MVC 과거ver)

     

    2)현재사용기술

    •  애노테이션 기반 스프링 MVC 등장
      • @Controller 등으로 쉽게 처리되며 MVC 춘추전국시대의 마무리
    • 스프링부트 등장
      • 서버를 내장
      • 기존 : 서버에 WAS설치 후 소스는 War로 만들어 서버에 배포
      • 스프링부트방식 : 빌드결과(Jar)에 WAS서버 포함되어 있어서 빌드 단순화

     

    3)최신기술 - 스프링 웹 기술 분화

    • Web Servlet - Spring MVC
    • Web Reactive - Spring WebFlux

     

    4)스프링 웹플럭스(WebFlux)

    • 비동기 Non-Blocking 처리
    • 최소 쓰레드로 최대 성능 - 컨텍스트 스위칭 비용 효율적
    • 함수형 스타일로 개발 - 동시처리 코드 효율화
    • 서블릿 기술 사용 안 함
    • 어렵고 RDB지원이 부족하며 일반 MVC로 충분히 빠르다.

     

    5)자바 뷰템플릿 역사

    • HTML을 편리하게 생성하는 뷰 기능
    • JSP : 속노느림, 기능부족
    • 프리마커, 벨로시티 : 속도문제 해결, 다양한 기능
    • 타임리프(Thymeleaf) : 내추럴 템플릿(HTML모양 유지), 스프링 MVC와 강력한 기능 통합, 최선의 선택

     

     

    Intro 장이라서 요약식으로 간단하게 써봤는데도 길다. 다음은 본격적으로 서블릿부터 학습한다.

     

    반응형

    댓글