웹 어플리케이션에 대해

Spring MVC는 백엔드 개발에 필요한 수많은 기능을 제공하고 있으나, 기능이 너무 많아서 학습이 어렵다.

이를 다 이해하고 활용하려면 웹 어플리케이션이 어떠한 과정으로 발전해왔는지 이해할 필요가 있다.

 

---

웹은 HTTP 기반으로 통신한다.

 

HTTP란 무엇일까?

• 거의 모든 형태의 데이터를 주고 받을 수 있는 프로토콜 (JSON, XML, 이미지, 파일, 영상, 텍스트, ...)
• 서버간 데이터를 주고 받을 때도 사용

 

웹 시스템의 구성

• WAS, DB: WAS가 너무 많은 역할을 함. WAS에 장애나면 오류 화면조차 못봄
• WAS, Web server, DB: 정적 리소스는 웹이, 중요한 로직 처리는 WAS가 전담. -> 효율적! WAS 장애 나도 오류 화면 출력이 가능해진다.
• Web server와 WAS는 개인적으로 공부한 적이 있어 링크로 생략한다. yeonyeon.tistory.com/40

Web Server와 WAS 차이부터 연동 방법까지

 

---

서블릿의 등장

 

html의 <form> 태그를 통해 데이터를 보낸다고 하자.

 

옛날에는...

• 웹 애플리케이션을 처음부터 끝까지 구현해야 했다.
• 헤더에 저장된 내용에 따라 로직을 차근차근 수행했으며, 의미있는 비즈니스 로직 외에 헤더를 해석하거나 응답메시지를 생성하는 등의 과정이 굉장히 길었다.

 

서블릿의 등장

• URL이 호출되면 서블릿 코드를 실행한다.
• HttpServletRequest, HttpServletResponse를 이용해 HTTP 요청/응답 정보를 편리하게 사용할 수 있다.

 

1. WAS: Req, Res 객체를 새로 만들고 서블릿 객체 호출
2. 개발자: Req 객체에서 HTTP 요청 정보 편리하게 꺼내고 사용
3. 개발자: Res 객체에서 HTTP 요청 정보 편리하게 입력
4. WAS: Res 객체에 담긴 내용으로 HTTP 응답 정보 생성

 

서블릿 컨테이너

• 서블릿을 지원하는 WAS
• 서블릿 객체 생성, 초기화, 호출, 종료하는 생명주기 관리
• 싱글톤으로 관리
• 동시 요청을 위한 멀티 스레드 처리 지원
• ex: Tomcat

 

---

스레드; Thread

 

스레드

• 애플리케이션 코드를 하나하나 순차적으로 실행하는 것
• Java main 메소드 첫 실행 시, main이라는 이름의 스레드가 실행
• 스레드 없으면 자바 어플리케이션 실행이 불가능
• 한번에 하나의 코드 라인만 수행
• 동시 처리가 필요하면 스레드 추가 생성

 

단일 스레드인 경우

• 요청이 여러개 들어오면 요청마다 스레드 따로 생성
• 스레드 생성 비용이 비쌈
• 들어올 때 마다 생성 시 응답 속도 slow
• 컨텍스트 스위칭 비용 발생
• 스레드 생성 제한이 없는 경우, 요청이 너무 많으면 CPU 나 메모리 임계점 넘어서 서버가 죽을 수 있다.

 

이를 보완해서 나타난 것이 스레드 풀

• 이미 생성되어 있는 스레드를 풀에서 꺼내서 사용
• 사용 종료 시 스레드 풀에 반납
• 최대 스레드 모두 사용 중이면 요청 대기/거절하도록 설정 가능
• 스레드 생성 및 종료 비용 절약하고 응답 속도 fast

 

스레드 풀에 관한 실무 tip

• 적정한 숫자가 정해져있지 않다. 상황에 따라 모두 다르니 실제 서비스와 유사한 환경에서 성능 테스트를 해야한다.
• 장애 발생 시 클라우드면 일단 서버부터 늘리고 튜닝하면 되지만, 클라우드가 아니면 평상시에 열심히 튜닝할 것.
• WAS의 튜닝 포인트는 최대 스레드 수!

• 너무 적은 경우: 스레드 수에 비해 요청이 과다하면 대기가 계속 늘어나 장애날 수 있음. 서버 리소스가 굉장히 여유로운 것에 비해 응답 지연 발생.
• 너무 많은 경우: CPU, 메모리 리소스 임계점 초과로 서버 다운 가능성

 

WAS의 멀티 스레드 지원

• 멀티 스레드에 대한 부분은 WAS가 처리
• 개발자가 멀티 스레드 관련 코드를 신경쓰지 않아도 코딩이 가능해짐
• 싱글톤 객체(서블릿, 스프링 빈)에 관해서는 주의해서 사용해야 한다.

 

 

---

백엔드 개발자들이 고민해야 할 3가지

 

1. 정적 리소스

• html 파일, css, js, 이미지, 영상, ... 
• 주로 웹 브라우저에서 사용

 

2. html 페이지

• 동적으로 필요한 html 파일

 

3. http API

• html이 아닌 데이터 전달
• 주로 JSON 형식 사용
• Web client to Server, App client to Server, Server to Server 등 다양한 시스템에서 연동

 

 

---

렌더링

 

SSR; 서버 사이드 렌더링

• server에서 최종 html을 생성해 client에 전달
• 주로 정적 화면에 사용
• JSP, Tymeleaf, ...

 

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

• html 결과를 javascript를 사용해 웹 브라우저에서 동적으로 생성해 적용
• 주로 동적 화면에 사용.
• 웹 환경을 앱처럼 필요한 부분만 변경할 수 있다.
• Google Map, Gmail, Google Calendar, ...

 

 

---

Java Web의 발전

 

1. 서블릿

• html 생성이 어려움

 

2. JSP

• html 생성이 쉬움
• 비즈니스 로직을 포함해 너무 많은 역할

 

3. MVC 패턴 사용

• 수많은 프레임워크 등장
• 어노테이션 기반의 스프링 MVC 등장
• 서버를 내장한 스프링 부트 등장

스프링 부트

• war 파일 만들어서 WAS에 배포
• 빌드 결과(jar)에 WAS 서버가 포함됨 -> 빌드 및 배포 단순화

 

4. Spring WebFlux [new]

• 완전 최신 기술이고 여러 장단점 때문에 실무에서 사용은 적은 편
• 비동기 넌블러킹 처리
• 최소 스레드로 최대 성능 -> 스레드 컨텍스트 스위칭 비용 효율화
• 함수형 스타일로 개발 -> 동시처리 코드 효율화
• 서블릿 기술 사용 X
• 러닝 커브 높음
• 아직은 관계형 DB에 대한 지원이 부족
• 일반 MVC의 스레드 모델도 충분히 빠름

 

---

Java View Template의 발전

 

JSP

• 느리다
• 기능 부족

 

Freemarker, Velocity

• 속도 문제 해결
• 다양한 기능 제공
• 발전을 잘 하지 않음

 

Thymeleaf

• html 모양을 유지하며 뷰 템플릿 적용 가능
• 스프링 MVC와 기능 통합
• 성능은 Freemarker와 Velocity가 더 빠른 편

 

---

본 게시글은 김영한 님의 '스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술' 강의를 구매 후 정리하기 위한 포스팅입니다.

내용을 임의로 추가, 수정, 삭제한 부분이 많으며 정확한 이해를 위해서 강의를 구매하시는 것을 추천 드립니다.

 

inf.run/B756

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의