토스테크

안녕하세요. 토스증권 실시간 데이터팀 강병수입니다.
토스증권은 실시간 데이터 파이프라인을 적극적으로 구성해서 활용 중인데요. 데이터 영역에서는 빅데이터를 실시간으로 적재하고 활용하기 위해 실시간 데이터 파이프라인을 구성해서 활용 중이고, 서비스 영역에서는 CQRS(Command and Query Responsibility Segregation) 아키텍처를 적용하는 과정에서 실시간 데이터 파이프라인을 활용하고 있습니다.
서비스가 계속해서 성장하면서 활용 사례가 쌓여가다 보니 어느새 수천 개의 실시간 데이터 파이프라인을 운영하게 되었습니다. 이번 글에서는 증권사의 실시간 데이터 파이프라인을 대규모로 구성하고 운영해 온 경험을 소개하려고 합니다.
실시간 데이터 파이프라인이란?
데이터 파이프라인은 우리에게 익숙한 개념이죠.
원천 테이블 A를 가공해서 많은 사람들이 사용하기 더 좋게 '구분' 값을 붙여서 B 테이블로 만들고, '구분' 별 수량 집계를 필요한 사람은 B테이블을 활용해서 집계 결과를 C로 만들어서 사용합니다.
데이터의 활용성이 높아지도록 중간 산출물을 저장해가며 변환을 해나가는데요. 실시간 데이터 파이프라인은 이 과정들이 이벤트가 발생하면 즉시 수행되는 '실시간' 성격을 가진 데이터 파이프라인입니다.
실시간 데이터 파이프라인은 서비스가 성장하면서 수요가 늘어납니다.
서비스가 성장해서 데이터가 너무 커지면, OLTP 데이터베이스에서 OLAP 데이터베이스 배치로 하루 치 덤프로 데이터를 가져오는 방식에 한계가 찾아옵니다. 데이터를 옮기는 시간이 서비스 요건을 충족할 수 없을 정도로 너무 오래 걸리거나, 가져가야 할 데이터가 너무 크다 보니 원천 데이터베이스에 큰 부담을 주기 때문이죠. 이런 문제가 커지면 배치 성격으로 데이터를 가져가던 방식에서, 데이터가 생성되면 즉시 실시간으로 가져가는 방식으로 문제를 해결하기 시작합니다.
서비스가 성장하면서 서비스 영역에서도 유사한 상황을 겪게 돼요. 원천 데이터베이스로 활용하는 OLTP 데이터베이스는 집계 성격의 쿼리나 여러 테이블 간 대규모 Join이 필요한 경우 혹은 배치 작업으로 테이블 전체를 스캔하는 쿼리들을 모두 지원하기가 어려워집니다. CQRS 패턴을 적용하여 이 문제를 풀기 시작하는데요. 결국 OLTP 데이터베이스에서 OLAP 데이터베이스로 실시간으로 데이터를 이동 시켜주는 역할을 실시간 데이터 파이프라인이 수행합니다.
데이터의 양적인 측면에서도 실시간 데이터 파이프라인이 필요하지만, 이뿐만 아니라 유저들은 더 빠른 반응을 보여주는 성숙한 서비스를 요구합니다. 주식 종목 랭킹을 보여주거나 증시 관련 뉴스를 제공할 때 실시간 시황이 반영된 콘텐츠를 요구하는데, 이 역시 실시간 데이터 파이프라인을 통해 목표를 달성하고 있습니다.
이러한 문제들을 풀어나가는 과정에서 토스증권은 어느새 실시간 데이터 파이프라인을 수천 개 구성하여 운영하게 되었습니다.
운영을 잘한다는 것
모든 일에 실시간이라는 단어가 들어가면 굉장히 고된 일이 됩니다. 데이터 파이프라인에 실시간이라는 단어가 추가되면 다음과 같은 성격을 갖게 돼요.
데이터 이동에 있어서 최소 Latency를 보장해야 하고, 동시에 365일 무중단 운영을 해내야 합니다. 또 데이터 이동 과정에서 유실은 발생하면 안되고, 중복은 최소화 돼야 합니다. 위 요건들이 모두 잘 지켜지고 있는지 모든 파이프라인에 대해서 모니터링이 되고 있어야 하죠.
또한 각각의 파이프라인이 독립적으로 리소스를 할당 받아야 합니다. 중요도가 굉장히 높은 주문의 체결을 처리하는 파이프라인이 다른 파이프라인의 추가에 따라 영향을 받으면 안되기 때문이에요. 독립적으로 리소스를 할당하기 위해서는 실시간 데이터 파이프라인이 몇백 개 혹은 몇천 개가 추가 되더라도 요구조건을 충족하도록 확장성을 고려한 클러스터 설계도 필요합니다.
나아가서 운영 관점에서는 파이프라인 시각화도 중요한 주제입니다. 파이프라인 시각화는 운영 편의성과 팀 간 커뮤니케이션 비용을 확연히 줄여줍니다. 수천 개의 파이프라인에서 특정 Job이 현재 사용 중인 것인지, 어디에 쓰이고 있는지, 뒷단의 어떤 것과 연결이 되어있는지 찾아보는 것은 굉장히 고된 일이지만 운영하다 보면 반복적으로 발생하는 업무입니다.
또 운영을 하다 보면 다른 팀 간의 커뮤니케이션에서 비용이 발생합니다. 토스증권에서는 대부분의 실시간 데이터 파이프라인을 제가 속해있는 실시간 데이터 팀에서 개발 후에 최종 테이블을 제공해 드리고 있는데요. 데이터가 어떤 로직으로 프로세싱 되고 있는 것인지에 대한 설명이 필요합니다. 또 어떤 데이터를 활용했는지, 어디로 이동하고 있는지 설명이 매번 필요하죠. 중앙 집권 형태로 파이프라인을 개발하고 운영하면 장점도 많지만, 적은 인원이 다양하고 많은 것들을 해내야 한다는 점에서 문서화를 잘 하는 방식으로 이 문제를 푸는 것도 현실적으로 어렵습니다. 운영상 편의성을 향상시키고 타 팀과의 커뮤니케이션 비용을 줄이기 위해서 데이터 파이프라인을 시각화하는 것 역시 운영을 잘 하기 위해 필요합니다.
이 내용을 정리해 보면 대규모의 실시간 데이터 파이프라인 운영에서 세 가지가 지켜질 경우 '잘' 운영한다고 할 수 있을 것 같습니다.
SLA 충족(Latency 최소화, 무중단 운영, 유실/중복 최소화)과 SLA 준수 여부 모니터링
확장성을 고려한 클러스터 설계
파이프라인 시각화
이번 1부 글에서는 토스증권에서 어떻게 운영하고 있는지 파이프라인 시각화를 주제로 다루려고 합니다.
Lineage 시각화
대규모 실시간 데이터 파이프라인을 잘 운영하기 위해서는 파이프라인 시각화가 필요합니다. 운영 편의성을 얻고, 사내 커뮤니케이션 비용을 줄일 수 있기 때문입니다.
그렇다면 파이프라인 시각화를 어떻게 해야 할까요? 
데이터 파이프라인을 구성하는 Job들은 서로 간 순서가 있고 관계가 있습니다. 많은 경우 아래와 같은 흐름으로 구성되는데요.
원천 MySQL에서 A Table CDC 발행 [ A ] -> A 토픽을 Consume해서 Flink로 데이터를 원하는 모습으로 프로세싱 [ B ] -> 분석을 위해 B토픽을 Consume해서 Iceberg로 적재 [ C ]
1번 파이프라인에서 생성한 B 토픽을 Consume해서 실시간 랭킹 서비스에 활용 [ D ]
B는 A로부터 파생됐고, C는 B로부터 파생되므로 'Data Lineage(데이터 리니지)' 라고 부르기로 했습니다.
데이터 흐름이 담겨있는 리니지를 표현하기 위해 가장 적합한 자료구조는 Graph이고 그중에서도 DAG(Directed Acyclic Graph) 라고 생각했습니다. 실제로도 비슷한 영역에서 DAG를 활용해 시각화를 하고 있습니다.
토스증권에서 사용하고 있는 모든 실시간 데이터 파이프라인을 DAG에 담고, 상세하게 알아볼 파이프라인을 Graph 탐색을 통해 시각화해서 보여주는 웹을 만들어서 사내 서비스로 제공하기로 했습니다.
이것을 만들어 내기 위해 먼저 DAG 형태의 메타데이터 테이블을 만들었습니다.
위 형태로 모든 파이프라인의 정보를 MongoDB에 담았고, MongoDB의 Graph Search 쿼리를 활용해서 탐색 결과를 그리도록 구성했습니다.
MongoDB graphSearch는 v5.1 이상부터 활용 가능합니다. 링크
모든 준비물이 갖춰지면 이제 메타데이터를 생성하고 검색 결과로 리니지를 그려주면 끝인데요. 모든 파이프라인에 대해 메타데이터를 생성하기 위해 먼저 토스증권에서 사용 중인 실시간 데이터 파이프라인을 구성하고 있는 것들에 대해 정리가 필요했습니다.
원천 데이터 생성 주체
Service Server
Kafka Producer
File 수집 데몬 (Filebeat, fluentbit, vector)
MySQL, Oracle, MongoDB, Vitess CDC
실시간 데이터 프로세싱 엔진
Flink
Kafka Connect
ClickHouse MView
Kafka Consumer
ksqlDB
데이터 저장소
Kafka
ClickHouse
Hadoop ( Parquet , Iceberg )
Kudu
ElasticSearch
Vitess
이 시스템들에 대해서 메타데이터를 생성해서 MongoDB에 저장하고, 리니지 시각화 웹 서비스를 제공하기 시작했습니다.
실제 사례로 데이터 파이프라인을 해석해 보기
실제 토스증권에 구성된 파이프라인 사례로 리니지 시각화 서비스를 활용해 보려고 합니다.
먼저 궁금한 파이프라인을 검색합니다. 자동 완성을 지원해서 쉽게 찾아볼 수 있습니다.
알아보고 싶은 Job을 선택하면 리니지가 그려집니다.
시세를 검색하니 위와 같은 리니지가 그려졌습니다.
리니지를 보며 파이프라인을 이해해보면, Spring 서비스 서버가 서비스 Kafka로 시세를 전송합니다. 시세 토픽은 서비스 Kafka에서 정보계 Kafka로 미러링 됩니다. 이후 정보계 Kafka에서 각각 용도에 맞게 활용하기 위해서 Hadoop, ClickHouse, Kudu 로 적재됩니다. 
저장된 테이블들은 분석 용도로 활용이 되기도 하고, 집계 같은 무거운 쿼리 결과를 서빙해야하는 서비스에서 활용됩니다.
이번에는 토스증권 커뮤니티 서비스 테이블을 검색해 볼게요.
이번에는 원천 데이터 발행지가 두 개의 MySQL 테이블 CDC 입니다. 데이터베이스 CDC가 실시간으로 Kafka 토픽으로 발행됩니다. 그 다음 Kafka 토픽은 ClickHouse 테이블로 적재됩니다. 두 ClickHouse 테이블은 ClickHouse MView에 의해 데이터 적재가 된 순간 실시간으로 트리거 돼서 Join 및 Processing 해서 결과물을 최종 테이블에 적재하고 있다는 걸 볼 수 있습니다.
이렇게 만들어진 최종 ClickHouse 테이블은 토스증권 커뮤니티 라운지 서비스의 트래픽을 받아서 무거운 집계 결과를 서비스로 제공하게 됩니다.
마지막으로 MSA(Micro Service Architecture)에서 서비스 서버 간 통신을 위해 활용하는 Kafka 토픽을 검색해 봤습니다.
서비스 서버가 Kafka로 이벤트를 발행합니다. 발행된 메시지는 토스증권 데이터센터간 이중화 구성을 위해 두 데이터센터 Kafka로 양방향 미러링이 됩니다. 양방향 미러링 결과, 양쪽 데이터센터에 메시지가 온전히 존재하기 때문에 서비스 서버의 Kafka Consumer는 한쪽 데이터센터에서 메시지를 소비합니다.
(참고) 토스증권의 DC간 Kafka 이중화 구성 관련 글
리니지 시각화는 잘 됐습니다. 나아가서 각 팀에서 이 파이프라인이 어떻게 생긴 것인지 확인할 수 있습니다.  리니지 그래프에서 궁금한 Node나 Edge를 클릭하면 어떻게 생성된 것인지 정보를 제공합니다.
이 정보는 MongoDB에 담는 메타데이터에서 Properties필드에 Json 형태로 저장해서 활용하고 있습니다.
앞으로의 모습
모든 실시간 데이터 파이프라인에 대해서 리니지 시각화와 각 Job이 어떻게 구성돼있는지 보여주는 것은 완료했습니다. 여기서 더 나아가서 이 서비스가 토스증권 전체 시스템 가시성을 높이는 방향으로 진화하려고 합니다.
그 목표를 위해 가장 먼저 시도하려는 것은 각 구간별 메트릭 연동입니다.
A → B 로 가는데 Latency와 초당 전송량 같은 것을 리니지 그래프에 표현하려고 합니다. 토스증권은 시스템 메트릭을 ClickHouse로 통합 저장하고 있기 때문에 추가로 메트릭도 보여주는 기능도 빠른 시간 내에 개발해서 배포할 수 있을 것입니다.
그 다음으로는 팀 간 커뮤니케이션 비용을 줄여주는 메타데이터 관리 서비스가 되려고 합니다. 
각 파이프라인 별 목표 SLA를 갖고있고, 현재 목표 SLA를 충족하고 있는지 표현하는 것도 필요합니다. 또 담당자가 누구인지, 또 이 파이프라인이 문제가 생겼을 때 영향받는 사람이 누구인지도 명시해 줘야 합니다. 데이터 프로세싱 영역에서는 웹만 보면 모두가 이해할 수 있는 수준으로 상세한 로직을 담을 필요가 있을 것이고, 데이터 적재 영역에서는 Append 성격인지, Upsert 성격인지, 그리고 실시간 적재인지 준실시간 적재인지 파이프라인의 메타 정보를 제공하는 웹 서비스가 되어야 합니다.  
마지막으로 추가하려는 기능은 DBT와 연동입니다.
실시간 데이터 파이프라인 리니지는 Datalake까지 실시간 입수를 하는 과정 까지를 주제로 다루고 있습니다. 그 이후는 Data Warehouse 생태계로 넘어가는데요. 현재 DBT로 배치 파이프라인이 일원화 돼있어서 실시간 데이터 파이프라인과 배치 데이터 파이프라인을 잘 연결한다면 진정한 End-to-End 리니지가 만들어질 것 같습니다.
마무리
실시간 데이터 파이프라인 리니지를 시각화하여 사내 서비스로 오픈 했습니다. 초기에 기대했던대로 수천 개의 파이프라인을 운영하는데도 큰 효율이 생겼고, 또 누구나 검색해서 파이프라인을 확인할 수 있게 되어 커뮤니케이션 비용도 많이 줄어들게 되었습니다.
이번 1부 글에서는 대규모 실시간 데이터 파이프라인을 잘 운영하기 위해서 리니지 시각화 서비스를 개발한 사례를 공유해 드렸습니다. 실시간 데이터 파이프라인 운영을 잘하기 위해서는 더 중요한 일들이 많은데요.
SLA 충족(Latency 최소화, 무중단 운영, 유실/중복 최소화)과 SLA 준수 여부 모니터링
확장성을 고려한 클러스터 설계
남은 이 두 가지 주제에 대해서 2부, 3부 글을 통해 소개하려고 합니다. 긴 글 읽어주셔서 감사합니다.

토스증권의 수천 개 실시간 데이터 파이프라인 운영방법 #1: Visualize Lineage

댓글