개요

API 서버 설계 후 SCDF에 회사 업무와 연관되어 공부를 하다가 작년 네이버 DEVIEW에서 발표한 SCDF 관련 자료가 있어 정리해보았다.

• 영상

  • https://youtu.be/eXZ3W7zlpmk?si=_ywFSUYV1E_swC8

• 영상 자료

  • https://deview.kr/data/deview/session/attach/[135]SCDF%EB%A1%9C+%ED%95%98%EB%A3%A8+N%EB%A7%8C%EA%B3%A1+%EC%9D%B4%EC%83%81+VIBE+%EB%A9%94%ED%83%80+%EB%8D%B0%EC%9D%B4%ED%84%B0+%EC%8B%A4%EC%8B%9C%EA%B0%84%EC%9C%BC%EB%A1%9C+%EC%A0%81%EC%9E%AC%ED%95%98%EA%B8%B0!+-+%EB%B0%B0%ED%8F%AC%EC%9A%A9%20(1).pdf

• SCDF 공식 문서
  https://dataflow.spring.io/docs/installation/local/manual/#install-messaging-middleware

1. 대용량데이터를처리하는2가지방식

1.1 데이터를 다루는 프로그래밍 환경

배치 : 대량의 데이터를 벌크(일괄)처리하는
스트림 : 무한한 데이터를 실시간(스트림)처리
=> SCDF는 스트림 처리에 가깝다.

1.2 더 많은 데이터를 더 빠르게 처리하는 기법

부하분산 & 파티셔닝

• 워크플로 매니지먼트
  배치처리(대규모데이터) : Airflow - Spark
  스트림처리(일부, 개별데이터) : kafka - SCDF - K8s
  => SCDF로 스트림 외 배치도 처리 가능한데 아직은 Minor 함.

1.3 누가 스트림 처리를 사용해야 할까?

• 데이터를 수집하거나 저장하지 않는다.
• 무한한 작은 데이터가 지속적으로 유입되고 이를 연속으로 처리한다.
• 데이터가 도착하자마자 처리한다.
  => 신용카드 부정사용, 구매처리, 실시간 금 시세, 위치추적

네이버 VIBE

매일 같이 오픈 되는 음원, 앨범 데이터를 공급사로 공급받아 적재하는 프로세스가 있음.
-> 2019년 8월에 12,700,000곡의 메타 데이터를 적재해달라는 요청이 옴
-> 일간 5천곡 가능 = 6년뒤에나 적재 가능
=> 연말까지 불가

2. 레거시전환계획과전략

2.1 배치 + 젠킨스로는 충분하지 않다

공급사로부터 데이터 받음 - DB 저장 - 배치로 가공 - API로 제공

문제가 된 부분은 AOD JOB(파일을 다루는 JOB)
-> AOP JOB을 늘려봄
-> 10개로 늘리니까 5만곡으로 늘어남(부하분산)
-> 추가 개선 해보겠다.

프로젝트 운영 중 문제
1. 코드뭉치 업로드
2. 전체코드로드에 따른 자원소모
3. 커넥션 잦은 연결/끊음
4. 변경/확장의 어려움
5. 워크플로 관리의 어려움
6. 특정 Job에서 Hadoop을 추가해서 사용하는 경우?
7. Job이 실행도중 Lock이 걸리는 경우 다음 데이터가 처리 되지 못함

고민

• 현재 시스템의 개발/운영 하는 방식에 어떤 문제점이 있는가?
• 새롭게 개발하면서 우리가 얻고자 하는 가치는 무엇인가?
• 어떠한 기준을 가장 우선 순위에 두고 아키텍처를 설계 할 것인가?
• 어떤 데이터 저장소를 사용하는게 적합한 것인가?
• 어떤 구현방식으로 개발해서 구축할 것인가?
  => 여러가지 조사한 결과 SCDF가 알맞다고 판단

2.2 STOP/SWITCH/MODELING 기초공사

젠킨스 : 42
쿼리수 : 976
테이블 : 244
테이터수 : 703,033,612

Jenkins Job Stop : 중지 할 수 있는 기능들은 최대한 찾아서 정리
Function Switch : 위임 가능한 기능들은 상호협력해서 전환한다.
MongDB Modeling : Full Embed, Reference Embed, Subset Pattern

2.3 Dual-Write로 데이터 적재하기

데이터 입수 서버를 듀얼로 열었음.
/v0 -> 레거시
/v1 -> 신규 API 호출(SCDF로 적재 된 데이터)

2.4 RDBMS -> MongoDB 마이그레이션

MongoSyphon : json 파일 제공하면 마이그레이션해주는 기능이 있음
450,000,000곡 -> 쿠버네티스 환경에서 지속적으로 마이그레이션을 할 수 있도록 함

2.5 배포, 롤백, 리마이그레이션 전략 세우기

한대 배포해보고 문제 있으면 롤백하고 없으면 하나 배포하고 다음날 또 배포하고...

3. SCDF 스트림 구조와 설계

SCDF란?
Microservice based Streaming and Batch data processing for Cloud Foundry and Kubernetes

Data Flow Server - 전용 Database -> 대쉬보드 제공
Skipper Server - 전용 Database -> DFS에서 위임 받아 실제 배포하는 역할

3.1 Functional Interface로 개념 이해하기

• Source : Supplier<R>
• Processonr : Function<T,R>
• Sink : Consumer<T>
• 메세지 미들웨어 이용해서 전달 : Kafka나 RabbitMQ 사용

SpringBatch의 Reader-Processor-Writer와 동일한 개념

3.2 SCDF 컨셉 이해하기

어플리케이션 구현 -> 도커허브 업로드 -> SCDF 등록 -> 파이프라인 생성 -> 스키퍼 서버에 요청 -> 스트림 배포

• Application Type
  • long-lived : source, processor, sink
  • short-lived : tasks

3.3 데이터 플로우 이벤트 전달 방식의 이해

• Event Driven Microservice : 이벤트 버스
• Spring Cloud Data Flow : 메세지 미들웨어
  - app1 -> kafka -> app2 -> kafka -> app3
  - Kafka Topic은 SCDF에서 자동으로 만들어줌
  • 장점 : app2가 잘못되어도 다시 실행되면 컨슘 됨

topic name : {streamName}-{applicationLabelName}

3.4 데이터 플로우 스트림 연결 방식의 이해

• tap : 다른 애플리케이션의 이벤트를 연속해서 처리한다.
  - 기존 스트림 명을 넣어주면 연결이 됨
• destination : 카프카 토픽 이벤트를 처리한다.
  - 시작을 카프카 토픽으로 하고 싶을 때

3.5 대표적인 엔트리포인트 소비방식 3가지

시작점을 어떻게 잡는게 좋을까? 일반적인 POST/GET으로 받는데
신규 입수 서버로 요청이 들어오면 어떻게 할까?
CDC는 힘듦, 기존처럼 HTTP는 너무 똑같은데, Destination으로 소비하는 전략 사용

그다음 고민, 이게 맞나?

3.6 DAG - 방향성 비순환 그래프 방식으로 설계하기

Directed Acyclic Graph, DAG(대그)

• 반복이나 순환을 허용하지 않는다.
• 애플리케이션간의 순환 실행을 방지하기 위해서 중요함

다음 고민, 복잡도 낮추기

3.7 팬인(Fan-in) & 팬아웃(Fan-out) 설계측정

모듈을 계층적으로 분석하거나 시스템 복잡도를 측정하는 기법

3.8 IO처리와 DB접근은 다르게 고민하기

파드가 늘어나면 발생 할 문제 고민해봐야함

4. SCDF 실 서비스 적용하기

Prometheus? Grafana?

4.1 SCDF 설치하기

Kubectl
7가지 설치

4.2 SCDF 개발하기(Source, Processor, Sink)

application.yml에 매칭되는 이름이 있어야함

4.3 SCDF 무중단 배포전략

• app register transform:V1
• time | transform | log
• app register transform:V2
• update to transform:V2
• rollback

4.4 SCDF 모니터링하기

Prometheus 활용

• Stream과 Task를 함께 배포하고 모니터링 하려면 RSocket을 활용하라고 권장

이렇게 SCDF로 데이터 흐름 관리까지 해봤음.
그런데 해결해야 할 문제는 파일을 빠르게 처리하는 것.
데이터는 이전에도 문제 없었음.
둘 다 빨리 되는데 SCDF로 바꾸면서 데이터 흐름 잘 볼 수 있다는 점은 장점.
근데 아직 파일 어플리케이션 속도는 해소 안됨 -> 스케일링으로 해소

4.5 SCDF 스케일링 기술을 이용한 성능 끌어올리기

Manual Scaling / Data Partitioning

Manual Scaling : Pod 갯수 조절
Data Partitioning : 파티셔닝

하지만 무작정 갯수 늘려버리면 비용 증가

그래서 SCDF에선 동적으로 컨테이너 수를 조절함.
https://www.youtube.com/watch?v=IDH6X1pmgxc

VIBE SCDF Stream's Show Data Pipeline

• Stream : 8
• Application : 21
  - 장점 : 갯수 줄었음. 하지만 그보다 좋은 건 데이터 흐름 볼 수 있고, 어디를 개선해야할 지 알 수 있고, 해당 부분만 교체할 수 있고, 스케일링이 가능하다는 점

하루에 5,000 -> 50,000 -> 480,000 -> 현재는 N만곡 처리 가능(공급받는대로)

Additional

1. CDS - Kafka Connect + UI
2. Kafka Consumer Lag
3. Central Log

• 댓글 남기기...
• SCDF 공부하는 분들이 있다면 한번쯤 보는걸 추천하고 싶다.

마치며

관련 한국어 자료가 없어 이해하는데 어려움을 겪다가 해당 pdf 자료를 찾게 되었는데 발표 자료다보니 발표 영상을 유튜브에 검색 후 찾게 되었다.
영상을 모두 보고 확실히 전체적인 흐름과 SCDF 제공 기능을 이해할 수 있었고 이전에 Spotify API를 활용한 프로젝트를 진행 한 적이 있는데 당시 데이터를 가져오는데 있어서 전체 데이터를 받아오지 못하여 검색 시 매번 Spotify 서버로 검색 하도록 구현했었던게 기억이 났다. 그리고 트랙 < 앨범 < 아티스트 형식의 구조 때문에 DB 설계에 어려움을 겪었던 기억도 있었는데 이런 음악 관련 서비스를 다시 한번 도전해보고 싶어졌다.