Spring Cloud Config와 분산 추적

💡  오늘 학습 키워드

• Spring Cloud Config
• 분산 추적

 

🎯  학습 내용 정리

마이크로서비스 아키텍처(MSA)는 서비스를 독립적으로 개발하고 배포할 수 있다는 장점이 있지만, 서비스 수가 증가할수록 운영해야 하는 설정 파일과 로그 또한 기하급수적으로 늘어난다.

 

예를 들어 주문 서비스, 회원 서비스, 결제 서비스가 각각 별도의 서버에서 실행된다면 데이터베이스 주소, Redis 정보, API Key, 외부 서비스 URL 등 수많은 설정을 서비스마다 관리해야 한다. 또한 하나의 요청이 여러 서비스를 거쳐 처리되는 만큼 장애가 발생했을 때 어느 서비스에서 문제가 발생했는지 추적하는 것도 쉽지 않다.

 

Spring Cloud는 이러한 문제를 해결하기 위해 Spring Cloud Config를 통한 중앙 설정 관리와 Micrometer, Zipkin을 이용한 분산 추적 기능을 제공한다.

 

1. Spring Cloud Config

Spring Cloud Config는 여러 마이크로서비스에서 사용하는 설정 파일을 중앙에서 관리하는 기능이다.

기존에는 각 서비스마다 application.yml 파일을 따로 관리했지만 Config Server를 사용하면 하나의 저장소에서 모든 설정을 관리할 수 있다.

   Config Repository(Git)
           │
    Config Server
           │
    ┌──────┼──────┐
    |      |      |
  User   Order  Product

각 서비스는 실행 시 Config Server로부터 자신의 설정을 받아 사용한다.

이를 통해 다음과 같은 장점을 얻을 수 있다.

• 설정 파일 중앙 관리
• 환경(dev, test, prod)별 설정 분리
• 설정 변경 시 서비스 재배포 최소화
• Git 기반 버전 관리

 

 

Config Server는 Git 또는 File System에 저장된 설정 파일을 읽어서 클라이언트에게 제공하는 서버이다.

Spring Boot에서는 Config Server 의존성을 추가한 뒤 @EnableConfigServer를 선언하면 된다.

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {

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

}

 

application.yml에서는 Git 저장소를 지정한다.

server:
  port: 8888

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

애플리케이션이 실행되면 Git Repository에서 설정 파일을 읽어 각 서비스에 전달한다.

 

 

각 마이크로서비스는 Config Client 역할을 수행한다.

Config Client는 실행 시 Config Server에 접속하여 자신의 설정을 가져온다.

 

의존성을 추가한다.

implementation 'org.springframework.cloud:spring-cloud-starter-config'

 

설정 파일은 다음과 같다.

spring:
  application:
    name: user-service

  cloud:
    config:
      discovery:
        enabled: true
        service-id: config-server

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

 

서비스 이름(spring.application.name)을 기준으로 Config Server가 해당 서비스의 설정 파일을 찾아 전달한다.

예를 들어

user-service.yml
order-service.yml
payment-service.yml

처럼 서비스별 설정 파일을 관리할 수 있다.

 

 

실제 운영에서는 개발 환경과 운영 환경의 설정이 다르다.

Spring Cloud Config는 프로필(Profile)을 이용하여 환경별 설정을 제공한다.

application-dev.yml
application-test.yml
application-prod.yml

 

애플리케이션은 활성 프로필에 따라 적절한 설정을 가져온다.

spring:
  profiles:
    active: dev

운영 환경에서는 데이터베이스 주소와 Redis 서버가 다르더라도 동일한 코드로 실행할 수 있다.

 

 

설정 파일을 수정했다고 해서 실행 중인 애플리케이션이 자동으로 변경 사항을 읽지는 않는다. 이를 해결하기 위해 Spring Cloud는 Refresh 기능을 제공한다.

 

동작 과정은 다음과 같다.

Git 수정
  ↓
Config Server 갱신
  ↓
Client Refresh 요청
  ↓
새로운 설정 적용

 

대표적인 방법은 /actuator/refresh 엔드포인트를 호출하는 것이다.

POST /actuator/refresh

그러면 변경된 설정이 메모리에 다시 로드된다. 서비스를 재시작하지 않아도 되는 것이 가장 큰 장점이다.

 

 

서비스가 수십 개 이상이라면 모든 서비스의 /refresh를 직접 호출하는 것은 매우 번거롭다.

이를 해결하는 것이 Spring Cloud Bus이다.

Git 변경
  ↓
Config Server
  ↓
RabbitMQ / Kafka
  ↓
모든 서비스

Spring Cloud Bus는 Kafka 또는 RabbitMQ를 이용하여 변경 이벤트를 전달한다. 관리자는 한 번만 Refresh를 요청하면 메시지가 모든 서비스로 전파되어 설정이 동시에 갱신된다.

대규모 MSA 환경에서는 거의 필수적으로 사용되는 기능이다.

 

 

2. 분산 추적

모놀리식에서는 하나의 로그만 확인하면 요청 흐름을 파악할 수 있었다. 하지만 MSA에서는 하나의 요청이 여러 서비스를 거친다.

예를 들어 주문 요청은 다음과 같이 처리된다.

Client
  ↓
Gateway
  ↓
Order Service
  ↓
Product Service
  ↓
Payment Service
  ↓
Notification Service

이 과정에서 응답이 느려졌다면 어느 서비스가 병목인지 확인하기 어렵다.

이를 해결하는 기술이 분산 추적(Distributed Tracing) 이다.

 

 

분산 추적에는 두 가지 핵심 개념이 있다.

 

Trace

하나의 요청 전체를 의미한다.

사용자 주문 요청
  ↓
Gateway
  ↓
Order
  ↓
Product
  ↓
Payment

위 전체가 하나의 Trace이다.

 

Span

각 서비스에서 수행하는 하나의 작업이다.

Trace
 ├─ Gateway Span
 ├─ Order Span
 ├─ Product Span
 └─ Payment Span

Span에는 다음 정보가 포함된다.

• 시작 시간
• 종료 시간
• 실행 시간
• 부모 Span
• Trace ID
• Span ID

Trace ID를 통해 하나의 요청을 끝까지 추적할 수 있다.

 

 

Micrometer는 Spring Boot의 메트릭 수집 라이브러리이다.

CPU 사용량, 메모리, HTTP 요청 수, 응답 시간 등 다양한 정보를 수집한다.

대표적으로 다음과 같은 메트릭을 제공한다.

• HTTP 요청 수
• 평균 응답 시간
• JVM 메모리
• CPU 사용량
• Thread 수
• Database Connection Pool

Micrometer는 Prometheus와 쉽게 연동된다.

Spring Boot
  ↓
Micrometer
  ↓
Prometheus
  ↓
Grafana

Grafana에서는 수집된 메트릭을 대시보드 형태로 시각화할 수 있다.

 

 

Zipkin은 Trace 정보를 저장하고 시각화하는 서버이다.

각 서비스는 Trace 정보를 Zipkin으로 전송한다.

Gateway
  ↓
Order
  ↓
Product
  ↓
Payment
  ↓
Zipkin

Zipkin에서는 다음 정보를 확인할 수 있다.

• 요청 흐름
• 호출 순서
• 서비스별 실행 시간
• 병목 발생 위치
• 에러 발생 서비스

웹 UI에서는 하나의 Trace를 선택하면 호출 관계를 시간순으로 확인할 수 있다.

 

 

Docker를 사용하면 Zipkin을 쉽게 실행할 수 있다.

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

실행 후

<http://localhost:9411>

에 접속하면 Trace 정보를 확인할 수 있다.

 

 

예를 들어 사용자가 상품을 주문한다고 가정해 보자.

Client
  ↓
Gateway
  ↓
Order Service
  ↓
Product Service
  ↓
Payment Service
  ↓
Notification Service

 

각 서비스는 요청을 처리하면서 새로운 Span을 생성한다.

Trace
 ├── Gateway (5ms)
 ├── Order (20ms)
 ├── Product (80ms)
 ├── Payment (250ms)
 └── Notification (30ms)

Zipkin에서는 이러한 호출 관계를 하나의 화면에서 확인할 수 있다.

 

만약 Payment Service의 처리 시간이 지나치게 길다면 즉시 병목 지점을 확인할 수 있으며, 장애가 발생한 서비스 역시 빠르게 식별할 수 있다.

이처럼 분산 추적은 운영 환경에서 장애 분석과 성능 개선에 매우 중요한 역할을 한다.

 

 

Spring Cloud Config는 분산된 설정 파일을 중앙에서 관리하여 운영 효율성을 높여준다. 또한 Config Refresh와 Spring Cloud Bus를 활용하면 서비스 재시작 없이 설정을 변경할 수 있어 대규모 MSA 환경에서도 유연한 운영이 가능하다.

Micrometer와 Zipkin은 서비스의 메트릭과 요청 흐름을 수집하고 시각화하여 장애 원인과 성능 병목을 빠르게 분석할 수 있도록 지원한다. 서비스 수가 많아질수록 이러한 운영 도구의 중요성은 더욱 커지며, 안정적인 마이크로서비스 운영을 위해 반드시 고려해야 할 핵심 요소이다.

 

 

📚  한줄 정리

1. Spring Cloud Config는 분산 환경의 설정 정보를 중앙에서 관리하여 일관성과 유지보수성을 높이는 구성 관리 도구이다.

2. 분산 추적은 여러 마이크로서비스를 거치는 요청의 흐름을 추적하여 장애 원인과 성능 병목을 빠르게 분석하는 기술이다.