[DE] 2023 DEVIEW - SCDF로 하루 N만곡 이상 VIBE 메타 데이터 실시간으로 적재하기 (스트림 처리 레거시 극복일지 엿보기)

지난 2월에 있었던 DEVIEW 2023에서 가장 인상 깊게 들었던 세션
"SCDF로 하루 N만곡 이상 VIBE 메타 데이터 실시간으로 적재하기"

세션의 주 목적은 "SCDF를 사용해보세요!" 였겠지만,
실시간 데이터를 직접 다루지는 않는 입장에서는 조금 다른 관점에서 세션을 들을 수 있었다.

우선 서비스 데이터를 직접 다뤄보지 못하는 아쉬움을 세션을 통해 해소할 수 있었고,
기존 작업에서 어떻게 문제점을 찾고 극복해 나갔는지 그 여정을 듣고 배울 수 있어서 많은 도움을 받을 수 있었다.
첫 입사 때부터 지금까지도(ㅠㅠ) 얼굴도 모르는 분들이 만들어 놓고 떠나신 레거시 작업을 해결해보려다 실패한 적이 많았는데,
이 세션을 듣고 어떤 방향으로 다가가면 좋을지 조금이나마 가이드라인을 잡을 수 있게 되었다.

SCDF로 하루 N만곡 이상 VIBE 메타 데이터 실시간으로 적재하기

 

1. 대용량 데이터 처리 방식

우선 데이터 처리 방식은 크게 배치 처리(batch processing)와 스트림 처리(stream processing)으로 나눌 수 있다.
특정 주기마다 일괄적으로 데이터를 한꺼번에 처리하면 배치(batch),
실시간으로 무한하게 데이터가 들어올 때마다 이벤트성으로 처리하면 스트림(stream)으로 구분할 수 있다.
배치 처리는 보통 대규모 데이터를 주기적으로 처리하기 때문에 시간이 오래 걸리고 복잡한 분석을 할 때 주로 사용하고,
스트림 처리는 데이터 크기는 작지만 빠르게 처리해야 할 때 많이 사용한다는 차이점이 있다.

그리고 "대용량" 데이터를 "빠르게" 처리할 수 있는 방법은 아래 3가지가 있다.

• 부하분산(load balancing)
  : 작업을 여러 서버에 나눠 분산 처리하는 방식
• 파티셔닝(partitioning)
  : 처리할 데이터를 분할하여 처리하는 방식
• 워크플로 매니지먼트(workflow management)
  : 데이터 처리 파이프라인 관리하는 부분

3가지 중에서 가장 강조된 것은 자칫하면 많이들 무시하고 넘어갈 수 있는 "워크플로 매니지먼트"였다.
사실 성능적으로는 위 2가지가 중요한거 아닌가..? 싶으면서 가장 의아했던 부분이지만 들으면서 공감이 많이 됐던 부분이다.
어떤 흐름으로 데이터가 가공되고 있는지 알아야 문제가 발생했을 때 빠르게 캐치하고 처리할 수 있기 때문에
레거시를 극복하기 위해 가장 필요한 부분이지 않을까 싶다.

데이터 처리 방식이 배치와 스트림으로 나뉜 것처럼,
워크플로 매니지먼트 툴도 배치와 스트림 각각 대표적으로 쓰이고 있는 것이 다르다.
배치는 주로 airflow를 많이 사용하고, 스트림은 여기에서 소개하게 될 SCDF(Spring Cloud Data Flow)를 많이 사용한다.
(airflow에 대해 적용한 예시로는 아래 쏘카에서 도입한 고정을 참고하면 좋을 것 같다.)

쏘카 데이터 그룹 - Airflow와 함께한 데이터 환경 구축기(feat. Airflow on Kubernetes)

 

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

해당 세션을 준비하신 부서에서는 매일 오픈되는 앨범 데이터와 음원, 비디오 등의 파일을 공급사로부터 요청 받아 저장하는 업무가 진행되고 있었다.

문제가 발생한 것은 3년 전으로 거슬러 올라간다.
당시 하루 5천곡 정도 처리할 수 있는 상황이었는데, 기획팀으로부터 "1270만 곡을 올려주세요!"라는 요청사항이 들어왔다고 한다.
계산을 해보니.. 12,700,000/5,000 = 2,540일(6.958..년)을 돌려야 끝나는 작업이었고..
당연히 요청자는 6년 동안 기다릴 수 없는 상황이었기에 시간을 단축시켜야만 하는 상황이었다.

기존에 진행하던 방식은 공급사로부터 데이터를 받으면 먼저 db에 적재한 뒤, jenkins 기반으로 배치 처리를 통해 가공한 뒤 api로 서빙하는 방식이었다.
여러 데이터 중 음원 관련된 처리(인코딩 등 ...)를 하는 부분이 가장 문제가 되었기에
"배치를 스트림으로 바꿔서 그냥 카프카 쓰면 되지 않을까?" 로 접근을 했으나.. 음악 도메인 특성 상의 문제가 발생했다.
특정 노래가 있으려면 그 노래에 대한 앨범이 있어야 하고, 앨범이 있으려면 그 앨범에 대한 아티스트 정보가 있어야 했기에,
단순히 카프카로 바꾼다고 선행조건을 만족시킬 수는 없었다.

1) 분산 처리
1차적으로는 앞에 언급했던 부하 분산과 파티셔닝을 도입했다.
기존의 jenkins 동일한 job을 10개로 분할해서 진행시킨 다음, 데이터도 10분할해서 작업시키도록 했다.
그 덕분에 10배 더 빠르게 작업할 수 있어서 5천곡/1일 작업을 5만곡/1일로 향상시키고 6년 걸려야 했던 작업도 1년 안에 가능해졌다.
당장 급한 불은 껐지만, 아직 더 향상시킬 수 있는 길이 남아있다고 보고 개선점을 찾아나갔다고 한다.
(너무 소소해보일수도 있지만 이런 부분에서도 깨달음을 얻을 수 있었다.
당장 급한 일이 해결됐으면 이 부분은 안보고 다른 일에 신경썼을 것 같은데,
이렇게 끈기 있게 다가가야 근본적인 것이 해결되고 데뷰 발표까지 할 수 있구나..! 하는 생각이 들었다)

2) 기존 처리 방식 분석

기존 작업을 살펴보니 하나의 jar 파일에 음원 관련된 작업 뿐만 아니라 앨범, 아티스트 등 다른 작업이 한꺼번에 뭉쳐져 있었다고 한다.
그렇기에 음원 등 특정 job만 실행시키려고 해도 전체 프로세스를 로드해야 했고,
만약 앨범 작업을 돌리려는데 아티스트 작업 코드가 잘못 작성되어 있으면 앨범 작업을 돌릴 수 없는 의존적인 문제가 있었다.
또한 공통적인 db 커넥션도 존재하고, 무엇보다 워크플로우 관리가 어려운 것이 가장 문제였다.
앨범 전에 아티스트 작업이 되어야하는걸 코드를 뜯어봐야만 알 수 있었기에 전체적인 흐름을 관리하기 어려웠다.

3) 기초공사
우선 기초적으로 덜어낼 수 있는건 최대한 덜어내는 부분부터 진행되었다.
기존 jenkins job을 살펴보니 42개가 있어서 최대한 중지시킬 수 있는 job은 중지시켰고,
사내 여러 플랫폼을 최대한 활용해서 위임 가능한 기능들은 최대한 위임시키는 방향으로 나아갔다.
(모든걸 직접 하려고 하지 말고 최대한 사용할 수 플랫폼 등이 있으면 적극 활용하는 전략도 중요한 것 같다.)

또한 이 시기에 전사적으로 Oracle DB 사용을 지양하는 방향으로 가고 있었기에 어떤 DBMS로 전환할지 고민하다가 
기존 RDBMS 형태로 인해 많은 테이블로 나눠 저장하던 데이터를 하나의 document 형태로 저장할 수 있는 MongoDB로 결정되었다고 한다.
전환하는 과정은 dual write 방식으로 입고 서버를 하나 더 만들어 투트랙으로 진행하고 api 서빙도 버전을 2가지 만들었으며.
특히 MongoSyphon(https://github.com/johnlpage/MongoSyphon)이라는 오픈소스를 통해 쉽게 RDBMS에서 MongoDB로 마이그레이션할 수 있었다고 한다.
(찾아보니 MongoDB에 실무자 분들이 직접 만든 오픈소스인 것 같아서 더 믿음직스럽다!)

GitHub - johnlpage/MongoSyphon: A tool for transferring data from a Relational Database to MongoDB

 

3. SCDF

이제 가장 중요하게 다뤄진 workflow 부분이다.
SCDF는 마이크로 서비스 기반의 스트림 또는 배치 데이터 프로세싱을 컨테이너 환경에서 진행할 수 있도록 도와주는 툴이다.
(공식 사이트 : https://dataflow.spring.io)

Spring Cloud Data Flow

스트림과 배치 작업 모두 가능하지만 스트림 작업과 관련된 기능이 더 많이 제공되고 있어서 스트림에 좀 더 최적화 되어 있다고 한다.

위 사진처럼 data flow server에서 데이터 흐름이나 환경설정 정보를 저장해두고,
실제 동작은 skipper server를 통해 kubernetes 환경에서 진행된다는 것이 SCDF의 큰 장점이다.

SCDF 작업을 위해서는 애플리케이션을 만들어줘야 하는데,
데이터를 받아오는 or 처리 or 적재하는 작업인지에 따라 각각 source, processor, sink type으로 분류하여 생성해줘야 한다.
특히 각 type 사이마다 kafka 또는 RabbitMQ 등 메시지 미들웨어가 존재하는 덕분에
작업 중간마다 데이터를 저장해주고, 중간에 오류가 생겨도 데이터가 날라가지 않고 메시지 미들웨어에 저장됐다가 복구되면 다시 이용할 수 있는 장점이 있다.

또한 SCDF가 마이크로 서비스 기반인 만큼 애플리케이션 단위는 최대한 작은 작업 단위로 만들어줘야 하고,
데이터 파이프라인은 위 사진처럼 대시보드에서 각 애플리케이션을 drag-n-drop 해서 손쉽게 구축할 수 있다.

그렇다면 데이터 파이프라인을 잘 구축했다는 것은 어떻게 평가할 수 있을까?

1) DAG (Directed Acyclic Graph)
Airflow를 주로 다뤄봤다면 많이 들어봤을 DAG는 반복이나 순환을 허용하지 않는다.
데이터 파이프라인은 순환되면 안되는 문제가 있기 때문에, 해당 파이프라인이 DAG인지 여부를 확인해서 잘 구축되었는지를 1차적으로 확인할 수 있다.

2) fan-in / fan-out
각 애플리케이션마다 몇개의 애플리케이션으로부터 input을 받고, 몇개의 애플리케이션으로 output이 되는지를 측정하는 것으로,
이를 통해 얼마나 복잡하게 파이프라인이 구현되어 있는지 파악할 수 있다.
데이터 파이프라인도 simple is the best로 fan-in, fan-out이 너무 과도하게 커서 복잡한 구조는 아닌지 확인할 수 있다.

 

4. SCDF 실 서비스 적용하기 (성능 끌어올리기)

우선 설치는 docker-compose, helm 및 kubectl 3가지 방식으로 진행할 수 있는데,
kubectl로 진행하면 어떤 dbms와 메시지 미들웨어 등을 사용하는지 관리할 수 있어서 더 권장한다고 한다.
설치 과정은 아래 링크를 참고해서 진행할 수 있다.

Documentation | Spring Cloud Data Flow

전체적인 파이프라인 형태는 위 사진과 같은데,
기존에 문제이던 성능을 끌어올리기 위해서는 SCDF의 아래 3가지 기능이 중점적으로 이용되었다고 한다.

1) 파티셔닝
앞에서 다룬 파티셔닝 기능 설정을 아래와 같이 파라미터 입력을 통해 제공해줘서 데이터를 몇개의 크기로 분할할지 직접 결정할 수 있다.

2) 무중단 배포 전략
메시지 미들웨어를 이용하는 SCDF의 특징 덕분에
애플리케이션 코드가 변경되었다고 해서 파이프라인을 셧다운시킨 뒤에 다시 실행해야 하지 않고
transform 과정만 잠깐 중단시키는 동안 메시지 미들웨어에서 데이터를 저장해줬다가 다시 흘러가도록 배포할 수 있다.

https://dataflow.spring.io/docs/2.9.x/stream-developer-guides/continuous-delivery/cd-basics/

3) autoscaling
마지막으로 쿠버네티스 환경을 이용했기 때문에 누릴 수 있는 기능으로,
실시간으로 갑자기 처리할 데이터가 많아지면 자동으로 프로세서 수가 증가했다가 다시 데이터 수가 적어지면 낮아진다.

이런 기능들 덕분에 일일 5천 곡만 처리할 수 있던 작업을 이제는 하루에 N만곡까지 처리할 수 있는 큰 성과를 거뒀다고 한다 👍🏻

 

---

 

우선 나는 스트림 데이터를 현업에서 다루지 않고, 슬프게도 아직 자바를 잘 다루지 못하기 때문에 SCDF와는 거리가 좀 먼 사람이었지만,
해당 세션을 통해 실시간 데이터는 이렇게 처리할 수 있다는걸 간접적으로 경험할 수 있었다.
기회가 된다면 사이드 프로젝트로 유튜브 등 실시간으로 생성되는 데이터를 스트림 형태로 받아와 대시보드 구축까지 해보는 작업을 진행해보고 싶다.

또한 2019년에 해당 문제가 시작됐으니 최대 3~4년 정도 소요된 것 같은데,
레거시를 덜어내고 새로운 툴을 기반으로 도입하는 과정이 순탄치 않구나를 느낄 수 있었다.
마지막에 함께 노력한 동료분들에게 감사를 표한 연사님의 말씀처럼
해당 솔루션을 찾는 데까지 여러 팀원분들의 수많은 고민들과 노력이 함께했기에 무사히 SCDF를 잘 적용하지 않았을까 싶다.
특히 아래 5가지 관점으로 접근해서 고민하고 해결책을 찾아나간 부분도 인상깊었다.

비록 3-4년 간의 노하우를 1시간의 세션으로 압축해서 들으면서 바로 해답을 들었기 때문에 레거시를 덜어내는 과정이 얼마나 어려웠을지 감히 체감할 수는 없겠지만,
그저 모른채 무시하고 있던 잘 돌아가기는 하지만 너무 오래 걸리는 나의 레거시 작업들이 하나둘씩 떠올랐다..🙄
언젠가 이런 예기치 못한 작업이 들어올 수도 있을테니, 나도 레거시 작업을 그냥 잘 돌아간다고 피하지 말고 근본적인 문제 원인을 파악해 기술 포인트를 찾아 해결해나갈 수 있었으면 좋겠다..!!