ML Documentation

目次

特徴量計算の最適配置戦略

📊 現在のシステム分析

アーキテクチャ概要

現在のシステムは以下の構成となっています：

Crawler (Rust) → Kafka → Consumer (Rust) → QuestDB
                    ↓
               特徴量計算 (Consumer内)

現在の実装状況

Crawler での処理

Consumer での処理

🔍 特徴量計算タイミングの比較分析

リアルタイム vs バッチ計算

項目 リアルタイム計算 バッチ計算
遅延 最小（<100ms） 中程度（5-60秒）
CPU負荷 分散 集中的
メモリ使用量 高（常時保持） 低（一時的）
実装複雑さ 高 中
スケーラビリティ 限定的 高

処理場所別比較

処理場所 メリット デメリット 推奨度
Crawler • 最低遅延
• データの鮮度最高		 • 処理負荷増大
• WebSocket接続への影響
• スケーラビリティ低下		 ⭐⭐
Consumer • 適度な遅延
• 処理負荷分散
• 実装済み		 • バッチ処理による遅延
• メモリ使用量増加		 ⭐⭐⭐⭐
別プロセス • 最高のスケーラビリティ
• 処理負荷分離
• 柔軟な計算		 • 追加の複雑さ
• データ転送遅延		 ⭐⭐⭐⭐⭐

⚡ 高頻度取引への影響分析

現在の遅延要因

  1. WebSocket → Kafka: ~1-5ms
  2. Kafka → Consumer: ~5-50ms (バッチサイズ依存)
  3. 特徴量計算: ~1-10ms
  4. QuestDB書き込み: ~5-20ms (ILP使用)

総遅延

高頻度取引要件

🎯 推奨アーキテクチャ: ハイブリッド多層設計

設計概要

                    ┌─────────────────┐
                    │   Raw Data      │
    WebSocket ─────▶│   Crawler       │─────▶ Kafka (raw-data)
                    │   (最小処理)     │
                    └─────────────────┘
                             │
                    ┌─────────────────┐
                    │ Feature Engine  │
                    │ (専用プロセス)   │◀─────┤
                    │                 │
                    │ ┌─────────────┐ │      ┌─────────────────┐
                    │ │ Real-time   │ │─────▶│ Redis/Memory    │
                    │ │ Features    │ │      │ Cache           │
                    │ └─────────────┘ │      └─────────────────┘
                    │                 │
                    │ ┌─────────────┐ │      ┌─────────────────┐
                    │ │ Batch       │ │─────▶│ QuestDB         │
                    │ │ Features    │ │      │ (長期保存)       │
                    │ └─────────────┘ │      └─────────────────┘
                    └─────────────────┘
                             │
                    ┌─────────────────┐
                    │ Trading Engine  │
                    │ (高頻度取引)     │◀─────┤
                    └─────────────────┘

各層の責務

1. 軽量Crawler (現状維持+最適化)

pub struct LightweightCrawler {
    // バッチサイズ最適化: 100 → 50
    batch_size: 50,
    // フラッシュ間隔最適化: 1000ms → 100ms
    flush_interval_ms: 100,
}

2. 専用特徴量エンジン (新規実装)

pub struct FeatureEngine {
    // リアルタイム特徴量 (遅延<10ms)
    realtime_calculator: RealtimeFeatureCalculator,

    // バッチ特徴量 (遅延<60s)
    batch_calculator: BatchFeatureCalculator,

    // 機械学習特徴量 (遅延<5min)
    ml_calculator: MLFeatureCalculator,
}

impl FeatureEngine {
    async fn process_realtime(&self, data: OrderbookData) -> RealtimeFeatures {
        // <10ms での計算
        // - スプレッド
        // - 即座のインバランス
        // - 流動性指標
    }

    async fn process_batch(&self, window: TimeWindow) -> BatchFeatures {
        // <60s での計算
        // - 統計的指標
        // - ローリング相関
        // - ボラティリティ
    }

    async fn process_ml(&self, historical_data: Vec<Data>) -> MLFeatures {
        // <5min での計算
        // - LSTM予測
        // - 異常検知
        // - パターン認識
    }
}

3. 最適化されたConsumer

// 既存のConsumerは軽量化
pub struct OptimizedConsumer {
    // 特徴量計算を削除
    // 書き込み専用に特化
    ilp_writer: HighPerformanceILPWriter,
}

📈 特徴量計算の最適配置

タイプ別配置戦略

特徴量タイプ 計算場所 遅延 用途 実装優先度
即座指標 専用エンジン <10ms 高頻度取引 高
スプレッド Crawler <1ms リアルタイム監視 高
統計指標 Consumer <60s 分析・監視 中
ML特徴量 バッチ処理 <5分 予測・戦略 低

計算項目詳細

リアルタイム特徴量（<10ms）

バッチ特徴量（<60s）

ML特徴量（<5分）

🚀 実装ロードマップ

Phase 1: 即座の最適化 (1-2週間)

目標

実装内容

// Consumer設定最適化
AppConfig {
    batch_size: 50,           // 100 → 50
    batch_timeout_ms: 100,    // 5000 → 100
    enable_metrics_calculation: false, // 一時的に無効化
}

// ILP書き込み最適化
IlpConfig {
    batch_size: 25,           // 100 → 25  
    flush_interval: Duration::from_millis(50), // 5000 → 50
    request_timeout: Duration::from_millis(100), // 30000 → 100
}

期待効果

Phase 2: 専用特徴量エンジン (3-4週間)

目標

実装内容

// 新規特徴量エンジン
pub struct HighFrequencyFeatureEngine {
    redis_client: RedisClient,
    websocket_feed: WebSocketFeed,
    feature_cache: DashMap<String, RealtimeFeatures>,
}

// リアルタイムAPI
#[tokio::main]
async fn main() {
    let engine = HighFrequencyFeatureEngine::new().await;

    // WebSocket → Feature計算 → Redis Cache
    engine.run_realtime_pipeline().await;

    // HTTP API for trading engine
    engine.serve_features_api("0.0.0.0:8080").await;
}

期待効果

Phase 3: 機械学習統合 (6-8週間)

目標

実装内容

// ML特徴量エンジン
pub struct MLFeatureEngine {
    lstm_model: TensorFlowLiteModel,
    anomaly_detector: IsolationForest,
    pattern_matcher: PatternMatcher,
}

// バッチ処理パイプライン
impl MLFeatureEngine {
    async fn process_batch(&self, data: TimeSeriesData) -> MLPredictions {
        let predictions = self.lstm_model.predict(&data).await?;
        let anomalies = self.anomaly_detector.detect(&data).await?;
        let patterns = self.pattern_matcher.match_patterns(&data).await?;

        MLPredictions {
            price_prediction: predictions,
            anomaly_score: anomalies,
            pattern_signals: patterns,
        }
    }
}

期待効果

📊 実装の複雑さ vs パフォーマンス

アプローチ 実装複雑さ パフォーマンス 保守性 総合評価
現状維持 ⭐ ⭐⭐ ⭐⭐⭐ ⭐⭐
Consumer最適化 ⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐
ハイブリッド設計 ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐

🎉 将来の拡張性考慮

スケーラビリティ設計

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│ Exchange 1      │    │ Exchange 2      │    │ Exchange N      │
│ Crawler         │    │ Crawler         │    │ Crawler         │
└─────────────────┘    └─────────────────┘    └─────────────────┘
         │                       │                       │
         └───────────────────────┼───────────────────────┘
                                 │
                ┌─────────────────▼─────────────────┐
                │         Kafka Cluster             │
                │   (Topic per Exchange/Symbol)     │
                └─────────────────┬─────────────────┘
                                 │
                ┌─────────────────▼─────────────────┐
                │      Feature Engine Cluster      │
                │   (Horizontal Scaling)            │
                └─────────────────┬─────────────────┘
                                 │
                ┌─────────────────▼─────────────────┐
                │       Storage Cluster             │
                │  Redis (Hot) + QuestDB (Cold)    │
                └───────────────────────────────────┘

マルチ取引所対応

📝 結論と推奨事項

推奨アプローチ

ハイブリッド多層アーキテクチャ

選定理由

  1. 最適な遅延: リアルタイム要求に対応（<10ms）
  2. 高いスループット: 水平スケーリング対応
  3. 柔軟性: 用途別の最適化が可能
  4. 将来性: 機械学習・複数取引所対応

実装優先度

  1. Phase 1の即座最適化 → 現在の50-80%性能向上
  2. Phase 2の専用エンジン → 高頻度取引対応
  3. Phase 3のML統合 → 次世代機能

期待される最終効果

この設計により、現在のシステムを段階的に進化させながら、高頻度取引要求と将来の拡張性の両方を満たすことができます。