대규모 거래 자동화를 위한 멀티 캔들 관리 시스템

개요

Multi-Kline Management 시스템은 MagicTradeBot이 수십만 개의 거래 심볼에 대해 여러 타임프레임의 캔들(kline) 데이터를 동시에 효율적으로 로드·캐시·유지할 수 있게 해주며, 거래소 API의 레이트 리밋을 철저히 준수합니다. 이 기능은 고빈도 스캘핑부터 장기 포지션 트레이딩까지 다양한 전략을 완전히 격리된 상태로 동시에 실행할 수 있게 지원합니다.

핵심 기능

전략별 인터벌 로딩

봇은 활성화된 전략 종류에 따라 kline 데이터를 동적으로 로드합니다. 각 전략마다 최적의 타임프레임이 미리 정의되어 있습니다:

전략별 인터벌:

  • HFT (High-Frequency Trading): 1m – 분 단위 움직임에 초고속 실행
  • Scalp: 15m – 15분 차트에서의 단기 모멘텀 플레이
  • Day Trading: 15m, 30m, 1h, 2h, 4h – 여러 타임프레임 인트라데이 분석
  • Swing Trading: 1h, 2h, 4h, 6h, 12h – 포지션 진입을 위한 다시간 패턴
  • Long-Term: 1d – 매크로 트렌드 분석을 위한 일봉 차트
  • Default: 5m, 15m, 1h – 균형 잡힌 멀티 타임프레임 접근

각 심볼은 할당된 전략에 따라 하나 이상의 인터벌을 동시에 로드할 수 있어, 멀티 타임프레임 확인이 가능하면서도 메모리 효율을 유지합니다.

지능형 레이트 리밋 관리

적응형 요청 스로틀링

거래소 API 제한을 준수하는 정교한 알고리즘이 적용됩니다:

  • maxRequestsPerSecond: 10 – 거래소의 초당 하드 리밋
  • safeBuffer: 0.2 – 안전 여유분 (최대 용량의 80% 사용)
  • 실효 레이트: 초당 8회 요청 (10 × 0.8)

요청 분산 전략

심볼 청크 처리:

  • chunk_size: 20 – 한 업데이트 사이클당 가져오는 심볼 수
  • 수십만 심볼을 시간에 분산
  • API 버스트 위반 방지
청크 처리 시간 = chunk_size / 실효_레이트
예시: 20 심볼 / 8 req/s = 청크당 2.5초

리프레시 사이클:

  • kline_refresh_rate: 7 초마다 전체 업데이트 사이클
  • 데이터 신선도 유지 + API 과부하 방지
  • 응답 시간에 따라 지연을 적응적으로 삽입

멀티 거래소 지원

  • Binance: 1200회/분 (20회/초)
  • OKX: 20회/2초
  • Bybit: 120회/5초

봇은 감지된 거래소에 따라 maxRequestsPerSecond를 자동 조정합니다.

메모리 효율적인 Kline 저장

롤링 윈도우 방식

대량 심볼 처리 시 메모리 고갈 방지:

  • 심볼별 Kline 관리:
    • max_kline_length: 100 – 인터벌당 최대 보관 캔들 수
    • 원형 버퍼(FIFO) 구현
    • 신규 캔들 도착 시 오래된 캔들 자동 제거
단일 Kline 객체: ~200 바이트
심볼당 (5개 인터벌 × 100 캔들): ~100 KB
100,000 심볼: 총 ~10 GB 메모리 사용량

Lazy Loading & 캐싱

  • 최초 로드는 max_kline_length 전체 히스토리 가져옴
  • 이후 업데이트는 최신 캔들만 요청
  • 메모리 내 LRU 캐시로 비활성 심볼 관리
  • 24시간 비활성 심볼은 자동으로 메모리에서 제거

동시 전략 실행

심볼-전략 매핑

BTCUSDT:
  strategy: "day"
  intervals: ["15m", "1h", "4h"]
 
ETHUSDT:
  strategy: "scalp"
  intervals: ["15m"]
XRPUSDT:
  strategy: "swing"
  intervals: ["1h", "4h", "12h"]

격리된 시그널 처리

  • signal_refresh_interval: 20 초 (전략별 설정 가능)
  • Scalp → 20초마다
  • Long-term → 1800초(30분)마다

각 심볼은 독립적으로 지표를 계산하며 전략 간 교차 오염이 없습니다. CPU 집약 작업은 워커 스레드로 병렬 실행됩니다.

확장성 아키텍처

분산형 Kline 페칭

우선순위 큐 시스템:

  1. 최우선 (진행 중인 거래)
  2. 중간 (강한 시그널)
  3. 낮음 (모니터링 전용)
  4. 오래된 데이터 (리프레시 레이트의 2배 이상 미갱신)

배치 요청 최적화:

  • 한 번의 API 호출로 동일 심볼의 여러 인터벌 동시 수집 가능
  • 전체 요청 수 약 40% 감소
  • 거래소별 배치 엔드포인트 활용

장애 내성

  • 레이트 리밋 도달 → 지수 백오프 (2x, 4x, 8x)
  • 요청 실패 → 최대 3회 재시도
  • 지속 실패 → 해당 심볼 일시 비활성화
  • 연결 끊김 → 재연결까지 큐에 보관

데이터 검증 항목:

  • 타임스탬프 간격 누락 감지
  • 가격 이상치 감지
  • 자동 백필
  • 오래된 데이터 제외

성능 최적화

업데이트 사이클 워크플로

매 7초 리프레시 사이클:

  1. 선택 단계 (0.1초)
  2. 페치 단계 (2.5초)
  3. 처리 단계 (1.5초)
  4. 대기 단계 (2.9초)

총 처리량:

  • 초당 2.86 심볼
  • 시간당 10,285 심볼 업데이트
  • 100,000 심볼 전체 리프레시 ≈ 9.7시간

전략별 최적화

  • Scalp: 빠른 리프레시, 작은 버퍼
  • Long-Term: 느린 리프레시, 표준 버퍼

최적 설정 가이드

소규모 포트폴리오 (<1,000 심볼)

chunk_size: 50
kline_refresh_rate: 5
maxRequestsPerSecond: 15
safeBuffer: 0.3

중규모 포트폴리오 (1,000~10,000 심볼)

chunk_size: 20
kline_refresh_rate: 7
maxRequestsPerSecond: 10
safeBuffer: 0.2

대규모 포트폴리오 (>100,000 심볼)

chunk_size: 10
kline_refresh_rate: 10
maxRequestsPerSecond: 8
safeBuffer: 0.15
max_kline_length: 50

거래소별 튜닝

  • Binance: 큰 청크, 빠른 리프레시
  • 엄격한 거래소: 작은 청크, 느린 리프레시

실제 적용 예시

시나리오: Binance에서 50,000 심볼 거래

chunk_size: 25
kline_refresh_rate: 8
maxRequestsPerSecond: 12
safeBuffer: 0.2
max_kline_length: 80

성능:

  • 실효 레이트: 9.6 req/s
  • 청크 처리: 2.6초
  • 전체 리프레시: 약 4.4시간마다
  • 메모리 사용량: 약 8 GB
  • 일일 API 호출: 약 275,000회

요약 분석

summary_interval: "1d" 설정 시 매일 다음 정보를 제공합니다:

  • 모니터링 중인 총 심볼 수
  • API 사용량
  • 레이트 리밋 사용률 (%)
  • 데이터 신선도
  • 전략별 시그널 수
  • 메모리 사용량

📎 Related Topics