Spring Cloud Data Flow

입사하고 시간이 얼마 안 지났지만 굉장히 다사다난(?)한 일들을 겪었는데, 그 중 하나가 조직 이동이다. 연말 회고에서 그 때의 심경을 남기겠지만 이번 포스팅은 그 과정에서 운이 좋게도(?) 새로운 프로젝트를 시작하면서 Spring Cloud Data Flow(SCDF) 구축한 내용에 대해서 남기고자 한다.

 

이전에 스트림, 배치 기반의 마이크로서비스 개발 경험이 없어서(이번에 처음 Stream, Task 개념에 대해 학습했다) SCDF가 기존의 비슷한 역할을 수행하는 솔루션들과 비교했을 때 얼마나 큰 효용이 있는지 체감 못했지만, 현재 사용하는 입장에서 느낀 편리한 점은 스트림/배치 파이프라이닝이 굉장히 편하고, 모니터링 구축이 용이하다는 것이다.

 

기본적으로 Spring Cloud Stream과 Binder(Kafka, RabbitMQ 등)를 통해 파이프라인 구축을 위해서 각 컴포넌트 간의 메시징 토픽을 결정하는 불편함이나, 하나의 파이프라인이지만 한 눈에 확인하기 어려운 문제가 생길 수 있는데, SCDF에서 제공하는 대시보드를 사용하면 아래 보이는 것처럼 편리하게 UI로 스트림 컴포넌트(Source, Processor, Sink) 파이프라이닝이 가능하다.

 

물론 그냥 뚝닥 되진 않고, input, output 별칭으로 설정된 functional bindings을 사용해 배포할 때 컴포넌트를 매핑해 준다고 한다.

https://dataflow.spring.io/docs/recipes/functional-apps/scst-function-bindings/

스트림 파이프라인

 

Task(독립적으로 실행되며, 간단한 데이터 처리, 배치 작업을 처리하는 단위)의 순차 실행을 구축하기도 쉽고, 스케줄링(crontab 사용)도 제공한다.

 

SCDF는 로컬에서 세팅하고 로컬에 존재하는 jar 파일을 등록해 배포가 가능하다는 것도 편리하지만, SCDF 자체적으로 Spring Cloud Deployer를 사용하기 때문에 쿠버네티스 클러스터 환경에도 손쉽게 배포 가능하다.

https://dataflow.spring.io/docs/installation/

 

Spring Cloud Data Flow

기본적인 SCDF 구축에 필요한 서버 컴포넌트가 다양한 만큼 레퍼런스의 양도 상당하다.

 

개요, 버전 정보

https://dataflow.spring.io/docs/installation/

 

간단한(?) 셋업 가이드(local, k8s, cloud foundry...)

https://spring.io/projects/spring-cloud-dataflow

 

세부 설정 가이드

https://docs.spring.io/spring-cloud-dataflow/docs/current/reference/htmlsingle/

 

SCDF를 구축하기 위해서 띄워야 하는 서버 컴포넌트는 크게 4가지다.

1. Dataflow Server

2. Skipper Server

3. DB(mysql, mariadb, oracle... 등)

4. Message Queue(RabbitMQ, Kafka)

 

아래는 개략적인 동작 흐름(호출 방향 중심)을 나타낸 그림이다

 

1. dataflow server:
   • 스트림 및 태스크를 정의하고 배포, 관리하는 역할
   • 스트림과 태스크의 상태를 추적하고 모니터링
   • 스트림 및 태스크의 실행을 시작하고 중단
2. skipper:
   • 버전 업그레이드 및 롤백과 같은 배포 관련 작업을 수행
   • 서로 다른 환경 간의 애플리케이션 배포를 단순화

배포된 태스크는 단일 작업을 수행하고 종료되며, 스트림의 경우 컴포넌트(source, processor, sink) 간 MessageQueue(위에서 kafka)통해 비동기 메시징 처리를 수행한다.

 

skipper, dataflow server 를 구축하면서 세팅한 설정 정보는 크게 아래와 같다.

Skipper

1. db connection
2. imagePullSecrets 설정(private image hub 사용시)
3. Binder(kafka, zookeeper) 설정
4. prometheus export

 

Dataflow

1. db connection
2. imagePullSecrets 설정(private image hub 사용시)
3. docker registry 설정
4. skipper server connection
5. prometheus export

 

DB

dataflow server 와 skipper server 에서 사용하는 테이블이 사전에 세팅돼 있어야 한다. (RDB만 지원)

 

기본적으로 내부에서 flyway를 통해 DB 테이블을 세팅해주지만, 직접 세팅할 수도 있다.

https://github.com/spring-cloud/spring-cloud-dataflow/tree/main/spring-cloud-dataflow-server-core/src/main/resources/schemas

 

Monitoring

스트림은 생명 주기가 비교적 길어 모니터링이 수월할 수 있지만, 태스크(특히 스케줄링된 것)처럼 단순 작업을 처리하고 종료되는 프로세스는 원하는 시점에 모니터링 하기 쉽지 않다.

 

그래서 SCDF에서는 prometheus rsocket을 사용해 매트릭을 수집한다 

https://dataflow.spring.io/docs/feature-guides/general/server-monitoring/

 

rsocket 설정 방법

https://dataflow.spring.io/docs/installation/kubernetes/kubectl/#enable-monitoring

 

크게 복잡한 것은 아닌데, 태스크/스트림에서 prometheus-rsocket(proxy)서버로 매트릭을 전송하고, 우리가 운영 중인 prometheus 서버에서 주기적으로 이 proxy 서버에서 저장하고 있는 내용을 스크랩 해 가는 방식인데

공식 문서에서, proxy 서버의 사전 정의된 스크랩 엔드포인트(/metrics/connected, /metrics/proxy)를 참조한다고 한다.

 

직접 프로메테우스를 구축하면 해당 엔드포인트로 스크랩 설정을 해줘야 하지만, 프로메테우스를 추상화한 솔루션을 사용하면 prometheus.io/scrape, prometheus.io/path 어노테이션으로 손쉽게 기존 인프라와 연동이 가능하다.

1. Prometheus is configured to scrape the /metrics/connected and /metrics/proxy endpoints of the proxy(ies) and not the application instances.

 

개인적으로 proxy 서버에 매트릭을 적재하고 이를 기존 인프라(prometheus)에서 수집해 가는 방식이 새삼 유용하다 생각했는데, 이런 구조를 채택하면 스트림과 태스크의 지표를 별도로 적재하면서도 기존에 운영하던 인프라와 손쉽게 붙였다 떼었다 할 수 있기 때문이다.

 

TIP(?)

온라인에 레퍼런스가 많지만, 산재된 지식이 많고 개발 환경이 동일하지 않기 때문에 헷갈리는 설정들이 많을 수 있다.

 

필자의 경우에는 기존에 구축해 놓은 시스템 레퍼런스가 있어서 삽질(?)의 시간이 비교적 적었지만, 좋은 레퍼런스가 있음에도 헷갈렸던 부분이 많다.

 

그 때, 학습에 큰 도움이 됐던 방법은 (내가 종종 새로운 프레임워크를 학습할 때 쓰는 방법이기도 한데)프로젝트를 하나 판 뒤에 maven 에서 실제 의존성을 하나씩 추가하면서 yml 설정을 샘플과 똑같이 해보고, 코드에서 실제로 어떻게 동작하는지 command+b 등으로 탐색하면서 이해하면 조금 더 쉬웠던 것 같다

 

SCDF 공식 레포 이름을 바탕으로 maven Repository에 서칭 가능하다

https://github.com/spring-cloud/spring-cloud-dataflow