웹 애플리케이션 이해

유병익·2022년 10월 17일
SpringspringMVC
0

Spring MVC - 백엔드 웹 개발 핵심 기술

목록 보기
1/7
post-thumbnail

1. Web

  • HTTP 기반
    • HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML (API) 등
    • 거의 모든 형태의 데이터 전송 가능
    • 서버 간에 데이터를 주고 받을 때도 대부분 HTTP사용
    • 지금은 HTTP 시대!

1.1 Web Server

  • HTTP 기반으로 동작
  • 정적 리소스 제공
    • ex) HTML, CSS, Javascript, 이미지, 영상 등
  • 기타 부가기능
  • ex) NGINX, APACHE 등

1.2 Web Application Server - WAS

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

1.3 Web Server vs Web Application Server

  • Web Server는 정적 리소스(파일)
  • Web Application Server는 애플리케이션 로직

📌 Web Server 와 Web Application Server의 용어 &경계는 모호함

  • Web Server도 프로그램을 실행하는 기능을 포함하기도 함
  • Web Application Server도 웹 서버의 기능을 제공

📌 Java는 서블릿 컨테이너 기능을 제공하면 Web Application Server

  • 서블릿 없이 자바코드를 실행하는 서버 프레임워크도 있음

📌 WAS는 애플리케이션 코드를 실행하는데 더 특화되어 있다.

1.4 Web System의 구성

1.4.1 WAS, DB

  • WAS, DB 만으로 시스템 구성 가능하긴 하다.
    • WAS는 정적 리소스, 애플리케이션 로직 모두 제공 가능하기 때문

  • 하지만, WAS가 너무 많은 역할을 담당하게 된다.
    • 서버 과부하 우려
  • 중요한 애플리케이션 로직이 정적 리소스 때문에 수행 못 할 수 있음
  • WAS 장애시 오류 화면도 노출 불가능

1.4.2 Web Server, WAS, DB

  • Web Server는 정적 리소스 처리
  • 동적인 처리(애플리케이션 로직)가 필요하면 WAS에 요청을 위임
    • WAS는 중요한 애플리케이션 로직 처리 전담
  • 효율적인 리소스 관리
    • 정적 리소스가 많이 사용 →Web Server 증설
    • 애플리케이션 리소스가 많이 사용 → WAS 증설

  • 정적 리소스만 제공하는 Web Server는 장애가 거의 발생하지 않음
  • 애플리케이션 로직이 동작하는 WAS 서버는 장애가 자주 발생함
  • WAS, DB 장애시 WEB 서버가 오류 화면 제공 가능

2. Servlet

2.1 Before Servlet

2.1.1 HTML Form 데이터 전송

  • 클라이언트가 서버로 HTTP 요청 메시지를 보낸다고 가정
  • 웹 브라우저가 생성한 요청 HTTP 메시지를 서버로 전송

2.1.2 서버에서 처리해야 하는 업무

  • Web Application Server를 직접 구현한다고 가정
  • 실제 의미있는 비지니스 로직은 초록색 부분
  • 하지만 비지니스 로직 이전, 이후에 처리해야할 업무가 너무 많다!
  • Web Application Server를 개발할 때 마다 이 과정을 반복 → 비효율적

2.2 Servlet

2.2.1 Servlet 이란?

Java를 사용하여 Web을 만들기 위해 필요한 기술

클라이언트의 요청을 처리하고, 그 결과를 반환하는
Servlet 클래스의 구현 규칙을 지킨 자바 웹 프로그래밍 기술

  • Example

📌 Servlet은 비지니스 로직 전 후에 많은 업무를 대신 처리해줌

2.2.2 Servlet의 특징

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

		@Override
		protected void servie(HttpServletRequest request, HttpServletResponse response){
				// Application Logic
		}
}
  • urlPatterns의 URL 호출 → Servlet Code실행
  • HTTP 요청 정보를 편리하게 사용할 수 있는 HttpServletRequest
  • HTTP 응답 정보를 편리하게 제공할 수 있는 HttpServletResponse
  • 개발자는 덕분에 HTTP 스펙을 매우 편리하게 사용 가능

2.2.3 Servlet의 전체적인 흐름

  • HTTP 요청, 응답 흐름
    1. HTTP 요청
    2. WAS는 Request, Response객체 생성 → Servlet객체 호출
    3. 개발자는 Request객체에서 HTTP 요청 정보를 꺼내서 사용
    4. 개발자는 Response객체에 HTTP 응답 정보를 입력
    5. WAS는 Response객체에 담겨있는 내용으로 HTTP 응답 정보 생성
    6. HTTP 응답

2.3 Servlet Container

  • Servlet을 지원하는 WAS == Servlet Container
    • ex) Tomcat
  • Servlet 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리
  • Servlet 객체는 싱글톤으로 관리
    • 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율
    • 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용
    • 모든 고객 요청은 동일한 Servlet 객체 인스턴스에 접근 ⚠️ 공유 변수 사용 주의
  • Servlet Container 종료 → Servlet 객체 도 함께 종료
  • JSP도 서블릿으로 변환 되어서 사용
  • 동시 요청을 위한 멀티 쓰레드 처리 지원

3. 동시 요청 - Multithreads

  • 클라이언트로부터 요청이 오면 WAS와 연결을 설정
  • 이후 Servlet 객체를 호출한다.
    • Servlet 객체를 누가 호출할까? → Thread !!

2.1 Thread

  • Application Code 순차적으로 실행
  • Java main method를 처음 실행 → main이라는 이름의 쓰레드 실행
  • Thread가 없으면?
    • Java Application 실행 불가능
  • Thread는 한번에 하나의 코드 라인만 수행
  • 동시 처리가 필요하면?
    • Thread 추가 생성

2.1.1 단일 요청 - 하나의 Thread 사용


2.1.2 다중 요청 - 하나의 Thread 사용

  • 요청1의 처리가 지연되면 요청2 역시 지연된다.

2.1.3 요청마다 Thread 생성

  • 장점
    • 동시 요청 처리 가능
    • Resource(CPU, 메모리)가 허용할 때 까지 처리 가능
    • 하나의 Thread가 지연 되더라도, 나머지 Thread는 정상 동작
  • 단점
    • Thread 생성 비용은 매우 비쌈
    • 고객의 요청 마다 Thread생성 → 응답 속도 늦어짐
    • Context Switching비용 발생
    • Thread 생성에 제한이 없음
      • 고객 요청이 너무 많으면, CPU, 메모리 임계점을 넘어서 Server Down

2.2 Thread Pool

  • 요청마다 Thread 생성할 때의 단점 보완

  • 특징

    • 필요한 Thread를 Thread Pool에 보관 & 관리
    • Thread Pool에 생성 가능한 Thread 최대치를 관리
      • Tomcat은 최대 200개 기본 설정 (변경 가능)

  • 사용

    • Thread가 필요하면, Thread Pool에서 꺼내서 사용
    • 사용을 종료 →Thread Pool에 해당 Thread 반납
    • 모든 Thread가 모두 사용 중이면?
      • 기다리는 요청 거절
      • 설정을 통해 특정 시간 만큼 대기

  • 장점

    • Thread가 미리 생성되어 있음
      • Thread를 생성하고 종료하는 비용(CPU) 절약
      • 응답 시간이 빠르다.
    • 생성 가능한 쓰레드의 최대치가 있음
      • 너무 많은 요청 → 기존 요청 안전하게 처리 가능

2.2.1 Thread Pool - Max Thread

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

  • Max Thread 값을 너무 낮게 설정

    • 동시 요청이 많을 때
      • Server Resource는 여유로움
      • But, 클라이언트는 쉽게 응답 지연

  • Max Thread 값을 너무 높게 설정

    • 동시 요청이 많을 때
      • CPU, 메모리 등 Resource 임계점 초과 → Server Down

  • Thread Pool의 Max Thread의 적절한 값

    • Application Logic의 복잡도, CPU, 메모리, I/O Resource 등 상황에 따라 모두 다름
    • 실제 서비스와 유사한 환경에서 성능 테스트를 통해 찾아야 함
      • Tool : Apache ab, Jmeter, nGrinder 등

2.3 정리

📌 Multithread 관련 부분은 WAS가 처리한다는 것이 핵심!!

개발자는 Multithread 관련 부분을 신경 쓰지 않아도 됨!! (Max Thread 값만 설정하면 됨)

⚠️ Multithread 이므로 싱글톤 객체(Servlet, Spring Bean 등) 사용할 때 주의!!

4. HTML, HTTP API, CSR, SSR

4.1 HTML

4.1.1 정적 리소스

  • 고정된 HTML 파일, CSS, JS, 이미지, 영상 등을 제공

4.1.2 HTML 페이지

  • 동적으로 필요한 HTML 파일을 생성해서 전달

4.2 HTTP API

  • HTML이 아니라 데이터를 전달
  • 주로JSON 형식 사용
  • UI 화면이 필요 → 클라이언트가 별도 처리
  • 다양한 시스템에서 호출
    • Mobile App, Web Client, Server to Server ..

4.3 SSR, CSR

4.3.1 SSR - Server Side Rendering

  • HTML 최종 결과를 Server에서 생성해 웹 브라우저에 전달
  • 주로 정적인 화면에 사용
  • 관련 기술
    • JSP, Thymeleaf ..

4.3.2 CSR - Client Side Rendering

  • HTML 결과를 Javascript를 사용해 웹 브라우저에서 동적 생성 및 적용

  • 주로 동적인 화면에 사용

  • 관련 기술

    • React, Vue.js ..

  • 참고

📌 React, Vue.js를 CSR + SSR 동시에 지원하는 Web Framework도 있음

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

4.3.3 Backend 개발자 입장에서 UI 기술

  • SSR - Server Side Rendering

    • JSP, Thymeleaf 등
    • 화면이 정적이고, 복잡하지 않을 때 사용
    • Backend 개발자는 SSR - Server Side Rendering 기술 학습 필수

  • 선택과 집중

📌 Backend 개발자의 Web Frontend 기술 학습은 선택

Backend 개발자는 수 많은 Backend 기술을 공부해야 함
Web Frontend도 깊이 있게 배우기엔 오랜 시간이 필요

profile
유병익
Backend 개발자가 되고 싶은
다음 포스트

Servlet

0개의 댓글