실시간 시세 시스템아키텍처에 대한 고민, feat.토스증권

개요

 

현재 진행 중인 백엔드 프로젝트에서 카프카를 활용한 실시간 비트코인 시세를 어떻게 구현을 해야 하는지 많은 고민을 하게 되었고
토스증권의 시스템아키텍처를 통해서 힌트를 얻을 수 있었다.

 

 

출처 - youtube

https://www.youtube.com/watch?v=SF7eqlL0mjw

https://www.youtube.com/watch?v=DQFroVSkqJM

 

토스증권의 실시간 및 누적 시세 시스템 아키텍처

토스증권의 실시간 시세 시스템 아키텍처는 크게 국내시세와 해외시세로 나누어져 있는 것을 볼 수 있다.기존의 증권 시스템들과의 차이점은 카프카를 활용하여 실시간 시세를 클라이언트에게 전달한다는 점이 있다. 또한 가공 서버에서는 누적시세와 실시간시세로 나뉘며 누적시세는 과거 데이터 활용을 위해서 mysql DB나 Memory DB에 시세를 저장하게 된다. 실시간 시세는 카프카를 통해서 웹소켓과 함께 클라이언트에게 바로 전달이 된다.

 

딥다이브 프로젝트 시스템 아키텍처

 

딥다이브 프로젝트 시스템 아키텍처와의 차이점

 

토스증권에서는 원장시스템을 활용하여 주식 데이터를 받아오지만 우리는 원장시스템이 없기 때문에 비트코인 OpenAPI에 의존하고 있는 상황이다. 

 

 

시스템 아키텍처에 대한 고민

 

1. 누적시세를 사용하기 위해서 분마다 저장을 하고 RollUp을 적용해서 분 시 일 월 년 테이블 따로 관리가 필요하지 않을까? (RollUp = 디비에서 저장된 분을 말 그대로 말아 올려서 자동으로 시 일 월 년을 만듦)
2. 년 월 일 테이블을 제외한 분 시 테이블은 지속적으로 많은 데이터가 쌓이기 때문에 삭제나 압축을 할 시점을 정해야한다. 예 ) 미래에셋증권 - 분 / 1일, 일 / 5일
3. 현재 프로젝트 시스템 아키텍처는 웹소켓에서 카프카로 가고 카프카에서 DB로 데이터를 저장한다. 굳이 불필요한 과정인 카프카를 거쳐서 DB로 갈 이유가 있을까? 웹소켓에서 바로 DB로 저장하는것이 간단하고 효과적일 수 있을 것 같다. 카프카는 실시간 시세를 클라이언트에게 전달할 때 사용한다.
4. 누적 시세를 위해서 API를 통해 계속해서 과거 데이터를 가져오기 vs 최초 한 번만 과거 데이터 저장하고, 이후 실시간 데이터 덧붙이기
   1. 계속해서 과거 데이터 가져오기
      1. 장점 : 
         1. 항상 최신 데이터를 DB에 저장
      2. 단점 : 
         1. 과도한 API 호출로 비용 발생
         2. 네트워크 또는 API 서버의 문제로 데이터 손실 발생 가능
   2. 데이터 덧붙이기
      1. 장점 : 
         1. API 호출 횟수가 줄어들어 비용 절감 및 제한 피함
         2. 한번의 초기 설정으로 과거 데이터 저장한 후, 실시간 데이터만 관리하면 된다.
      2.  단점 : 
         1. API에서 데이터 수정이 발생하면 이를 반영하기 어렵다.
         2. 실시간 데이터 수집 및 저장에 문제가 생기면 데이터 손실이 발생할 수 있다.
5. API를 통해서 어차피 가져올 거 디비에 저장할 필요가 없지 않을까?
   1. API만 사용해서 과거 데이터 가져오기
      1. 장점 : 
         1. 디비 구축 및 유지보수가 필요 없으므로 간단
         2. 최신 데이터 제공
         3. 스토리지 저장 공간 절약
      2. 단점 :
         1. 과도한 호출로 제한에 걸릴 위험
         2. 실시간으로 API를 호출하므로 응답시간이 API서버와 네트워크 지연에 영향을 받을 수 있다.
         3. 비용이 많이 발생한다.
         4. API 서버에 문제가 생길 경우 데이터에 액세스 할 수 없게 된다.
   2. API와 DB 모두 사용하기
      1. 장점 : 
         1. 데이터를 직접 저장하므로 필요한 형식이나 구조로 변환 및 가공이 가능하다.
         2. DB에서 직접 데이터를 가져오므로 지연시간을 걱정할 필요가 없으며, 캐싱 및 최적화 기법 사용 가능
         3. API서버에 문제가 발생해도 DB에 저장된 데이터를 통해 서비스 제공이 가능하다.
         4. DB에 저장된 데이터를 활용하므로 API 호출 횟수를 줄일 수 있어 API 비용을 절감할 수 있다.
      2. 단점 : 
         1. 초기 구축이 복잡하다.
         2. 데이터베이스 관리 백업 보안 등의 유지보수 작업이 필요하다.
         3. 대량이 데이터를 저장하기 위한 스토리지 비용이 발생한다.
         4. DB에 저장된 데이터와 API의 실제 데이터 간의 차이가 발생할 수 있어 정기적으로 동기화가 필요하다.