Bot

開発記録#163(2025/4/2)「論文ベースのbot開発フローpart.25 デプロイと運用安定化」

2025年4月2日

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

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

参考

Detecting Crypto Pump-and-Dump Schemes: A Thresholding-Based Approach to Handling Market Noise

✅ 1. 運用ルールの確立

  • Botの稼働スケジュール設計
  • 障害発生時の対応フロー策定
  • 異常検出やリスク回避の優先順位決定

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

  • シミュレーション結果と実運用結果の比較
  • 取引成功率、利益率、エラー率の再評価
  • 調整が必要なパラメータの特定

✅ 3. デプロイ後の安定性確認←今ここ

  • Podの状態、リソース使用率の監視
  • APIエラーやデータ欠損の確認
  • Slack通知やログ記録の精度確認

次は 「デプロイと運用安定化」 に進みます。
ここでは、Botを本番運用環境に安全かつ安定的に稼働させ続けるための最終プロセスを整備します。

✅ 1. デプロイ前チェックリスト

項目確認ポイント
✅ コード調整後ロジック・パラメータが反映されているか
✅ モード切替scheduler.py による時間帯対応が動作しているか
✅ SecretsAPIキーがKubernetes Secretsで安全に管理されているか
✅ Loggingloggerが適切に記録＆Slack通知が動作しているか
✅ モニタリングGrafana/Prometheusで稼働状況が可視化されているか

🚀 2. Kubernetes デプロイ手順（再確認）

1. イメージビルドとDockerHubへプッシュ

docker build -t youruser/crypto-bot:latest .
docker push youruser/crypto-bot:latest

2. Kubernetesマニフェスト再適用

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f hpa.yaml
kubectl apply -f configmap.yaml  # if used

🔁 3. 稼働後の安定化ポイント

カテゴリ実施内容使用技術・コマンド例
🎯 モニタリングCPU/メモリ、異常イベント監視kubectl top pods, Grafana
🧠 障害復旧restartPolicy: Always + ログ監視kubectl logs
🔔 通知Slack連携により異常をリアルタイム検知Webhook
💾 バックアップログ/モデルのS3保存スクリプトbackup_script.py + cron

「3. 稼働後の安定化ポイント」**について、より具体的な実装・運用手順をそれぞれ詳細に説明します。

🎯 1. モニタリング：CPU/メモリ、異常イベント監視

✅ Kubernetes CLI で確認する場合

kubectl top pods --namespace=default

各PodのCPU（m）とMemory（Mi）使用量をリアルタイムで確認できます。

✅ Grafana + Prometheus を使う場合

導入手順（簡易）：

  1. kube-prometheus-stack を Helm で導入（1回だけ）
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack
  1. Grafanaにログイン（初期は admin/admin）
    URL: http://localhost:3000
  2. 以下のようなパネルを作成：
    • container_cpu_usage_seconds_total
    • container_memory_usage_bytes
    • kube_pod_container_status_restarts_total

✅ アラート例（Prometheus Alertmanager）

- alert: HighCPUUsage
  expr: container_cpu_usage_seconds_total > 0.8
  for: 1m
  labels:
    severity: warning
  annotations:
    summary: "高CPU使用率"

🧠 2. 障害復旧：再起動とログ監視

✅ Kubernetes 自動再起動設定（deployment.yaml）

spec:
  template:
    spec:
      restartPolicy: Always  # 異常終了時に自動再起動

✅ ログ監視でエラーを発見

kubectl logs <pod-name>
kubectl logs -f <pod-name>  # リアルタイム監視

ログに "Exception" や "ERROR" のキーワードが含まれていれば、Slack通知 or 自動リカバリ対象にします。

🔔 3. 通知：Slackで異常を即時検知

✅ Slack Webhook 設定方法

  1. Slackの「App」→「Incoming Webhook」を作成
  2. チャンネルを選び、Webhook URLを取得（例）：
https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

✅ Python から通知するコード

import requests

def send_slack_alert(message):
    url = "https://hooks.slack.com/services/XXXX/XXXX/XXXX"
    payload = {"text": f"🚨 {message}"}
    requests.post(url, json=payload)

✅ 通知例

send_slack_alert("Botが異常終了しました（BTCUSDT）")

💾 4. バックアップ：ログ/モデルのS3保存 + cron自動化

✅ Pythonスクリプト（backup_script.py）

import boto3
import os
from datetime import datetime

AWS_ACCESS_KEY = "YOUR_ACCESS"
AWS_SECRET_KEY = "YOUR_SECRET"
BUCKET_NAME = "crypto-bot-backups"

def backup_to_s3():
    s3 = boto3.client('s3', aws_access_key_id=AWS_ACCESS_KEY,
                             aws_secret_access_key=AWS_SECRET_KEY)

    for folder in ["./logs", "./models"]:
        for root, _, files in os.walk(folder):
            for f in files:
                local_path = os.path.join(root, f)
                s3_key = f"{datetime.now().strftime('%Y-%m-%d')}/{f}"
                s3.upload_file(local_path, BUCKET_NAME, s3_key)
                print(f"✅ {f} を S3 にバックアップ済み")

if __name__ == "__main__":
    backup_to_s3()

✅ cron で毎日バックアップ自動実行（Linux/Mac）

crontab -e

0 3 * * * /usr/bin/python3 /path/to/backup_script.py >> /var/log/bot_backup.log 2>&1

毎日3:00にバックアップが自動実行され、ログも記録されます。

✅ おまけ：すべてを統合する「安定性チェック」スクリプト例（monitor.py）

from retry_with_alert import retry_with_alert
from logger import get_logger
from backup_script import backup_to_s3
from send_slack import send_slack_alert

def monitor():
    try:
        # CPU / メモリ 使用率が高ければ Slack 通知
        # 再起動回数チェックなどを組み合わせても良い
        print("🧠 モニタリング中...")
    except Exception as e:
        send_slack_alert(f"モニタリングエラー：{e}")

if __name__ == "__main__":
    monitor()
    backup_to_s3()

🔜 次のステップ候補

  • 複数Botのモニタリングを 1つのダッシュボードで可視化
  • バックアップ対象を拡張（取引履歴やエラーログなど）
  • Slack通知テンプレートを標準化（成功/警告/失敗ごと）

📊 4. 安定性の最終チェックリスト

  • ✅Botは定期的に再起動されても状態復元できるか？
  • ✅主要な操作は logs/*.log に記録されているか？
  • ✅Slack通知は異常・成功時どちらも届いているか？
  • ✅Prometheus + GrafanaでCPU、イベント数が見えるか？
  • ✅バックテストとの性能差が大きくないか？

🔜 今後の発展候補（ステージアップ案）

フェーズ発展内容
📡 ステージ1自動モード切替 + データ蓄積による学習ベース戦略化
🤖 ステージ2AIモデル（LSTM/Transformer）でP&Dや価格予測強化
☁️ ステージ3複数Botの同時運用（Kubernetesでスケーリング）
🔒 ステージ4セキュアなKey Vault、RBAC、監査ログによる強固な運用基盤

次に取り組みたいのは、

  • ✅ 実際の稼働チェック（1日〜1週間後のパフォーマンス分析）
  • ✅ 新しい戦略の追加（ブレイクアウト、MLモデルなど）
  • ✅ 他通貨ペアのBot追加展開（複数Bot運用）

などがあります。

Yodaka

次は、「実際の稼働チェック（1日〜1週間後のパフォーマンス分析）」についてまとめます。

関連
開発記録#164(2025/4/2)「論文ベースのbot開発フローpart.26 実際の稼働チェック」

続きを見る

👇ラジオで話したこと

デプロイと運用安定化
タイトル：仮想通貨Botの「最後の壁」──デプロイと安定運用の全手順


こんにちは、よだかです。
今日のテーマは、「デプロイと運用安定化」。
Botの開発が終わったあと、いよいよ実運用に踏み出す瞬間ですね。
ただし、ここからが本当の勝負です。今回は、Kubernetes環境でBotを安全・安定に動かし続けるための最終準備と運用ノウハウを、初心者の方にもわかりやすくお話ししていきます。

【セクション1｜デプロイ前チェックリスト】

まずは本番突入前のチェックリストから確認しましょう。

🔍1. コードは本当に最新ですか？
── 意外と多いのが「ローカルでは修正したのに、実行中のコードには反映されていなかった」というミス。GitのプルやDockerイメージの再ビルド、忘れずに。

🔍2. モード切替は時間帯に応じて動いてる？
── たとえば scheduler.py を使って、日中は攻めモード、夜間は守りモードなど。これは、スケジューリングで大きく差がつきます。

🔍3. APIキー（Secrets）の安全性は？
── Kubernetes Secrets を使って、設定ファイルやコードにベタ書きしないように。これ、セキュリティ的に超重要です。

🔍4. ログやSlack通知は動作確認済み？
── loguru などでログを残し、異常時にはSlackに即通知。これは“運用者の目”の代わりになります。

🔍5. 可視化ツール（Grafana）は導入済み？
── 視覚的に「Botの健康状態」を見る仕組みがあると安心です。

【セクション2｜Kubernetes デプロイの再確認】

本番環境では、**Kubernetes（クバネティス）**というツールを使ってBotを運用します。

🛠️1. Docker イメージをビルド → プッシュ

docker build -t youruser/crypto-bot:latest .
docker push youruser/crypto-bot:latest

🛠️2. 各種マニフェストを適用

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f hpa.yaml
kubectl apply -f configmap.yaml

これでBotがクラウド上で起動し、常時稼働状態に入ります。
ただし、起動したら終わりではありません。ここからが本番です。

【セクション3｜稼働後の安定化ポイント】

ここからは、実際にBotを動かしたあと、安定運用をどう支えるかの解説です。

🎯① モニタリング：動作確認の目を持つ

Kubernetes CLI なら、

kubectl top pods

これで、Botが今どれだけCPUやメモリを使っているか確認できます。

より高機能なのがGrafana + Prometheus。
GUIで可視化しつつ、以下のようなメトリクスをパネル化します：

  • container_cpu_usage_seconds_total
  • container_memory_usage_bytes
  • kube_pod_container_status_restarts_total

さらに、高CPU使用率などを自動で検知し、Prometheus Alertmanager からSlack通知もできます。

🧠② 障害復旧：トラブル時に自動で立て直す

Kubernetesでは、restartPolicy: Always を設定しておくことで、Botがクラッシュしても自動で再起動されます。

また、トラブルの原因を調べるには、

kubectl logs <pod-name>

ログをリアルタイムで監視するには -f オプションも使えます。

🔔③ 通知：Slackでリアルタイム把握

異常を検知したら、Slackに通知して即対応。

Pythonでの通知例はこんな感じ：

import requests
def send_slack_alert(message):
    url = "https://hooks.slack.com/services/XXX"
    payload = {"text": f"🚨 {message}"}
    requests.post(url, json=payload)

エラーだけでなく、成功時も通知できると開発効率がグンと上がります。

💾④ バックアップ：万が一に備える

Botのログや学習済みモデルなどを定期的にS3へバックアップするのも大事。

Pythonスクリプトで、

s3.upload_file(local_path, BUCKET_NAME, s3_key)

といった形でアップロード。
cronを使えば、毎日自動で深夜に実行可能です：

0 3 * * * /usr/bin/python3 /path/to/backup_script.py

【セクション4｜まとめと今後のステップ】

最後に、安定運用のための最終チェックリストをおさらいしましょう：

  • ✅ 再起動してもBotの状態が復元できるか？
  • ✅ 主要なログが残っているか？
  • ✅ Slack通知が正常に届くか？
  • ✅ Grafanaでリソース状態が見えるか？
  • ✅ 実運用とバックテストの差異が小さいか？

このあたりまでチェックできていれば、Botは“稼働中のプロダクト”として完成です。

【ラストセクション】
次のフェーズでは、以下のようなステージアップが待っています。

  • 🤖AI戦略の組み込み（LSTMやTransformer）
  • 📡複数Botの同時稼働とスケーリング
  • 🔒セキュリティ強化と監査体制の導入

さらに、今後すぐ取り組みたいのは：

  • ✅ 1日～1週間後の稼働チェックと性能分析
  • ✅ 新しい戦略の追加（ブレイクアウト、ML戦略など）
  • ✅ 他通貨ペアへのBot展開

こうしたアップデートは、Botを「資産を生む仕組み」へと進化させていくうえで欠かせません。

【エンディング】
ということで、今回は「デプロイと運用安定化」についてお届けしました。
このフェーズを越えることで、Botはようやく“走り出した”といえます。

「開発で終わらず、運用で勝つ」
その第一歩が、この安定化プロセスです。

次回は、「Botの本番稼働から得られた1日〜1週間の実データをもとに、勝率・損益・P&D検出精度などを総合的に分析します。
特に、パンプ＆ダンプ戦略の検出モデルが実環境でどれだけ機能しているかに焦点を当て、今後の改善につなげます。

それでは、次回の放送でお会いしましょう。
よだかでした。

-Bot