로드밸런싱 수행 과정
Eureka와 FeignClient를 함께 사용하면 동적으로 서비스 인스턴스를 조회하여 로드 밸런싱을 수행한다.
→ (spring cloud 환경에서) FeignClient는 Eureka에 등록된 서비스 인스턴스 목록을 동적으로 조회하고,
로드 밸런싱 기능을 수행하는 리본과 자동으로 연동되어 리본이 로드 밸런싱을 수행한다.
1. @FeignClient(name="product")
→ Feign이 Eureka에 등록된 서비스 목록에서 이름이 product인 서비스를 찾아 해당 인스턴스 정보를 가져온다.
2. FeignClient는 Ribbon(로드 밸런싱 기능을 수행)과 연동되어 로드 밸런싱을 수행한다.
기본적으로 spring cloud 환경에서 Feign과 Ribbon은 자동으로 연동된다.
Eureka에서 여러 개의 서비스 인스턴스를 제공하면 Ribbon이 로드 밸런싱을 수행하여 적절한 인스턴스를 선택한다.
서킷브레이커 ex.Resilience4j
서킷브레이커는 마이크로서비스 간의 호출실패를 감지
└ 장애를 격리해서 시스템의 다른 부분에 영향을 주지 않도록 한다
└ 시스템의 전체적인 안정성을 유지하는 패턴
Resillence4j는 서킷브레이커 라이브러리다.
서킷브레이커 라이브러리인 Resilience4j 를 사용하기 위한 설정
Resilience4j를 사용하려면 Spring Boot 애플리케이션에 의존성을 추가해야 하는데
resilience4j 의존성이 아닌 'io.github.resilience4j:resilience4j-spring-boot3:2.2.0' 의존성을 build.gradle 에 작성한다.
***깃허브에 올려져 있는? resilience4j를 의존성으로 추가하는 이유는 spring starter 에서 제공하는 Resilience4j는 추상화 계층만 있고, 구현체가 존재하지 않아 개발자가 구현체 클래스를 작성해야 하기 때문이다. 추상 클래스? 추상 인터페이스? 인 Resilience4j를 구현하는 클래스를 만들어 추상 메서드를 오버라이딩 하고 해당 로직을 작성하려면 시간도 많이 걸리고 초보자들에겐 어려울 것이기 때문에 구현체가 존재하는, 깃허브에 올려져 있는 resilience4j 의존성을 사용하는 것이 정신건강에 도움이 될 것 같다고 이해함.
서킷브레이커와 fallback 실습
package com.spring_cloud.resilience4j.sample.products;
import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
@Service
@RequiredArgsConstructor
public class ProductService {
// @CircuitBreaker 애너테이션의 속성 name 값은
// Resilience4j의 서킷 브레이커 설정에서 사용할
// 특정 서킷 브레이커 인스턴스의 이름을 의미한다.
// 아래 메서드가 실행될 때 에러가 발생하면, 서킷 브레이커가 발동하는데,
// 해당 서킷 브레이커를 식별하는 값을 name 에 작성하면 됨.
// 그리고 name 을 기준으로 설정파일(*.yml) 에 해당 서킷 브레이커 관련 설정을 할 수 있다.
@CircuitBreaker(name="productService", fallbackMethod="fallbackGetProductDetails")
public Product getProductDetails(String productId) {
// id가 111로 들어왔을 때 에러를 발생시킬 것
if("111".equals(productId)) {
// 1. productId 가 111이 들어왔을 때
// 2. RuntimeException 이 발생
// 3. 서킷 브레이커가 발동되면서 상태가 변경될 것임
// 4. fallbackMethod 가 호출되면서 new Product(productId, "fallback Product") 가 반환됨
throw new RuntimeException("Empty response body");
}
return new Product(productId, "Sample Product");
}
public Product fallbackGetProductDetails(String productId, Throwable t) {
return new Product(productId, "fallback Product");
}
}
API 게이트웨이(Spring Cloud) ex. spring cloud gateway
api 게이트웨이를 사용하는 이유
MSA 의 환경에서 클라이언트가 서버로 서비스를 요청할 때 서비스가 마이크로 단위로 나누어져 있고,
위치가 상이하기 때문에 클라이언트는 요청 url을 각각 달리해야 한다. MSA 에서는 각 서비스가 독립적으로 운영됨.
마이크로서비스의 url을 직접 호출해야하는 클라이언트로부터 일관된 요청을 받기 위해 api gateway 를 사용하는 것.
api gateway 를 사용하면 클라이언트는 요청 서비스의 url들을 알 필요 없이 단일 엔드포인트만으로 서비스를 요청할 수 있고,gatway 의 내부적인 로직에 의해 클라이언트의 요청을 처리할 서비스로 요청처리가 위임되고?반환된 값을 다시 클라이언트에게 전달한다.api gateway 도 유레카 서버의 클라이언트다. 그래서 api gateway 의 설정파일에 유레카 서버의 url 주소를 작성해준다.
'[부트캠프] kdt 심화 과정' 카테고리의 다른 글
2025년 4월 7일 (0) | 2025.04.07 |
---|---|
MSA(Microservice Architecture)_컨피그 서버(Config Server) (0) | 2025.03.13 |
MSA(Microservices Architecture) 서비스 디스커버리, 로드 밸런싱 (0) | 2025.03.11 |
2025년 3월 10일(월) (1) | 2025.03.10 |
2025년 3월 7일(금) (0) | 2025.03.07 |