분산 추적(Zipkin)은 마이크로서비스 간의 요청 흐름을 추적하고 시각화하여 성능 문제와 오류를 분석하는 기법입니다.
분산 추적과 Zipkin에 대한 내용은 아래의 포스팅에서 확인 가능합니다.▼
사용 코드
product-service
build.gradle
application.yml
order-service
build.gradle
application.yml
OrderController
OrderService
management.zipkin.tracing.endpoint
management.zipkin.tracing.endpoint : "http://localhost:9411/api/v2/spans"
위 설정은 Spring Boot의 Zipkin 통합에서 사용하는 프로퍼티 중 하나입니다. 이 설정의 기본값은 http://localhost:9411/api/v2/spans입니다.
URL: http://localhost:9411/api/v2/spans
- localhost
- Zipkin 서버가 로컬 호스트에서 실행되고 있음을 의미합니다.
- 9411
- Zipkin의 기본 포트입니다.
- /api/v2/spans
- Zipkin의 스팬 데이터 전송 엔드포인트입니다.
management.zipkin.tracing.probability
management.zipkin.tracing.probability는 Zipkin 추적을 샘플링할 확률을 설정하는 데 사용됩니다.
분산 추적 시스템에서는 모든 요청을 추적하는 것이 성능에 큰 부담을 줄 수 있기 때문에, 일반적으로 샘플링하여 일부 요청만 추적합니다.
이 설정은 어떤 요청을 추적할지 결정하는 데 사용됩니다.
값의 범위: 이 설정은 0.0 ~ 1.0 사이의 값으로 설정할 수 있습니다.
- 0.0: 아무것도 추적하지 않음 (샘플링 비율 0%)
- 1.0: 모든 요청을 추적함 (샘플링 비율 100%)
- 예를 들어, 0.1로 설정하면 전체 요청 중 10%만 추적합니다.
Zipkin을 통한 분산 추적 아키텍처
위 아키텍처 그림은 이번 포스팅에서 알아볼 분산 추적을 하기 위한 간단한 프로젝트의 아키텍처입니다.
orderId를 통해 Order 서비스를 호출하고, orderId가 1일 경우 Product 서비스를 호출하여 제품 정보를 가져오는 간단한 프로젝트입니다.
이 프로젝트는 사용자가 Order 애플리케이션을 호출하고, Order 서비스가 Product 서비스를 호출하는 체인 구조로 요청이 흐른다는 것을 의미합니다.
이번 포스팅에서는 이러한 요청의 흐름을 Zipkin을 사용하여 요청을 추적하고 시각화하는 방법에 대해 알아보겠습니다.
Docker를 통한 Zipkin 서버 실행
docker run -d -p 9411:9411 openzipkin/zipkin
위와 같이 Zipkin 서버를 Docker를 사용하여 실행할 수 있습니다.
- docker run
- Docker 컨테이너를 새로 실행합니다.
- -d
- "detached" 모드로 컨테이너를 백그라운드에서 실행합니다.
- -p 9411:9411
- 호스트의 포트 9411을 컨테이너의 포트 9411에 매핑합니다. Zipkin의 기본 포트입니다.
- openzipkin/zipkin
- 사용할 Docker 이미지를 지정합니다. Zipkin의 공식 Docker 이미지입니다.
Zipkin 분산 추적 동작 확인
Eureka 서버를 확인해보면 위와 같이 ODER-SERVICE와 PRODUCT-SERVICE가 연결된 것을 확인할 수 있습니다.
ORDER-SERVICE의 "http://localhost:19091/order/1"로 요청을 하면 ProductApp까지 정상적으로 호출해서 가져온 것을 볼 수 있습니다.
"localhost:9411"에 접속하여 이제 Zipkin을 RUN QUREY눌러 확인을 해보면, Result에 데이터가 생겼습니다.
Zipkin UI에서 order-service의 HTTP GET /order/{orderId} 요청을 확인해보면, 요청 흐름이 어떻게 전개되는지를 시각적으로 알 수 있습니다.
- order-service
- HTTP GET /order/{orderId} → order-service: HTTP GET → product-service: HTTP GET /product/{id}
이러한 추적을 통해 다음과 같은 정보를 확인할 수 있습니다.
- 각 서비스의 호출 경로
- 요청이 어떻게 각 서비스 간에 전달되는지, 즉 서비스 호출의 흐름을 파악할 수 있습니다.
- 각 서비스의 응답 시간
- 각 서비스에서 요청을 처리하는 데 소요된 시간을 밀리초(ms) 단위로 확인할 수 있습니다. 이를 통해 각 서비스의 성능을 평가할 수 있습니다.
이 정보를 통해 Zipkin은 다음과 같은 인사이트를 제공합니다.
- 응답 시간이 오래 걸리는 서비스 식별:
- 각 서비스의 응답 시간을 분석하여, 지연이 발생하는 특정 서비스를 쉽게 찾아낼 수 있습니다.
- 이는 성능 문제를 해결하고 시스템의 효율성을 향상시키는 데 도움이 됩니다.
이와 같이 분산 추적을 사용하면 서비스 호출 경로와 각 서비스의 응답 시간을 명확히 파악할 수 있으며, 이를 통해 응답 시간이 긴 서비스에 대한 조치를 취할 수 있습니다.
또한, 위 그림과 같이 Zipkin의 Dependencies 탭을 통해, 서비스 간의 호출 관계를 시각적으로 확인할 수 있습니다. 이 탭에서는 각 서비스가 서로를 호출하는 방식과 호출 경로를 한눈에 볼 수 있으며, 서비스 간의 의존성을 파악할 수 있습니다.
'Framework > Spring\Spring boot' 카테고리의 다른 글
[Spring Boot] Spring Boot에서 데이터 검증: @Valid와 @Column(nullable = false)의 차이와 함께 사용하는 방법 (0) | 2024.08.15 |
---|---|
[Spring boot] @Builder 어노테이션의 장점 (0) | 2024.08.09 |
[Spring Cloud] Spring Cloud Sleuth(분산 추적)와 Zipkin이란 ❓ (0) | 2024.08.07 |
[Spring Cloud] Spring Cloud Config의 중앙 집중식 설정 관리와 실시간 구성 변경 방법 (@RefreshScope, 수동 구성 갱신) (0) | 2024.08.06 |
[SpringCloud] JWT 토큰을 통한 Spring Cloud Gateway 인증 및 권한 관리 (0) | 2024.08.05 |