[요청응답 A-Z] 3. 서버 Boot

1.정보가 네트워크로 전달 
2. 네트워크에서 서버의 네트워크로 (Netowrk -> AWS) 
3. 서버 Bootstrapping (Tomcat Spring Container)
4. 서버 Runtime 환경 (handler)

---

1. Tomcat의 구동과 Servlet의 실행 

✅ 개념 정리 

• ✨ Tomcat : 제품명. Java J2EE 규격을 준수하는 application을 실행하기 위한 플랫폼을 제공 (=구현체)
• Java2EE : 웹 어플리케이션 개발을 위한 표준 기술 사양 (Servlet이라는 표준을 어떻게 따라야할 것인지 인터페이스(=호환규칙)로 정리해놓음)
• Servlet :웹 요청을 처리하고 동적인 웹 페이지를 생성하는 서버 측 컴포넌트 (=작은모듈)

Servlet 사용시 interface 호환규칙 : doService()

 

🎃 발전방향

• 요청마다 servlet 클래스를 매번 생성 -> 번거로움
• 요청을 하나로 모을 수는 없을까? 

 

2.  Servlet의 발전 - Dispatcher Servlet의 등장  

✅ 클라이언트의 모든 요청은 DispatcherServlet에서 관리한다. 

Servlet중 하나, 결국 Tomcat (Servlet Container) 에 의해 관리되는 것은 동일하다

 

 

3. EC2 움직임 시작

✅ JVM의 동작과정

ㄴ EC2에 설치된 OS가 JVM 프로세스를 띄우고, jar 또는 war 파일을 읽으며 class가 로더에 적재된다

Runtime은 실제 요청이 오면 실행되는 부분

 

✅ 중요 사항

• ClassLoader는 내부에서 클래스 파일을 로드하고 초기화 하는 역할
  • .class 바이트 코드로 컴파일링 된 클래스 파일은 클래스 로더의 meta space에 적재됨 
  • JVM 메모리의 Class 를 말하는 것 (Tomcat이 처음 구동될 때 업로드 됨) 
  • (참고) Heap - 필드와 인스턴스 변수(new Instance) / Stack - Thread 즉, 지역변수와 프로그램 카운트 
• TCP/IP 네트워크 통신을 수행하기 위해 소켓 설정을 함 (연결)
• 멀티 스레드 
  • 자바코드에서 cpu=thread 즉, 프로그램을 실행하는 가장 작은 단위 
  • 1개의 스레드만 작동할 땐, os에 그 다음 요청이 대기하고, socket 연결이 완료가 된 후에 backlog 요청을 꺼내 그 다음 스레드로 할당하던 방식
  • (framework) server thread / worker thread 를 분리하여 연결만 처리하고 그 다음 요청에 스레드 할당이 가능

 

4-1. Spring Boot 

ㄴ Application.run

ㄴ JVM 프로세스 (내장 톰캣)

순서와 관계성

1) 서버 동작 방식 

Spring Boot: 내가 바로 서버! 내장 서버를 품은 방식 🚗

 

스프링 부트는 이런 번거로움을 해결하기 위해 등장. 가장 큰 차이점은 톰캣 같은 WAS가 애플리케이션 안에 내장되어 있다는 것.

1. EC2에 Java 설치: EC2 인스턴스에는 오직 Java만 설치되어 있으면 충분. 별도의 톰캣을 설치하거나 설정할 필요가 없음.
2. JAR 파일 배포: 프로젝트를 .jar (Java Archive) 파일로 빌드해서 EC2 서버에 복사. 이 .jar 파일 안에는 내장 톰캣과 프로젝트 코드가 모두 들어있음.
3. 애플리케이션이 주도하는 시작:
   • EC2 터미널에서 java -jar my-app.jar 라는 간단한 명령어로 애플리케이션을 직접 실행.
   • 애플리케이션의 main 메소드가 실행되면서, 내장된 톰캣을 스스로 깨워 실행시킴.
   • 동시에 스프링 부트의 AutoConfiguration(자동 설정) 기능이 동작하여 클래스패스를 스캔하고 필요한 설정들을 알아서 처리. 예를 들어, spring-boot-starter-web 의존성이 있으면 "아, 이건 웹 애플리케이션이구나!" 하고 톰캣을 띄우고 디스패처 서블릿을 등록.
4. 요청 대기: 내장 톰캣이 뜨고 스프링 컨테이너 설정이 완료되면, 애플리케이션은 곧바로 외부 요청을 받을 수 있는 상태

이 방식은 애플리케이션이 직접 자신의 생명주기를 관리하며, 외부에 거의 의존하지 않고 독립적으로 실행.

Spring Boot Application (자체 실행)
  └─ Single ApplicationContext
      ├─ Embedded Tomcat (빈으로 관리)
      ├─ @Service 빈들
      ├─ @Repository 빈들
      ├─ @Controller 빈들
      ├─ @RestController 빈들
      ├─ DataSource (Auto-configured)
      ├─ TransactionManager (Auto-configured)
      └─ 모든 빈들이 하나의 컨텍스트에

 

 

---

4-2.  Spring Framework

ㄴ web.xml 파싱 

ㄴ JVM Tomcat 프로세스 (서버에 이미 Tomcat 설치됨) 

순서와 관계성

1) 서버 동작 방식 

전통적인 Spring Framework: 집주인(Web Server)에게 세 들어가는 방식 🏠

 

전통적인 스프링 프레임워크(이하 '레거시 스프링')는 혼자서 웹 요청을 직접 받을 수 없음

그래서 톰캣(Tomcat)이나 제티(Jetty) 같은 웹 애플리케이션 서버(WAS)의 도움이 반드시 필요.

1. EC2에 웹 서버(WAS) 설치 및 설정: 먼저 EC2 인스턴스에 톰캣 같은 WAS를 직접 설치하고, 포트 설정이나 성능 튜닝 같은 환경 설정을 마쳐야.
2. WAR 파일 배포: 개발한 스프링 프로젝트를 .war (Web Application Archive) 파일로 빌드해서 이 톰캣의 특정 디렉토리(webapps)에 복사해 넣음.
3. 웹 서버(WAS)가 주도하는 시작:
   • 톰캣을 실행하면, 톰캣이 webapps 디렉토리에 있는 .war 파일을 발견하고 압축을 품
   • 톰캣은 프로젝트 내의 web.xml 파일 또는 ServletContainerInitializer 설정을 읽어들여 스프링을 깨우기 시작
   • 스프링은 ApplicationContext라는 핵심 컨테이너를 생성하기 위해 XML 파일(application-context.xml, dispatcher-servlet.xml 등)이나 자바 설정(@Configuration)을 읽어와 필요한 객체(Bean)들을 만들고 서로 의존성을 주입
4. 요청 대기: 이 모든 과정이 끝나야 비로소 톰캣은 외부의 요청을 받아서 해당 스프링 애플리케이션으로 전달할 준비가 완료

이 방식의 핵심은 애플리케이션의 생명주기를 톰캣과 같은 외부 컨테이너가 관리.

집주인인 톰캣의 규칙에 맞춰야

Tomcat 서버 (독립 실행)
  └─ Web Application
      ├─ Root ApplicationContext (부모)
      │   ├─ @Service 빈들
      │   ├─ @Repository 빈들
      │   ├─ DataSource
      │   ├─ TransactionManager
      │   └─ 기타 인프라 빈들
      │
      └─ Web ApplicationContext (자식)
          ├─ @Controller 빈들
          ├─ DispatcherServlet
          ├─ ViewResolver
          ├─ HandlerMapping
          └─ 기타 웹 관련 빈들

 

 

 

 

 

 

4. 비고 

CSR과 같이 API - DATA 응답이 아닌, JSP로 데이터를 화면에 그려서 HTML을 응답 값으로 주는 프로세스에선

JSP를 응답으로 받을 때에도 Servlet이 실행됨 (즉, doService() 가 실행되는 방식으로 HTML 파일을 가져옴)