> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/5-4.-spring-cloud-and-cloud-native.md).
# 5-4. Spring Cloud & Cloud Native
Spring Cloud & Cloud Native에 대하여
### Spring Cloud 개요
* Spring Boot 상에서 MSA를 쉽고 효율적으로 구현하기 위한 Cloud/분산 시스템 구축 라이브러리 집합이다.
* 프레임워크 체계: 그 자체로 독립적인 인프라 혹은 아키텍칭이라기보다는, MSA 아키텍처를 구현하고자 할 때 필요한 공통 인프라 기능(라이브러리)을 제공하는 framework이자 framework를 모아둔 체계이다.
* Spring Boot와의 관계: Spring Boot가 하나의 Process(Application), 하나의 서비스를 만드는 데 최적화되어 있다면, Spring Cloud는 이러한 여러 개의 Spring Boot가 모인 Application들의 MSA 구성을 위한 인프라/도구들을 제공하였다.
* Spring Boot: 독립적인, 개별 서비스 (예: 주문 서비스, 결제 서비스, 회원 서비스 등 각각은 독립적인 Spring Boot 애플리케이션으로 존재)
* Spring Cloud: 분산 환경을 위한 인프라/도구 모음
* MSA 인프라 해결 도구 Spring Boot 애플리케이션들이 여러 개 존재할 때 발생하는 다음과 같은 필수적인 분산 환경 문제들을 해결해 주는 도구 모음이었다.
* 서비스 간 통신
* 서비스 등록/발견
* 설정 중앙화
* 로드밸런싱
* 장애 대응
* 분산 트레이싱
* MSA 아키텍처 계층 구조 Spring Cloud는 시스템 아키텍처 상에서 비즈니스 로직과 실제 클라우드 인프라 환경 사이의 공통 인프라 계층에 해당하는 도구(framework) 역할을 담당하였다.
* \[비즈니스 로직]
* ↑
* Spring Boot
* ↑
* Spring Cloud (MSA 공통 인프라)
* ↑
* Container / Kubernetes / Cloud
* 마이크로서비스 구축 단계 분산 서비스를 Spring Boot로 만들고, Spring Cloud 의존성을 추가하여 MSA 환경 인프라를 구성하였다. Spring Cloud는 Boot 위에 얹는 라이브러리 세트였다.
* Step 1: 각 마이크로서비스를 Spring Boot로 만든다.
* Step 2: 필요한 Spring Cloud 모듈을 dependency로 추가한다.
* Gradle 의존성 설정 예시:
```gradle
implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
implementation 'org.springframework.cloud:spring-cloud-starter-config'
implementation 'org.springframework.cloud:spring-cloud-starter-openfeign'
```
### Spring Cloud 프레임워크 : Cloud Native 구조를 이해할 수 있는 도구
* 설정 중앙 관리 (Centralized Configuration Management) 개념: 서비스가 10개이면 Boot 프로젝트도 10개이며, 각 프로젝트의 application.yml 설정도 10개가 되었다. 설정 변경 시 application.yml을 전부 수정할 필요 없이, 중앙의 단일 서버에서 설정을 일괄 관리하였다. 실체 기술: Spring Cloud Config Server (Git 등의 원격 저장소와 연동하여 CurrencyCalculationService, CurrencyExchangeService, LimitsService 등의 설정을 중앙 관리)
* 위치 투명성 (Location Transparency) 개념: 분산 트랜잭션 구성 시 하나의 서비스가 다른 서비스의 IP 주소를 알아야 호출이 가능하였다. 분리된 컨테이너 환경에서는 IP 주소가 계속 바뀌기 때문에, 서비스 이름을 호출하면서 해당 주소를 동적으로 찾아야 했다. 환경적 특징: MSA 환경에서는 보통 Docker 컨테이너, Kubernetes Pod, Cloud VM Auto Scaling 위에서 서비스가 실행되었다. 배포된 격리된 컨테이너 환경은 고정 IP가 아니었으며, 장애 발생으로 인한 재시작, 오토 스케일링으로 인한 인스턴스 추가, 배포로 인한 컨테이너 교체 작업이 지속적으로 이루어져 IP 주소가 지속 변경되는 환경이었다. 따라서 과거 Monolithic 환경에서의 localhost:8080과 같이 고정 IP를 기재하는 것이 불가능하였다. 실체 기술: Naming Server (Eureka) = 서비스를 등록 관리해 주는 “레지스트리”
* 부하 분산 (Load Distribution / Load Balancing) 개념: MSA에서는 여러 다양한 서비스가 Eureka 혹은 K8S를 통해 레지스트리 되어있는 상태였다. 고가용성을 위해 서비스 요청을 분산시켜야 했으며, 로드밸런싱(요청분산) 및 Gateway(라우팅) 기능이 요구되었다. 진정한 의미: 로드 밸런서의 진정한 의미는 내부적으로 endpoint 주소를 매핑해 주어 Client가 단순한 요청만으로도 목적지 서비스를 찾을 수 있게 하는 것이었다. 실체 기술: Ribbon / Load Balancer (Client Side), Spring Cloud Gateway / Netflix API gateway (Inner Routing) 구조 예시: CurrencyCalculationService가 Ribbon을 통해 Naming Server에서 주소를 확인한 후, CurrencyExchangeService1, 2, 3으로 요청을 분산하여 전송하였다.
* 간편한 HTTP 클라이언트 (Easier REST Clients) 개념: 분산된 서비스 간의 통신 중 직접 호출을 채택해야 하는 경우, 기존의 복잡하고 번거로운 restTemplate 방식 대신 FeignClients 방식을 활용하여 API가 아닌 인터페이스 추상화 기반의 실체를 구축하였다.
* ASIS: restTemplate.getForObject("...", ...)
* TOBE: 인터페이스 기반의 추상화 선언
* ```
@FeignClient(name="exchange-service")
public interface ExchangeProxy {
@GetMapping("/rate")
...
}
```
* 가시성 및 모니터링 (Visibility and Monitoring) 개념: MSA 환경에서의 분산 트랜잭션은 오류 및 성능 문제 발생 시 문제 발생의 원인점을 찾기가 매우 어려웠다. 따라서 Request ID 기반으로 전체 호출 흐름을 추적하여 분산 트랜잭션의 구체적인 호출 모니터링이 가능해야 했다. 실체 기술: Zipkin Distributed Tracing / Netflix API Gateway
* 장애 허용 (Fault Tolerance) 개념: 하나의 서비스에 장애가 발생하면 이를 호출하는 다른 서비스에도 장애가 발생하는 연쇄 오류가 나타났다. 해결: Circuit Breaker Pattern을 제공하여 서비스 장애를 다른 서비스로 전파하지 않고 fallback을 수행하도록 만들었다. (예: 서비스 장애 발생 시 기본값 반환) 실체 기술: Hystrix / Resilience4j
### Gateway에 대하여 (WebMVC vs WebFlux)
* 동기와 비동기의 핵심 차이점 가장 큰 차이점은 결국 처리에 대한 제어권이 호출 측에 있느냐, 처리하는 측에 있느냐와 응답을 기다리느냐, 응답을 기다리지 않고 제어권을 Application 측에 위임하느냐에 대한 여부였다.
* webMVC (Dispatcher 기반의 동기 방식): Thread가 전달받은 요청을 처리할 때까지 해당 스레드의 점유를 계속 유지하였다.
* webFlux (Reactor 기반의 Event loop 비동기 방식): Thread가 전달받은 요청을 그대로 Event loop에 위임하였다. 즉, thread의 처리 제어권이 Application 측에 위임된 형태였다. Gateway에서 처리에 대한 I/O를 기다리지 않고, thread는 응답이 올 때까지 점유하지 않은 채 다른 작업을 수행할 수 있었다.
* Event Loop 메커니즘의 올바른 이해 잘못된 이해 (X): "Event loop에서 'loop'라고 해서 응답이 안 온 요청이 최후방 순위로 밀려나서 무작정 대기 지연된다." 올바른 이해 (O): 응답이 안 온 요청을 큐의 뒤로 미는 것이 아니라, 일단 보류(대기 상태로 등록)해 두었다가 추후 외부에서 응답이 도착하면 그것을 이벤트(Event)로 감지해서 요청한 측에서 해당 응답을 확보하고 마저 처리해 나가는 구조였다.
* Gateway 비동기 처리 흐름 예시 (WebFlux)
* Thread-1 수신
* ↓
* Order Service 요청 전송
* ↓
* "응답 오면 알려줘" (Event loop에 위임 후 보류)
* ↓
* Thread 반환 (스레드가 점유되지 않고 즉시 풀로 돌아감)
### Gateway 구성 전략
#### 다양한 도메인과 서비스의 집합체인 Topology에서 Gateway를 어떻게 취할 것인가
* Single Shared : 말 그대로 하나의 Gateway 서버를 운용하여, 단순하고 간편한 배치가 가능하지만 문제 발생 시 모든 유관부서에 영향을 유발할 수 있다(SPOF).
* BFF : Backend For Frontend, Mobile 및 PC 등 Client 및 이에 기반한 구체적 환경에 따른 요구사항을 분리하고, 이를 위한 전용 백엔드 도입부를 도입하는 구성 방법.
* Hierarchical : 동일한 도입 지점이라도, 지역/조직/보안/설정 등 그 책임과 역할을 분명히 구분하여 계층적으로 Gateway를 도입하는 방법.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://leehyokyun.gitbook.io/openbook/5-4.-spring-cloud-and-cloud-native.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.