MSA (Microservice Architecture)

 

 

🗨️ MSA

MSA 개요

MSA란?

• Microservices Architecture (MSA)
  • MSA는 하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발, 배포, 유지보수를 용이하게 하는 소프트웨어 아키텍처 스타일
  • 각 서비스는 특정 비즈니스 기능을 수행하며, 서로 독립적으로 배포되고 확장될 수 있음
  • 서비스 간의 통신은 주로 HTTP/HTTPS, 메시지 큐 등을 통해 이루어짐
• 주요 특징
  • 독립적인 배포 가능성: 각 서비스는 독립적으로 배포할 수 있으며, 다른 서비스에 영향을 주지 않고 업데이트할 수 있음
  • 작은 팀 구성: 각 서비스는 작은 팀이 독립적으로 개발하고 관리할 수 있음
  • 기술 스택의 다양성: 각 서비스는 적절한 기술 스택을 자유롭게 선택할 수 있음

 

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

모놀리틱 아키텍처

• 정의:
  • 모놀리틱 아키텍처는 하나의 큰 코드베이스(특정 소프트웨어, 애플리케이션 또는 라이브러리를 빌드하고 실행하는 데 필요한 전체 소스 코드의 집합)로 구성된 애플리케이션
  • 모든 기능이 하나의 애플리케이션 내에 포함
• 장점:
  • 간단한 배포: 모든 코드가 하나의 코드베이스에 포함되어 있어 배포가 단순
  • 단일 데이터베이스: 하나의 데이터베이스를 사용하여 데이터 일관성을 쉽게 유지할 수 있음
• 단점:
  • 확장성 부족: 특정 기능을 확장하려면 전체 애플리케이션을 확장해야 함
  • 긴 개발 주기: 작은 변경 사항도 전체 애플리케이션을 다시 배포해야 함
  • 유연성 부족: 새로운 기술 도입이 어렵고, 특정 모듈에 종속적임

MSA

• 정의:
  • MSA는 여러 개의 독립적인 서비스로 구성된 애플리케이션
  • 각 서비스는 특정 비즈니스 기능을 수행
• 장점:
  • 확장성: 특정 서비스만 확장하여 성능을 최적화할 수 있음
  • 독립적 배포: 개별 서비스의 변경 사항을 독립적으로 배포할 수 있음
  • 유연성: 서비스별로 적합한 기술 스택을 선택할 수 있음
• 단점:
  • 복잡성 증가: 서비스 간 통신, 데이터 일관성 유지 등의 복잡성이 증가
  • 운영비용 증가: 각 서비스의 모니터링, 로깅 등을 개별적으로 관리해야 함

 

MSA의 장단점

• 장점
  • 확장성: 각 서비스는 독립적으로 확장 가능, 특정 기능에 대한 성능 최적화가 용이
  • 유연성: 다양한 기술 스택을 사용하여 서비스별 최적화 가능
  • 독립적 배포: 서비스별로 독립적 배포가 가능하여 배포 주기를 단축
  • 작은 팀 구성: 서비스별 작은 팀으로 구성되어 민첩한 개발 가능
• 단점
  • 복잡성: 서비스 간 통신, 데이터 일관성 유지, 트랜잭션 관리 등의 복잡성이 증가
  • 운영비용: 각 서비스의 모니터링, 로깅, 장애 대응 등을 개별적으로 관리해야 하므로 운영 비용이 증가
  • 데이터 관리: 분산된 데이터베이스로 인해 데이터 일관성 유지가 어려울 수 있음
  • 네트워크 지연: 서비스 간의 통신이 네트워크를 통해 이루어지므로 지연 시간이 발생할 수 있음

 

🗨️ Spring Cloud

Spring Cloud 개요

Spring Cloud란?

• 정의
  • Spring Cloud는 마이크로서비스 개발을 위해 다양한 도구와 서비스를 제공하는 스프링 프레임워크의 확장
  • 마이크로서비스 아키텍처를 쉽게 구현하고 운영할 수 있도록 도움
• 주요 기능
  1. 서비스 등록 및 디스커버리: Eureka, Consul, Zookeeper
     • 서비스 위치 탐색: 동적으로 변하는 마이크로서비스 인스턴스의 위치(IP, 포트)를 등록하고, 클라이언트가 이를 찾아낼 수 있게 관리하는 '전화번호부' 역할 
  2. 로드 밸런싱: Ribbon, Spring Cloud LoadBalancer
     • 트래픽 부하 분산: 특정 서버에 부하가 집중되지 않도록 여러 대의 서버 인스턴스에 트래픽을 균등하게 분산시켜 주는 기술 
  3. 서킷 브레이커: Hystrix, Resilience4j
     • 장애 전파 차단: 특정 서비스에 장애가 발생했을 때 호출을 차단하여 전체 시스템으로 장애가 전파되는 것을 막고 우회로를 제공하는 안전장치
  4. API 게이트웨이: Zuul, Spring Cloud Gateway
     • 통합 관문 관리: 시스템의 단일 진입점으로서 인증/인가 처리, 요청 라우팅, 로드 밸런싱, 로깅 등을 공통적으로 처리하는 문지기 역할
  5. 구성 관리: Spring Cloud Config
     • 환경 설정 중앙화: 서버를 재시작하지 않고도 분산된 마이크로서비스들의 설정값(properties, yaml)을 중앙 서버에서 한 번에 관리하고 변경하는 기능
  6. 분산 추적: Spring Cloud Sleuth, Zipkin
     • 처리 경로 시각화: 여러 마이크로서비스를 거쳐 처리되는 하나의 요청(Request)의 흐름과 처리 시간을 시각화하여 장애 지점을 파악하는 기술
  7. 메시징: Spring Cloud Stream
     • 비동기 데이터 전달: Kafka나 RabbitMQ 같은 메시지 브로커를 통해 서비스 간 비동기 데이터 전달을 쉽게 구현하도록 돕는 추상화 레이어

현업에서는 버전 업데이트 시의 안정성 문제나 기존 레거시 시스템과의 호환성 때문에 여전히 Hystrix나 Zuul을 사용하는 곳이 많습니다. 따라서 최신 표준인 Spring Cloud Gateway나 Resilience4j가 이들과 기능적으로 유사한 역할을 한다는 점을 이해하고, 환경에 따라 유연하게 파악할 수 있어야 합니다.

 

Spring Cloud 주요 모듈

서비스 등록 및 디스커버리

📌 Eureka

• 넷플릭스가 개발한 서비스 디스커버리 서버로, 마이크로서비스 아키텍처에서 각 서비스의 위치를 동적으로 관리
• 주요 특징:
  • 서비스 레지스트리: 모든 서비스 인스턴스의 위치를 저장하는 중앙 저장소
  • 헬스 체크(Health check): 서비스 인스턴스의 상태를 주기적으로 확인하여 가용성을 보장

로드 밸런싱

📌 Ribbon

• 넷플릭스가 개발한 클라이언트 사이드 로드 밸런서로, 서비스 인스턴스 간의 부하를 분산
• 주요 특징:
  • 서버 리스트 제공자: Eureka로부터 서비스 인스턴스 리스트를 제공받아 로드 밸런싱에 사용
  • 로드밸런싱 알고리즘: 라운드 로빈, 가중치 기반 등 다양한 로드 밸런싱 알고리즘 지원
  • Failover: 요청 실패 시 다른 인스턴스로 자동 전환

서킷 브레이커

📌 Hystrix

• 넷플릭스가 개발한 서킷 브레이커 라이브러리로, 서비스 간의 호출 실패를 감지하고 시스템의 전체적인 안정성을 유지
• 주요 특징:
  • 서킷 브레이커 상태: 클로즈드, 오픈, 하프-오픈 상태를 통해 호출 실패를 관리
  • Failback: 호출 실패 시 대체 로직을 제공하여 시스템 안정성 확보
  • 모니터링: Hystrix Dashboard를 통해 서킷 브레이커 상태 모니터링

📌 Resilience4j

• Resilience4j는 자바 기반의 경량 서킷 브레이커 라이브러리로, 넷플릭스 Hystrix의 대안으로 개발
• 주요 특징:
  • 서킷 브레이커: 호출 실패를 감지하고 서킷을 열어 추가적인 호출을 차단하여 시스템의 부하를 줄임 
  • Failback: 호출 실패 시 대체 로직을 실행하여 시스템의 안정성을 유지
  • 타임아웃 설정: 호출의 응답 시간을 설정하여 느린 서비스 호출에 대응할 수 있음
  • 재시도: 재시도 기능을 지원하여 일시적인 네트워크 문제 등에 대응할 수 있음

 

Spring Cloud 구성 요소의 활용

API 게이트웨이

📌 Zuul

• 넷플릭스가 개발한 API 게이트웨이로, 모든 서비스 요청을 중앙에서 관리
• 주요 특징:
  • 라우팅: 요청 URL에 따라 적절한 서비스로 요청 전달
  • 필터: 요청 전후에 다양한 작업을 수행할 수 있는 필터 체인 제공
  • 모니터링: 요청 로그 및 메트릭을 통해 서비스 상태 모니터링 할 수 있음

📌 Cloud Gateway

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

 

구성 관리 

📌 Spring Cloud Config

• Spring Cloud Config는 분산된 환경에서 중앙 집중식 설정 관리를 제공
• 주요 특징:
  • Config 서버: 중앙에서 설정 파일을 관리하고 각 서비스에 제공
  • Config 클라이언트: Config 서버에서 설정을 받아서 사용하는 서비스
  • 설정갱신: 설정 변경 시 서비스 재시작 없이 실시간으로 반영

 

Spring Cloud의 적용 사례

Netflix

• 배경
  • 넷플릭스는 2000년대 후반 데이터 베이스 장애를 통해 심각한 서비스 장애를 겪게 됩니다.
  • 사용자가 급격히 증가 함에 따라 기존 모놀리틱 아키텍처로는 빠르게 증가하는 트래픽과 사용자 요구를 감당하기 어려워졌습니다.
  • 또한 신뢰성 높고 수평 확장이 가능한 클라우드 시스템으로 이전할 필요성을 느꼈습니다.
  • 폭발적인 사용자 증가, 빈번한 서비스 장애, 인프라 확장의 어려움, 빠른 기능 배포의 필요성, 클라우드 전환 등의 계기로 인해 MSA 전환이 시작되었습니다.
• MSA로의 전환 이유
  • 확장성(Scalability): 넷플릭스는 글로벌 서비스를 제공하며, 수백만 명의 사용자가 동시 접속할 수 있는 인프라가 필요했습니다.
  • 신뢰성(Reliability): 한 부분의 장애가 전체 시스템에 영향을 미치지 않도록 해야 했습니다.
  • 개발 속도(Speed of Development): 새로운 기능을 빠르게 배포하고, 독립적인 팀이 동시에 작업할 수 있는 환경이 필요했습니다.
• 전환 과정
  • 서비스 분리: 넷플릭스는 기존 모놀리식 애플리케이션을 여러 개의 독립적인 마이크로서비스로 분리했습니다.
  • 자동화 도구 도입: CI/CD 파이프라인을 구축하여 코드의 빌드, 테스트, 배포 과정을 자동화했습니다. 이를 통해 개발 속도를 크게 향상시켰습니다.
  • 자체 도구 개발: 넷플릭스는 Hystrix, Eureka, Ribbon 등의 도구를 개발하여 서비스 간 통신, 장애 복구, 로드 밸런싱 등을 효율적으로 처리했습니다.
  • 클라우드 인프라 활용: AWS와 같은 클라우드 인프라를 활용하여 서비스 확장성을 높였습니다.
• 결과
  • 향상된 확장성: 넷플릭스는 MSA 전환 이후 수천 개의 마이크로서비스를 운영하며, 글로벌 사용자 증가에 유연하게 대응할 수 있었습니다.
  • 높은 가용성: 서비스 장애 시 다른 서비스에 영향을 미치지 않고 독립적으로 복구할 수 있어, 사용자에게 지속적인 서비스를 제공할 수 있었습니다.
  • 빠른 배포 주기: 새로운 기능을 신속하게 개발하고 배포할 수 있어, 사용자 요구에 빠르게 대응할 수 있었습니다.

 

*참고 Spring Initializr사이트

https://start.spring.io/

주문 처리 시스템에 필요한 Spring Could의 주요 기능 알아보기 

1. 주문 처리를 위해 오더, 프로덕트, 유저 세 가지 애플리케이션이 필요하며, 서비스 간 통신이 필수적입니다.
2. 서비스 중복과 부하 분산을 위해 리본(Ribbon)을 사용하여 라운드 로빈 방식의 Load Balancing을 적용합니다.
3. 서비스의 위치를 동적으로 관리하기 위해 유레카(Eureka) 서버를 두고, 각 서비스는 유레카 클라이언트로 등록됩니다.
4. 외부 요청은 API 게이트웨이를 통해 접수되고, 엔드포인트에 따라 각각의 서비스로 요청이 분배됩니다.
5. 로그인 등 인증 요구는 API 게이트웨이의 필터 기능에서 처리하여, 인증되지 않은 요청은 서비스 내부로 전달하지 않습니다.
6. 서비스 요청 과정에서 장애 발생 시, Resilience4j Circuit Breaker를 활용해 실패 전파와 다양한 예외 처리를 합니다.
7. 설정 파일 관리를 위해 별도의 컨피그(Config) 서버를 두고, 모든 서비스가 중앙 서버에서 실시간으로 설정을 공유합니다.
8. 집킨(Zipkin) 등 분산 추적 도구로 각 서비스 간 호출 경로와 전체 흐름을 직관적으로 파악할 수 있습니다.
9. 시스템 설계 및 설명 능력 강화를 위해 구성도 작성의 중요성을 강조하며, 직접 그림을 그릴 것을 제안합니다

 

🗨️ 서비스 디스커버리

구성 요소	역할 (간단 요약)	비유	정확한 기술적 정의 (Precise Meaning)
@EnableFeignClients	Feign 활성화 버튼	공장 가동 스위치	애플리케이션 내에서 @FeignClient가 붙은 인터페이스를 찾아 Bean(객체)으로 등록하는 스캔 프로세스를 시작함.
@FeignClient	호출할 대상 지정	리모컨의 채널	외부 서비스와 통신하기 위한 HTTP 클라이언트를 선언적으로 정의하며, name 속성을 통해 Eureka에 등록된 서비스 ID와 매핑함.
Eureka Client	서비스 주소록 관리	최신 전화번호부	Eureka 서버로부터 전체 서비스 레지스트리(주소 목록)를 로컬 메모리에 내려받아 유지하고 관리하는 에이전트.
Ribbon (또는 LoadBalancer)	인스턴스 선택	전화 걸 상대 선택	Eureka Client가 가져온 목록 중 어떤 서버 주소로 요청을 보낼지 알고리즘(Round Robin 등)에 따라 결정하는 클라이언트 측 로드 밸런서.

 

서비스 디스커버리 개요

서비스 디스커버리란?

• 서비스 디스커버리는 마이크로서비스 아키텍처에서 각 서비스의 위치를 동적으로 관리하고 찾아주는 기능
• 각 서비스는 등록 서버에 자신의 위치를 등록하고, 다른 서비스는 이를 조회하여 통신
• 주요 기능으로는 서비스 등록, 서비스 조회, 헬스 체크 등이 있음

 

Eureka 개요

Eureka란?

• 넷플릭스가 개발한 서비스 디스커버리 서버로, 마이크로서비스 아키텍처에서 각 서비스의 위치를 동적으로 관리
• 모든 서비스 인스턴스의 위치를 저장하는 중앙 저장소 역할을 하며, 서비스 인스턴스의 상태를 주기적으로 확인하여 가용성을 보장
• 여러 인스턴스를 지원하여 고가용성을 유지할 수 있음

Eureka 서버 설정

• Eureka 서버는 서비스 레지스트리를 구성하는 중앙 서버
• 서버 설정 파일 예시:

server:
  port: 8761

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

• 해당 설정을 통해 Eureka 서버를 구성하고, 클라이언트가 등록할 수 있도록 준비

 

Eureka 클라이언트 설정

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

spring:
  application:
    name: my-service

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  # 리스 만료 기간

 

서비스 등록 및 디스커버리

서비스 등록

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

서비스 디스커버리

• 클라이언트 애플리케이션은 Eureka 서버에서 필요한 서비스의 위치를 조회
• RestTemplate을 사용하는 경우
  • 클라이언트 애플리케이션은 Eureka 서버에서 필요한 서비스의 위치를 조회합니다.
  • Spring Boot 애플리케이션에서 @LoadBalanced 애노테이션을 사용하여 RestTemplate에 로드 밸런싱 기능을 추가합니다.

  @SpringBootApplication
  public class MyApplication {
      public static void main(String[] args) {
          SpringApplication.run(MyApplication.class, args);
      }
  
      // [핵심] RestTemplate에 로드 밸런싱 기능을 활성화하는 설정
      // Eureka에 등록된 '서비스 이름'을 실제 IP 주소로 변환해주는 역할을 함
      @Bean
      @LoadBalanced
      public RestTemplate restTemplate() {
          return new RestTemplate();
      }
  }

  @RestController
  public class MyRestTemplateController {
  
      @Autowired
      private RestTemplate restTemplate;
  
      @GetMapping("/get-data-rest")
      public String getDataWithRestTemplate() {
          // [중요] 실제 IP/포트 대신 Eureka에 등록된 '서비스 이름(my-service)'을 사용
          // 내부적으로 로드 밸런서가 이 이름을 보고 가용 서버 리스트 중 하나를 선택함
          String serviceUrl = "<http://my-service/api/data>";
          // GET 요청을 보내고 응답을 String 클래스 형태로 받아옴
          return restTemplate.getForObject(serviceUrl, String.class);
      }
  }

• FeignClient를 사용하는 경우
  • 클라이언트 애플리케이션은 Eureka 서버에서 필요한 서비스의 위치를 조회합니다.
  • Spring Boot 애플리케이션에서 FeignClient를 사용하여 간편하게 서비스 호출을 수행합니다.

@SpringBootApplication
// [필수] 해당 애플리케이션에서 FeignClient 사용을 활성화함
@EnableFeignClients
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

// [핵심] 'my-service'라는 이름을 가진 마이크로서비스를 호출하겠다고 선언
@FeignClient(name = "my-service")
public interface MyServiceClient {

    // 외부 서버의 "/api/data" 경로로 GET 요청을 매핑
    // 메서드 호출만으로 원격 서버의 API가 실행됨
    @GetMapping("/api/data")
    String getData();
}

• name = "my-service": 호출할 상대방의 이름 (유레카 등록 명칭)
• @GetMapping("/api/data"): 상대방 서버에 작성된 실제 API 주소
• 원격 서버 (Remote Server): 실제로 일을 처리해서 응답을 줄 상대방 서비스

📌 @FeignClient name 속성 핵심 정리

1. 1. name의 본질
   • 정의: 유레카(Eureka) 서버에 등록된 대상 서비스의 고유 ID.
   • 역할: "어떤 녀석들을 부를 것인가?"를 결정하는 그룹 이름.
2. 동작 프로세스 (3단계)
   1. 목록 Fetch (전체 조회)
      • Feign이 유레카에게 "my-service 주소 다 줘!"라고 요청.
      • 유레카는 해당 이름을 가진 모든 인스턴스(A, B, C)의 주소 목록을 반환.
   2. 캐싱 (메모리 저장)
      • 우리 서버(호출자)는 받은 주소록을 자기 메모리에 저장해 두고 관리함.
   3. 로드 밸런싱 (선택 호출)
      • Ribbon이 메모리 속 목록 중 딱 하나를 선택 (기본: 라운드 로빈).
   4. 결정된 서버 주소로만 최종 HTTP 요청을 보냄.

스프링은 이 인터페이스를 보고 이렇게 해석합니다:

"아하! 개발자가 getData()라는 메서드를 호출하면, 나는 my-service라는 서버 주소를 찾아서 그 뒤에 /api/data를 붙이고 GET 방식으로 요청을 보내면 되는구나!"

• ✍️ 필기용 요약
  • Controller의 @GetMapping: 사용자가 나를 부르는 주소
  • FeignClient의 @GetMapping: 내가 다른 서버를 부르는 주소 (규격 정의)
  • 인터페이스를 쓰는 이유: "어떤 주소로, 어떤 방식으로 보낼지"만 적어두면, 복잡한 통신 코드(URL 연결, 데이터 변환 등)를 스프링이 대신 짜주기 때문입니다.

@RestController
public class MyFeignClientController {

    @Autowired
    private MyServiceClient myServiceClient;

    @GetMapping("/get-data-feign")
    public String getDataWithFeignClient() {
        // [장점] 마치 같은 프로젝트 내의 로컬 메서드를 호출하듯이 사용 가능
        // 내부적으로 Eureka 조회 + 로드 밸런싱이 모두 수행됨
        return myServiceClient.getData();
    }
}

• 입구 열기: @GetMapping("/get-data-feign")
  • 사용자가 브라우저에 http://localhost:8080/get-data-feign이라고 입력하고 엔터를 치면 이 메서드가 실행됩니다.
• 명령 전달: return myServiceClient.getData();
  • 사용자의 요청을 받은 컨트롤러가 "자, 이제 미리 만들어둔 FeignClient 리모컨을 눌러서 다른 서버(my-service)에 있는 데이터를 가져와!"라고 시키는 것입니다.
• 결과 배달:
  • 다른 서버에서 가져온 데이터를 그대로 사용자(브라우저)에게 화면으로 보여주며 마무리합니다.

 

헬스 체크 및 장애 처리

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

 

Eureka의 고가용성 구성

클러스터 구성

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

eureka:
  client:
    service-url:
      defaultZone: http://eureka-peer1:8761/eureka/,http://eureka-peer2:8761/eureka/

• Eureka 서버를 다중 인스턴스로 구성할 때 각 서버의 피어 설정을 통해 서로를 인식하고 백업할 수 있음

 

실습

💡 Eureka server 하나에 같은 기능을 하는 인스턴스 2개를 연결해 보겠습니다.

• Eureka server
  • start.spring.io 에 접속하여 Eureka Service 디펜던시를 추가하여 프로젝트 생성
• service instance
  • start.spring.io 에 접속하여 Eureka Discovery Client 디펜던시를 추가하여 프로젝트 생성
  • Artifact 를 first, second 로 바꿔서 GENERATE 하여 2개를 다운

ServerApplication.java

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

@EnableEurekaServer
@SpringBootApplication
public class ServerApplication {

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

}

src/resource/application.properties [server]

spring.application.name=server

server.port=19090

# 유레카 서버에 자신을 등록할지 여부를 설정합니다.
# true로 설정하면 유레카 클라이언트가 유레카 서버에 자신을 등록합니다.
# 유레카 서버에서는 일반적으로 false로 설정하여, 서버가 자기 자신을 등록하지 않도록 합니다.
eureka.client.register-with-eureka=false

# 유레카 서버로부터 레지스트리를 가져올지 여부를 설정합니다.
# true로 설정하면 유레카 클라이언트가 유레카 서버로부터 다른 서비스 인스턴스 목록을 가져옵니다.
# 유레카 서버에서는 일반적으로 false로 설정하여, 레지스트리를 가져오지 않도록 합니다.
eureka.client.fetch-registry=false

# 유레카 서버 인스턴스의 호스트 이름을 설정합니다.
# 유레카 서버가 자신의 호스트 이름을 다른 서비스에 알릴 때 사용합니다.
eureka.instance.hostname=localhost

# 유레카 클라이언트가 유레카 서버와 통신하기 위해 사용할 기본 서비스 URL을 설정합니다.
# 클라이언트 애플리케이션이 유레카 서버에 연결하고 등록하거나 레지스트리를 가져올 때 사용할 URL을 지정합니다.
eureka.client.service-url.defaultZone=http://localhost:19090/eureka/

src/resource/application.properties [first]

spring.application.name=first

server.port=19091

# 유레카 클라이언트가 유레카 서버와 통신하기 위해 사용할 기본 서비스 URL을 설정합니다.
# 유레카 서버의 포트와 호스트 이름을 정확히 지정해야 합니다.
eureka.client.service-url.defaultZone=http://localhost:19090/eureka/

src/resource/application.properties [second]

spring.application.name=second

server.port=19092

# 유레카 클라이언트가 유레카 서버와 통신하기 위해 사용할 기본 서비스 URL을 설정합니다.
# 유레카 서버의 포트와 호스트 이름을 정확히 지정해야 합니다.
eureka.client.service-url.defaultZone=http://localhost:19090/eureka/

 

• Run
  • 유레카 서버 → first → second 순으로 실행
  • http://localhost:19090/ 으로 접속하면 두 개의 인스턴스가 있는 것을 확인할 수 있음

 

🗨️ 로드밸런싱

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

로드 밸런싱이란?

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

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

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

 

FeignClient 개요

FeignClient란?

• FeignClient는 Spring Cloud에서 제공하는 HTTP 클라이언트로, 선언적으로 RESTful 웹 서비스를 호출할 수 있음
• Eureka와 같은 서비스 디스커버리와 연동하여 동적으로 서비스 인스턴스를 조회하고 로드 밸런싱을 수행

FeignClient는 다른 마이크로서비스의 REST API를 호출하기 위한 HTTP 클라이언트 코드를, 인터페이스 선언만으로 알아서 만들어주는 매우 편리한 라이브러리입니다. 개발자는 비즈니스 로직에만 집중할 수 있게 해줍니다.

예를 들어, @FeignClient(name = "product-service") 라고 이름을 지정하면, Spring Cloud는 Eureka(서비스 레지스트리)를 통해 product-service라는 이름을 가진 서버들의 실제 IP 주소와 포트를 알아냅니다. 만약 product-service 서버가 3대 떠 있다면, FeignClient는 내부적으로 로드밸런서(Spring Cloud LoadBalancer)와 연동되어 3대의 서버로 요청을 적절히 분산시켜 줍니다.

용어	핵심 의미	한 줄 요약
HTTP 클라이언트	요청 대리인	서버가 다른 서버의 API를 호출하기 위해 사용하는 도구
선언적 호출	인터페이스 정의	구체적인 로직 구현 없이 인터페이스와 어노테이션만으로 통신하는 방식
FeignClient	스마트한 통신 도구	인터페이스 선언만으로 로드 밸런싱까지 알아서 해주는 HTTP 클라이언트

FeignClient의 주요 특징

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

 

Ribbon 개요

Ribbon이란?

• 넷플릭스가 개발한 클라이언트 사이드 로드 밸런서로, 마이크로서비스 아키텍처에서 서비스 인스턴스 간의 부하를 분산
• 다양한 로드 밸런싱 알고리즘을 지원하며, Eureka와 같은 서비스 디스커버리와 연동하여 사용

Ribbon의 주요 특징

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

 

FeignClient와 Ribbon 설정

기본 설정

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

build.gradle 파일 예시:

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

Spring Boot 애플리케이션 설정:

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

 

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 연동

Eureka 설정

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

application.yml 파일 설정 예시:

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

 

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 인스턴스 중 하나를 선택하여 호출합니다. 이 과정에서 Round Robin 알고리즘을 사용하여 요청을 순차적으로 분배합니다.
4. 응답 처리: 선택된 Product 인스턴스에서 응답을 받아 Order 서비스에 반환하고, 최종적으로 클라이언트에 응답을 전달합니다.

 

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": Eureka 서버에 등록된 대상 서비스의 이름을 적습니다.
 * Ribbon은 이 이름을 보고 "어떤 주소(IP)로 보낼지" 결정합니다.
 */
@FeignClient(name = "my-service")
public interface MyServiceClient {

    /**
     * @GetMapping: 대상 서버(my-service)의 "/endpoint"라는 경로로 GET 요청을 보낸다는 뜻입니다.
     * @RequestParam: 요청을 보낼 때 주소창에 ?param=값 형식으로 데이터를 붙여서 보냅니다.
     * 반환 타입(String): 상대방 서버가 응답으로 돌려줄 데이터 형식을 지정합니다.
     */
    @GetMapping("/endpoint")
    String getResponse(@RequestParam(name = "param") String param);
}

서비스 사용 예제

• FeignClient를 사용하여 다른 서비스 호출을 수행

예시 코드:

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

@RestController
public class MyController {

    // 위에서 만든 MyServiceClient를 스프링이 자동으로 구현해서 넣어줍니다(DI).
    @Autowired
    private MyServiceClient myServiceClient;

    /**
     * 클라이언트(사용자 브라우저 등)가 이 서버의 "/call-service"를 호출했을 때 실행됩니다.
     */
    @GetMapping("/call-service")
    public String callService(@RequestParam String param) {
        
        /*
         * [핵심 동작 과정]
         * 1. myServiceClient.getResponse(param)를 실행하면,
         * 2. Feign이 "my-service"라는 이름을 보고 Eureka에서 인스턴스 목록을 가져옵니다.
         * 3. Ribbon이 라운드 로빈 방식으로 인스턴스 하나를 고릅니다.
         * 4. 선택된 인스턴스로 HTTP 요청을 슝~ 보내고 결과를 받아와서 리턴합니다.
         */
        return myServiceClient.getResponse(param);
    }
}

 

실습

💡 유레카 서버 하나에 주문 인스턴스 1개와 같은 기능의 포트만 다른 상품 인스턴스 3개를 연결합니다. 상품을 요청(http://localhost:19091/order/1) 하면 응답하는 인스턴스의 포트를 받아서 노출합니다. 이를 통해 라운드로빈으로 로드밸런싱이 되는 것을 확인합니다.

 

Eureka Server

• 서비스 디스커버리 (Eureka) 강의에서 진행했던 유레카 서버를 그대로 복사해서 실행합니다.

Product instance

• 💡 Product는 요청이 오면 아래의 문자열을 반환합니다.
• ”Product {productId} info!!!! From port : ${serverPort}”

ProductApplication.java

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

@SpringBootApplication
@EnableFeignClients
public class ProductApplication {

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

}

ProductController.java

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 {

    @Value("${server.port}") // 애플리케이션이 실행 중인 포트를 주입받습니다.
    private String serverPort;

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

    
}

resources/application.yml (application.properties 파일은 삭제)

spring:
  application:
    name: product-service
server:
  port: 19092
eureka:
  client:
    service-url:
      defaultZone: http://localhost:19090/eureka/

• 19092,19093,19094 포트에 같은 애플리케이션 실행하기
  • 인텔리제이의 상단 메뉴에서 실행 > 구성 편집으로 들어갑니다.
  • ProductApplication 의 이름을 ProdcutApplication:19092로 변경합니다.
  • 우측 상단의 복사버튼을 클릭하여 ProductApplication을 두 개 더 생성하고 이미지와 같이 19093,19094로 이름을 변경합니다.
  • 옵션수정을 클릭하여 VM옵션 추가를 클릭합니다.
  • 이미지와 같이 -Dserver.port=19093 을 입력합니다. 19094에도 같은 작업을 해줍니다.

 

Order instance

💡 Order는 요청이 오면 product를 호출하여 상품의 정보를 가져옵니다. 그리고 아래의 문자열을 반환합니다.
”Your order {orderId} product info => ${프로덕트에서 받은 문자열}”

주문은 주문아이디가 1인 주문만 있다고 가정하겠습니다. 1 주문은 112번 상품을 호출한다고 가정합니다.

• start.spring.io 에 접속하여 프로젝트를 생성합니다 (디펜던시는 이미지 참고

OrderApplication.java

• Feign 기능 활성화 (OrderApplication.java)
  • Logic: 애플리케이션이 시작될 때 외부 서비스를 호출할 수 있는 능력을 부여하는 가장 첫 번째 단계입니다.
  • Hint: 이 파일은 일종의 '메인 스위치'입니다. 여기서 스위치를 켜지 않으면 아무리 리모컨(@FeignClient)을 잘 만들어도 작동하지 않습니다.

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

@SpringBootApplication
// [핵심] 애플리케이션 내에서 @FeignClient가 붙은 인터페이스를 찾아 활성화합니다.
@EnableFeignClients
public class OrderApplication {

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

}

OrderController.java

• 클라이언트 요청 접수 (OrderController.java)
  • Logic: 외부(사용자)로부터 /order/{orderId} 형태의 요청을 가장 먼저 받아내는 창구 역할입니다.
  • Hint: 컨트롤러는 복잡한 로직을 직접 처리하지 않고, 들어온 요청을 OrderService로 토스하는 역할만 깔끔하게 수행하는 것이 좋습니다.

import org.springframework.web.bind.annotation.RestController;

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

// 이 클래스가 REST API 요청을 처리하는 컨트롤러임을 선언합니다.
@RestController
/ final이 붙은 필드(orderService)의 생성자를 자동으로 만들어주어 의존성을 주입(DI)합니다.
@RequiredArgsConstructor
public class OrderController {

    // 비즈니스 로직을 처리할 서비스 객체입니다. (Lombok에 의해 자동 주입됨)
    private final OrderService orderService;
	
    // GET 메서드로 "/order/1" 같은 형태의 URL 요청이 들어오면 이 메서드가 실행됩니다.
    @GetMapping("/order/{orderId}")
    // URL 경로에 있는 {orderId} 값을 변수 orderId로 쏙 빼옵니다.
    public String getOrder(@PathVariable String orderId) {
    	// 실제 데이터 가공 및 조립은 서비스 계층으로 넘겨서 처리한 뒤 그 결과를 반환합니다.
        return orderService.getOrder(orderId);
    }
    
}

ProdcutClient.java (클래스가 아닌 인터페이스로 생성)

• 원격 서비스 호출 정의 (ProductClient.java)
  • Logic: 대상 서비스의 이름과 API 명세를 선언하여, 복잡한 HTTP 통신 코드를 직접 작성하지 않고도 원격 서버를 호출할 수 있게 해주는 인터페이스입니다. 즉, 유레카 서버에 있는 product-service에게 어떤 경로로, 어떤 데이터를 넘겨주며 요청할지 정의하는 인터페이스입니다.
  • Hint: 이 코드는 "통신 명세서"입니다. 이 명세서를 바탕으로 스프링이 런타임(실행 시점)에 실제 통신을 수행하는 구현체를 자동으로 만들어줍니다. 코드를 직접 구현( { } 블록 )할 필요 없이 선언만 해두면, 런타임에 스프링과 Feign이 알아서 구현체를 만들어줍니다. 

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

// [Logic 1: 대상 서비스 지정 및 로드 밸런싱 준비]
// 유레카 캐시에서 "product-service"라는 이름으로 등록된 서버 목록을 찾습니다.
// 호출이 발생할 때마다 Ribbon이 이 목록 중 하나를 선택하여 최종 목적지(Target URL)를 결정합니다.
@FeignClient(name = "product-service")
public interface ProductClient {
    
    // [Logic 2: HTTP 요청 규격 정의]
    // 선택된 대상 서버에게 보낼 HTTP 메서드(GET)와 경로("/product/{id}")를 정의합니다.
    @GetMapping("/product/{id}")
    String getProduct(
            // [Logic 3: 요청 데이터 맵핑]
            // 우리가 코드를 짤 때 getProduct("112") 라고 호출하면,
            // 파라미터 "112"가 위 경로의 {id}에 맵핑되어 최종적으로 타겟 서버의 "/product/112" 경로로 HTTP 요청이 전송됩니다.
            @PathVariable("id") String id 
    );
}

 

💡 내부 실행 흐름 (Under the Hood)

• 우리가 나중에 OrderService에서 productClient.getProduct("112")를 실행했을 때, 내부적으로 벌어지는 일은 딱 3단계입니다.
  1. 타겟 선정: Feign이 @FeignClient(name="product-service")를 보고, Ribbon을 통해 호출할 서버 1개를 선택합니다.
  2. URL 조립: 선택된 서버의 기본 주소에 @GetMapping의 경로와 @PathVariable의 값을 합쳐서 완전한 URL을 만듭니다. (예: http://{선택된서버주소}/product/112)
  3. 요청 및 응답: 조립된 URL로 실제 HTTP GET 요청을 전송하고, 대상 서버가 처리한 결과값(String)을 반환받습니다.

OrderService.java

• 비즈니스 로직 처리 및 원격 호출 (OrderService.java)
  • Logic (목적): 컨트롤러로부터 전달받은 요청을 분석하고, 외부 서비스(Product)의 데이터가 필요할 경우 FeignClient를 호출하여 데이터를 가져온 뒤 최종 결과를 조립합니다. Hint: 실제 애플리케이션의 핵심 업무(조건 확인, 타 서버 통신, 데이터 가공)는 모두 이 Service 계층에서 이루어집니다.

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

// [Logic 1: 서비스 계층 선언]
// 이 클래스가 핵심 비즈니스 로직을 처리하는 컴포넌트임을 스프링에 알립니다.
@Service 
// [Logic 2: 의존성 자동 주입 (DI)]
// 스프링이 실행될 때, 메모리에 생성된 ProductClient 구현체를 이곳에 자동으로 연결해 줍니다.
@RequiredArgsConstructor 
public class OrderService {

    // 외부 서비스(Product)와 통신하기 위해 정의해둔 FeignClient 인터페이스입니다.
    private final ProductClient productClient;

    // [Logic 3: 외부 통신 메서드 분리]
    // Product 서버와 통신하는 코드를 별도의 메서드로 빼두어 재사용성과 가독성을 높입니다.
    // 이 메서드를 호출하는 순간, 내부적으로 [유레카 주소 검색 -> 로드 밸런싱 -> HTTP 요청]이 발생합니다.
    public String getProductInfo(String productId) {
        return productClient.getProduct(productId);
    }

    // [Logic 4: 핵심 주문 처리 로직]
    // 컨트롤러에서 넘어온 주문 번호(orderId)를 기반으로 시나리오를 수행합니다.
    public String getOrder(String orderId) {
        
        // 조건: 전달받은 주문 번호가 "1"일 때만 정상 프로세스를 진행합니다.
        if(orderId.equals("1")) {
            
            // 1번 주문에 필요한 타겟 상품 번호를 "2"로 설정합니다.
            String productId = "2"; 
            
            // 분리해둔 메서드를 이용해 외부(Product) 서버에서 상품 데이터를 가져옵니다.
            String productInfo = getProductInfo(productId);
            
            // [Logic 5: 최종 응답 데이터 조립]
            // 현재 서버가 가진 데이터(orderId)와 외부 서버에서 응답받은 데이터(productInfo)를 합쳐서 반환합니다.
            return "Your order is " + orderId + " and " + productInfo;
        }
        
        // "1"번 이외의 주문이 들어왔을 때의 예외 처리 메시지입니다.
        return "Not exist order...";
    }
}

application.yml

spring:
  application:
    name: order-service
server:
  port: 19091
eureka:
  client:
    service-url:
      defaultZone: http://localhost:19090/eureka/

 

Run

• 유레카 서버 → order → product(3개 모두) 순으로 실행
• http://localhost:19090/ 으로 접속하면 인스턴스를 확인할 수 있음
• PRODUCT-SERVICE에 포트가 19092,19093,19094 3개가 떠있는 것을 확인할 수 있음

 

확인

• http://localhost:19091/order/1 에 접속할 때마다 텍스트의 포트가 변경되는 것을 볼 수 있음 이를 통해 요청마다 라운드로빈으로 동작함을 확인할 수 있음

 

🎯 [총정리] Spring Cloud 기반 MSA 통신 구현 (Eureka + FeignClient)

• 지금까지 우리는 마이크로서비스 아키텍처(MSA) 환경에서 여러 개의 서비스가 어떻게 서로를 발견하고, 부하를 분산하며 통신하는지 직접 구현해 보았습니다. 전체적인 흐름과 파일별 설계도를 요약하면 다음과 같습니다.

🌟 전체 아키텍처 동작 흐름

1. 서비스 등록 (Eureka Registry): Product 서비스와 Order 서비스는 각각의 환경 설정(application.yml)을 통해 자신들의 이름과 포트 번호를 유레카(Eureka) 서버에 등록합니다.
2. 다중 인스턴스 실행: 트래픽 분산 테스트를 위해 Product 서비스를 인텔리제이의 실행 구성을 활용하여 서로 다른 3개의 포트(19092, 19093, 19094)로 동시에 띄웁니다.
3. 선언적 원격 호출 (Feign Client): Order 서비스 내부에 Product 서비스의 정보를 호출할 수 있는 인터페이스를 만듭니다. 복잡한 통신 코드 없이 어노테이션만으로 원격 호출 준비를 마칩니다.
4. 로드 밸런싱 (Round-Robin): 사용자가 Order 서비스로 주문을 요청하면, Order 서비스는 유레카에서 받아온 Product 인스턴스 목록 중 하나를 선택해 요청을 보냅니다. 이때 라운드 로빈(Round-Robin) 알고리즘이 작동하여 트래픽을 공평하게 분배합니다.
5. 동작 확인: 최종 응답 메시지에 포함된 Product 서버의 포트 번호가 새로고침할 때마다 순차적으로 변경되는 것을 통해, 분산 호출이 정상적으로 이루어지고 있음을 증명합니다.

📂 파일별 핵심 역할 설계도

• 🛒 [Product Service] - 데이터 제공자
  • 요청을 받으면 자신의 포트 번호를 포함한 상품 정보를 반환하는 역할입니다.
    1. application.yml: 내 서비스 이름(product-service)을 지정하고, 실행할 포트와 유레카 서버 주소를 등록하는 호적 파기.
    2. ProductApplication.java: 스프링 부트 애플리케이션 실행.
    3. ProductController.java: 실제 요청을 받아 "나는 OOO번 포트에서 일하는 Product 서버야!"라고 응답을 내려주는 창구.
• 📦 [Order Service] - 데이터 소비자
  • 사용자의 주문을 받고, 필요시 Product 서비스에 통신을 요청하는 역할입니다.
    1. application.yml: 내 서비스 이름(order-service)과 포트(19091)를 설정하고 유레카에 등록.
    2. OrderApplication.java: @EnableFeignClients를 붙여 다른 서비스를 호출할 수 있는 능력을 활성화하는 메인 스위치.
    3. ProductClient.java: 유레카에 product-service로 등록된 서버를 찾아가기 위한 인터페이스 명세서 (리모컨 역할).
    4. OrderService.java: 비즈니스 로직의 핵심. "주문 번호 1번이 들어오면, ProductClient를 통해 2번 상품 정보를 가져와서 조합해라!"라고 지시하는 두뇌.
    5. OrderController.java: 외부 사용자(클라이언트)가 접근할 수 있는 최초의 API 진입점.

✅ 최종 테스트 및 결과

• 모든 서버를 띄운 후 브라우저나 Postman에서 http://localhost:19091/order/1을 여러 번 호출해 봅니다. 결과 문자열 끝에 찍히는 포트 번호(19092 → 19093 → 19094)가 계속 바뀐다면, 유레카를 통한 서비스 디스커버리와 클라이언트 사이드 로드 밸런싱이 완벽하게 성공한 것입니다! 🚀

 

🗨️ 서킷브레이커

서킷 브레이커 개요

서킷 브레이커란?

• 서킷 브레이커는 마이크로서비스 간의 호출 실패를 감지하고 시스템의 전체적인 안정성을 유지하는 패턴
• 외부 서비스 호출 실패 시 빠른 실패를 통해 장애를 격리하고, 시스템의 다른 부분에 영향을 주지 않도록 합니다.
• 상태 변화: 클로즈드 -> 오픈 -> 하프-오픈

 

Resilience4j 개요

Resilience4j란?

• Resilience4j는 서킷 브레이커 라이브러리로, 서비스 간의 호출 실패를 감지하고 시스템의 안정성을 유지합니다.
• 다양한 서킷 브레이커 기능을 제공하며, 장애 격리 및 빠른 실패를 통해 복원력을 높입니다.

Resilience4j의 주요 특징

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

 

Resilience4j 설정

기본 설정

💡 resilience4j 의존성은 spring starter에서 추가하여 사용하지 않을 것입니다.
”io.github.resilience4j:resilience4j-spring-boot3:2.2.0” 를 사용합니다. ”boot3” 임을 주의하세요.

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

build.gradle 파일 예시:

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

Resilience4j 설정 파일

• Resilience4j의 설정은 application.yml 파일에서 설정할 수 있습니다.

예시 설정 파일:

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 설정

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

예시 코드:

@Service
public class MyService {

    /**
     * @CircuitBreaker: 외부 호출 장애 시 시스템을 보호하는 차단기 역할을 합니다.
     * - name: 설정 파일(yml)에서 정의한 서킷 브레이커의 식별자입니다.
     * - fallbackMethod: 장애 발생(에러, 타임아웃 등) 시 호출할 대체 메서드입니다.
     */
    @CircuitBreaker(name = "myService", fallbackMethod = "fallbackMethod")
    public String myMethod() {
        // 외부 서비스 호출 로직 (장애가 발생할 수 있는 지점)
        return externalService.call();
    }

    /**
     * Fallback 메서드: 원본 메서드 실패 시 실행되는 대체 로직입니다.
     * - 원본 메서드와 반환 타입이 반드시 일치해야 합니다. (String)
     * - 파라미터 마지막에 Throwable(예외 객체)을 포함해야 에러 내용을 확인할 수 있습니다.
     */
    public String fallbackMethod(Throwable t) {
        // 에러 발생 시 사용자에게 반환할 안전한 기본값이나 메시지
        return "Fallback response";
    }
}

 

Fallback의 장점

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

 

Resilience4j Dashboard

Resilience4j Dashboard 설정

• Resilience4j Dashboard를 사용하여 서킷 브레이커의 상태를 모니터링할 수 있습니다.

build.gradle 파일 예시:

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 에 접속하여 서킷브레이커 항목을 확인 가능합니다.

 

Resilience4j Dashboard 사용

• Prometheus와 Grafana를 사용하여 Resilience4j 서킷 브레이커의 상태를 실시간으로 모니터링할 수 있습니다.
• Prometheus를 통해 수집된 메트릭을 Grafana 대시보드에서 시각화할 수 있습니다.

 

Resilience4j와 Spring Cloud 연동

Spring Cloud와의 통합

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

spring:
  application:
    name: my-service
  cloud:
    circuitbreaker:
      resilience4j:
        enabled: true

 

실습

💡 이번 실습에서 유레카는 사용하지 않겠습니다. 프로젝트에서는 상품을 조회하는 것을 가정하겠습니다. 상품 아이디 111을 호출하면 에러를 발생시켜 fallbackMethod를 실행하는 것을 확인합니다. 또한 이벤트리스너를 사용하여 서킷브레이커의 상태를 조회해 보겠습니다.

 

프로젝트 생성 및 코드 작성

• start.spring.io 에 접속하여 프로젝트를 생성합니다. (디펜던시는 이미지 참고)
  • ❗ 주의: starter에서 resilience4j 디펜던시를 추가하지 않습니다. starter에서 추가하면 “org.springframework.cloud:spring-cloud-starter-circuitbreaker-resilience4j”가 추가됩니다. 이는 추상화 계층을 통해 Resilience4j를 사용하는데 우리는 직접 resilience4j를 사용하기 위해 build.gradle에 “io.github.resilience4j:resilience4j-spring-boot3:2.2.0”를 추가하겠습니다.

build.gradle의 dependencies에 다음을 추가합니다. (아래 코드는 완성코드입니다.)

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()
}

java/com/spring_cloud/resilience4j/sample/products/Product.java

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

@Data
@AllArgsConstructor
@NoArgsConstructor
public class Product {

    private String id;
    private String title;

}

java/com/spring_cloud/resilience4j/sample/products/ProductController.java

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("id") String id) {
        return productService.getProductDetails(id);
    }
}

java/com/spring_cloud/resilience4j/sample/products/ProductService.java

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: 서비스가 실행되자마자 이벤트를 감시하도록 등록
    @PostConstruct
    public void registerEventListener() {
    	// "productService"라는 이름의 서킷 브레이커 상태 변화를 실시간으로 로그에 남깁니다.
        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: 장애 시 fallbackMethod가 실행되도록 설정
    @CircuitBreaker(name = "productService", fallbackMethod = "fallbackGetProductDetails")
    public Product getProductDetails(String productId) {
        log.info("###Fetching product details for productId: {}", productId);
        
        // 특정 아이디(111) 호출 시 억지로 에러를 발생시켜 서킷 브레이커 테스트
        if ("111".equals(productId)) {
            log.warn("###Received empty body for productId: {}", productId);
            throw new RuntimeException("Empty response body");
        }
        return new Product(
            productId,
            "Sample Product"
        );
    }

    // Fallback 메서드: 에러가 나거나 서킷이 열려있을 때 대신 실행됨
    // 규칙: 원래 메서드와 리턴 타입(Product)이 같아야 하며, 마지막에 Throwable을 받아야 함
    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: ...           |
    // +------------------------------------------+-------------------------------------------+-----------------------------------------------------------------+


   
}

resources/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

 

Run

• http://localhost:19090/products/11를 3번 호출합니다.
• http://localhost:19090/products/111을 여러 번 호출하면서 서킷브레이커의 상태가 변경되는 것을 확인합니다.
• 또한 서킷브레이커가 Open 상태가 되면 getProductDetails 함수를 타지않고 바로 fallbackGetProductDetails 로 호출되는 것을 확인할 수 있습니다.

 

프로메테우스 데이터 전달

• http://localhost:19090/actuator/prometheus로 접속하면 인스턴스의 상태 값들이 나옵니다.
• 아래로 내려가다보면 서킷브레이커 관련 내용을 확인할 수 있습니다. 이를 통해 프로메테우스에서 서킷브레이커의 정보를 수집할 수 있습니다.
  • 📊 프로메테우스(Prometheus): 서버의 실시간 상태 정보(메트릭)를 주기적으로 수집하고 저장하여, 시스템에 문제가 없는지 한눈에 파악할 수 있게 도와주는 오픈소스 모니터링 시스템입니다.

 

🗨️ Api GW

게이트웨이 개요

API 게이트웨이란?

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

API 게이트웨이의 주요 기능

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

 

Spring Cloud Gateway 개요

Spring Cloud Gateway란?

• Spring Cloud Gateway는 Spring 프로젝트의 일환으로 개발된 API 게이트웨이로, 클라이언트 요청을 적절한 서비스로 라우팅하고 다양한 필터링 기능을 제공합니다.
• Spring Cloud Netflix 패키지의 일부로, 마이크로서비스 아키텍처에서 널리 사용됩니다.

Spring Cloud Gateway의 주요 특징

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

 

Spring Cloud Gateway 설정

기본 설정

• Spring Cloud Gateway를 사용하려면 Spring Boot 애플리케이션에 의존성을 추가해야 합니다.

build.gradle 파일 예시:

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'라는 이름으로 로드 밸런싱된 서비스로 라우팅
          predicates:
            - Path=/users/** # /users/** 경로로 들어오는 요청을 이 라우트로 처리
        - id: orders-service  # 라우트 식별자
          uri: lb://orders-service  # 'orders-service'라는 이름으로 로드 밸런싱된 서비스로 라우팅
          predicates:
            - Path=/orders/** #/orders/** 경로로 들어오는 요청을 이 라우트로 처리

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

 

Spring Cloud Gateway 필터링

필터 종류

• Global Filter: 모든 요청에 대해 작동하는 필터
• Gateway Filter: 특정 라우트에만 적용되는 필터
  • 특정 라우트 설정(yml)에 명시적으로 등록된 특정 서비스 요청에만 선별적으로 적용되는 필터입니다.  
  • 라우트 (Route): 유입된 요청의 목적지 주소(URI)와 조건(Predicate)을 정의하여 특정 서비스로 연결해 주는 경로 매핑 규칙입니다.

필터 구현

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

 

필터 주요 객체

• Mono
  • Mono는 리액티브 프로그래밍에서 0 또는 1개의 데이터를 비동기적으로 처리합니다.
    1. 비동기 작업이 끝났을 때 '결과값 1개를 반환'하거나, 혹은 데이터 없이 '작업 완료 신호'만 보낼 때 사용하는 비동기 전용 리턴 객체입니다.
    2. 리액티브 프로그래밍 (Reactive Programming): 특정 작업이 완료될 때까지 기다리지 않고(Non-blocking), 데이터가 발생하거나 변화할 때마다 즉각적으로 반응하여 처리하는 방식입니다.
  • Mono<Void>는 아무 데이터도 반환하지 않음을 의미합니다.
• ServerWebExchange
  • ServerWebExchange는 HTTP 요청과 응답을 캡슐화한 객체입니다.
  • exchange.getRequest()로 HTTP 요청을 가져옵니다.
  • exchange.getResponse()로 HTTP 응답을 가져옵니다.
• GatewayFilterChain
  • GatewayFilterChain은 여러 필터를 체인처럼 연결합니다.
  • chain.filter(exchange)는 다음 필터로 요청을 전달합니다.

 

필터 시점별 종류

Pre 필터

• Pre 필터는 요청이 처리되기 전에 실행됩니다. 따라서 Pre 필터에서는 요청을 가로채고 필요한 작업을 수행한 다음, 체인의 다음 필터로 요청을 전달합니다. 이때, 추가적인 비동기 작업을 수행할 필요가 없기 때문에 then 메서드를 사용할 필요가 없습니다.

@Component
public class PreFilter implements GlobalFilter, Ordered {

    /**
     * filter: 모든 라우트 요청 시 실행되는 필터 로직입니다.
     * @param exchange: 현재 요청의 HTTP Request 및 Response를 담고 있는 통합 객체
     * @param chain: 필터 체인 객체로, 현재 필터 처리가 끝난 뒤 다음 필터로 제어권을 넘깁니다.
     * @return Mono<Void>: 비동기 작업의 완료 신호를 반환합니다.
     */
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // [Logic] 현재 요청의 URI 경로를 추출하여 콘솔에 로깅
        System.out.println("Request Path: " + exchange.getRequest().getPath());

        // [Chain] 다음 필터로 요청을 전달 (비동기 처리 체인 연결)
        return chain.filter(exchange);
    }

    /**
     * getOrder: 여러 필터 간의 실행 순서를 결정합니다.
     * - 반환 값이 낮을수록 우선순위가 높습니다. (음수 가능)
     * - 여기서는 -1로 설정하여 가장 먼저 실행되도록 지정했습니다.
     */
    @Override
    public int getOrder() {
        return -1;
    }
}

• ServerWebExchange: 스프링 리액티브 환경(WebFlux)에서 HTTP 요청(Request)과 응답(Response)을 하나로 묶어 관리하는 컨텍스트 객체입니다.
• GatewayFilterChain: 여러 필터가 순차적으로 연결된 구조입니다. chain.filter(exchange)를 호출해야만 멈추지 않고 다음 필터로 요청이 넘어갑니다.
• Ordered: 필터의 실행 순서를 제어합니다. 전역 필터가 여러 개일 때, 보안이나 로깅처럼 먼저 실행되어야 하는 작업에 낮은 숫자(예: -1)를 부여합니다.

 

Post 필터

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

@Component
public class PostFilter implements GlobalFilter, Ordered {

    /**
     * filter: 요청이 하위 서비스로 전달된 후, 응답이 돌아올 때 실행됩니다.
     * @param exchange: 요청/응답 컨텍스트 객체
     * @param chain: 필터 체인 제어 객체
     */
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // [Logic] chain.filter(exchange)가 완료된 후(.then) 실행할 로직을 정의합니다.
        // 이 구조 덕분에 "요청 -> 하위 서비스 호출 -> 응답" 과정 이후에 필터가 동작합니다.
        return chain.filter(exchange).then(Mono.fromRunnable(() -> {
            
            // [Post Logic] 응답 상태 코드를 추출하여 로그로 출력
            System.out.println("Response Status: " + exchange.getResponse().getStatusCode());
            
        }));
    }

    /**
     * getOrder: 필터의 실행 순서를 결정합니다.
     * Pre Filter 단계에서는 우선순위가 높을수록 먼저 실행되지만, 
     * Post Filter 단계(then 이후)에서는 우선순위가 높을수록 가장 나중에 실행됩니다.
     */
    @Override
    public int getOrder() {
        return -1;
    }
}

• .then(...): 리액티브 프로그래밍에서 앞선 작업(chain.filter)이 성공적으로 완료된 직후에 실행할 후속 작업을 지정하는 연산자입니다. 이 부분에 작성된 코드가 바로 Post Filter 역할을 하게 됩니다.
• Mono.fromRunnable(() -> { ... }): 리턴할 데이터는 없지만, 특정 로직(로그 출력 등)을 비동기 흐름 안에서 실행시키고 싶을 때 사용하는 객체 생성 방식입니다.
• exchange.getResponse(): 요청이 아닌, 최종적으로 가공되어 사용자에게 나갈 응답 객체에 접근하여 상태 코드나 헤더 정보를 읽어올 때 사용합니다.

 

 

Spring Cloud와의 통합

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

 

Zuul(Spring Boot 2)

• 대부분의 회사에서 이미 만들어진 시스템은 스프링 부트 2를 사용하고 있을 가능성이 큽니다. 따라서 Zuul을 알고 가는 것이 좋을것 같습니다. 코드 보다는 기능에 집중하세요. ”클라우드 게이트웨이와 같은 기능을 제공하고 있구나” 라고 생각하고 넘어가면 됩니다.

Zuul 설정

• Spring Boot 2에서는 Zuul을 사용하여 API 게이트웨이를 설정할 수 있습니다.

build.gradle 파일 예시:

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

Spring Boot 애플리케이션 설정:

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

라우팅 설정

• application.yml 파일에서 라우팅 설정을 정의할 수 있습니다.

예시 설정 파일:

zuul:
  routes:
    users-service:
      path: /users/**
      serviceId: users-service
    orders-service:
      path: /orders/**
      serviceId: orders-service

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

 

필터 설정

• Zuul 필터를 사용하여 요청 전후에 다양한 작업을 수행할 수 있습니다.

예시 코드:

@Component
public class PreFilter extends ZuulFilter {

    @Override
    public String filterType() {
        return "pre";
    }

    @Override
    public int filterOrder() {
        return 1;
    }

    @Override
    public boolean shouldFilter() {
        return true;
    }

    @Override
    public Object run() throws ZuulException {
        RequestContext ctx = RequestContext.getCurrentContext();
        HttpServletRequest request = ctx.getRequest();
        // 요청 로깅
        System.out.println(String.format("%s request to %s", request.getMethod(), request.getRequestURL().toString()));
        return null;
    }
}

 

실습

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

 

🏗️ 전체 시스템 구조

1. Eureka Server (19090): 모든 서비스(Order, Product, Gateway)의 주소를 관리하는 전화번호부 역할을 합니다.
2. Order Service (19092): /order 요청을 처리하는 실제 서비스입니다.
3. Product Service (19093, 19094): /product 요청을 처리하며, 포트가 두 개라 게이트웨이가 로드밸런싱(분산 처리)을 수행합니다.
4. Gateway (19091): 모든 요청이 통과하는 단일 진입점이며, 필터를 통해 요청/응답을 검사합니다.

 

Eureka 및 Order, Product

• “로드밸런싱” 실습에서의 유레카 서버와 Order, Product를 그대로 복사하여 가져옵니다.

주문 애플리케이션

build.gradle

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-actuator'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
	compileOnly 'org.projectlombok:lombok'
	annotationProcessor 'org.projectlombok:lombok'
	providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

OrderContorller.java

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/order")
public class OrderController {

    @GetMapping
    public String getOrder() {
        return "Order details";
    }
}

application.yml

server:
  port: 19092

spring:
  application:
    name: order-service

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

 

상품 애플리케이션

build.gradle

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-actuator'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
	compileOnly 'org.projectlombok:lombok'
	annotationProcessor 'org.projectlombok:lombok'
	providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

ProductContorller.java

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

@RestController
public class ProductController {

    @Value("${server.port}") // 애플리케이션이 실행 중인 포트를 주입받습니다.
    private String serverPort;

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

application.yml

server:
  port: 19093

spring:
  application:
    name: product-service

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

• 상품 어플리케이션은 로드 밸런싱 확인을 위해 2개의 포트(19093.19094)에 실행하겠습니다.

 

[추가정보] 사용중인 포트 정지시키기

윈도우

• CMD 창을 열고 아래의 명령어를 입력합니다. 뒤에 숫자는 정지시키고자 하는 포트입니다.

netstat -a -o | findstr 19093

• 그러면 아래와 같이 해당 포트의 프로세스 리스트가 나옵니다. 리스트의 마지막이 PID 이며 이 아이드를 통해 포트를 사용하는 프로세스를 정지할 수 있습니다.

TCP     0.0.0.0:19093    0.0.0.0:0   LISTENING   2340

• 명령어를 통해 프로세스를 정지합니다. 정지 명령어의 숫자는 위에서 조회한 PID 입니다.

taskkill /f /pid 2340

 

게이트 웨이

• start.spring.io 에서 아래와 같은 디펜던시를 추가 후 프로젝트를 생성합니다.

 

📑 핵심 코드 요약

• GlobalFilter: 어떤 서비스로 가든 무조건 거쳐야 하는 필터임을 정의합니다.
• Ordered: 필터들이 여러 개일 때 실행될 순서를 숫자로 결정합니다. (작은 숫자가 먼저 실행)
• lb:// (Load Balancer): 유레카에 등록된 서비스 이름을 찾아 자동으로 트래픽을 분산하는 문법입니다.
• then(): 비동기 환경에서 "서비스를 갔다 온 다음에 실행해라"라고 시점을 지정하는 핵심 연산자입니다.

[게이트웨이 입장 -> 로그 기록 -> 유레카 주소 조회 -> 실제 서비스 호출 -> 돌아오면서 로그 기록 -> 응답 완료]의 과정을 구현한 것입니다.

 

CustomPreFilter.java

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());

    /**
     * filter: 게이트웨이로 들어온 모든 요청에 대해 실행되는 로직입니다.
     * @param exchange: HTTP 요청(Request)과 응답(Response)을 포함하는 웹 컨텍스트
     * @param chain: 다음 필터로 요청을 넘겨주는 필터 체인 제어 객체
     */
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // [Logic] 현재 요청(Request) 객체를 추출
        ServerHttpRequest request = exchange.getRequest();
        
        // [Logging] 요청의 목적지 URI를 로그로 남김 (Pre-Processing)
        logger.info("Pre Filter: Request URI is " + request.getURI());

        // [Chain] 다음 필터로 제어권을 넘김 (비동기 논블로킹 처리)
        return chain.filter(exchange);
    }

    /**
     * getOrder: 필터의 우선순위를 결정합니다.
     * - Ordered.HIGHEST_PRECEDENCE: 가장 낮은 정수값(Integer.MIN_VALUE)을 반환하여 
     * 전체 필터 체인 중 가장 먼저 실행되도록 보장합니다.
     */
    @Override
    public int getOrder() {
        return Ordered.HIGHEST_PRECEDENCE;
    }
}

• 📑 핵심 객체 및 설정 명세
  • ServerHttpRequest: 사용자가 보낸 HTTP 요청 정보(URI, Header, Method 등)에 접근할 수 있는 객체입니다.
  • Ordered.HIGHEST_PRECEDENCE: 필터 순서를 숫자로 일일이 지정하는 대신, 프레임워크가 제공하는 최우선순위 상숫값을 사용하여 가독성을 높였습니다.
  • 비동기 처리: 리턴 타입인 Mono<Void>는 해당 필터의 로직이 끝났음을 비동기적으로 알리고 다음 필터(chain.filter)를 실행하도록 연결합니다.
• ✅ 요약
  • 목적: 유레카에 등록된 Order/Product 서비스로 요청이 전달되기 전, 모든 요청의 URI를 감시하고 로깅합니다.
  • 순서: HIGHEST_PRECEDENCE를 통해 게이트웨이 내부의 수많은 필터 중 가장 먼저 실행됩니다.
  • 확장성: 이 필터 내부에 특정 헤더 검증이나 토큰 유효성 검사 로직을 추가하여 공통 보안 필터로 확장할 수 있습니다.

CustomPostFilter.java

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

import java.util.logging.Logger;

@Component
public class CustomPostFilter implements GlobalFilter, Ordered {

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

    /**
     * filter: 하위 서비스로부터 응답이 돌아온 후 실행되는 로직입니다.
     * @param exchange: 요청과 응답을 포함하는 컨텍스트 객체
     * @param chain: 필터 체인 제어 객체
     */
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, org.springframework.cloud.gateway.filter.GatewayFilterChain chain) {
        // [Logic] chain.filter(exchange)가 완료된 후(.then) 실행할 작업을 정의합니다.
        // 비동기 흐름상 '응답' 단계에서만 동작하도록 보장합니다.
        return chain.filter(exchange).then(Mono.fromRunnable(() -> {
            
            // [Response Status] 최종 응답 객체에서 HTTP 상태 코드를 가져옵니다.
            ServerHttpResponse response = exchange.getResponse();
            
            // [Logging] 응답 상태 코드를 로그로 남깁니다. (Post-Processing)
            logger.info("Post Filter: Response status code is " + response.getStatusCode());
            
        }));
    }

    /**
     * getOrder: 필터의 우선순위를 결정합니다.
     * - Ordered.LOWEST_PRECEDENCE: 가장 높은 정수값(Integer.MAX_VALUE)을 반환하여
     * 전체 필터 체인 중 가장 낮은 우선순위를 가집니다. (가장 나중에 실행)
     */
    @Override
    public int getOrder() {
        return Ordered.LOWEST_PRECEDENCE;
    }
}

• 📑 핵심 문법 및 동작 명세
  • .then(Mono.fromRunnable(...)): 리액티브 프로그래밍의 핵심 연산자로, 하위 서비스(Order, Product 등)의 처리가 완전히 끝난 시점에 특정 로직을 실행시키기 위해 사용합니다.
  • ServerHttpResponse: 요청이 아닌, 최종적으로 가공되어 사용자에게 나갈 응답 정보(Status Code, Headers 등)를 담고 있는 객체입니다.
  • Ordered.LOWEST_PRECEDENCE: 이 필터를 체인의 가장 끝에 배치합니다. 모든 서비스 로직과 다른 필터들의 처리가 끝난 후 최종적으로 응답 상태를 확인하기에 적합한 설정입니다.
• ✅ 요약
  1. 동작 시점: 서비스의 응답이 게이트웨이에 도착하여 클라이언트에게 전송되기 직전에 실행됩니다.
  2. 구현 특징: then 메서드를 통해 비동기 처리의 '완료 이후' 시점을 잡는 것이 핵심입니다.
  3. 실습 의미: 이 필터까지 통과해야 사용자는 최종적으로 Product나 Order의 데이터를 받아보게 됩니다.

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을 지정

 

⚙️ Gateway YAML 핵심 설정 요약

 

1. routes (라우팅 규칙)

• id: 해당 라우팅 규칙의 고유 식별자입니다. 관리용 이름이라고 보시면 됩니다.
• predicates (조건): "어떤 요청이 들어왔을 때 이 규칙을 적용할 것인가?"를 정의합니다.
  • - Path=/order/**: 접속한 URL이 /order/로 시작하면 이 라우트(Order 서비스)로 보내겠다는 매칭 조건입니다.

2. uri: lb:// (로드밸런싱 및 목적지)

• lb:// (Load Balancer): 가장 중요한 부분입니다. 목적지 주소를 http://192.168... 처럼 고정 IP로 적지 않고, 서비스 이름으로 적습니다.
• 작동 원리: 게이트웨이가 유레카(Eureka) 서버에 물어보고, 해당 이름을 가진 인스턴스(예: Product 1, Product 2) 중 하나를 골라 요청을 분산해서 보냅니다.

3. discovery.locator.enabled: true

• 유레카 서버에 등록된 서비스들의 목록을 게이트웨이가 실시간으로 감시하며, 새로운 서비스가 추가될 때마다 동적으로 경로를 찾아낼 수 있게 허용하는 설정입니다.

4. eureka.client.service-url.defaultZone

• 게이트웨이가 서비스들의 실제 주소 정보를 가져올 유레카 서버의 위치를 지정합니다. 이 설정이 있어야 게이트웨이가 유레카라는 '전화번호부'를 읽을 수 있습니다.

📑 한 줄 핵심 요약

• "게이트웨이는 predicates 조건에 맞는 요청이 오면, 유레카에서 lb:// 뒤에 적힌 서비스 이름을 찾아 해당 주소로 요청을 토스한다."

 

🔄 요청 처리 흐름 (Step-by-Step)

• 사용자가 http://localhost:19091/product로 요청을 보냈을 때의 동작 순서입니다.

1단계: Gateway 진입 및 사전 필터 실행

• 가장 우선순위가 높은 CustomPreFilter가 실행됩니다.
• 코드의 exchange.getRequest().getURI() 로직을 통해 "어떤 주소로 요청이 왔는지" 로그를 남깁니다.
• chain.filter(exchange)를 호출하여 다음 단계로 바통을 넘깁니다.

2단계: 라우팅 및 로드밸런싱 (YML 설정 기준)

• application.yml의 predicates 설정에 따라 /product/** 경로임을 확인합니다.
• uri: lb://product-service 설정을 보고 유레카에게 "Product 서비스 주소 하나 줘"라고 요청합니다.
• 유레카로부터 19093 또는 19094 포트를 받아 해당 인스턴스로 요청을 전달합니다.

3단계: 실제 서비스(Microservice) 실행

• Product 서비스의 컨트롤러가 실행되어 "Product info!!!!! From port : 1909x" 문자열을 생성하여 반환합니다.

4단계: 사후 필터 실행 (복귀 길)

• 응답이 게이트웨이로 돌아오면, 아까 예약해둔 CustomPostFilter의 .then() 내부 로직이 실행됩니다.
• exchange.getResponse().getStatusCode()를 통해 서비스가 정상적으로 응답했는지(200 OK 등) 로그를 남깁니다.

5단계: 최종 응답

• 게이트웨이가 사용자에게 최종 결과물을 전달하며 통신이 종료됩니다.

 

Run

• 유레카 서버 ⇒ 게이트웨이 ⇒ 주문 ⇒ 상품 순으로 어플리케이션을 실행합니다.
• http://localhost:19090에 접속하여 각 인스턴스를 확인합니다.
• http://localhost:19091/order 로 접속하여 게이트웨이에서 order 서비스를 호출하는 것을 확인할 수 있습니다.

• http://localhost:19091/product 를 여러번 호출 하면서 포트가 달라지는 것을 확인합니다. 이를 통해 로드밸런싱이 동작함을 확인합니다.

• 게이트웨이의 로그를 보면 호출 할때마다 필터가 동작하는것을 확인 할 수 있습니다.

 

🗨️ 보안구성

보안 개요

보안의 중요성

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

 

OAuth2 개요

OAuth2란?

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

OAuth2의 주요 개념

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

 

JWT 개요

JWT란?

• JWT(JSON Web Token)는 JSON 형식의 자가 포함된 토큰으로, 클레임(claim)을 포함하여 사용자에 대한 정보를 전달합니다.
• JWT는 세 부분으로 구성됩니다: 헤더, 페이로드, 서명
• JWT는 암호화를 통해 데이터의 무결성과 출처를 보장합니다.
• https://jwt.io/

JWT의 주요 특징

• 자가 포함: 토큰 자체에 모든 정보를 포함하고 있어 별도의 상태 저장이 필요 없습니다.
• 간결성: 짧고 간결한 문자열로, URL, 헤더 등에 쉽게 포함될 수 있습니다.
• 서명 및 암호화: 데이터의 무결성과 인증을 보장합니다.

 

실습

• ❗ 이번 강의에서는 실습을 통해 클라우드 게이트웨이의 Pre 필터에서 JWT 인증을 진행해봅니다. 우선 “스프링 클라우드 게이트웨이”에서 학습한 모든 프로젝트를 복사하여 사용하겠습니다.
• 여기에 Auth Service 를 생성하여 로그인 기능을 아주 간단하게 구현하겠습니다. 클라우드 게이트웨이에 Pre 필터를 하나 더 생성하여 로그인을 체크 하겠습니다.
• 아래 이미지의 점선만 실행하여 확인하겠습니다.
• PostMan 또는 크롬 익스텐션 중 Talend API Tester를 설치합니다. 강의에서는 Talend를 사용하겠습니다.
  • PostMan : https://www.postman.com/
  • Talend : https://chromewebstore.google.com/detail/talend-api-tester-free-ed/aejoelaoggembcahagimdiliamlcdmfm?hl=ko

 

Auth Service

• 로그인을 담당하는 서비스 어플리케이션을 생성합니다. 로그인을 진행하면 토큰을 발급받고 이 토큰을 사용하여 Gateway를 호출 합니다.

start.spring.io 를 사용하여 프로젝트를 생성합니다.

build.gradle 파일의 디펜던시를 아래와 같이 수정합니다. ( jwt 추가 )

dependencies {
	implementation 'io.jsonwebtoken:jjwt:0.12.6'
	implementation 'org.springframework.boot:spring-boot-starter-actuator'
	implementation 'org.springframework.boot:spring-boot-starter-security'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
	compileOnly 'org.projectlombok:lombok'
	annotationProcessor 'org.projectlombok:lombok'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testImplementation 'org.springframework.security:spring-security-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
	testImplementation 'io.projectreactor:reactor-test'
	
}

application.yml

spring:
  application:
    name: auth-service

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

service:
  jwt:
    access-expiration: 3600000
    secret-key: "401b09eab3c013d4ca54922bb802bec8fd5318192b0a75f201d8b3727429080fb337591abd3e44453b954555b7a0812e1081c39b740293f765eae731f5a65ed1"

server:
  port: 19095

AuthConfig.java

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())
            // 요청에 대한 접근 권한을 설정합니다.
            .authorizeRequests(authorize -> authorize
                // /auth/signIn 경로에 대한 접근을 허용합니다. 이 경로는 인증 없이 접근할 수 있습니다.
                .requestMatchers("/auth/signIn").permitAll()
                // 그 외의 모든 요청은 인증이 필요합니다.
                .anyRequest().authenticated()
            )
            // 세션 관리 정책을 정의합니다. 여기서는 세션을 사용하지 않도록 STATELESS로 설정합니다.
            .sessionManagement(session -> session
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            );

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

AuthService.java

import io.jsonwebtoken.Jwts;
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;

    /**
     * AuthService 생성자.
     * Base64 URL 인코딩된 비밀 키를 디코딩하여 HMAC-SHA 알고리즘에 적합한 SecretKey 객체를 생성합니다.
     *
     * @param secretKey Base64 URL 인코딩된 비밀 키
     */
    public AuthService(@Value("${service.jwt.secret-key}") String secretKey) {
        this.secretKey = Keys.hmacShaKeyFor(Decoders.BASE64URL.decode(secretKey));
    }

    /**
     * 사용자 ID를 받아 JWT 액세스 토큰을 생성합니다.
     *
     * @param user_id 사용자 ID
     * @return 생성된 JWT 액세스 토큰
     */
    public String createAccessToken(String user_id) {
        return Jwts.builder()
                // 사용자 ID를 클레임으로 설정
                .claim("user_id", user_id)
                .claim("role", "ADMIN")
                // JWT 발행자를 설정
                .issuer(issuer)
                // JWT 발행 시간을 현재 시간으로 설정
                .issuedAt(new Date(System.currentTimeMillis()))
                // JWT 만료 시간을 설정
                .expiration(new Date(System.currentTimeMillis() + accessExpiration))
                // SecretKey를 사용하여 HMAC-SHA512 알고리즘으로 서명
                .signWith(secretKey, io.jsonwebtoken.SignatureAlgorithm.HS512)
                // JWT 문자열로 컴팩트하게 변환
                .compact();
    }
}

AuthController.java

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;

    /**
     * 사용자 ID를 받아 JWT 액세스 토큰을 생성하여 응답합니다.
     *
     * @param user_id 사용자 ID
     * @return JWT 액세스 토큰을 포함한 AuthResponse 객체를 반환합니다.
     */
    @GetMapping("/auth/signIn")
    public ResponseEntity<?> createAuthenticationToken(@RequestParam String user_id){
        return ResponseEntity.ok(new AuthResponse(authService.createAccessToken(user_id)));
    }

    /**
     * JWT 액세스 토큰을 포함하는 응답 객체입니다.
     */
    @Data
    @AllArgsConstructor
    @NoArgsConstructor
    static class AuthResponse {
        private String access_token;

    }
}

 

Cloud Gateway

• 기존 게이트웨이 코드에 JWT인증 및 auth-service 라우팅 정보를 추가합니다.

build.gradle 파일에 필요한 의존성을 추가합니다. ( jwt 추가 )

dependencies {
	implementation 'io.jsonwebtoken:jjwt:0.12.6'
	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'
	compileOnly 'org.projectlombok:lombok'
	annotationProcessor 'org.projectlombok:lombok'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testImplementation 'io.projectreactor:reactor-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

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/** 경로로 들어오는 요청을 이 라우트로 처리
        - 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:
    secret-key: "401b09eab3c013d4ca54922bb802bec8fd5318192b0a75f201d8b3727429080fb337591abd3e44453b954555b7a0812e1081c39b740293f765eae731f5a65ed1"

LocalJwtAuthenticationFilter.java

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;

@Slf4j
@Component
public class LocalJwtAuthenticationFilter implements GlobalFilter {

    @Value("${service.jwt.secret-key}")
    private String secretKey; // 설정 파일(yml)에서 가져온 암호화 키

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 1. 접속한 경로(Path) 추출
        String path = exchange.getRequest().getURI().getPath();

        // 2. 화이트리스트 처리: 로그인 경로는 토큰 검사 없이 통과시킴
        if (path.equals("/auth/signIn")) {
            return chain.filter(exchange); 
        }

        // 3. 헤더에서 토큰 추출
        String token = extractToken(exchange);

        // 4. 토큰이 없거나 유효하지 않으면 401(Unauthorized) 에러 반환
        if (token == null || !validateToken(token)) {
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete(); // 여기서 요청 중단
        }

        // 5. 검증 성공 시 다음 필터로 이동
        return chain.filter(exchange);
    }

    // [토큰 추출 메서드]
    private String extractToken(ServerWebExchange exchange) {
        // Authorization 헤더에서 "Bearer "로 시작하는 문자열을 찾음
        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 {
            // 암호화 키 생성 및 토큰 해석(Parsing)
            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; // 위조되었거나 만료된 토큰인 경우 에러 발생 -> false 반환
        }
    }
}

• ServerWebExchange와 Path 추출
  • ServerWebExchange exchange: HTTP 요청(Request)과 응답(Response) 정보를 모두 담고 있는 통합 바구니입니다. 게이트웨이는 비동기 방식(WebFlux)을 쓰기 때문에 기존의 HttpServletRequest 대신 이걸 사용합니다.
  • exchange.getRequest().getURI().getPath():
    1. getRequest(): 바구니에서 요청 정보를 꺼냅니다.
    2. getURI(): 요청된 전체 주소 정보(예: http://localhost:19091/auth/signIn)를 가져옵니다.
    3. getPath(): 그중에서 호스트와 포트를 제외한 순수 경로인 /auth/signIn만 문자열로 뽑아냅니다. 필터에서 "어떤 서비스로 가려는 요청인가?"를 판단하는 기준이 됩니다.
• extractToken (Bearer 토큰 처리)
  • HTTP 표준 규약상 JWT 토큰은 헤더에 Authorization: Bearer <토큰값> 형태로 보냅니다.
  • substring(7)을 하는 이유는 앞의 Bearer (총 7자)를 떼어내고 순수한 토큰 데이터만 얻기 위해서입니다.
• validateToken (JWT 검증 원리)
  • SecretKey: 서버가 토큰을 만들 때 썼던 비밀번호입니다. 이 키가 있어야만 토큰이 위조되지 않았는지 확인할 수 있습니다.
  • parseSignedClaims(token): 암호화된 토큰을 풀어서 내용을 확인하는 과정입니다. 만약 토큰 유통기한이 지났거나 누군가 내용을 수정했다면 여기서 바로 예외(Exception)가 발생하여 false를 반환하게 됩니다.

 

RUN

유레카 서버 ⇒ 게이트웨이⇒ 인증 ⇒ 상품 순으로 어플리케이션을 실행합니다.

• http://localhost:19090에 접속하여 각 인스턴스를 확인합니다.
• 게이트웨이에서 상품을 요청해 봅니다. 401 에러가 발생하는 것을 볼 수 있습니다.
• 게이트웨이에서 로그인을 요청하여 토큰을 발급받아봅니다.
• 해당 토큰을 상품요청에 헤더에 넣어서 요청합니다. 이미지를 확인해주세요.
  • 해당 토큰을 상품요청에 헤더에 넣어서 요청합니다.
  • 요청을 통해 정상적으로 응답이 오는 것을 볼 수 있습니다.

Bearer 란?

• Bearer는 OAuth 2.0 프로토콜에서 사용하는 인증 토큰 유형 중 하나로, 액세스 토큰을 통해 보호된 리소스에 접근할 수 있도록 합니다. Bearer 토큰은 요청 헤더에 포함되어 서버에 전달되며, 서버는 이를 검증하여 요청이 유효한지 확인합니다.
• 간단한 사용법: 클라이언트는 서버에서 받은 Bearer 토큰을 HTTP 요청 헤더에 포함시키기만 하면 됩니다.
• 서버 측 검증: 서버는 이 토큰을 검증하여 요청이 인증된 사용자의 요청인지 확인합니다. 일반적으로 토큰의 유효성, 만료 시간 등을 확인합니다.
• 보안: Bearer 토큰은 HTTPS를 통해 전달되어야 합니다. 이를 통해 토큰이 전송 중에 도난당하지 않도록 보호할 수 있습니다.

 

🗨️ Config

Spring Cloud Config 개요

Spring Cloud Config란?

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

주요 기능

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

 

Spring Cloud Config 서버 설정

Config 서버 구성

• 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);
    }
}

설정 파일 구성

• application.yml 파일에서 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 클라이언트 설정

클라이언트 구성

• Config 클라이언트는 Config 서버에서 설정을 받아오는 역할을 합니다.
• build.gradle 파일에 필요한 의존성을 추가합니다.

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

설정 파일 구성

• 클라이언트의 application.yml 파일에서 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 서버는 환경별로 다른 설정 파일을 제공할 수 있습니다.
• 예를 들어, application-dev.yml, application-prod.yml 파일을 Git 저장소에 저장하여 환경별 설정을 관리합니다.

프로필 사용

• Spring Boot 애플리케이션에서 프로필을 사용하여 환경을 구분할 수 있습니다:

spring:
  profiles:
    active: dev

 

실시간 구성 변경

❗ 실시간 구성 변경을 반영하는 방법에는 여러 가지가 있습니다.

• Spring Cloud Bus를 사용하는 방법, 수동으로 /actuator/refresh 엔드포인트를 호출하는 방법, Spring Boot DevTools를 사용하는 방법, 그리고 Git 저장소를 사용하는 방법이 있습니다.
• 각 방법은 상황에 따라 적절히 선택하여 사용할 수 있습니다.
• Spring Cloud Bus는 메시징 시스템을 통해 실시간으로 설정 변경 사항을 전파하는 데 매우 유용하며, Git 저장소를 사용하면 설정 파일의 버전 관리를 쉽게 할 수 있습니다.
• Spring Boot DevTools는 주로 개발 환경에서 유용하게 사용됩니다.

 

Spring Cloud Bus

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

 

수동 구성 갱신

• /actuator/refresh 엔드포인트 사용
  • Spring Cloud Bus를 사용하지 않는 경우, 클라이언트 애플리케이션에서 수동으로 설정을 갱신할 수 있습니다. 이를 위해 Spring Actuator의 /actuator/refresh 엔드포인트를 사용할 수 있습니다.
• 설정 갱신 절차
  1. Config 서버에서 설정 파일을 변경합니다.
  2. 클라이언트 애플리케이션의 /actuator/refresh 엔드포인트를 POST 요청으로 호출하여 변경된 설정을 반영합니다.

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

• Spring Boot DevTools 사용
  • Spring Boot DevTools를 사용하면 개발 환경에서 파일 변경을 자동으로 감지하고 애플리케이션을 재시작할 수 있습니다. 이는 classpath 내의 파일 변경도 포함됩니다.

 

Git 저장소 사용

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

 

실습

❗ 컨피그 서버를 생성하고 product 애플리케이션이 local 에서 동작할 때 포트 정보 및 메시지를 컨피그 서버에서 가져옵니다 컨피그 서버의 메시지를 변경하여 product 애플리케이션의 message가 갱신되는 모습을 확인합니다.

 

• 💡실습에서는 네이티브 모드를 사용하겠습니다.
  • 로컬 환경 (네이티브 모드)에서는 설정 변경 후 반영하려면 애플리케이션을 재시작해야 함
• 현업에서는 직접 컨피그 서버를 구현하기보다는, 이미 구축된 컨피그 서버를 연동하여 사용하는 경우가 일반적일 것입니다.

 

Config-server

start.spring.io 에서 프로젝트를 생성합니다.

 

1️⃣ Config-Server (설정 관리 서버)

• 이 서버는 다른 마이크로서비스들에게 설정 정보(포트, 메시지 등)를 중앙에서 배포하는 역할을 합니다.

ConfigApplication.java

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

@SpringBootApplication
@EnableConfigServer // 이 애플리케이션을 설정(Config) 데이터를 제공하는 서버로 작동하게 만듭니다.
public class ConfigApplication {

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

}

resources/appication.yml

server:
  port: 18080

spring:
  profiles:
    active: native # [핵심] 외부 Git 저장소가 아닌, 애플리케이션 내부(로컬 파일 시스템)에서 설정 파일을 읽어오도록 지정합니다.
  application:
    name: config-server
  cloud:
    config:
      server:
        native:
          search-locations: classpath:/config-repo  # 설정 파일들이 모여있는 디렉토리 경로입니다. (src/main/resources/config-repo)



eureka:
  client:
    service-url:
      defaultZone: http://localhost:19090/eureka/ # 설정 서버 자신도 유레카에 등록되어 다른 서비스들이 찾을 수 있게 합니다.

 

• classpath: 스프링 프로젝트에서 src/main/resources 폴더를 가리키는 기본 약속어입니다.
• /config-repo: 그 밑에 직접 만든 폴더 이름이죠.
  • 즉, 서버에게 "내가 파일들 저 폴더에 다 모아놨으니까, 앞으로 클라이언트(Product 등)가 자기 설정 파일 달라고 요청하면 무조건 저 폴더 안을 뒤져서 찾아줘" 라고 룰을 세워둔 것입니다.

 

 

2️⃣ Config-Repo (설정 파일 저장소)

• 클라이언트 애플리케이션의 이름과 프로필(환경)에 따라 어떤 파일을 읽을지 결정됩니다. 규칙은 {application-name}-{profile}.yml 입니다.

resources 안에 config-repo라는 폴더를 생성한 후 아래의 두 파일을 만듭니다.

• product-service.yml (기본 설정)

server:
  port: 19093

message: "product-service message"

• product-service-local.yml (local 프로필 전용 설정)

server:
  port: 19083 # 클라이언트가 'local' 환경으로 실행되면 이 포트(19083)와 메시지가 우선 적용되어 덮어씌워집니다.

message: "product-service-local message"

 

Product-service

3️⃣ Product-Service (설정을 제공받는 클라이언트)

build-gradle의 디펜던시에 config 를 추가합니다.

dependencies {
    // Actuator: 애플리케이션의 상태 모니터링 및 설정값 동적 갱신(/refresh) 기능을 제공합니다.
	implementation 'org.springframework.boot:spring-boot-starter-actuator'
    // Config Client: 설정 서버로부터 설정값을 가져오기 위한 필수 라이브러리입니다.
	implementation 'org.springframework.cloud:spring-cloud-starter-config'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
	compileOnly 'org.projectlombok:lombok'
	annotationProcessor 'org.projectlombok:lombok'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

application.yml

server:
  port: 0  # 임시 포트입니다. Config 서버에서 받아온 포트(19083)로 최종 덮어씌워집니다.

spring:
  profiles:
    active: local # 'local' 프로필을 활성화하여 Config 서버의 product-service-local.yml 파일을 요청합니다.
  application:
    name: product-service # Config 서버에서 찾을 파일명의 기준이 됩니다.
  config:
    import: "configserver:" # Spring Boot 2.4 이후 방식. 설정 서버에서 설정을 가져오라는 명시적 선언입니다.
  cloud:
    config:
      discovery:
        enabled: true # 설정 서버의 IP 주소를 하드코딩하지 않고, 유레카를 통해 동적으로 찾아냅니다.
        service-id: config-server # 유레카에 등록된 설정 서버의 이름입니다.

management:
  endpoints:
    web:
      exposure:
        include: refresh # /actuator/refresh 엔드포인트를 열어, 서버 재시작 없이 설정값을 다시 읽어올 수 있게 합니다.

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

message: "default message" # Config 서버 접속 실패 시 사용될 기본값(Fallback)입니다.

 

 

• 스프링 클라우드 컨피그에는 전 세계 개발자들이 공통으로 사용하는 절대 규칙(공식)이 하나 있습니다. 클라이언트가 설정을 요구하면, 컨피그 서버는 무조건 아래 공식으로 파일 이름을 검색합니다.
  • 탐색 공식: {application-name}-{profile}.yml

• 서버 간의 대화 (작동 원리): Product 서버가 처음 켜질 때, 자신이 가진 application.yml을 읽고 Config 서버에게 이렇게 소리칩니다.
  • Product 서버: "야 컨피그 서버! 내 이름(application.name)은 product-service고, 나 지금 local 환경(profiles.active)으로 실행됐어! 내 설정 파일 내놔!"
  • Config 서버: "알았어, 잠깐만. 공식에 대입해보자... product-service + - + local + .yml 이니까... 오케이! 내 폴더(config-repo)에서 product-service-local.yml 파일을 찾아서 너한테 보내줄게!"

 

ProductController.java

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.RequestMapping;
import org.springframework.web.bind.annotation.RestController;


/**
 * @RefreshScope 애노테이션은 Spring 애플리케이션의 빈이 설정 변경을 반영할 수 있도록 하는 역할을 합니다.
 * 기본적으로 Spring 애플리케이션의 빈은 애플리케이션이 시작될 때 초기화되고, 설정 값이 변경되더라도 해당 빈은 갱신되지 않습니다.
 * 이 애노테이션을 사용하면 /actuator/refresh 엔드포인트를 호출하여 설정 변경 사항을 동적으로 반영할 수 있습니다.
 */
@RefreshScope
@RestController
@RequestMapping("/product")
public class ProductController {

    @Value("${server.port}") // 애플리케이션이 실행 중인 포트를 주입받습니다.
    private String serverPort;

    @Value("${message}") // Config 서버에서 가져온 'message' 값을 주입받습니다.
    private String message;

    @GetMapping
    public String getProduct() {
        return "Product detail from PORT : " + serverPort + " and message : " + this.message ;
    }
}

 

RUN

• 유레카 서버 > 컨피그 서버 > 상품 순으로 실행합니다.

상품이 실행될때 로그의 포트를 확인합니다. 19083 으로 할당됨을 볼 수 있습니다.

http://localhost:19083/product 을 호출하면 포트와 메시지를 확인 할 수 있습니다.

config-server 의 product-service-local.yml 파일의 message를 수정하고 config-server 를 재시작 합니다.

server:
  port: 19083

message: "product-service-local message updated"

talend api tester를 실행하고 http://localhost:19083/actuator/refresh 로 post 요청을 합니다. 응답으로 메시지가 업데이트 됨을 확인할 수 있습니다.

"Product 서버야, 방금 설정 파일 바뀌었으니 Config 서버에 다시 접속해서 값만 쏙 빼와!"

다시 http://localhost:19083/product를 호출 하면 메시지가 변경된 것을 확인 할 수 있습니다.

*참고 http://localhost:18080/product-service/local 로 접속하면 product-service의 설정 값들을 볼 수 있습니다. (이를 통해 다른 설정값들도 확인할 수 있습니다.)

 

 

📑 핵심 개념 요약

1. 설정 파일 매칭 규칙 (Naming Convention)
   • spring.application.name = product-service
   • spring.profiles.active = local
   • 위 두 가지 설정이 결합되어, Config 서버에 있는 product-service-local.yml 파일을 최우선으로 읽어옵니다.
2. 유레카(Eureka) 연동의 장점 (discovery.enabled: true)
   • 기존에는 클라이언트 YAML에 uri: http://localhost:18080 처럼 설정 서버 주소를 직접 적어야 했습니다.
   • 유레카를 연동하면 service-id: config-server 이름만으로 주소를 찾아내므로, 설정 서버의 IP나 포트가 변경되어도 클라이언트 코드를 수정할 필요가 없습니다.
3. 동적 설정 갱신 (@RefreshScope + Actuator)
   • 코드를 수정하거나 서버를 내리지 않아도, product-service-local.yml의 메시지 내용을 수정한 뒤 클라이언트 측에 /actuator/refresh POST 요청을 보내면 ProductController의 message 변수 값이 즉시 바뀝니다. (이것이 MSA에서 Config Server를 쓰는 가장 큰 이유입니다.)

 

🗨️ 분산추적 

분산 추적

분산 추적이란?

• 분산 추적은 분산 시스템에서 서비스 간의 요청 흐름을 추적하고 모니터링하는 방법입니다.
• 각 서비스의 호출 관계와 성능을 시각화하여 문제를 진단하고 해결할 수 있도록 돕습니다.
• 주요 개념: 트레이스(Trace), 스팬(Span), 컨텍스트(Context)
  1. 트레이스(Trace) : 트레이스는 하나의 요청이 시작부터 끝까지 각 서비스를 거치는 전체 흐름을 나타냅니다
     • 하나의 트레이스는 여러 개의 스팬으로 구성됩니다
     • 분산 시스템에서 클라이언트의 요청이 여러 서비스로 전달될 때, 각 서비스 호출이 트레이스의 일부로 기록됩니다
     • 트레이스 ID는 각 스팬에 공통으로 부여되며, 이를 통해 전체 요청 흐름을 추적할 수 있습니다
  2. 스팬(Span) : 스팬은 분산 추적에서 가장 작은 단위로, 특정 서비스 내에서의 개별 작업 또는 요청을 나타냅니다.
     • 각 스팬은 시작 시간과 종료 시간을 기록하여 작업의 지속 시간을 나타냅니다.
     • 스팬은 고유한 스팬 ID를 가지며, 이는 트레이스 ID와 함께 특정 작업을 식별하는 데 사용됩니다.
     • 스팬은 부모-자식 관계를 가질 수 있으며, 이를 통해 호출 계층 구조를 표현합니다.
     • 스팬에는 메타데이터(태그, 로그, 이벤트 등)를 추가하여 상세한 정보를 기록할 수 있습니다.
  3. 컨텍스트(Context) : 컨텍스트는 요청이 서비스 간에 전달될 때 함께 전파되어, 각 서비스가 요청의 전체 흐름에 대한 정보를 가질 수 있게 합니다.
     • 컨텍스트는 트레이스 ID, 스팬 ID, 부모 스팬 ID 등의 정보를 포함하여 각 서비스가 요청의 출처와 경로를 추적할 수 있도록 돕습니다.
     • 서비스 호출 간에 컨텍스트를 유지함으로써, 분산 시스템 전체에서 일관된 추적이 가능합니다.

 

왜 분산 추적이 필요한가?

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

 

Micrometer

Micrometer란?

• Micrometer는 Spring 기반 애플리케이션에서 메트릭을 수집하고 모니터링하기 위한 라이브러리입니다.
  • 메트릭(Metric)은 CPU 사용량이나 에러 발생 횟수처럼, 서버의 현재 상태와 성능을 정확하게 파악하기 위해 수집하는 '객관적인 숫자 데이터(측정값)입니다.
• 각 서비스의 성능 지표를 수집하고, Prometheus, Grafana 등과 연동하여 시각화할 수 있습니다.
• 분산 추적을 위한 기능도 제공하여 서비스 간의 호출 흐름을 추적할 수 있습니다.

주요 특징

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

 

Zipkin

Zipkin이란?

• Zipkin은 트레이스 데이터를 수집하고 시각화하는 분산 추적 시스템입니다.
• 각 서비스의 트레이스와 스팬 데이터를 저장하고, 이를 통해 호출 흐름을 시각화합니다.

주요 특징

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

 

Zipkin 서버 설정

Zipkin 서버 실행

• Zipkin 서버를 Docker를 사용하여 실행할 수 있습니다:

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

Zipkin 대시보드 사용

• Zipkin 대시보드에 접속하여 트레이스 데이터를 시각화합니다:
  • URL: http://localhost:9411
  • 트레이스 검색 및 분석

 

분산 추적 예제

서비스 호출 흐름 추적

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

성능 병목 진단

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

 

실습

• 이 실습은 MSA 환경에서 가장 골치 아픈 문제인 "요청 추적(Distributed Tracing)"을 해결하기 위한 Zipkin(집킨) 연동 실습입니다. 마이크로서비스에서는 사용자의 요청 하나가 여러 서버(Order -> Product 등)를 거치게 되는데, 중간에 에러가 나거나 느려졌을 때 어느 서버에서 문제가 생겼는지 한눈에 파악하기 위해 사용합니다.

Product-service

build.gradle 파일 디펜던시를 아래와 같이 수정합니다.

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-actuator'
    // Micrometer Tracing (Brave): 스프링 부트 3.x에서 분산 추적을 담당하는 핵심 엔진입니다.
	implementation 'io.micrometer:micrometer-tracing-bridge-brave'
    // Feign Micrometer: Order가 Product를 호출할 때, HTTP 헤더에 '추적 ID(Trace ID)'를 몰래 끼워 넣어 흐름이 끊기지 않게 연결해 주는 역할을 합니다.
	implementation 'io.github.openfeign:feign-micrometer'
    // Zipkin Reporter: Brave 엔진이 수집한 추적 데이터(메트릭)를 Zipkin 서버로 전송(Report)하는 통신 라이브러리입니다.
	implementation 'io.zipkin.reporter2:zipkin-reporter-brave'

	implementation 'org.springframework.boot:spring-boot-starter-web'
	implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
	implementation 'org.springframework.cloud:spring-cloud-starter-openfeign'
	compileOnly 'org.projectlombok:lombok'
	annotationProcessor 'org.projectlombok:lombok'
	providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

application.yml

spring:
  application:
    name: product-service
server:
  port: 19092
eureka:
  client:
    service-url:
      defaultZone: http://localhost:19090/eureka/

management:
  zipkin:
    tracing:
      endpoint: "http://localhost:9411/api/v2/spans" # Zipkin 서버가 데이터를 수집하기 위해 열어둔 API 주소입니다.
  tracing:
    sampling:
      probability: 1.0 # 샘플링 확률. 1.0은 100%를 의미하며, 들어오는 모든 요청을 추적하겠다는 뜻입니다.

Order-service

build.gradle 파일 디펜던시를 아래와 같이 수정합니다.

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-actuator'
	implementation 'io.micrometer:micrometer-tracing-bridge-brave'
	implementation 'io.github.openfeign:feign-micrometer'
	implementation 'io.zipkin.reporter2:zipkin-reporter-brave'

	implementation 'org.springframework.boot:spring-boot-starter-web'
	implementation 'org.springframework.cloud:spring-cloud-starter-netflix-eureka-client'
	implementation 'org.springframework.cloud:spring-cloud-starter-openfeign'
	compileOnly 'org.projectlombok:lombok'
	annotationProcessor 'org.projectlombok:lombok'
	providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

application.yml

spring:
  application:
    name: order-service
server:
  port: 19091
eureka:
  client:
    service-url:
      defaultZone: http://localhost:19090/eureka/

management:
  zipkin:
    tracing:
      endpoint: "http://localhost:9411/api/v2/spans"
  tracing:
    sampling:
      probability: 1.0

Zipkin

• Zipkin 도커 컨테이너 실행 코드를 커맨드를 켜서 입력합니다.

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

RUN

• Eureka Server > Order > Product 순으로 실행합니다.
• http://localhost:19091/order/1 를 접속해봅니다. 이전의 응답과 결과가 같습니다.
• http://localhost:9411/zipkin/ 로 접속 후에 RUN QUERY를 클릭합니다. 리스트가 나오며 Spans 3 인 항목의 SHOW를 클릭합니다.

• Order-service가 Product-service를 호출하는 과정이 트래킹 되는 것을 확인할 수 있습니다.

 

📑 핵심 개념 (Trace와 Span)

• Zipkin 화면을 보면 Trace와 Span이라는 단어가 나옵니다. 이 두 가지를 구분하는 것이 분산 추적의 전부입니다.
  1. Trace (트레이스): 사용자의 최초 요청부터 최종 응답까지의 전체 흐름(1개의 큰 작업)을 의미합니다. (고유한 Trace ID를 가집니다.)
  2. Span (스팬): 전체 흐름 속에서 각 서비스가 수행한 개별 작업 단위를 의미합니다. (각자 고유한 Span ID를 가집니다.)
     • 공식: 1개의 Trace = N개의 Span

💡 왜 Spans 리스트가 '3'으로 나올까요? (실습 결과 분석)

• http://localhost:19091/order/1 을 호출했을 때 Zipkin에 Span이 3개 찍히는 기술적인 이유는 다음과 같습니다.
  1. Span 1 (Order Service): 사용자의 요청이 Order 서버에 최초로 도착하여 처리를 시작한 작업.
  2. Span 2 (Feign Client): Order 서버가 Product 서버로 HTTP 요청을 보내기 위해 통신을 시도하고 대기한 작업.
  3. Span 3 (Product Service): Product 서버가 요청을 전달받아 실제 데이터를 만들고 응답한 작업.

이 3개의 Span이 모여 1개의 Trace(전체 흐름)를 구성하며, Zipkin은 이를 시간 순서대로 연결하여 그래프로 보여줍니다.

 

🗨️ 이벤트 드리븐

이벤트 드리븐 아키텍처

이벤트 드리븐 아키텍처란?

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

주요 개념

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

이벤트 드리븐 아키텍처의 장점

• 느슨한 결합
  • 서비스 간의 강한 종속성을 제거하여 독립적인 개발과 배포가 가능
  • 이벤트 기반 통신을 통해 서비스 간의 결합도 낮춤
• 확장성
  • 수평 확장이 용이하여 대규모 시스템에서 유용
  • 이벤트 프로듀서와 컨슈머를 독립적으로 확장 가능
    • 📢 이벤트 프로듀서 (Producer): 시스템에서 상태 변화가 발생했을 때, 이를 이벤트 메시지로 만들어 브로커에 발행(Publish)하는 서비스입니다.
    • 📮 메시지 브로커 (Broker): 프로듀서가 보낸 이벤트를 안전하게 보관하고, 필요한 컨슈머들에게 전달해 주는 비동기 중계소(우체국) 역할입니다." (예: Kafka, RabbitMQ)
    • 🎧 이벤트 컨슈머 (Consumer): 브로커를 구독(Subscribe)하고 있다가, 이벤트가 도착하면 이를 가져와 자신의 비즈니스 로직(알림 발송, DB 업데이트 등)을 독립적으로 처리하는 서비스입니다.
• 비동기 처리
  • 이벤트를 비동기적으로 처리하여 시스템의 응답성 향상
  • 요청과 응답을 비동기적으로 처리하여 성능 최적화

"결과적으로 브로커라는 중간 다리가 있기 때문에, 프로듀서와 컨슈머는 서로가 누군지 몰라도(느슨한 결합) 통신할 수 있으며, 각자 트래픽에 맞춰 독립적으로 스케일 아웃(확장)할 수 있습니다."

이벤트 드리븐 아키텍처의 단점

• 복잡성 증가
  • 이벤트 기반 통신으로 인해 시스템의 복잡성 증가 가능
  • 이벤트 흐름과 상태 관리를 체계적으로 설계 필요
• 장애 전파
  • 이벤트 실패 시 다른 서비스로 장애가 전파될 수 있음
  • 이벤트 재처리 및 장애 복구 메커니즘 구현 필요

 

예시: 온라인 쇼핑몰

1. 이벤트 소스: 사용자가 온라인 쇼핑몰에서 주문을 합니다.
   • 주문 서비스가 '주문 생성' 이벤트를 발생시킵니다.
2. 이벤트 버스: Kafka나 RabbitMQ와 같은 메시지 브로커가 '주문 생성' 이벤트를 전달합니다.
3. 이벤트 핸들러:
   • 재고 서비스: '주문 생성' 이벤트를 수신하여 재고를 확인하고 업데이트합니다.
   • 배송 서비스: '주문 생성' 이벤트를 수신하여 배송 준비를 시작합니다.
   • 결제 서비스: '주문 생성' 이벤트를 수신하여 결제 처리를 합니다.

 

Spring Cloud Stream

Spring Cloud Stream이란?

• Spring Cloud Stream은 이벤트 드리븐 마이크로서비스를 구축하기 위한 프레임워크입니다.
• Kafka, RabbitMQ 등의 메시지 브로커와 통합하여 이벤트 스트리밍을 처리합니다.
• 프로듀서와 컨슈머 간의 통신을 추상화하여 간편하게 이벤트 기반 애플리케이션을 개발할 수 있습니다.

 

주요 특징

• 바인더 추상화: 메시지 브로커와의 통합을 위한 추상화 레이어를 제공합니다.
• 프로듀서/컨슈머 모델: 이벤트를 생성하고 처리하는 프로듀서와 컨슈머 모델을 지원합니다.
• 유연한 설정: 다양한 설정 옵션을 통해 손쉽게 커스터마이징할 수 있습니다.

 

🗨️ 마무리

무조건 MSA!?

• MSA를 도입하기 위해서는 수업의 내용처럼 많은 것들이 사용되며, 정책 설정을 해야 할 것이 많습니다. 빠르게 프로젝트의 프로토 타입을 만들어야 한다면 모놀리틱 아키텍쳐를 사용하고, 후에 부분, 부분 전환하는 것도 방법일 것입니다.
• 만약 스프링 클라우드가 아닌 다른 프레임워크로 MSA를 개발 한다고 해도 우리는 지금까지 공부했던 기능들이 있어야 함을 알 수 있습니다.
• 개발에 정답은 없습니다. 개발팀이 추구하는 방향에 따라 개발의 크기, 기능의 구성 등 정말 다양한 사항들이 결정될 것입니다. 개발된 레거시의 구조, 신규 프로젝트에서의 합의된 구조를 잘 파악하고 따라 가는 것도 중요합니다. 그래야 개발이 완료되었을 때 유지보수도 수월 할 것이며, 추가 투입 인원이 있다면 보다 수월하게 프로젝트에 진입할 수 있을 것입니다.

Tip. 기존 프로젝트를 파악할 때 CRUD 관점으로 파악하면 수월해짐! 기존에 프로젝트에 투입이 됐다면 기존 프로젝트에서 CRUD가 어떻게 생성되는지 CRUD Search까지  한 사이클을 기존 패턴을 그대로 따라해서 샘플로 만들어 보기.

 

추가 정보 “쿠버네티스”

쿠버네티스란?

• 쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션의 배포, 확장, 운영을 자동화하는 오픈소스 플랫폼입니다.
  • 수많은 컨테이너(앱)들이 중단 없이 안정적으로 돌아가도록 배포, 확장, 복구 작업을 자동으로 수행하는 '통합 운영 관리 시스템'
  • 📦 컨테이너 (Container): 애플리케이션과 그 실행에 필요한 라이브러리, 설정 파일 등을 하나로 묶어 패키징한 '독립적인 가상화(자원을 격리한 독립 실행 영역) 실행 단위'입니다. 이를 통해 개발 환경이나 운영 OS에 종속되지 않고 어디서든 동일하게 프로그램을 구동할 수 있습니다.
• Google에서 개발하고 현재는 CNCF(Cloud Native Computing Foundation)에서 관리합니다.
• 컨테이너 오케스트레이션 도구로, 다수의 컨테이너를 효율적으로 관리할 수 있습니다.
  • 🎼 컨테이너 오케스트레이션 도구 (Container Orchestration Tool): "수십~수만 개의 컨테이너가 안정적으로 운영될 수 있도록 배포, 스케일링(확장/축소), 로드밸런싱, 장애 복구 등의 '전체 생명주기를 자동화하여 통합 관리'하는 시스템입니다.

주요 개념

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

개발자가 "이 앱 좀 띄워줘"라고 클러스터에 요청하면, 클러스터는 내부에 연결된 여러 대의 노드 중 가장 여유로운 녀석을 골라 자동으로 앱을 배포합니다. 즉, 사용자는 서버가 여러 대라는 사실을 신경 쓸 필요 없이, 클러스터라는 '거대한 하나의 자원 덩어리'만 보고 작업하면 되는 것이죠.

 

쿠버네티스와 Spring Cloud 비교

• 공통점
  • 확장성: 둘 다 마이크로서비스 아키텍처의 확장성을 지원합니다.
  • 관리성: 서비스의 배포, 관리, 확장 등을 쉽게 할 수 있도록 도와줍니다.
  • 고가용성: 서비스의 가용성을 높이고, 장애 발생 시 자동 복구를 지원합니다.
• 차이점
  1. 초점:
     • Spring Cloud: 마이크로서비스 간의 통신, 서비스 디스커버리, 구성 관리 등 애플리케이션 레벨의 문제 해결에 초점
     • 쿠버네티스: 컨테이너 관리, 배포, 스케일링 등 인프라 레벨의 문제 해결에 초점
  2. 구성 요소:
     • Spring Cloud: Eureka, Ribbon, Zuul, Config Server, Hystrix 등 다양한 마이크로서비스 패턴을 지원하는 구성 요소
       • MSA, 애플리케이션 단위 초점 
     • 쿠버네티스: Pod, Deployment, Service, Ingress, ConfigMap, Secret 등 컨테이너 오케스트레이션에 필요한 구성 요소
       • 인프라 초점 
  3. 배포 방식:
     • Spring Cloud: 애플리케이션 코드와 함께 다양한 클라우드 서비스에 직접 배포
     • 쿠버네티스: 컨테이너 이미지를 기반으로 클러스터 내에서 배포 및 관리

 

Spring Cloud와의 통합도 가능

• Spring Cloud Kubernetes
  • Spring Cloud Kubernetes는 Spring Cloud와 Kubernetes의 통합을 지원합니다.
  • 서비스 디스커버리, ConfigMap, Secrets 등을 Spring Cloud 애플리케이션에서 사용할 수 있도록 지원합니다.
• 주요 기능
  • 서비스 디스커버리: Kubernetes API를 통해 서비스 인스턴스를 동적으로 검색하고 로드 밸런싱을 수행합니다.
  • 구성 관리: Kubernetes ConfigMap과 Secrets을 사용하여 애플리케이션 설정을 중앙에서 관리합니다.
  • 자동화된 배포: CI/CD 파이프라인과 통합하여 애플리케이션의 자동 배포와 관리를 지원합니다.

 

쿠버네티스의 장점과 단점

• 장점
  • 확장성: 수평 확장을 통해 대규모 트래픽을 처리할 수 있습니다.
  • 자동화: 배포, 스케일링, 복구 등의 작업을 자동화하여 운영 부담을 줄입니다.
  • 유연성: 다양한 인프라 환경에서 일관된 운영이 가능합니다.
• 단점
  • 복잡성: 초기 설정과 운영에 대한 학습 곡선이 높습니다.
  • 운영 비용: 클러스터 운영과 모니터링에 추가적인 리소스가 필요합니다.
  • 디버깅 어려움: 분산 환경에서 문제를 추적하고 해결하는 것이 복잡할 수 있습니다.

 

사례

• 성공 사례
  • Google: 내부적으로 Borg라는 시스템을 사용하다가 Kubernetes로 발전시켜 오픈소스화
  • Netflix: 대규모 마이크로서비스 아키텍처를 지원하기 위해 Kubernetes를 활용
  • Airbnb: 애플리케이션 배포와 관리를 자동화하여 운영 효율성 극대화
• 실패 사례와 교훈
  • 초기 설정의 복잡성: 많은 기업들이 초기 설정의 복잡성으로 인해 도입에 어려움을 겪음
  • 리소스 관리의 중요성: 적절한 리소스 할당과 관리가 이루어지지 않으면 비용이 급증할 수 있음
  • 전문성 부족: 충분한 Kubernetes 전문성이 없는 팀에서는 운영상의 어려움을 겪을 수 있음