이책은 스프링으로 하는 마이크로서비스 구축(스프링 부트와 스프링 클라우드를 이용한 도커/쿠버네티스 마이크로서비스) 책을 읽고 학습한 내용을 정리한 글입니다.
📌 이번 포스팅에서는 스프링 클라우드를 사용해 마이크로서비스 즉, 분산 시스템을 구축할 때 발생하는 문제를 관리하는 방법에 대해 정리하려고 합니다.
분산 시트넴을 구축할 때 발생하는 문제는 다음과 같습니다.
- 서비스 검색
- 에지 서버
- 구성 중앙화
- 서킷 브레이커
- 분산 추적
이후에는 스프링 클라우드를 사용해 소개한 문제들을 어떻게 해결하는지 간략하게 정리하려고 합니다. 그리고 책에서 마지막 절에 소개한 질문들에 답을 하는 방식으로 포스팅 하겠습니다.
1. 넷플리스 유레카를 검색 서비스로 사용
- 스프링 클라우드를 사용해 넷플릭스 유레카에 마이크로서비스를 등록하고, 클라이언트가 RESTful API와 같은 HTTP 방식의 요청을 넷플릭스 유레카에 등록된 인스턴스로 전송한다.
❓ 넷플릭스 유레카의 사용목적은 무엇인가?
- 넷플릭스 유레카(Netflix Eureka)는 서비스 중인 마이크로서비스를 발견하고 검색하는 데 사용되는 오픈 소스 소프트웨어입니다.
- 마이크로서비스 아키텍처에서는 여러 개의 작은 서비스들이 하나의 애플리케이션을 이루게 됩니다. 이러한 작은 서비스들은 각각 다른 시간에 시작되거나 중단될 수 있습니다. 따라서 마이크로서비스 환경에서는 각 서비스의 상태를 추적하고, 필요한 경우에 해당 서비스를 적절히 발견하고 검색하여 다른 서비스와 상호작용할 수 있도록 해야 합니다.
- 넷플릭스 유레카는 이러한 문제를 해결하기 위해 개발된 서비스 디스커버리 솔루션으로, 마이크로서비스 간의 통신을 용이하게 하기 위해 사용됩니다. 또한, 유레카를 이용하면 서비스의 가용성과 확장성을 높일 수 있으며, 로드 밸런싱과 같은 기능을 제공하여 서비스의 성능을 개선할 수 있습니다.
2. 스프링 클라우드 게이트웨이를 에지 서버로 사용
- 마이크로서비스 환경을 보호하고자 에지 서버를 사용한다. 즉 사설 서비스를 외부에서 접근하지 못하도록 숨기고 외부 클라이언트가 공개 서비스를 사용할 때 보호한다.
- 처음에 스프링 클라우드는 넷플릭스 주울 v1을 에지 서버로 사용했으나 스프링 그리니치가 출시된 이후로 스프링 클라우드 게이트웨이로 대체하는 것이 권장된다.
- 스프링 클라우드 게이트웨이는 스프링 5와 프로젝트 리액터, 스프링 부트 2 기반의 논블로킹 API를 사용한다는 점이 특징이다. 즉 더 많은 양의 동시 요청을 처리할 수 있으며, 이는 모든 외부 트래픽을 처리해야 하는 서버에게는 중요한 특성이다.
❓ 스프링 클라우드 게이트웨이의 주요 기능은 무엇인가?
- 라우팅(Routing): 클라이언트의 요청을 수신하고 목적지 서비스로 전달하는 역할을 합니다. 요청 경로, 헤더, 쿼리 매개변수, 요청 본문 등의 정보를 기반으로 유연한 라우팅 규칙을 정의할 수 있습니다.
- 필터링(Filtering): 요청과 응답에 대한 필터링을 제공하여 보안, 로깅, 인증 등의 기능을 적용할 수 있습니다.
- 로드 밸런싱(Load Balancing): 여러 개의 인스턴스로 구성된 서비스를 분산해서 처리할 수 있도록 로드 밸런싱 기능을 제공합니다.
- 서비스 디스커버리(Service Discovery): 서비스 디스커버리를 통해 스프링 클라우드 서비스 레지스트리나 Netflix Eureka와 같은 외부 서비스 디스커버리를 사용할 수 있습니다.
- 써킷 브레이킹(Circuit Breaking): 서비스의 장애나 부하 등의 문제로 인해 서비스 요청이 실패할 경우, 회복을 도와주는 써킷 브레이커 기능을 제공합니다.
- 분산 추적(Distributed Tracing): Zipkin, Sleuth와 같은 분산 추적 도구와 연동하여 분산 서비스의 추적 및 모니터링 기능을 제공합니다.
3. 구성 중앙화를 위해 스프링 클라우드 컨피그 사용
- 스프링 클라우드 컨피그를 사용하면 계층 구조로 구성을 관리할 수 있다.
- 예를 들어 공통 구성 정보는 공통 파일에 배치하고, 특정 마이크로서비스를 위한 설정은 별도의 구성 파일에 배치할 수 있다.
- 스프링 클라우 컨피그는 구성 변경을 감지하며, 스프링 클라우드 버스를 사용해 영향받는 마이크로서비스 알림을 보내는 기능도 지원한다.
앞의 다이어그램을 설명하면 다음과 같다.
- 마이크로서비스는 컨피그 서버에 구성을 요청하면서 시작한다.
- 컨피그 서버는 깃 저장소에서 구성을 가져온다.
- 깃 저장소에 깃 커밋이 푸시되면 컨피그 서버에 알림을 보내도록 깃 저장소를 구성한다.(선택 사항)
- 컨피그 서버는 스프링 클라우드 버스를 사용해 변경 이벤트를 게시한다. 변경에 영향받는 마이크로서비스는 이에 반응해 컨피그 서버에서 업데이트된 구성을 받아 온다.
❓ 스프링 클라우드 컨피그는 어떤 백엔드를 지원하는가?
- 스프링 클라우드 컨피그(Spring Cloud Config)는 다양한 백엔드 저장소를 지원합니다. 기본적으로는 Git이나 Subversion과 같은 버전 관리 시스템을 사용하여 프로퍼티 파일을 저장하고 관리할 수 있습니다.
- 파일 시스템(File System): 파일 시스템에 저장된 프로퍼티 파일을 사용할 수 있습니다.
- Vault: HashiCorp Vault와 연동하여 보안 관련 정보를 저장하고 관리할 수 있습니다.
- JDBC: JDBC를 사용하여 데이터베이스에 저장된 프로퍼티 파일을 사용할 수 있습니다.
- AWS Parameter Store: AWS Parameter Store와 연동하여 AWS 클라우드에서 사용하는 프로퍼티 파일을 사용할 수 있습니다.
- Consul: Consul과 연동하여 분산 시스템에서 사용하는 프로퍼티 파일을 사용할 수 있습니다.
4. 탄력성 향상을 위해 Resilience4j 사용
- 대규모 공조 마이크로서비스 시스템 환경에선 언제든 문제가 발생할 수 있다고 가정해야한다. 즉 장애가 있는게 당연하다고 간주하고, 장애를 처리할 수 있도록 시스템 환경을 설계한다.
앞의 다이어그램을 설명하면 다음과 같다.
- 서킷 브레이커가 닫힘 상태에서 시작해 요청을 처리한다.(닫힘 상태는 문제가 없음을 의미)
- 요청이 성공적으로 처리되는 한 닫힘 상태를 유지한다.
- 요청에 실패하면 카운터 값이 증가하기 시작한다.
- 설정한 실패 임계값에 도달하면 서킷 브레이커가 트립한다. 즉 추가 요청을 처리할 수 없는 열림 상태가 된다.
- 요청은 빠르게 실패한다. 즉 곧바로 예외를 반환한다.
- 설정한 시간이 지나면 서킷 브레이커가 반열림 상태로 전환되며, 프로브 요청을 보내서 장애가 해결됬는지 확인한다.
- 프로브 요청이 실패하면 서킷 브레이커는 다시 열림 상태로 돌아간다.
- 프로브 요청이 성공하면 서킷 브레이커는 닫힘 상태로 초기화 되며, 새 요청을 처리할 수 있다.
❓ Resilience4j가 제공하는 기능은 무엇인가?
📌 Resilience4j의 서킷 브레이커에 의해 보호되는 myService라는 REST 서비스가 있다고 가정해보자
- 의존하는 서비스에 도달할 수 없는 등의 문제로 서비스 내부에서 오류가 발생하기 시작하면 서비스는 500와 같은 오류를 반환하게 된다.
- 요청을 계속 보내서 입계값에 도달하면 서킷이 열리면서 빠른 실패 상태로 전환되며 CircuitBreaker 'myService' is open과 같은 오류 메시지를 반환한다.
- 오류가 해결되고 설정된 대기시간이 지난 다음에 프로브 요청을 보낸다.
- 호출에 성공해 서킷이 닫히면 서비스가 정상 동작하게 된다.
5. 스프링 클라우드 슬루스와 집킨을 사용한 분산 추적
- 공조 마이크로서비스의 시스템 환경과 같은 분산 시스템에서 발생하는 상황을 파악하려면 시스템 환경에 대한 외부 호출을 처리하는 과정에서 마이크로서비스 사이를 오가는 요청 및 메시지의 흐름을 추적하고 시각화 할 수 있어야 한다.
- 스프링 클라우드 슬루스는 상관ID를 사용해 하나의 처리 흐름에 포함된 요청과 메시지/이벤트에 표시를 남긴다.
- 또한 하나의 처리 흐름에서 나오는 여러 마이크로서비스의 로그 메시지를 쉽게 추적할 수 있도록 로그 메시지에 상관 ID를 덧붙인다.
- 스프링 클라우드 슬루스는 추적 데이터를 저장 및 시각화 하고자 분산 추적 시스템인 집킨(Zipkin)으로 보낸다.
- 스프링 클라우드 슬루스와 집킨이 분산 추적 정보를 처리하고자 사용하는 인프라는 구글 대퍼(Google Dapper)를 기반으로 한다.
- 대퍼에서는 전체 워크플로의 추적 정보를 추적 트리라고 하며, 기본 작업 단위와 같은 트리의 서브파트를 스팬이라고 한다.
- 스팬은 추적 트리를 형성하는 하위 스팬으로 구성된다. 상관 ID를 TraceID라고 부르며, 소속된 추적 트리의 TraceId와 고유한 SpanId를 사용해 스팬을 식별한다.
- 위의 그림은 Product Composite 정보 생성 처리 과정을 추적 트리로 시각화해서 보여주는 집킨 UI 화면이다.
- product-composite 서비스로 HTTP POST 요청이 전송되면 이에 대한 응답으로 products 및 recommendations 토픽에 생성 이벤트가 게시된다.
- 세가지 핵심 마이크로서비스가 이 이벤트를 병렬로 처리하며, 생성 이벤트의 데이터는 각 마이크로서비스의 데이터베이스에 저장된다.
❓ 분산 추적에 사용하는 추적 트리, 스팬의 개념은 무엇인가?
- 분산 추적(Distributed Tracing)은 분산 시스템 내에서 발생하는 서비스 간 요청과 응답의 전체 과정을 추적하여 분석하고 모니터링하는 기술입니다. 추적 트리(Trace Tree)와 스팬(Span)은 이러한 분산 추적 기술에서 중요한 개념입니다.
- 추적 트리는 분산 시스템 내에서 여러 서비스를 거쳐 전파되는 단일 요청의 전체 과정을 나타내는 트리 구조입니다. 추적 트리는 요청의 시작부터 끝까지 모든 단계를 포함하며, 각 단계는 스팬으로 구성됩니다.
- 스팬(Span)은 추적 트리의 노드에 해당하며, 단일 서비스에서 수행되는 작업 단위를 나타냅니다. 스팬은 시작 시간과 종료 시간, 태그(tag)와 로그(log)와 같은 메타데이터를 가지며, 상위 추적 트리와 연결되어 전체 요청 과정에서의 역할과 관련 정보를 기록합니다.
-
예를 들어, 분산 시스템 내에서 서비스 A가 서비스 B에 요청을 보내는 경우, 추적 트리는 전체 요청 과정을 나타내는 트리 구조로 표현됩니다. 이 추적 트리에서 각각의 스팬은 서비스 A에서의 요청 송신, 서비스 B에서의 요청 수신, 처리 및 결과 전송 등 서비스 내부의 작업 단위를 나타냅니다.
-
이러한 추적 트리와 스팬은 분산 시스템에서의 디버깅, 모니터링, 성능 최적화 등에 필수적인 개념으로 활용됩니다. 각각의 스팬에서는 성능 이슈나 에러가 발생하는 경우, 해당 스팬에 대한 메타데이터를 수집하고, 분산 추적 시스템을 통해 상위 추적 트리로 전달하여 문제점을 파악하고 대처할 수 있습니다.
