스프링 부트 핵심 가이드 2장 [개발에 앞서 알면 좋은 기초 지식]
2장 개발에 앞서 알면 좋은 기초 지식
2.1 서버 간 통신
- 서비스를 개발한다고 가정했을 때, 포털 사이트에 있는 블로그, 카페, 메일 등의 기능들을 하나의 애플리케이션으로 통합한 단일 서비스로 구성한다면, 서버 업데이트나 애플리케이션 유지보수 시마다 "사이트 작업 중"이라는 공지를 내고 작업을 해야 한다.
- 이러한 문제점을 해결하기 위한 방법으로 마이크로서비스 아키텍처(MSA; Microservice Architecture)가 제안되었다. 마이크로서비스 아키텍처는 서비스를 작은 단위로 나누어 구성하는 아키텍처를 의미하며, 이로 인해 유지보수 및 업데이트 작업이 훨씬 용이해 진다.
- 독립적 인 애플리케이션 개발 과정에서 각 서비스들이 상호 통신이 필요한 상황이 발생한다. 이를 위해 다양한 통신 프로토콜을 통해 여러 통신 방식이 적용 가능하며, 가장 널리 사용되는 방식은 HTTP/HTTPS 이다. (TCP/IP, HTTP/HTTPS, SOAP 등 다양한 통신 프로토콜 존재)
2.2 스프링 부트의 동작 방식
- 스프링 부트에서 spring-boot-starter-web 모듈을 사용하면 기본적으로 톰캣(Tomcat)을 사용하는 스프링 MVC 구조를 기반으로 동작한다.
- 서블릿(Servlet)은 클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술이다. 일반적으로 서블릿은 서블릿 컨테이너(Servlet Container)에서 관리한다. 서블릿 컨테이너는 서블릿 인스턴스(Servlet Instance)를 생성하고 관리하는 역할을 수행하는 주체로서 톰캣은 WAS의 역할과 서블릿 컨테이너의 역할을 수행하는 대표적인 컨테이너이다.
- 서블릿 컨테이너의 특징
- 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리한다.
- 서블릿 객체는 싱글톤 패턴으로 관리한다.
- 멀티 스레딩을 지원한다.
- 스프링에서는 DispatcherServlet이 서블릿의 역할을 수행한다. 일반적으로 스프링은 톰캣을 임베드(embed)하여 사용한다. 따라서 서블릿 컨테이너와 DispatcherServlet은 자동 설정된 web.xml의 설정값을 공유한다.
- 동작 과정
- DispatcherServlet으로 요청(HttpServletRequest)이 들어오면, 핸들러 매핑(Handler Mapping)을 통해 요청 URI에 매핑된 핸들러를 찾는다. 여기서 핸들러는 컨트롤러(Controller)를 의미한다.
- 그런 다음 핸들러 어댑터(HandlerAdapter)로 컨트롤러를 호출한다.
- 핸들러 어댑터로부터 컨트롤러의 응답이 돌아오면 ModelAndView로 응답을 가공하여 반환한다.
- 뷰 형식으로 리턴하는 컨트롤러를 사용할 때는 뷰 리졸버(View Resolver)를 통해 뷰(View)를 받아 반환한다. 핸들러 매핑은 요청 정보를 기준으로 어떤 컨트롤러를 사용할지 선정하는 인터페이스이다.
- 뷰를 사용하는 DispatcherServlet의 동작 방식
- @RestController를 사용하는 DispatcherServlet의 동작 방식
여기서 MessageConverter는 요청과 응답에 대해 Body 값을 변환하는 역할을 수행.
2.3 레이어드 아키텍처
- 레이어드 아키텍처(Layered Architecture)란 애플리케이션의 컴포넌트를 유사 관심사를 기준으로 레이어로 묶어 수평적으로 구성한 구조를 의미한다.
- 각 레이어는 가장 가까운 하위 레이어의 의존성을 주입받는다.
- 각 레이어는 관심사에 따라 묶여 있으며, 다른 레이어의 역할을 침범하지 않는다.
- 각 컴포넌트의 역할이 명확하므로 코드의 가독성과 기능 구현에 유리하다.
- 코드의 확장성도 좋아진다.
- 프레젠테이션 계층 : 애플리케이션의 최상단 계층, 클라이언트의 요청을 해석, 응답하는 역할.
- 비즈니스 계층 : 애플리케이션이 제공하는 기능을 정의하고 세부 작업을 수행, 도메인 객체를 통해 업무를 위임하는 역할.
- 데이터 접근 계층 : DB에 접근한느 일련의 작업 수행.
- 스프링의 레이어드 아키텍처 (Spring MVC는 Model-View-Controller의 구조)
- 프레젠테이션 계층 (유저 인터페이스(UI) 계층) : 클라이언트로부터 데이터와 함께 요청을 받고 처리 결과를 응답으로 전달하는 역할.
- 비즈니스 계층 (서비스(Service) 계층) : 핵심 비즈니스 로직을 구현하는 영역으로 트랜잭션 처리나 유효성 검사 등의 작업도 수행.
- 데이터 접근 계층 : 데이터베이스에 접근해야 하는 작업을 수행. 그림에서는 DAO라는 컴포넌트를 표현했지만 Spring Data JPA에서는 DAO 역할을 리포지토리가 수행하기 때문에 리포지토리로 대체할 수 있다.
2.4 디자인 패턴
- 디자인 패턴(Design Pattern)은 소프트웨어를 설계할 때 자주 발생하는 문제들을 해결하기 위해 고안된 해결책이다.
2.4.1 디자인 패턴의 종류
- 디자인 패턴을 구체화해서 정리한 대표적인 분류 방식으로 GoF(Gang of Four)의 디자인 패턴이라는 것이 있다.
- GoF 디자인 패턴은 세 가지로 구분된다.
- 생성 패턴 : 객체 생성에 사용되는 패턴으로, 객체를 수정해도 호출부가 영향을 받지 않게 한다.
- 구조 패턴 : 객체를 조합해서 더 큰 구조를 만드는 패턴.
- 행위 패턴 : 객체 간의 알고리즘이나 책임 분배에 관한 패턴, 객체 하나로는 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배.
2.5 REST(Representational State Transfer) API
- REST(Representational State Transfer) API는 대중적으로 가장 많이 사용되는 애플리케이션 인터페이스. 주고받는 자원(Resource)에 이름을 규정하고 URI에 명시해 HTTP 메서드(GET, POST, PUT, DELETE)를 통해 해당 자원의 상태를 주고받는 것을 의미한다.
2.5.2 REST API란?
- -API는 ‘Application Programming Interface’의 약자로, 애플리케이션에서 제공하는 인터페이스를 의미한다. API를 통해 서버 또는 프로그램 사이를 연결할 수 있다. 즉, REST API는 REST 아키텍처를 따르는 시스템/애플리케이션 인터페이스이다.
2.5.3 REST의 특징
1. 유니폼 인터페이스
- 일관된 인터페이스를 의미한다. 즉, REST 서버가 HTTP 표준 전송 규약을 준수함으로써 다양한 언어, 플랫폼, 기술과 호환성을 보장한다.
2. 무상태성 (stateless)
- 서버가 상태 정보(세션 또는 쿠키)를 별도로 저장하거나 관리하지 않는다는 것을 의미한다. 따라서 각 처리가 독립적이며, 서버가 불필요한 정보를 관리하지 않아 비즈니스 로직이 자유롭고 설계가 간결하다.
3. 캐시 가능성
- REST에서는 HTTP 표준을 그대로 활용함으로써 HTTP의 캐싱 기능을 적용할 수 있다. 이러한 캐싱 기능을 통해 서버의 트랜잭션 부하를 줄이고 효율성을 높이며, 사용자에게는 성능 향상의 이점이 있다.
4. 레이어 시스템
- REST 서버는 네트워크 상에서 다수의 계층으로 구성될 수 있다. 이 때 클라이언트는 서버와의 연결 지점만 알고 있으면 되며, 서버의 내부 복잡성에 대해서는 알 필요가 없다.
5. 클라이언트-서버 아키텍처
- REST 서버는 API를 제공하고, 클라이언트는 사용자 정보를 관리하는 구조로 설계된다. 이러한 구성을 통해 양측의 의존성이 낮아진다.
2.5.4 REST의 URI 설계 규칙
1. URI의 마지막에는 ‘/’를 포함하지 않는다.
2. 언더바(_)는 사용하지 않는다. 대신 하이픈(-)을 이용한다.
3. URL에는 행위(동사)가 아닌 결과(명사)를 포함한다.
옳은 예) http://localhost.com/product/123
잘못된 예) http://localhost.com/delete-product/123
4. URI는 소문자로 작성해야 한다.
5. 파일의 확장자는 URI에 포함하지 않는다.