Bot

開発記録#152(2025/3/25)「論文ベースのbot開発フローpart.14」

2025年3月25日

前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。

本記事では「暗号通貨のパンプ&ダンプスキームの検出」に関する論文をベースにbot開発の過程をまとめていきます。

🚀 運用ルールの確立と本番稼働準備

次のステップでは、システムの安定稼働を確保するために、以下の3つの項目に取り組みます。


1. 運用ルールの確立

運用ルール設計の目的

  • Botの稼働スケジュールと条件を明確化
  • 障害発生時の対応フローを策定

🕒 Botの稼働スケジュールの提案

稼働時間帯内容
平日 (9:00〜22:00)通常運用 (通常取引と監視)
深夜 (22:00〜6:00)低頻度運用 (P&Dイベントの検出のみ)
週末 (土日)稼働停止 or 低頻度モード (要件次第)

🛠️ 障害発生時の対応フロー

障害の種類対応方法
APIエラー (接続失敗/タイムアウト)自動再試行 (3回) → Slack通知 → 手動再起動
データ異常 (欠損/不正データ検出)データロギング → 再リクエスト
CPU使用率の過負荷KubernetesのAuto ScalingによりPodを追加
Botの停止Slack通知 → 自動再起動 (5分後)
重大エラー (不正APIキー/セキュリティ問題)即時Slack通知 → 手動対応 (APIキー変更)

2. 最終パフォーマンスチェック

チェック項目

チェック項目内容
取引精度シミュレーション結果と実運用結果の比較
応答速度APIレスポンス時間の測定
リカバリー速度ネットワーク障害後の再接続までの所要時間
データ保存P&DイベントとBotの動作ログが正確に記録されるか

🧪 パフォーマンステストスクリプト

import requests
import time

URL = "http://localhost:5000"  # 監視システムのURL

# パフォーマンステスト
def test_response_time():
    start_time = time.time()
    response = requests.get(URL)
    end_time = time.time()

    if response.status_code == 200:
        print(f"✅ サーバーレスポンス: {end_time - start_time:.2f}秒")
    else:
        print("❌ サーバー応答エラー")

if __name__ == "__main__":
    test_response_time()

スクリプトの実行

python performance_test.py

3. デプロイ後の安定性確認

確認項目

確認項目内容
Podの状態正常に稼働しているか (kubectl get pods)
CPU/メモリ使用率kubectl top pods で過負荷がないか確認
ログ確認kubectl logs <POD_NAME> でエラーログ確認
GrafanaダッシュボードCPU、APIエラー、異常検出などの可視化確認
Slack通知Bot停止や異常検出時に通知が届くか確認

監視コマンドの例

Podの状態確認

kubectl get pods

ログの確認

kubectl logs <POD_NAME>

CPU/メモリ使用状況の確認

kubectl top pods

4. 本番稼働の最終手順

  1. すべてのPodの起動確認
  2. 異常発生時の通知確認
  3. 実際の取引結果とシミュレーション結果の比較
  4. APIエラーやデータ欠損のリカバリー動作確認

5. 次のステップ

  • 🟩 最終確認結果のレビュー
  • 🟩 必要に応じて、パラメータやエラーハンドリングの微調整
  • 🟩 完了後、本番環境の安定稼働開始 🚀
Yodaka

次回の記事では、最終確認結果のレビューと調整についてまとめます。

関連
開発記録#153(2025/3/25)「論文ベースのbot開発フローpart.15」

続きを見る

-Bot