Spring Boot 개발을 위한 필수 지식

1. 서버 간 통신 이해

사이트 하나를 서비스 단위로 개발한다고 한다면, 서버를 업데이트하거나 애플리케이션을 유지보수할 때마다 사이트 사용이 어려워진다.

그만큼 개발에 보수적이게 되고, 서비스 자체의 규모도 커지기 때문에 서비스를 구동하는 데 걸리는 시간도 길어진다.

이 같은 문제를 해결하기 위해 나온것이 마이크로서비스 아키텍처(MSA: Microservice Architecture)이다.

 

1.1 단일 서비스 아키텍처와 마이크로서비스 아키텍처

단일 서비스 아키텍처: 단일 서비스 애플리케이션에서는 모든 서비스(예: 블로그, 메일, 포럼)가 ​​하나의 대규모 애플리케이션으로 결합된다. 하나의 서비스를 업데이트하려면 전체 애플리케이션을 다시 배포해야 할 수 있으므로 확장에 문제가 발생한다.

MSA(마이크로서비스 아키텍처): 단일 서비스 아키텍처와 대조적으로 MSA는 애플리케이션을 HTTP/HTTPS를 통해 통신하는 더 작고 독립적인 서비스로 나눕니다. 각 서비스는 특정 기능을 처리하므로 확장 및 관리가 더 쉬워진다. 예를 들어, 블로그 플랫폼에는 블로그, 메일, 포럼에 대한 별도의 서비스가 있을 수 있다.

 

2. 스프링 부트 작동 방식

'spring-boot-starter-web' 모듈을 사용할 때 Spring Boot는 들어오는 웹 요청을 처리하기 위해 내장된 웹 서버(일반적으로 Tomcat)를 설정한다. 이러한 요청을 처리하는 핵심 메커니즘에는 Servlet이 포함된다.

 

2.1 Servlet Container의 특징

- 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리

- 서블릿 객체는 싱글톤 패턴으로 관리 (싱글톤과 유사한 동작이지만, 기술적으로 일부 구현에서는 엄격한 싱글톤이 아닌 '공유 인스턴스'이다.)

- 멀티 스레딩 지원

 

DispatcherServlet 

DispatcherServlet은 Spring MVC 아키텍처의 핵심으로, 모든 HTTP 요청을 처리하고 이를 적절한 컨트롤러에 매핑한다. 기본 프로세스 흐름은 다음과 같다.

클라이언트 요청: 클라이언트가 HTTP 요청을 보냄

DispatcherServlet: DispatcherServlet은 요청을 수신하고 핸들러 매핑을 통해 이를 올바른 컨트롤러에 매핑

컨트롤러 처리: 컨트롤러는 비즈니스 로직을 실행

View Resolver: 해당되는 경우 DispatcherServlet은 응답을 뷰(예: JSP 또는 Thymeleaf)로 전달합니다.

 

즉, Client -> DispathcerServlet -> Controller -> View Resolber -> view

 

2.2 Spring의 핸들러 매핑

 

핸들러 매핑은 요청 정보를 기준으로 어떤 컨트롤러를 사용할지 선정하는 인터페이스이다. 핸들러 매핑 인터페이스는 여러 구현체를 가지며, 대표적인 구현체 클래스는 다음과 같다.

BeanNameUrlHandlerMapping: URL을 Bean 이름에 매핑
ControllerClassNameHandlerMapping: URL과 일치하는 클래스 이름을 갖는 빈을 컨트롤로 사용
SimpleUrlHandlerMapping: 특정 URL 패턴을 컨트롤러에 매핑
DefaultAnnotationHandlerMapping: @RequestMapping과 같은 어노테이션을사용하여 URL과 컨트롤러를 매핑

 

 

3. Spring Boot에서 REST 작업

 

RESTful 애플리케이션에서 JSON은 클라이언트와 서버 간 데이터 교환에 가장 일반적으로 사용되는 형식이다. Spring Boot는 MessageConverter를 사용하여 자동으로 객체를 JSON 또는 XML로 변환한다. REST 컨트롤러가 @ResponseBody와 함께 사용되면 MessageConverter가 변환 프로세스를 처리한다.

 

3.1 HttpMessageConverter 구성

Spring Boot는 다음 클래스를 사용하여 HttpMessageConverter를 자동 구성한다.

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(HttpMessageConverter.class)
public class HttpMessageConvertersAutoConfiguration {
    // Configures message converters
}

 

이를 활용함으로써 Spring Boot는 요청과 응답이 Java 객체와 JSON(또는 다른 형식)간에 적절하게 변환하도록 보장한다.

 

 

4. 레이어드 아키텍처

 

레이어 아키텍처는 애플리케이션을 계층으로 구성하는 소프트웨어 디자인 패턴으로, 각 계층은 애플리케이션 기능의 고유한 측면을 담당한다. 일반적으로 이러한 레이어는 다음과 같다.

 

프레젠테이션 레이어: 사용자 인터페이스와 사용자 요청을 처리하며 종종 API 엔드포인트를 제공
비즈니스 계층: 애플리케이션의 핵심 비즈니스 로직을 포함
데이터 액세스 계층: 종종 Spring Data JPA 또는 기타 지속성 기술을 사용하여 데이터베이스 상호 작용을 담당

 

이러한 아키텍처를 사용하면 우려 사항과 책임을 분리하여 유지보수 및 확장성이 좋아진다.

 

예시

Spring에서 MVC(Model-View-Controller) 디자인 패턴은 레이어드 아키텍처를 반영한다. View 및 Controller는 프레젠테이션 계층을 나타내고, Service는 비즈니스 계층을 나타내며, Repository 또는 DAO는 데이터 액세스 계층을 나타낸다. 이러한 관심사 분리를 통해 각 레이어는 레이어 간의 깔끔한 상호 작용을 유지하면서 독립적으로 발전시킬 수 있다.

 

 

5. 디자인 패턴

 

디자인 패턴은 일반적인 소프트웨어 디자인 문제에 대한 해결책을 제시한다. 그러나 디자인 패턴이 모든 문제의 정답은 아니며, 상황에 맞는 최적 패턴을 결정해서 사용하는 것이 바람직하다.

 

5.1 디자인 패턴의 종류

 

디자인 패턴을 구체화해서 정리판 대표적인 분류 방식으로 'GoF 디자인 패턴'이 있다. 여기서 GoF는 'Gang of Four'의 줄임말로, 디자인 패턴을 구체화하고 체계화해서 분류한 4명의 인물을 의미한다.

 

GoF 디자인 패턴은 총 세가지로 구분된다.

1. 생성 패턴: 객체 생성에 사용되는 패턴(예: 싱글톤, 팩토리 메서드)으로, 객체를 수정해도 호출부가 영향을 받지 않는다.
2. 구조 패턴: 객체를 조합하여 더 큰 구조를 만드는 패턴 (예: 어댑터, 복합)
3. 행동 패턴: 객체간의 알고리즘 및 책임 분배에 관한 패턴 (예: 관찰자, 명령)

 

 

6. REST API

 

REST API 가장 많이 사용되는 애플리케이션 인터페이스이다. REST API를 통해 클라리언트는 서버에 접근하고 자원을 조작할 수 있다.

 

REST API는 REST 아키텍처를 따르는 시스템/애플리케이션 인터페이스라고 볼 수 있다. REST 아키텍처를 구현하는 웹 서비스를 'RESTful하다'라고 한다.

 

6.1 REST의 특징:

 

유니폼 인터페이스: HTTP 표준을 준수하므로 플랫폼에 종속되지 않고 타 언어, 플랫폼, 기술 등과 호환해 사용할 수 있다.

무상태성: 서버에 상태 정보를 따로 보관하거나 관리하지 않기 때문에 한 클라이언트가 여러 요청을 보내든 여러 클라이언트가 각각 하나의 요청을 보내든 개별적으로 처리한다. 이 때문에 비즈니스 로직의 자유도가 높고 설계가 단순해진다.

캐시 가능성: HTTP 표준을 준수하므로  HTTP 캐싱 기능을 적용할 수 있다. 이 기능을 이용하기 위해서는 응답과 요청이 모두 캐싱 가능한지 명시가 필요하고, 캐싱이 가능한 경우 클라리언트에서 캐시에 저장해두고 같은 요청에 대해서는 해당 데이터를 가져다 사용한다. 이 기능을 사용하여 서버의 트랜잭션 부하가 줄어 성능이 향상된다.
레이어 시스템: REST 서버는 네트워크 상의 여러 계층으로 구성될 수 있다. 그러나 서버의 복잡도와 고나계없이 클라이언트는 서버와 연결되는 포인트만 알면 된다.

클라이언트-서버 아키텍처: REST 서버는 API를 제공하는 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계한다. 이 구성은 서로에 대한 의존성을 낮춘다.

 

6.2 REST의 URI  설계 규칙

 

- URI의 마지막에는 슬래시(/)를 사용하지 않는다.
- URI에서 단어를 구분하려면 하이픈(-)을 사용한다.
- URI에는 동사보다는 명사(자원)를 사용한다. (예: /getProducts 대신 /products)
- 파일의 확장자는 URI에 포함하지 않는다.

 

 

7. Spring Boot의 REST 주요 개념

 

Spring Boot는 REST API를 구현하는 쉬운 방법을 제공한다. 개발자는 어노테이션을 사용하여 HTTP 요청을 핸들러 메서드에 매핑할 수 있다. MessageConverter 구성요소는 일반적으로 JSON을 사용하여 요청/응답 본문을 Java 객체로(또는 그 반대로) 변환하는 작업을 자동으로 처리합니다.

 

REST 컨트롤러 예시

@RestControllerpublic
public class ProductController {
    
    @GetMapping("/products")
    public List<Product> getAllProducts() {
        return productService.findAll();
    }
    
    @PostMapping("/products")
    public Product createProduct(@RequestBody Product product) {
        return productService.save(product);
    }
}

 

여기서 '@RequestBody' 어노테이션은 JSON을 'product' 객체에 매핑한다.

 

 

 

출처: 이 글의 출처는 책 '스프링 부트 핵심 가이드'를 참고하여 작성하였습니다.

https://www.yes24.com/Product/Goods/110142898