[내일배움캠프_MSA(Microservice Architecture)] MSA 특징과 Spring Cloud

 

MSA(Microservice Architecture)

MSA(Microservice Architecture)는 하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발, 배포, 유지보수를 용이하게 하는 소프트웨어 아키텍처 스타일

• 각 서비스는 특정 비즈니스 기능을 수행하며, 서로 독립적으로 배포되고 확장될 수 있음
• 서비스 간의 통신은 주로 HTTP/HTTPS, 메시지 큐 등을 통해 이루어짐

주요 특징

• 독립적인 배포 가능성: 각 서비스는 독립적으로 배포할 수 있으며, 다른 서비스에 영향을 주지 않고 업데이트 가능
• 작은 팀 구성: 각 서비스는 작은 팀이 독립적으로 개발하고 관리할 수 있음
• 기술 스택의 다양성: 각 서비스는 적절한 기술 스택을 자유롭게 선택 가능

모놀리틱 아키텍처와의 비교

모놀리틱 아키텍처

모놀리틱 아키텍처는 하나의 큰 코드베이스로 구성된 애플리케이션으로, 모든 기능이 하나의 애플리케이션 내에 포함되어 있음

모놀리틱 아키텍처

장점

• 간단한 배포: 모든 코드가 하나의 코드베이스에 포함되어 있어 배포가 단순
• 단일 데이터베이스: 하나의 데이터베이스를 사용해 데이터 일관성을 쉽게 유지 가능

단점

• 확장성 부족: 특정 기능을 확장하려면 전체 애플리케이션을 확장해야함
• 긴 개발 주기: 작은 변경 사항도 전체 애플리케이션을 다시 배포해야함
• 유연성 부족: 새로운 기술 도입이 어렵고, 특정 모듈에 종속적임

MSA

MSA는 여러 개의 독립적인 서비스로 구성된 애플리케이션으로, 각 서비스는 특정 비즈니스 기능을 수행함

MSA

장점

• 확장성: 특정 서비스만 확장하여 성능 최적화할 수 있음
• 독립적 배포: 개별 서비스의 변경 사항을 독립적으로 배포 가능
• 유연성: 서비스별로 적합한 기술 스택 선택 가능
• 작은 팀 구성: 서비스별 작은 팀으로 구성되어 민첩한 개발 가능

단점

• 복잡성 증가: 서비스 간 통신, 데이터 일관성 유지 등의 복잡성이 증가
  ex) 주문 서비스에서 상품이 존재하는지 확인을 위해 상품 서비스를 호출해야 하고, 누가 주문했는지 확인하기 위해 회원 서비스를 호출해야함
  - 즉, 하나의 서비스가 다른 서비스를 호출해야 하기 때문에 복잡함
  ex) 주문 서비스에서 사용하는 DB에 회원 정보를 가져와 저장하는 경우, 추후 회원 탈퇴와 같은 변경이 이루어졌을 때 데이터 일관성이 맞지 않게됨
• 운영 비용 증가: 각 서비스의 모니터링, 로깅 등을 개별적으로 관리해야 함
• 네트워크 지연: 서비스 간의 통신이 네트워크를 통해 이루어지므로 지연 시간이 발생할 수 있음

 

﹡장단점을 잘 파악해서 적합한 아키텍처 방식을 선택하는 것이 중요함

보통 신규 프로젝트는 빠른 랜딩이 필요하기 때문에 모놀리틱으로 개발하는게 좋고, 점점 서비스 사이즈가 커졌을 때 MSA 전환하는 방향으로 가도 좋음

---

Spring Cloud

Spring Cloud는 마이크로서비스 개발을 위해 다양한 도구와 서비스를 제공하는 스프링 프레임워크의 확장으로, 마이크로서비스 아키텍처를 쉽게 구현하고 운영할 수 있도록 도움

주요 기능

• 서비스 등록 및 디스커버리: Eureka, Consul, Zookeeper
• 로드 밸런싱: Ribbon, Spring Cloud LoadBalancer
• 서킷 브레이커: Hystrix, Resilience4j
• API 게이트웨이: Zuul, Spring Cloud Gateway
• 구성 관리: Spring Cloud Config
• 분산 추적: Spring Cloud Sleuth, Zipkin
• 메시징: Spring Cloud Stream

실제로 현업에서는 아마 Hystrix나 Zuul로 개발된 상태가 많음.

Spring은 계속해서 버전이 업데이트되기 때문에 현재 Spring 버전에 맞는 개발을 진행해야 하지만, 실제 현업에서는 버전을 올릴 때 고려 사항이 많이 때문에 어려움이 존재해서 버전업을 쉽게 할 수 없음

---

Spring Cloud 주요 모듈

서비스 등록 및 디스커버리

1) Eureka(유레카)

넷플릭스가 개발한 서비스 디스커버리 서버로, 마이크로서비스 아키텍처에서 각 서비스의 위치를 동적으로 관리

• 서비스 레지스트리: 모든 서비스 인스턴스의 위치를 저장하는 중앙 저장소
• 헬스 체크(Health check): 서비스 인스턴스의 상태를 주기적으로 확인해 가용성을 보장

로드 밸런싱

1) Ribbon

넷플릭스가 개발한 클라이언트 사이드 로드 밸런서로, 서비스 인스턴스 간의 부하를 분산

• 서버 리스트 제공자: Eureka로부터 서비스 인스턴스 리스트를 제공받아 로드 밸런싱에 사용
• 로드 밸런싱 알고리즘: 라운드 로빈, 가중치 기반 등 다양한 로드 밸런싱 알고리즘 지원
• Failover: 요청 실패 시 다른 인스턴스로 자동 전환

서킷 브레이커(Circuit Breaker)

1) Hystrix

넷플릭스가 개발한 서킷 브레이커 라이브러리로, 서비스 간의 호출 실패를 감지하고 시스템의 전체적인 안정성을 유지

• 서킷 브레이커 상태: 클로즈드, 오픈, 하드-오픈 상태를 통해 호출 실패를 관리
• Failback: 호출 실패 시 대체 로직을 제공해 시스템 안정성 확보
• 모니터링: Hystrix Dashboard를 통해 서킷 브레이커 상태 모니터링

2) Resilience4j

자바 기반의 경량 서킷 브레이커 라이브러리로, 넷프릭스 Hystrix의 대안으로 개발됨

• 서킷 브레이커: 호출 실패를 감지하고 서킷을 열어 추가적인 호출을 차단해 시스템의 부하를 줄임
• Fallback: 호출 실패 시 대체 로직을 실행해 시스템의 안정성 유지
• 타임아웃 설정: 호출의 응답 시간을 설정해 느린 서비스 호출에 대응
• 재시도: 재시도 기능을 지원해 일시적인 네트워크 문제 등에 대응

---

Spring Cloud 구성 요소의 활용

API 게이트웨이

1) Zuul

넷플릭스가 개발한 API 게이트웨이로, 모든 서비스 요청을 중앙에서 관리

• 라우팅: 요청 URL에 따라 적절한 서비스로 요청 전달
• 필터: 요청 전후에 다양한 작업을 수행할 수 있는 필터 체인 제공
• 모니터링: 요청 로그 및 매트릭을 통해 서비스 상태 모니터링 가능

2) Cloud gateway

스프링 클라우드에서 제공하는 API 게이트웨이로, 마이크로서비스 아키텍처에서 필수적인 역할

• 루팅 및 필터링: 요청을 받아 특정 서비스로 라우팅하고 필요한 인증 및 권한 부여 수행
• 보안: 외부 요청으로부터 애플리케이션을 보호하고, 보안 정책 적용
• 효율성: 마이크로서비스 아키텍처에서 필요한 요청 처리 및 분산 환경의 관리를 효율적으로 수행

구성 관리

1) Spring Cloud Config

분산된 환경에서 중앙 집중식 설정 관리를 제공

• Config 서버: 중앙에서 설정 파일을 관리하고 각 서비스에 제공
• Config 클라우드: Config 서버에서 설정을 받아서 사용하는 서비스
• 설정 갱신: 설정 변경 시 서비스 재시작 없이 실시간으로 반영

Spring Cloud의 적용 사례

Netflix는 Spring Cloud를 활용해서 마이크로서비스 아키텍처로 전환함

• 서비스 분리: 기존 모놀리식 애플리케이션을 여러 개의 독립적인 마이크로서비스로 분리
• 자동화 도구 도입: CI/CD 파이프라인을 구축해 코드의 빌드, 테스트, 배포 과정 자동화해 개발 속도 향상
• 자체 도구 개발: Hystrix, Eureka, Ribbon 등의 도구를 개발해 서비스 간 통신, 장애 복구, 로드 밸런싱 등을 효율적으로 처리
• 클라우드 인프라 활용: AWS와 같은 클라우드 인프라를 활용해 서비스 확장성 높임

---

MSA를 활용한 애플리케이션 설계

요구사항 및 로직

• 요구사항: 주문이 들어오면 주문 확인하고 처리
• 흐름: 주문 확인 → 상품 확인 → 유저 확인
• 즉, 총 3개의 애플리케이션 필요함! Order 애플리케이션, Product 애플리케이션, User 애플리케이션

요구사항 흐름

1. Ribbon을 통한 서비스 간의 통신

Ribbon을 통한 서비스 통신

각 애플리케이션이 하나만 존재하는 것이 아니라 여러 개가 존재하는 경우,

ex) Order 애플리케이션에서 Product 애플리케이션으로 요청 시 두 개의 Product 애플리케이션 서비스 중 어디로 호출해야 할지 Ribbon에서 해주고 실제 호출은 Feign Client를 통해서 이루어짐

 

2. Eureka 서버 구축

특정 애플리케이션을 호출할 때 위치를 알아야하기 때문에 Eureka 서버 구축 후, 각 애플리케이션 서버 등록

Eureka 서버 구축

ex) Order 애플리케이션에서 Product 애플리케이션을 호출할지 User를 호출할지 Host를 알아야함

즉 Order 서버에서 Product 서버 호출할 때, Eureka 서버에 들어가서 정보 확인하면 누굴 호출할지 알아낼 수 있음

• Eureka 서버에 등록된 모든 서비스 앱들은 Eureka 클라이언트가 됨

3. API 게이트웨이

어떤 사용자가 주문을 확인할 때는 Order 애플리케이션을 호출하고, 상품 등록할 때는 Product 애플리케이션 호출하는 등 Order, Product, User를 호출할 때마다 다른 호스트로 호출해야하는 번거로움 존재함

이를 해결하기 위해 앞단에 API 게이트웨이를 둬서 각 요청에 맞는 서버로 요청을 보냄

 

또한, 로그인된 회원만 사용가능하게 하기 위해서 API 게이트웨이가 로그인에 대해 체크하면, 불필요한 정보를 뒤로 전달하지 않고 Block 시켜 요청을 되돌릴 수 있음 → API 게이트웨이의 Filter에서 로그인 체크 수행

API 게이트 추가

4. Resilience4j 서킷 브레이커를 통한 Failover 처리

Order 서버가 User 서버를 호출한 후 Product 서버를 호출하는 흐름인 상황에서 User 서버 호출에 에러가 발생한 경우, 서킷 브레이커인 Resilience4j를 통해 Product 서버 호출까지 수행하지 않고 에러가 발생한 User 서버에서 Block 시키기

Resilience4j 서킷 브레이커를 통한 Failover 처리

 

5. yml 파일을 저장하는 Config 서버 추가

애플리케이션마다 각각의 yml 파일을 각각 넣어주면, 수정이 필요할 때 전부 수정해 줘야함. 이러한 것을 방지하기 위해 yml 파일을 저장하는 Config 서버 추가

• yml 파일이 수정되었을 때, 각 서비스에 알려주면 모든 서비스가 바로 업데이트됨

Config 서버 추가

 

6. 분산 추적 Zipkin으로 요청 호출 파악

주문 → 상품 → 회원 순으로 호출이 진행될 때, 각 앱들이 호출되는지 쉽게 알 수 없음! 분산 추적 Zipkin을 통해서 요청이 들어왔을 때 어떻게 호출되는지 파악

분산 추적 추가

---

서비스 디스커버리

서비스 디스커버리란?

서비스 디스커버리는 마이크로서비스 아키텍처에서 각 서비스의 위치를 동적으로 관리하고 찾아주는 기능

• 각 서비스는 등록 서버에 자신의 위치를 등록하고, 다른 서비스는 이를 조회해 통신함
• 주요 기능으로는 서비스 등록, 서비스 조회, 헬스 체크 등이 있음

Eureka란?

Eureka는 넷플릭스가 개발한 서비스 디스커버리 서버로, 마이크로서비스 아키텍처에서 각 서비스의 위치를 동적으로 관리

• 모든 서비스 인스턴스의 위치를 저장하는 중앙 저장소 역할을 하며, 서비스 인스턴스의 상태를 주기적으로 확인해 가용성을 보장함
• 여러 인스턴스를 지원하여 고가용성을 유지할 수 있음

1. Eureka 서버 설정

• Eureka 서버는 레지스트리를 구성하는 중앙 서버로, application.properties 혹은 application.yml 파일에서 진행

server:
  port: 8761

eureka:
  client:
    register-with-eureka: false  # 다른 Eureka 서버에 이 서버를 등록하지 않음
    fetch-registry: false  # 다른 Eureka 서버의 레지스트리를 가져오지 않음
  server:
    enable-self-preservation: false  # 자기 보호 모드 비활성화

 

2. Eureka 클라이언트 설정

• 각 서비스는 Eureka 서버에 자신을 등록해야 함
• spring-cloud-starter-netflix-eureka-client 의존성을 사용하고, 애플리케이션 이름만 설정파일에 있으면 자동으로 Eureka에 등록됨

spring:
  application:
    name: my-service # 반드시 properties나 yml 파일에 spring:application:name이 지정되어 있어야함!

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/  # Eureka 서버 URL
    register-with-eureka: true  # Eureka 서버에 등록
    fetch-registry: true  # Eureka 서버로부터 레지스트리 정보 가져오기
  instance:
    hostname: localhost  # 클라이언트 호스트 이름
    prefer-ip-address: true  # IP 주소 사용 선호
    lease-renewal-interval-in-seconds: 30  # 리스 갱신 간격
    lease-expiration-duration-in-seconds: 90  # 리스 만료 기간

---

서비스 등록 및 디스커버리

1. 서비스 등록

• 각 서비스 애플리케이션은 Eureka 서버에 자신의 위치 등록해야함
• spring-cloud-starter-netflix-eureka-client 의존성을 사용하고, 애플리케이션 이름만 설정파일에 있으면 Eureka에 등록됨

2. 서비스 디스커버리

클라이언트 애플리케이션은 Eureka 서버에서 필요한 서비스의 위치를 조회함

1. RestTemplate을 사용하는 경우
   • Spring Boot 애플리케이션에서 @LoadBalanced 애노테이션을 사용해 RestTemplate에 로드 밸런싱 기능 추가
2. FeignClient를 사용하는 경우
   • Spring Boot 애플리케이션에서 FeignClient를 사용해 간편하게 서비스 호출 수행함

@SpringBootApplication
@EnableFeignClients
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

@FeignClient(name = "my-service")
public interface MyServiceClient {

    @GetMapping("/api/data")
    String getData();
}

@RestController
public class MyFeignClientController {

    @Autowired
    private MyServiceClient myServiceClient;

    @GetMapping("/get-data-feign")
    public String getDataWithFeignClient() {
        return myServiceClient.getData();
    }
}

 

3. 헬스 체크 및 장애 처리

• 헬스 체크는 Eureka 서버가 주기적으로 서비스 인스턴스의 상태를 확인하여 가용성을 유지함
  • 기본 헬스 체크 앤드포인트 /actuator/health 사용
• 장애 처리는 서비스 장애 시 Eureka 서버는 해당 인스턴스를 레지스트리에서 제거해 다른 서비스의 접근 차단함

---

Eureka의 고가용성 구성

클러스터 구성

• Eureka 서버의 고가용성을 위해 여러 인스턴스를 구성할 수 있음
• 다중 인스턴스를 구성하여 고가용성을 유지하며, 각 인스턴스는 서로를 피어로 등록하여 상호 백업
• Eureka 서버는 다중 인스턴스로 구성할 때 각 서버의 피어 설정을 통해 서로를 인식하고 백업할 수 있음

실습

유레카 서버 하나에 같은 기능을 하는 인스턴스 2개 연결해보기

실습 내용

1. Spring Initializr를 통해 스프링 프로젝트 생성

프로젝트 생성

2. Eureka Server 설정

# application.properties 설정

spring.application.name=server

server.port=19090

# 유레카 서버에 본인 애플리케이션을 등록할지 결정
# 서버에서는 클라이언트로 인식되지 않게 false로 설정
eureka.client.register-with-eureka=false

# 유레카 서버로부터 레지스트리를 가져올지 결정하는 변수
eureka.client.fetch-registry=false

eureka.instance.hostname=localhost

# 유레카 클라이언트가 유레카 서버와 통신을 할 때 사용하는 URL 지정
eureka.client.service-url.defaultZone=http://localhost:19090/eureka/

package com.spring_cloud.eureka.server;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer // 추가해줘야지 유레카 서버로 동작함
public class ServerApplication {

	public static void main(String[] args) {
		SpringApplication.run(ServerApplication.class, args);
	}

}

 

3. Eureka Client 설정(두 곳 모두 추가)

spring.application.name=first

server.port=19091

eureka.client.service-url.defaultZone=http://localhost:19090/eureka/

spring.application.name=second

server.port=19092

eureka.client.service-url.defaultZone=http://localhost:19090/eureka/

Eureka Server(19090포트) 접속 화면

4. 두 Eureka Client 애플리케이션 실행 후 다시 접속

Eureka Server(19090포트) 접속 화면

---

로드밸런싱

로드 밸런싱은 네트워크 트래픽을 여러 서버로 분산시켜 서버의 부하를 줄이고, 시스템의 성능과 가용성을 높이는 기술
- 서버 간 트래픽을 고르게 분배하여 특정 서버에 부하가 집중되는 것을 방지
- 종류: 클라이언트 사이드 로드 밸런싱, 서버 사이드 로드 밸런싱

클라이언트 사이드 로드 밸런싱

클라이언트 사이드 로드 밸런싱은 클라이언트가 직접 여러 서버 중 하나를 선택해 요청을 보내는 방식으로, 클라이언트는 서버의 목록을 가지고 있으며 이를 바탕으로 로드 밸런싱을 수행함

FeignClient

FeignClient는 Spring Cloud에서 제공하는 HTTP 클라이언트로, 선언적으로 RESTful 웹 서비스를 호출할 수 있음

또한, Eureka와 같은 서비스 디스커버리와 연동하여 동적으로 서비스 인스턴스를 조회하고 로드 밸런싱을 수행함

• 선언적 HTTP 클라이언트: 인터페이스와 애노테이션을 사용해 REST API 호출할 수 있음
• Eureka 연동: Eureka와 통합해 서비스 인스턴스 목록을 동적으로 조회하고 로드 밸런싱 수행
• 자동 로드 밸런싱: Ribbon이 통합되어 있어 자동으로 로드 밸런싱 수행

Ribbon

Ribbon은 넷플릭스가 개발한 클라이언트 사이드 로드 밸런서로, 마이크로서비스 아키텍처에서 서비스 인스턴스 간의 부하를 분산함

다양한 로드 밸런싱 알고리즘을 지원하며, Eureka와 같은 서비스 디스커버리와 연동해 사용함

• 서버 리스트 제공자: Eureka 등으로부터 서비스 인스턴스 리스트를 제공받아 로드 밸런싱에 사용함
• 로드 밸런싱 알고리즘: 라운드 로빈, 가중치 기반 등 다양한 로드 밸런싱 알고리즘 지원
• Failover: 요청 실패 시 다른 인스턴스로 자동 전환

FeignClient와 Ribbon 설정

1. 기본 설정

• FeignClient와 Ribbon을 사용하려면 Spring Boot 애플리케이션에 의존성을 추가해야 함

dependencies {
    implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
    implementation 'org.springframework.cloud:spring-cloud-starter-openfeign'
}

@SpringBootApplication
@EnableFeignClients
public class MyServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyServiceApplication.class, args);
    }
}

 

2. FeignClient 인터페이스 작성

FeignClient 인터페이스를 작성해 서비스 호출 수행함(호출하고자 하는 서비스 작성)

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;

@FeignClient(name = "my-service")
public interface MyServiceClient {

    @GetMapping("/endpoint")
    String getResponse(@RequestParam(name = "param") String param);
}

---

로드 밸런싱 알고리즘

라운드 로빈

각 서버에 순차적으로 요청을 분배하는 방식으로, 간단하고 공평하게 트래픽을 분산함

 

가중치 기반 로드 밸런싱

각 서버에 가중치를 부여하고, 가중치에 비례하여 요청을 분배하는 방식으로, 서버의 성능이나 네트워크 상태에 따라 가중치를 조절함

 

기타 알고리즘

• 최소 연결: 현재 연결된 클라이언트 수가 가장 적은 서버로 요청을 보내는 방식
• 응답 시간 기반: 서버의 응답 시간을 기준으로 가장 빠른 서버로 요청을 보내는 방식

---

FeignClient와 Eureka 연동

1. Eureka 설정

• Eureka와 FeignClient를 함께 사용하면 동적으로 서비스 인스턴스를 조회하여 로드 밸런싱을 수행함

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka

 

2. FeignClient와 Ribbon 동작 원리

1) 서비스 이름: @FeignClient(name = "my-service") 어노테이션은 Eureka에 등록된 서비스 이름을 참조함

2) 서비스 인스턴스 조회: Eureka 서버에서 my-service라는 이름으로 등록된 서비스 인스턴스 목록 조회

3) 로드 밸런싱: 조회된 서비스 인스턴스 목록 중 하나를 선택해 요청을 보냄. 기본적으로 Ribbon을 사용해 로드 밸런싱 수행함

4) 요청 분배: 여러 서비스 인스턴스가 있을 경우, Round Robin 또는 다른 설정된 로드 밸런싱 알고리즘을 사용해 요청을 분배함

 

시나리오

Order 서비스는 Product 서비스를 호출해 상품 정보를 가져온다고 가정
- Order 서비스 인스턴스: 1개
- Product 서비스 인스턴스: 3개

 

1) Order 서비스 실행: Order 서비스가 실행되면 Eureka 서버에서 Product 서비스 인스턴스 목록 가져옴

2) Product 서비스 호출: Order 서비스에서 Product 서비스의 정보를 가져오기 위해 FeignClient를 사용해 호출함

3) Ribbon을 통한 로드 밸런싱: FeignClient는 Ribbon을 통해 3개의 Product 인스턴스 중 하나를 선택해 호출함(이 과정에서 RR 알고리즘 사용해 순차적으로 분배함)

4) 응답 처리: 선택된 Product 인스턴스에서 응답을 받아 Order 서비스에 반환하고, 최종적으로 클라이언트에 응답을 전달함

---

실습

유레카 서버 하나에 주문 인스턴스 1개와 같은 기능의 포트만 다른 상품 인스턴스 3개를 연결함
- 상품 요청(http://localhost:19090/order/1)하면 응답하는 인스턴스의 포트를 받아 노출함(RR 로드밸런싱으로 처리)

실습 내용

1. 프로젝트 생성

• Product 프로젝트와 Order 프로젝트 추가(유레카 서버는 위에서 만든거 그대로 사용)

프로젝트 생성

2. Product 서버 생성

package com.spring_cloud.eureka.client.product;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.openfeign.EnableFeignClients;

@SpringBootApplication
@EnableFeignClients // FeignClient 활성화
public class ProductApplication {

	public static void main(String[] args) {
		SpringApplication.run(ProductApplication.class, args);
	}

}

package com.spring_cloud.eureka.client.product;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class ProductController {

    // application.properties에 작성한 server.port 가져오기
    @Value("${server.port}")
    private String serverPort; // 애플리케이션 포트

    @GetMapping("/product/{id}")
    public String getProduct(@PathVariable("id") String id) {
        return "Product " + id + " info!!! From port :" + serverPort;
    }
}

// application.yml 설정 추가
spring:
  application:
    name: product-service

server:
  port: 19092

eureka:
  client:
    service-url:
      defaultZone: http://localhost:19090/eureka/

• Product 서버를 19092, 19093, 19094 총 3개의 포트에 실행해야함(인텔리제이 방법)

인텔리제이에서 포트 추가하기

유레카 서버 실행, Product 서버

3. Order 서버 생성

@SpringBootApplication
@EnableFeignClients // 추가
public class OrderApplication {

	public static void main(String[] args) {
		SpringApplication.run(OrderApplication.class, args);
	}

}

• Product 서버 호출 코드 작성 필요

package com.spring_cloud.eureka.client.order;

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

@FeignClient(name = "product-service") // Eureka 서버에서 'product-service' 식별자로 찾아서 호출
public interface ProductClient {
    @GetMapping("/product/{id}")
    String getProduct(@PathVariable("id") String id);
}

• OrderService에서 Product 호출한 후 String 조합 후 다시 Controller로 응답 반환

package com.spring_cloud.eureka.client.order;

import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class OrderService {

    // @RequiredArgsConstructor 애노테이션으로 주입받기
    private final ProductClient productClient;

    public String getProductInfo(String productId) {
        return productClient.getProduct(productId);
    }

    public String getOrder(String orderId) {
        if(orderId.equals("1")){
            String productId = "2";
            String productInfo = getProductInfo(productId);
            return "Your order is " + orderId + " and " + productInfo;
        }
        return "Not exist order...";
    }
}

package com.spring_cloud.eureka.client.order;

import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequiredArgsConstructor
public class OrderController {
    
    private final OrderService orderService;

    @GetMapping("/order/{orderId}")
    public String getOrder(@PathVariable("orderId") String orderId) {
        return orderService.getOrder(orderId);
    }
}

유레카 서버

주문 컨트롤러 호출(실패 예시)

주문 컨트롤러 호출(실패 예시)

• 어느 포트를 가진 서버에서 가져오는지 확인 가능함. 이때 라운드 로빈 방식으로 로드밸런싱 수행됨

---

서킷 브레이커

서킷 브레이커는 마이크로서비스 간의 호출 실패를 감지하고 시스템의 전체적인 안정성을 유지하는 패턴

• 외부 서비스 호출 실패 시 빠른 실패를 통해 장애를 격리하고, 시스템의 다른 부분에 영향을 주지 않도록 함
• 상태 변화: 클로즈드 → 오픈 → 하프오픈

Resilience4j

Resilience4j는 서킷 브레이커 라이브러리로, 서비스 간의 호출 실패를 감지하고 시스템을 안정성을 유지함

다양한 서킷 브레이커 기능을 제공하며, 장애 격리 및 빠른 실패를 통해 복원력을 높임

 

1. 서킷 브레이커 상태인 클로즈드, 오픈, 하프-오픈 상태를 통해 호출 실패를 관리

• 클로즈드(Closed): 기본 상태로, 모든 요청을 통과시킴
  • 이 상태에서 호출이 실패하면 실패 카운터가 증가함
  • 실패율이 설정된 임계값(ex: 50%)을 초과하면 서킷 브레이커가 오픈 상태로 전환됨
  • ex) 최근 5번의 호출 중 3번이 실패해 실패율이 60%에 도달하면 오픈 상태로 전환됨
• 오픈(Open): 서킷 브레이커가 오픈 상태로 전환되면 모든 요청을 즉시 실패로 처리
  • 이 상태에서 요청이 실패하지 않고 바로 에러 응답을 반환함
  • 설정된 대기 시간이 지난 후, 서킷 브레이커는 하프-오픈 상태로 전환됨
  • ex) 서킷 브레이커가 오픈 상태로 전환되고 20초 동안 모든 요청이 차단됨
• 하프-오픈(Half-Open): 오픈 상태에서 대기 시간이 지나면 서킷 브레이커는 하프-오픈 상태로 전환
  • 하프-오픈 상태에서는 제한된 수의 요청을 허용하여 시스템이 정상 상태로 복구되었는지 확인
  • 요청이 성공하면 서킷 브레이커는 클로즈드 상태로 전환
  • 요청이 다시 실패하면 서킷 브레이커는 다시 오픈 상태로 전환
  • ex) 하프-오픈 상태에서 3개의 요청을 하용하고, 모두 성공하면 클로즈드 상태로 전환됨. 만약 하나라도 실패하면 다시 오픈 상태로 전환됨

2. Fallback: 호출 실패 시 대체 로직을 제공해 시스템 안정성 확보

3. 모니터링: 서킷 브레이커 상태를 모니터링하고 관리할 수 있는 다양한 도구 제공

Resilience4j 설정

• Resilience4j를 사용하려면 Spring Boot 애플리케이션에 의존성을 추가해야 함

# resilience4j 의존성은 spring starter에서 추가하여 사용하지 않을 것입니다. 
# ”io.github.resilience4j:resilience4j-spring-boot3:2.2.0” 를 사용합니다. 
# ”boot3” 임을 주의 하세요.
dependencies {
    implementation 'io.github.resilience4j:resilience4j-spring-boot3:2.2.0'
	  implementation 'org.springframework.boot:spring-boot-starter-aop'
}

• application.yml 파일에 Resilience4j 설정 추가

resilience4j:
  circuitbreaker:
    configs:
      default:  # 기본 구성 이름
        registerHealthIndicator: true  # 애플리케이션의 헬스 체크에 서킷 브레이커 상태를 추가하여 모니터링 가능
        # 서킷 브레이커가 동작할 때 사용할 슬라이딩 윈도우의 타입을 설정
        # COUNT_BASED: 마지막 N번의 호출 결과를 기반으로 상태를 결정
        # TIME_BASED: 마지막 N초 동안의 호출 결과를 기반으로 상태를 결정
        slidingWindowType: COUNT_BASED  # 슬라이딩 윈도우의 타입을 호출 수 기반(COUNT_BASED)으로 설정
        # 슬라이딩 윈도우의 크기를 설정
        # COUNT_BASED일 경우: 최근 N번의 호출을 저장
        # TIME_BASED일 경우: 최근 N초 동안의 호출을 저장
        slidingWindowSize: 5  # 슬라이딩 윈도우의 크기를 5번의 호출로 설정
        minimumNumberOfCalls: 5  # 서킷 브레이커가 동작하기 위해 필요한 최소한의 호출 수를 5로 설정
        slowCallRateThreshold: 100  # 느린 호출의 비율이 이 임계값(100%)을 초과하면 서킷 브레이커가 동작
        slowCallDurationThreshold: 60000  # 느린 호출의 기준 시간(밀리초)으로, 60초 이상 걸리면 느린 호출로 간주
        failureRateThreshold: 50  # 실패율이 이 임계값(50%)을 초과하면 서킷 브레이커가 동작
        permittedNumberOfCallsInHalfOpenState: 3  # 서킷 브레이커가 Half-open 상태에서 허용하는 최대 호출 수를 3으로 설정
        # 서킷 브레이커가 Open 상태에서 Half-open 상태로 전환되기 전에 기다리는 시간
        waitDurationInOpenState: 20s  # Open 상태에서 Half-open 상태로 전환되기 전에 대기하는 시간을 20초로 설정

Fallback 메커니즘

Fallback 메서드는 외부 서비스 호출이 실패했을 때 대체 로직을 제공하는 메서드

@Service
public class MyService {

    @CircuitBreaker(name = "myService", fallbackMethod = "fallbackMethod")
    public String myMethod() {
        // 외부 서비스 호출
        return externalService.call();
    }

    public String fallbackMethod(Throwable t) {
        return "Fallback response";
    }
}

 

장점

• 시스템의 안정성을 높이고, 장애가 발생해도 사용자에게 일정한 응답 제공 가능
• 장애가 다른 서비스에 전파되는 것을 방지함

Resilience4j 대시보드

Resilience4j 대시보드를 사용해 서킷 브레이커의 상태를 모니터링할 수 있음

dependencies {
    implementation 'io.github.resilience4j:resilience4j-micrometer'
    implementation 'io.micrometer:micrometer-registry-prometheus'
    implementation 'org.springframework.boot:spring-boot-starter-actuator'
}

• application.yml 파일에 설정 추가

management:
  endpoints:
    web:
      exposure:
        include: prometheus
  prometheus:
    metrics:
      export:
        enabled: true

• 'http://${hostname}:${port}/actuator/prometheus'에 접속해 서킷브레이커 항목 확인 가능함
• Prometheus와 Grafana를 사용해 Resilience4j 서킷 브레이커의 상태를 실시간으로 모니터링할 수 있음
• Prometheus를 통해 수집된 메트릭을 Grafana 대시보드에서 시각화 가능

Resilience4j와 Spring Cloud 연동

• Resilience4j는 Spring Cloud Netflix 패키지의 일부로, Eureka와 Ribbon 등 다른 Spring Cloud 구성 요소와 쉽게 통합 가능
• Spring Cloud의 서비스 디스커버리와 로드 밸런싱을 활용해 더욱 안정적인 마이크로서비스 아키텍처 구축 가능

실습

﹡해당 실습에서는 Eureka 사용 X
프로젝트에서 상품을 조회하는 것을 가정하고,
- 상품 아이디 111을 호출하면 에러 발생시켜 fallbackMethod를 실행 확인
- 이벤트리스너를 사용해 서킷브레이커의 상태 조회 확인

 

1. 프로젝트 생성 및 의존성 추가

프로젝트 생성

plugins {
	id 'java'
	id 'org.springframework.boot' version '3.1.0'
	id 'io.spring.dependency-management' version '1.1.7'
}

group = 'com.spring-cloud.resilience4j'
version = '0.0.1-SNAPSHOT'

java {
	toolchain {
		languageVersion = JavaLanguageVersion.of(17)
	}
}

repositories {
	mavenCentral()
}

dependencies {
	implementation 'io.github.resilience4j:resilience4j-spring-boot3:2.2.0'
	implementation 'org.springframework.boot:spring-boot-starter-aop'

	implementation 'org.springframework.boot:spring-boot-starter-actuator'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	compileOnly 'org.projectlombok:lombok'
	runtimeOnly 'io.micrometer:micrometer-registry-prometheus'
	annotationProcessor 'org.projectlombok:lombok'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}


tasks.named('test'){
	useJUnitPlatform()
}

 

2. Product 관련 파일 생성(Product, ProductController, ProductService)

package com.spring_cloud.resilience4j.sample.products;

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@AllArgsConstructor
@NoArgsConstructor
public class Product {
    private String id;
    private String title;
}

package com.spring_cloud.resilience4j.sample.products;

import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequiredArgsConstructor
public class ProductController {

    private final ProductService productService;

    @GetMapping("/product/{id}")
    public Product getProduct(@PathVariable String id) {
        return productService.getProductDetails(id);
    }
}

package com.spring_cloud.resilience4j.sample.products;

import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class ProductService {


    public Product getProductDetails(String productId) {
        return new Product(productId, "Sample Product");
    }
}

 

3. 서킷 브레이커 추가

• ProductService 비즈니스 로직에 '상품 아이디 111을 호출' 시 에러 발생을 위한 서킷 브레이커 추가

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 = "productService", fallbackMethod = "fallbackGetProductDetails")
    public Product getProductDetails(String productId) {
        
        if("111".equals(productId)){
            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");
    }
}

 

4. application.yml 설정

spring:
  application:
    name: sample

server:
  port: 19090

resilience4j:
  circuitbreaker:
    configs:
      default:  # 기본 구성 이름
        registerHealthIndicator: true  # 애플리케이션의 헬스 체크에 서킷 브레이커 상태를 추가하여 모니터링 가능
        # 서킷 브레이커가 동작할 때 사용할 슬라이딩 윈도우의 타입을 설정
        # COUNT_BASED: 마지막 N번의 호출 결과를 기반으로 상태를 결정
        # TIME_BASED: 마지막 N초 동안의 호출 결과를 기반으로 상태를 결정
        slidingWindowType: COUNT_BASED  # 슬라이딩 윈도우의 타입을 호출 수 기반(COUNT_BASED)으로 설정
        # 슬라이딩 윈도우의 크기를 설정
        # COUNT_BASED일 경우: 최근 N번의 호출을 저장
        # TIME_BASED일 경우: 최근 N초 동안의 호출을 저장
        slidingWindowSize: 5  # 슬라이딩 윈도우의 크기를 5번의 호출로 설정
        minimumNumberOfCalls: 5  # 서킷 브레이커가 동작하기 위해 필요한 최소한의 호출 수를 5로 설정
        slowCallRateThreshold: 100  # 느린 호출의 비율이 이 임계값(100%)을 초과하면 서킷 브레이커가 동작
        slowCallDurationThreshold: 60000  # 느린 호출의 기준 시간(밀리초)으로, 60초 이상 걸리면 느린 호출로 간주
        failureRateThreshold: 50  # 실패율이 이 임계값(50%)을 초과하면 서킷 브레이커가 동작
        permittedNumberOfCallsInHalfOpenState: 3  # 서킷 브레이커가 Half-open 상태에서 허용하는 최대 호출 수를 3으로 설정
        # 서킷 브레이커가 Open 상태에서 Half-open 상태로 전환되기 전에 기다리는 시간
        waitDurationInOpenState: 20s  # Open 상태에서 Half-open 상태로 전환되기 전에 대기하는 시간을 20초로 설정

management:
  endpoints:
    web:
      exposure:
        include: prometheus
  prometheus:
    metrics:
      export:
        enabled: true

정상 요청 시

실패 요청 시(Fallback 메서드 호출)->일정 시간 지난 후 다시 클로즈드 상태됨

 

5. 이벤트 리스너 추가해 서킷 브레이커 상태 확인

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Service;

import io.github.resilience4j.circuitbreaker.CircuitBreakerRegistry;
import io.github.resilience4j.circuitbreaker.annotation.CircuitBreaker;
import jakarta.annotation.PostConstruct;
import lombok.RequiredArgsConstructor;

@Service
@RequiredArgsConstructor
public class ProductService {

    private final Logger log = LoggerFactory.getLogger(getClass());
    private final CircuitBreakerRegistry circuitBreakerRegistry;

    @PostConstruct
    public void registerEventListener() {
        circuitBreakerRegistry.circuitBreaker("productService").getEventPublisher()
            .onStateTransition(event -> log.info("#######CircuitBreaker State Transition: {}", event)) // 상태 전환 이벤트 리스너
            .onFailureRateExceeded(event -> log.info("#######CircuitBreaker Failure Rate Exceeded: {}", event)) // 실패율 초과 이벤트 리스너
            .onCallNotPermitted(event -> log.info("#######CircuitBreaker Call Not Permitted: {}", event)) // 호출 차단 이벤트 리스너
            .onError(event -> log.info("#######CircuitBreaker Error: {}", event)); // 오류 발생 이벤트 리스너
    }


    @CircuitBreaker(name = "productService", fallbackMethod = "fallbackGetProductDetails")
    public Product getProductDetails(String productId) {
        log.info("###Fetching product details for productId: {}", productId);
        if ("111".equals(productId)) {
            log.warn("###Received empty body for productId: {}", productId);
            throw new RuntimeException("Empty response body");
        }
        return new Product(
            productId,
            "Sample Product"
        );
    }

    public Product fallbackGetProductDetails(String productId, Throwable t) {
        log.error("####Fallback triggered for productId: {} due to: {}", productId, t.getMessage());
        return new Product(
            productId,
            "Fallback Product"
        );
    }

    
    // 이벤트 설명 표
    // +---------------------------+-------------------------------------------------+--------------------------------------------+
    // | 이벤트                      | 설명                                             | 로그 출력                                    |
    // +---------------------------+-------------------------------------------------+--------------------------------------------+
    // | 상태 전환 (Closed -> Open)   | 연속된 실패로 인해 서킷 브레이커가 오픈 상태로 전환되면 발생  | CircuitBreaker State Transition: ...       |
    // | 실패율 초과                  | 설정된 실패율 임계치를 초과하면 발생                     | CircuitBreaker Failure Rate Exceeded: ...  |
    // | 호출 차단                    | 서킷 브레이커가 오픈 상태일 때 호출이 차단되면 발생         | CircuitBreaker Call Not Permitted: ...     |
    // | 오류 발생                    | 서킷 브레이커 내부에서 호출이 실패하면 발생               | CircuitBreaker Error: ...                  |
    // +---------------------------+-------------------------------------------------+--------------------------------------------+


    // +------------------------------------------+-------------------------------------------+-----------------------------------------------------------------+
    // | 이벤트                                    | 설명                                        | 로그 출력                                                         |
    // +------------------------------------------+-------------------------------------------+-----------------------------------------------------------------+
    // | 메서드 호출                                | 제품 정보를 얻기 위해 메서드를 호출                | ###Fetching product details for productId: ...                  |
    // | (성공 시) 서킷 브레이커 내부에서 호출 성공        | 메서드 호출이 성공하여 정상적인 응답을 반환          |                                                                 |
    // | (실패 시) 서킷 브레이커 내부에서 호출 실패        | 메서드 호출이 실패하여 예외가 발생                 | #######CircuitBreaker Error: ...                                |
    // | (실패 시) 실패 횟수 증가                      | 서킷 브레이커가 실패 횟수를 증가시킴               |                                                                 |
    // | (실패율 초과 시) 실패율 초과                   | 설정된 실패율 임계치를 초과하면 발생               | #######CircuitBreaker Failure Rate Exceeded: ...                |
    // | (실패율 초과 시) 상태 전환 (Closed -> Open)   | 연속된 실패로 인해 서킷 브레이커가 오픈 상태로 전환됨   | #######CircuitBreaker State Transition: Closed -> Open at ...  |
    // | (오픈 상태 시) 호출 차단                      | 서킷 브레이커가 오픈 상태일 때 호출이 차단됨         | #######CircuitBreaker Call Not Permitted: ...                   |
    // | (오픈 상태 시) 폴백 메서드 호출                 | 메서드 호출이 차단될 경우 폴백 메서드 호출          | ####Fallback triggered for productId: ... due to: ...           |
    // +------------------------------------------+-------------------------------------------+-----------------------------------------------------------------+


   
}

서킷 브레이커 상태 확인

6. 프로메테우스로 서킷 브레이커 정보 확인 가능

• http://localhost:19090/actuator/prometheus

프로메테우스 데이터

---

API 게이트웨이(Spring Cloud Gateway)

API 게이트웨이는 클라이언트의 요청을 받아 백엔드 서비스로 라우팅하고, 다양한 부가 기능을 제공하는 중간 서버로,
클라이언트와 서비스 간의 단일 진입점 역할을 하며, 보안, 로깅, 모니터링, 요청 필터링 등을 처리함

• 라우팅: 클라이언트 요청을 적절한 서비스로 전달
• 인증 및 권한 부여: 요청의 인증 및 권한을 검증
• 로드 밸런싱: 여러 서비스 인스턴스 간의 부하 분산
• 모니터링 및 로깅: 요청 및 응답을 로깅하고 모니터링
• 요청 및 응답 변환: 요청과 응답을 변환하거나 필터링

Spring Cloud Gateway

Spring 프로젝트의 일환으로 개발된 API 게이트웨이로, 클라이언트 요청을 적절한 서비스로 라우팅하고 다양한 필터링 기능을 제공함

Spring Cloud Netflix 패키지의 일부로, 마이크로서비스 아키텍처에서 널리 사용됨

• 동적 라우팅: 요청의 URL 패턴에 따라 동적으로 라우팅
• 필터링: 요청 전후에 다양한 작업을 수행할 수 있는 필터 체인 제공
• 모니터링: 요청 로그 및 메트릭을 통해 서비스 상태 모니터링
• 보안: 요청의 인증 및 권한 검증

Spring Cloud Gateway 설정

• Spring Cloud Gateway 사용하려면 의존성 추가해야 함

dependencies {
      implementation 'org.springframework.boot:spring-boot-starter-web'
      implementation 'org.springframework.boot:spring-boot-starter-actuator'
      implementation 'org.springframework.cloud:spring-cloud-starter-gateway'
      implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
}

• application.yml 파일에 라우팅 설정 정의

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true  # 서비스 디스커버리를 통해 동적으로 라우트를 생성하도록 설정
      routes:
        - id: users-service  # 라우트 식별자
          uri: lb://users-service # 'users-service'라는 이름으로 로드 밸런싱된 서비스로 라우팅, lb는 로드밸런싱 뜻함
          predicates:
            - Path=/users/** # /users/** 경로로 들어오는 요청을 이 라우트로 처리
        - id: orders-service  # 라우트 식별자
          uri: lb://orders-service  # 'orders-service'라는 이름으로 로드 밸런싱된 서비스로 라우팅
          predicates:
            - Path=/orders/** #/orders/** 경로로 들어오는 요청을 이 라우트로 처리

# Gateway를 eureka client로 등록해서 eureka server를 통해 서비스 위치 확인
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/

 

Spring Cloud Gateway 필터링

필터 종류

• Global Filter: 모든 요청에 대해 작동하는 필터
• Gateway Filter: 특정 라우트에만 적용되는 필터

필터 구현

필터를 구현하려면 GlobalFilter 또는 GatewayFilter 인터페이스를 구현하고, filter 메서드를 오버라이드해야 함

 

필터 주요 객체

• Mono: 리액티브 프로그래밍에서 0 또는 1개의 데이터를 비동기적으로 처리
  - Mono<Void>는 아무 데이터도 반환하지 않음을 의미
• ServerWebExchange: HTTP 요청과 응답을 캡슐화한 객체
  - exchange.getRequest()로 HTTP 요청 가져옴
  - exchange.getResponse()로 HTTP 응답 가져옴
• GatewayFilterChain: 여러 필터를 체인처럼 연결
  - chain.filter(exchange)는 다음 필터로 요청 전달

필터 시점별 종류

• Pre 필터: 요청이 처리되기 전에 실행됨. Pre 필터에서는 요청을 가로채고 필요한 작업을 수행한 다음, 체인의 다음 필터로 요청을 전달함
  즉, '메인 요청인 라우팅에서 데이터 요청하고 가져오는 동작' 전에 수행
  이때, 추가적인 비동기 작업을 수행할 필요가 없기 때문에 then 메서드를 사용할 필요가 없음

@Component
public class PreFilter implements GlobalFilter, Ordered {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 요청 로깅
        System.out.println("Request: " + exchange.getRequest().getPath());
        return chain.filter(exchange);
    }

    @Override
    public int getOrder() {  // 필터의 순서를 지정합니다.
        return -1;  // 필터 순서를 가장 높은 우선 순위로 설정합니다.
    }
}

• Post 필터: 요청이 처리된 후, 응답이 반환되기 전에 실행됨. Post 필터에서는 체인의 다음 필터가 완료된 후에 실행되어야 하는 추가적인 작업을 수행해야 함. 따라서 chain.filter(exchange)를 호출해 다음 필터를 실행한 후, then 메서드를 사용해 응답이 완료된 후에 실행할 작업을 정의함

@Component
public class PostFilter implements GlobalFilter, Ordered {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        return chain.filter(exchange).then(Mono.fromRunnable(() -> {
            // 응답 로깅
            System.out.println("Response Status: " + exchange.getResponse().getStatusCode());
        }));
    }

    @Override
    public int getOrder() {
        return -1;
    }
}

Spring Cloud와의 통합

• Spring Cloud Gateway는 Spring Cloud Netflix 패키지의 일부로, Eureka와 쉽게 통합 가능
• Eureka를 통해 동적으로 서비스 인스턴스를 조회해 로드 밸런싱과 라우팅을 수행할 수 있음

실습

클라우드 게이트웨이 + 유레카 + Order 인스턴스(1개) + Product 인스턴스(2개)로 진행

실습 내용

1. 각 애플리케이션 포트 번호 수정

Eureka 서버와 Order 서비스 1개, Product 서비스 2개

 

2. Gateway 프로젝트 생성 및 application.yml 수정

프로젝트 생성

server:
  port: 19091  # 게이트웨이 서비스가 실행될 포트 번호

spring:
  main:
    web-application-type: reactive  # Spring 애플리케이션이 리액티브 웹 애플리케이션으로 설정됨
  application:
    name: gateway-service  # 애플리케이션 이름을 'gateway-service'로 설정
  cloud:
    gateway:
      routes:  # Spring Cloud Gateway의 라우팅 설정
        - id: order-service  # 라우트 식별자
          uri: lb://order-service  # 'order-service'라는 이름으로 로드 밸런싱된 서비스로 라우팅
          predicates:
            - Path=/order/**  # /order/** 경로로 들어오는 요청을 이 라우트로 처리
        - id: product-service  # 라우트 식별자
          uri: lb://product-service  # 'product-service'라는 이름으로 로드 밸런싱된 서비스로 라우팅
          predicates:
            - Path=/product/**  # /product/** 경로로 들어오는 요청을 이 라우트로 처리
      discovery:
        locator:
          enabled: true  # 서비스 디스커버리를 통해 동적으로 라우트를 생성하도록 설정

eureka:
  client:
    service-url:
      defaultZone: http://localhost:19090/eureka/  # Eureka 서버의 URL을 지정

 

3. Filter 생성

package com.spring_cloud.eureka.client.gateway;

import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.Ordered;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

import java.util.logging.Logger;

@Component
public class CustomPreFilter implements GlobalFilter, Ordered {

    private static final Logger logger = Logger.getLogger(CustomPreFilter.class.getName());

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        ServerHttpRequest request = exchange.getRequest();
        logger.info("Pre Filter: Request URI: "+request.getURI());
        return chain.filter(exchange); // 다음 필터로 전달
    }

    @Override
    public int getOrder() {
        return Ordered.HIGHEST_PRECEDENCE; // 최상위 우선순위
    }
}

package com.spring_cloud.eureka.client.gateway;

import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.Ordered;
import org.springframework.http.server.reactive.ServerHttpResponse;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

import java.util.logging.Logger;

public class CustomPostFilter implements GlobalFilter, Ordered {
    private static final Logger logger = Logger.getLogger(CustomPreFilter.class.getName());

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        return chain.filter(exchange).then(Mono.fromRunnable(() -> {
            ServerHttpResponse response = exchange.getResponse();
            logger.info("Post Filter : Response status code is " + response.getStatusCode());
        }));
    }

    @Override
    public int getOrder() {
        return 0;
    }
}

게이트웨이 추가

게이트웨이를 통해 각 서비스로 접근

게이트웨이 필터

---

보안 구성(OAuth2 + JWT)

• 마이크로서비스 아키텍처에서는 각 서비스가 독립적으로 배포되고 통신하기 때문에 보안이 매우 중요함
• 데이터 보호, 인증 및 권한 부여, 통신 암호화 등을 통해 시스템의 보안성을 확보해야 함

OAuth2

OAuth2는 토큰 기반의 인증 및 권한 부여 프로토콜로, 클라이언트 애플리케이션이 리소스 소유자의 권한을 얻어 보호된 리소스에 접근할 수 있도록함
- OAuth2 네 가지 역할 정의: 리소스 소유자, 클라이언트, 리소스 서버, 인증 서버

• Authorization Code Grant: 인증 코드를 사용해 액세스 토큰을 얻는 방식
• Implicit Grant: 클라이언트 애플리케이션에서 직접 액세스 토큰을 얻는 방식
• Resource Owner Passwrod Credentials Grant: 사용자 이름과 비밀번호를 사용해 액세스 토큰을 얻는 방식
• Client Credentials Grant: 클라이언트 애플리케이션이 자신의 자격 증명을 사용해 액세스 토큰을 얻는 방식

JWT(JSON Web Token)

JWT는 JSON 형식의 자가 포함된 토큰으로, 클레임(claim)을 포함해 사용자에 대한 정보 전달함
- JWT = 헤더 + 페이로드 + 서명
- JWT는 암호화를 통해 데이터의 무결성과 출처 보장

• 자가 포함: 토큰 자체에 모든 정보를 포함하고 있어 별도의 상태 저장이 필요 없음
• 간결성: 짧고 간결한 문자열로, URL, 헤더 등에 쉽게 포함될 수 있음
• 서명 및 암호화: 데이터의 무결성과 인증을 보장함
  • JWT는 데이터가 중간에 변경되었는지 안되었는지를 메인으로 확인!
  • 토큰의 내부에 있는 데이터보다는 토큰 변조 여부가 중점!
  • JWT 토큰이 변조가 이루어지면 통과가 안됨

실습

게이트웨이의 Pre 필터에서 JWT 인증을 진행
- 게이트웨이: 19091
- product 서비스: 19093(이 서비스만 활용)
- auth 서비스: 19095

1) 'http://localhost:19091/auth/signin?user_id=admin_1'로 요청이 게이트웨이로 왔을 때, user_id로 토큰 생성 후 반환
2) 클라이언트는 토큰을 활용해 Product로 호출
3) 게이트웨이로 먼저 들어와 토큰으로 로그인 여부 확인
4) 통과하면 Product 서비스로 이동

만약 권한을 확인해야 한다면, 게이트웨이 → auth 호출 필요
- 기본적인 User: Gateway → Product
- 권한을 가진 User: Gateway → auth 요청 후 응답 → Gateway → Product

실습 내용

1. auth 서비스 생성 후 build.gradle, application.yml 수정

프로젝트 생성

implementation 'io.jsonwebtoken:jjwt:0.12.6' // dependencies에 추가

spring:
  application:
    name: auth-service

eureka:
  client:
    service-url:
      defaultZone: http://localhost:19090/eureka/  # Eureka 서버의 URL을 지정

service:
  jwt:
    access-expiration: 3600000
    secret-key: {secret-key}

server:
  port: 19095

 

2. JWT Config 파일 생성

package com.spring_cloud.eureka.client.auth;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.http.SessionCreationPolicy;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
@EnableWebSecurity
public class AuthConfig {

    // SecurityFilterChain 빈을 정의합니다. 이 메서드는 Spring Security의 보안 필터 체인을 구성합니다.
    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
                // CSRF 보호를 비활성화합니다. CSRF 보호는 주로 브라우저 클라이언트를 대상으로 하는 공격을 방지하기 위해 사용됩니다.
                .csrf(csrf -> csrf.disable())
                // 요청에 대한 접근 권한을 설정합니다.
                .authorizeHttpRequests(authorize -> authorize
                        // /auth/signIn 경로에 대한 접근을 허용합니다. 이 경로는 인증 없이 접근할 수 있습니다.
                        .requestMatchers("/auth/signIn").permitAll()
                        // 그 외의 모든 요청은 인증이 필요합니다.
                        .anyRequest().authenticated()
                )
                // 세션 관리 정책을 정의합니다. 여기서는 세션을 사용하지 않도록 STATELESS로 설정합니다.
                .sessionManagement(session -> session
                        .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                );

        // 설정된 보안 필터 체인을 반환합니다.
        return http.build();
    }
}

 

3. Service 생성(토큰 발급)

package com.spring_cloud.eureka.client.auth;

import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
import io.jsonwebtoken.io.Decoders;
import io.jsonwebtoken.security.Keys;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Service;

import javax.crypto.SecretKey;
import java.util.Date;

@Service
public class AuthService {

    @Value("${spring.application.name}")
    private String issuer;

    @Value("${service.jwt.access-expiration}")
    private Long accessExpiration;

    private final SecretKey secretKey;

    public AuthService(@Value("${service.jwt.secret-key}") String secretKey) {
        this.secretKey = Keys.hmacShaKeyFor(Decoders.BASE64URL.decode(secretKey));
    }

    // access token 생성
    public String createAccessToken(String user_id) {
        return Jwts.builder()
                .claim("user_id", user_id)
                .issuer(issuer) // 토큰 발급자
                .issuedAt(new Date((System.currentTimeMillis())))
                .expiration(new Date(System.currentTimeMillis() + accessExpiration))
                .signWith(secretKey, Jwts.SIG.HS512)
                .compact();
    }
}

 

4. Controller 생성

package com.spring_cloud.eureka.client.auth;

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;
import lombok.RequiredArgsConstructor;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequiredArgsConstructor
public class AuthController {
    
    private final AuthService authService;
    
    // ResponseEntity<?>: ?는 와일드 카드
    @GetMapping("/auth/signIn")
    public ResponseEntity<?> createAuthToken(@RequestParam String user_id) {
        return ResponseEntity.ok(new AuthResponse(authService.createAccessToken(user_id)));
    }
    
    @Data
    @AllArgsConstructor
    @NoArgsConstructor
    static class AuthResponse {
        private String access_token;
    }
}

Eureka 서버에 auth 서비스 인스턴스 추가

auth 서비스 회원가입 API 호출 후 토큰 반환

 

5. Gateway에 토큰 체크 기능 추가(필터)

server:
  port: 19091  # 게이트웨이 서비스가 실행될 포트 번호

spring:
  main:
    web-application-type: reactive  # Spring 애플리케이션이 리액티브 웹 애플리케이션으로 설정됨
  application:
    name: gateway-service  # 애플리케이션 이름을 'gateway-service'로 설정
  cloud:
    gateway:
      server:
        webflux:
          routes: # Spring Cloud Gateway의 라우팅 설정
            - id: order-service  # 라우트 식별자
              uri: lb://order-service  # 'order-service'라는 이름으로 로드 밸런싱된 서비스로 라우팅
              predicates:
                - Path=/order/**  # /order/** 경로로 들어오는 요청을 이 라우트로 처리
            - id: product-service  # 라우트 식별자
              uri: lb://product-service  # 'product-service'라는 이름으로 로드 밸런싱된 서비스로 라우팅
              predicates:
                - Path=/product/**  # /product/** 경로로 들어오는 요청을 이 라우트로 처리
            - id: auth-service  # 라우트 식별자
              uri: lb://auth-service  # 'auth-service'라는 이름으로 로드 밸런싱된 서비스로 라우팅
              predicates:
                - Path=/auth/signIn  # /auth/signIn 경로로 들어오는 요청을 이 라우트로 처리
          discovery:
            locator:
              enabled: true # 서비스 디스커버리를 통해 동적으로 라우트를 생성하도록 설정

eureka:
  client:
    service-url:
      defaultZone: http://localhost:19090/eureka/  # Eureka 서버의 URL을 지정

service:
  jwt:
    access-expiration: 3600000
    secret-key: secret-key

// build.gradle 내 dependencies에 추가
implementation 'io.jsonwebtoken:jjwt:0.12.6'

package com.spring_cloud.eureka.client.gateway;

import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jws;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.io.Decoders;
import io.jsonwebtoken.security.Keys;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

import javax.crypto.SecretKey;

@Component
@Slf4j
public class LocalJwtAuthenticationFilter implements GlobalFilter {

    @Value("${service.jwt.secret-key}")
    private String secretKey;

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // /auth/signIn으로 들어온 URI는 필터 수행 X
        String path = exchange.getRequest().getURI().getPath();
        if(path.equals("/auth/signIn")) {
            return chain.filter(exchange);
        }

        // 토큰 가져오기
        String token = extractToken(exchange);

        // 토큰 검증 실패
        if(token == null || !validateToken(token)) {
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }

        return chain.filter(exchange);
    }

    // 헤더에서 토큰 추출하는 메서드
    private String extractToken(ServerWebExchange exchange) {
        String authHeader = exchange.getRequest().getHeaders().getFirst("Authorization");
        if(authHeader != null && authHeader.startsWith("Bearer ")) {
            return authHeader.substring(7); // Bearer 제외한 순수 토큰 추출
        }
        return null;
    }

    // 토큰 검증
    private boolean validateToken(String token) {
        try {
            SecretKey key = Keys.hmacShaKeyFor(Decoders.BASE64URL.decode(secretKey));
            Jws<Claims> claimsJws = Jwts.parser()
                    .verifyWith(key)
                    .build().parseSignedClaims(token);
            log.info("#####payload :: " + claimsJws.getPayload().toString());

            // 추가적인 검증 로직 (예: 토큰 만료 여부 확인 등)을 여기에 추가할 수 있습니다.
            return true;
        } catch (Exception e) {
            return false;
        }
    }
}

게이트웨이를 통한 signIn 호출

토큰을 활용한 게이트웨이 인증 처리

---

Config(Spring Cloud Config)

Spring Cloud Config는 분산 시스템 환경에서 중앙 집중식 구성 관리를 제공하는 프레임워크로,
애플리케이션의 설정을 중앙에서 관리하고, 변경 사항을 실시간으로 반영할 수 있음
- Git, 파일 시스템, JDBC 등 다양한 저장소를 지원함

• 중앙 집중식 구성 관리: 모든 마이크로서비스의 설정을 중앙에서 관리
• 환경별 구성: 개발, 테스트, 운영 등 환경별로 구성을 분리해 관리
• 실시간 구성 변경: 설정 변경 시 애플리케이션을 재시작하지 않고도 실시간으로 반영 가능

Spring Cloud Config 서버 설정

• build.gradle에 의존성 추가

dependencies {
    implementation 'org.springframework.cloud:spring-cloud-config-server'
    implementation 'org.springframework.boot:spring-boot-starter-web'
}

• Spring Boot 애플리케이션에서 Config 서버 설정

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

• Config 서버의 설정 정의

server:
  port: 8888

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/my-config-repo/config-repo
          clone-on-start: true

Spring Cloud Config 클라이언트 설정

• build.gradle 의존성 추가

dependencies {
    implementation 'org.springframework.cloud:spring-cloud-starter-config'
}

• Config 서버 설정 정의

spring:
  application:
    name: my-config-client
  cloud:
    config:
      discovery:
        enabled: true
        service-id: config-server
     
eureka:
  client:
    service-url:
      defaultZone: http://localhost:19090/eureka/

환경별 구성 관리

• Config 서버는 환경별로 다른 설정 파일을 제공할 수 있음
• ex) application-dev.yml, application-prod.yml 파일을 Git 저장소에 저장해 환경별 설정 관리함
• Spring Boot 애플리케이션에서는 프로필을 사용해 환경 구분할 수 있음

// Spring Boot 애플리케이션에서 프로필을 사용해 환경 구분
spring:
  profiles:
    active: dev

실시간 구성 변경

실시간 구성 변경을 반영하는 방법은 여러 가지 존재함

• Spring Cloud Bus 사용하는 방법
• 수동으로 /actuator/refresh 엔드포인트 호출하는 방법
• Spring Boot DevTools 사용하는 방법
• Git 저장소를 사용하는 방법

각 방법은 상황에 따라 적절히 선택해 사용할 수 있음

 

Spring Cloud Bus

Spring Cloud Bus를 사용하면 설정 변경 사항을 실시간으로 클라이언트 애플리케이션에 반영 가능함. 이를 위해서는 메시징 시스템(RabbitMQ 또는 Kafka 등)을 사용하여 변경 사항을 전파해야 함

 

수동 구성 갱신

1) /actuator/refresh 앤드포인트 사용

Spring Cloud Bus를 사용하지 않는 경우, 클라이언트 애플리케이션에서 수동으로 설정을 갱신할 수 있음. 이를 위해서는 Spring Actuator의 /actuator/refresh 앤드포인트를 사용할 수 있음

1. Config 서버에서 설정 파일 변경
2. 클라이언트 애플리케이션의 /actuator/refresh 앤드포인트를 POST 요청으로 호출해 변경된 설정 반영

이 방법은 간단하지만, 각 클라이언트 애플리케이션에서 수동으로 앤드포인트를 호출해야 함

 

2) Spring Boot DevTools 사용

개발 환경에서 파일 변경을 자동으로 감지하고 애플리케이션을 재시작할 수 있음. 이는 classpath 내의 파일 변경도 포함됨

 

Git 저장소 사용

Spring Cloud Config 서버가 Git 저장소에서 설정 파일을 읽어오도록 설정할 수 있음. 이는 설정 파일의 변경 사항을 쉽게 반영하고, 여러 서비스 간에 일관된 구성을 유지하는 데 유용함

실습

Config 서버 생성하고 product 애플리케이션이 local에서 동작할 때 포트 정보 및 메시지를 Config 서버에서 가져옴
Config 서버의 메시지를 변경해 product 애플리케이션의 message가 갱신되는 모습 확인

- 실습에서 네이티브 모드 사용
로컬 환경(네이티브 모드)에서는 설정 변경 후 반영하려면 애플리케이션을 재시작해야 함

현업에서는 직접 Config 서버를 구현하기보다는, 이미 구축된 Config 서버를 연동해 사용하는 경우가 일반적일 것임

실습 내용

1. Config-server 생성 및 필요 설정

프로젝트 생성

package com.spring_cloud.eureka.client.config;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;

@SpringBootApplication
@EnableConfigServer // 추가
public class ConfigApplication {

	public static void main(String[] args) {
		SpringApplication.run(ConfigApplication.class, args);
	}

}

// application.yml
server:
  port: 18080

spring:
  profiles:
    active: native
  application:
    name: config-server
  cloud:
    config:
      server:
        native:
          search-locations: classpath:/config-repo # config-repo를 resource 폴더로 지정

eureka:
  client:
    service-url:
      defaultZone: http://localhost:19090/eureka/  # Eureka 서버의 URL을 지정

 

2. product에 전달할 yml 파일 선언

// resources > config-repo > product-service.yml
server:
  port: 19093

message: "product-service message"

// resources > config-repo > product-service-local.yml
server:
  port: 19083

message: "product-service-local message"

 

3. product 서비스 수정(Config 서버에서 가져오기 위해)

// 의존성 추가
implementation 'org.springframework.cloud:spring-cloud-starter-config'

// application.yml
spring:
  application:
    name: product-service
  profiles:
    active: local
  config:
    import: "configserver:"
  cloud:
    config:
      discovery:
        enabled: true
        service-id: config-server

server:
  port: 0

eureka:
  client:
    service-url:
      defaultZone: http://localhost:19090/eureka/

message: "default message"

package com.spring_cloud.eureka.client.product;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class ProductController {

    // application.properties에 작성한 server.port 가져오기
    @Value("${server.port}")
    private String serverPort; // 애플리케이션 포트
    
    @Value("${message}")
    private String message;

    @GetMapping("/product")
    public String getProduct() {
        return "Product info!!! From port :" + serverPort + "and message : " + message;
    }
}

product 서비스 실행(19083 포트)

product 서비스 호출

 

4. Config 메시지 변경 시 Product 서비스에도 메시지 변경 반영

// product 서비스 application.yml 파일에 refresh 추가

...

management:
  endpoints:
    web:
      exposure:
        include: refresh


message: "default message"

package com.spring_cloud.eureka.client.product;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RefreshScope // value를 값을 가져와 사용 중이기 때문에, refresh 변경 시 해당 값도 업데이트
@RestController
public class ProductController {

    // application.properties에 작성한 server.port 가져오기
    @Value("${server.port}")
    private String serverPort; // 애플리케이션 포트

    @Value("${message}")
    private String message;

    @GetMapping("/product")
    public String getProduct() {
        return "Product info!!! From port :" + serverPort + "and message : " + message;
    }
}

config 서버에 있는 파일 수정 후 다시 실행

• 'http://localhost:19083/actuator/refresh' 수동 실행 후, 업데이트 반영 확인

Config 변경 반영 확인

---

분산 추적(Spring Cloud Sleuth) 및 로깅(Zipkin)

분산 추적은 분산 시스템에서 서비스 간의 요청 흐름을 추적하고 모니터링하는 방법으로, 각 서비스의 호출 관계와 성능을 시각화해 문제를 진단하고 해결할 수 있도록 도움
- 주요 개념: 트레이스(Trace), 스팬(Span), 컨텍스트(Context)

• 마이크로서비스 아키텍처에서 여러 서비스가 협력해 하나의 요청을 처리함
• 서비스 간의 복잡한 호출 관계로 인해 문제 발생 시 원인을 파악하기 어려울 수 있음
• 분산 추적을 통해 각 서비스의 호출 흐름을 명확히 파악하고, 성능 병목이나 오류를 빠르게 진단 가능

Micrometer

Spring 기반 애플리케이션에서 매트릭을 수집하고 모니터링하기 위한 라이브러리로,

각 서비스의 성능 지표를 수집하고, Prometheus, Grafana 등과 연동해 시각화 가능함

분산 추적을 위한 기능도 제공해 서비스 간의 호출 흐름을 추적할 수 있음

• 다양한 매트릭 수집: 애플리케이션의 다양한 성능 지표 수집
• 유연한 연동: Prometheus, Grafana 등 다양한 모니터링 도구와 연동 가능
• 추적 기능: 서비스 간의 호출 흐름을 추적해 성능 병목 진단 가능

Zipkin

트레이스 데이터를 수집하고 시각화하는 분산 추적 시스템으로, 각 서비스의 트레이스와 스팬 데이터를 저장하고, 이를 통해 호출 흐름을 시각화함

• 데이터 수집 및 저장: 각 서비스에서 전송된 트레이스 데이터를 수집하고 저장
• 시각화: 트레이스 데이터를 시각화해 서비스 간의 호출 관계를 명확히 파악 가능
• 검색 및 필터링: 특정 트레이스나 스팬을 검색하고 필터링해 문제 진단 가능

서버 설정

• Zipkin 서버는 Docker를 사용해 실행할 수 있음

docker run -d -p 9411:9411 openzipkin/zipkin

 

분산 추적 예제

1. 서비스 호출 흐름 추적

• 서비스 간의 호출 흐름을 추적하고, Zipkin 대시보드에서 시각화
• 각 서비스 호출 시 트레이스와 스팬이 생성되고, Zipkin 서버로 전송됨

2. 성능 병목 진단

• Zipkin 대시보드를 통해 성능 병목이 발생하는 부분 식별
• 각 스팬의 소요 시간과 호출 관계를 분석해 성능 문제를 진단하고 해결

Zipkin 내 서비스 호출 흐름 예시

---

이벤트 드리븐 아키텍처와 스트림 처리(Spring Cloud Stream)

이벤트 드리븐 아키텍처는 시스템에서 발생하는 이벤트(상태 변화나 행동)를 기반으로 동작하는 소프트웨어 설계 스타일임.
이벤트는 비동기적으로 처리되며, 서비스 간의 느슨한 결합을 통해 독립적으로 동작할 수 있게 함

• 이벤트: 시스템 내에서 발생하는 상태 변화나 행동을 나타내는 메시지
• 이벤트 소스: 이벤트를 생성해 이벤트 버스에 전달하는 역할
• 이벤트 핸들러: 이벤트를 수신해 처리하는 역할
• 이벤트 버스: 이벤트 소스와 이벤트 핸들러 간의 메시지 전달을 중계

장점

1. 느슨한 결합

• 서비스 간의 강한 종속성을 제거해 독립적인 개발과 배포 가능
• 이벤트 기반 통신을 통해 서비스 간의 결합도 낮춤

2. 확장성

• 수평 확장이 용이하여 대규모 시스템에서 유용
• 이벤트 프로듀서와 컨슈머를 독립적으로 확장 가능

3. 비동기 처리

• 이벤트를 비동기적으로 처리해 시스템의 응답성 향상
• 요청과 응답을 비동기적으로 처리해 성능 최적화

단점

1. 복잡성 증가

• 이벤트 기반 통신으로 인해 시스템의 복잡성 증가
• 이벤트 흐름과 상태 관리를 체계적으로 설계 필요

2. 장애 전파

• 이벤트 실패 시 다른 서비스로 장애가 전파될 수 있음
• 이벤트 재처리 및 장애 복구 메커니즘 구현 필요

예시: 온라인 쇼핑몰

1. 이벤트 소스: 사용자가 온라인 쇼핑몰에서 주문

• 주문 서비스가 '주문 생성' 이벤트 발생시킴

2. 이벤트 버스: Kafka나 RabbitMQ와 같은 메시지 브로커가 '주문 생성' 이벤트를 전달

3. 이벤트 핸들러:

• 재고 서비스: '주문 생성' 이벤트를 수신해 재고를 확인하고 업데이트
• 배송 서비스: '주문 생성' 이벤트를 수신해 배송 준비 시작
• 결제 서비스: '주문 생성' 이벤트를 수신해 결제 처리

Spring Cloud Stream

이벤트 드리븐 마이크로서비스를 구축하기 위한 프레임워크로, Kafka나 RabbitMQ 등의 메시지 브로커와 통합하여 이벤트 스트리밍을 처리함

• Producer-Consumer 간의 통신을 추상화해 간편하게 이벤트 기반 애플리케이션 개발 가능
• 바인더 추상화: 메시지 브로커와의 통합을 위한 추상화 레이어 제공
• 프로듀서/컨슈머 모델: 이벤트를 생성하고 처리하는 프로듀서와 컨슈머 모델 지원
• 유연한 설정: 다양한 설정 옵션을 통해 손쉽게 커스터마이징 가능

이벤트 기반 마이크로 서비스 동작 흐름

---

쿠버네티스(Kubernetes)

쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션의 배포, 확장, 운영을 자동화하는 오픈소스 플랫폼으로, Google에서 개발하고 현재는 CNCF(Cloud Native Computing Foundation)에서 관리함
- 컨테이너 오케스트레이션 도구로, 다수의 컨테이너를 효율적으로 관리 가능

• 컨테이너: 애플리케이션과 그 종속성을 함께 패키징한 가상화된 환경
• Pod: 쿠버네티스에서 실행되는 최소 단위의 배포 객체로, 하나 이상의 컨테이너를 포함
• 노드(Node): 쿠버네티스 클러스터에서 Pod가 실행되는 물리적 또는 가상 머신
• 클러스터: 여러 노드로 구성된 쿠버네티스의 집합
• 네임스페이스(Namespace): 클러스터 내에서 리소스를 논리적으로 구분하는 단위