大規模トレーディング自動化のためのマルチKライン管理システム

概要

Multi-Kline Management システムにより、MagicTradeBot は数十万の取引シンボルに対して複数の時間足のローソク足（kline）データを同時に効率的にロード・キャッシュ・維持しつつ、取引所のAPIレートリミットを厳格に遵守します。この機能は高頻度スキャルピングから長期ポジショントレードまで多様な戦略を完全に分離した状態で並行稼働させることを可能にします。

主な機能

戦略別インターバル読み込み

ボットは有効な戦略種別に応じてklineデータを動的に取得します。各戦略には最適な時間足があらかじめ定義されています：

戦略別インターバル：

  • HFT（高頻度取引）: 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 – バランスの取れたマルチタイムフレーム

各シンボルは割り当てられた戦略に応じて1つ以上のインターバルを同時に保持でき、マルチタイムフレームでの確認を可能にしつつメモリ効率を維持します。

インテリジェントなレートリミット管理

適応型リクエストスロットリング

取引所API制限を確実に守る高度なアルゴリズムを実装しています：

  • maxRequestsPerSecond: 10 – 取引所の1秒あたりのハードリミット
  • safeBuffer: 0.2 – 安全マージン（最大容量の80%使用）
  • 実効レート: 8リクエスト/秒（10 × 0.8）

リクエスト分散戦略

チャンク単位のシンボル処理：

  • chunk_size: 20 – 1更新サイクルあたりの取得シンボル数
  • 数十万シンボルを時間的に分散
  • 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本）: 約100KB
100,000シンボル: 合計約10GBメモリ使用量

遅延読み込み＆キャッシュ

  • 初回ロードは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倍以上未更新）

バッチリクエスト最適化：

  • 同一シンボルの複数インターバルを1回の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時間ごと
  • メモリ使用量: 約8GB
  • 1日あたりAPI呼び出し: 約275,000回

サマリー分析

summary_interval: "1d" を設定すると、以下の日次統計が得られます：

  • 監視シンボル総数
  • API使用量
  • レートリミット使用率（%）
  • データ鮮度
  • 戦略別シグナル数
  • メモリ使用量

📎 Related Topics