前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。
本記事では「暗号通貨のパンプ＆ダンプスキームの検出」に関する論文をベースにbot開発の過程をまとめていきます。
Detecting Crypto Pump-and-Dump Schemes: A Thresholding-Based Approach to Handling Market Noisehttps://t.co/ctCJEV1MBs
— よだか(夜鷹/yodaka) (@yodakablog) March 22, 2025
以下に、自動デプロイ化 / ダッシュボード連携 / 複数戦略統合のための方法を、順に詳しく説明します。
🚀 ① 自動デプロイ化
🔧 方法1：HelmチャートによるBotの一括デプロイ
📁 Helm構成例
helm-bot-chart/ ├── templates/ │ ├── deployment.yaml │ └── configmap.yaml ├── values.yaml
✅ values.yaml（複数通貨ペア定義）
bots:
- pair: btcusdt
strategy: breakout
- pair: ethusdt
strategy: ml
image:
repository: yourdocker/crypto-bot
tag: latest
✅ テンプレート（templates/deployment.yaml）
{{- range .Values.bots }}
apiVersion: apps/v1
kind: Deployment
metadata:
name: bot-{{ .pair }}
spec:
replicas: 1
template:
spec:
containers:
- name: bot
image: "{{ $.Values.image.repository }}:{{ $.Values.image.tag }}"
args: ["bots/{{ .pair }}/config.yaml"]
env:
- name: STRATEGY
value: "{{ .strategy }}"
{{- end }}
✅ インストール手順
helm install crypto-bots ./helm-bot-chart
→ 新しいペアを追加したら values.yaml に1行追加するだけ！
📊 ② ダッシュボード連携（Prometheus + Grafana）
✅ 必要な構成
- Prometheus：Botのメトリクスを収集
- Grafana：可視化（勝率/PnL/エラー数など）
- Pushgateway：Bot側からメトリクスを手動Push
📤 Prometheusメトリクス送信コード例（Python）
import requests
def push_metrics(pair, pnl, trades):
data = f"""
# TYPE bot_pnl gauge
bot_pnl{{pair="{pair}"}} {pnl}
# TYPE bot_trades gauge
bot_trades{{pair="{pair}"}} {trades}
"""
requests.post("http://prometheus-push:9091/metrics/job/crypto_bot", data=data)
📈 Grafanaでのダッシュボード項目例
bot_pnl{pair="btcusdt"}rate(bot_trades[1h])kube_pod_container_status_restarts_total
🧠 ③ 複数戦略の統合管理
✅ 戦略選択ロジック（例）
def select_strategy(name):
if name == "breakout":
from strategies.breakout import breakout_signal
return breakout_signal
elif name == "ml":
from strategies.ml import ml_predict_signal
return ml_predict_signal
→ config.yaml に戦略名を記載し、Botごとに切り替え可能。
symbol: ETHUSDT strategy: ml
→ 複数Botが同時に異なる戦略を実行可能！
✨ 発展的な構成（全体イメージ）
+---------------------+ +-------------------+
| BTC Bot (breakout) | ---> | Pushgateway |
+---------------------+ +-------------------+
↓
+------------------+
| Prometheus |
+--------+---------+
↓
+------------------+
| Grafana |
+------------------+
✅ 次のステップ候補
| フェーズ | 内容 |
|---|---|
| 🔧 Helmの雛形を生成 | 各Botをchart化して一括展開 |
| 📈 Grafanaパネルテンプレート作成 | ペア別勝率・P&Lダッシュボード |
| 🤖 複数戦略を1つのBotで自動切替 | 市況変化に応じてML or ブレイクアウト選択 |
今後は
- 🎁 Helmチャート雛形
- 📊 GrafanaダッシュボードJSONテンプレート
- 🧠 複数戦略の自動切替ロジック
などのアプローチが考えられます。
このシリーズも30回目となり、キリが良いので一旦ここまでにします。今後も追加・検証等を重ねながら更新していきます。
アーキテクチャ全体像（構成図的イメージ）
📁 Git Repository
├── helm-bot-chart/
│ ├── templates/ ← Deploymentテンプレート（Bot本体）
│ └── values.yaml ← ペア／戦略設定一覧（例: BTCUSDT×breakout）
├── bots/
│ ├── btcusdt/ ← 通貨ペアごとの設定フォルダ
│ │ └── config.yaml ← 戦略名などBot個別設定
│ └── ethusdt/
│ └── config.yaml
├── strategies/ ← 戦略別シグナル生成コード
│ ├── breakout.py
│ ├── ml.py
│ └── __init__.py
├── core/ ← 共通ロジック
│ ├── executor.py ← シグナルに基づいて発注する
│ ├── detector.py ← P&D検出など戦略外ロジック
│ ├── scheduler.py ← 時間帯・モード制御（main/test）
│ └── utils/
├── run_loop.sh ← 起動スクリプト
└── Makefile ← 開発・テスト切替用ワンコマンド
⬇︎
🔄 Kubernetes クラスタ（1通貨ペア=1Pod）
├── Bot Pod 1（BTCUSDT: breakout）
├── Bot Pod 2（ETHUSDT: ml）
└── ...（各設定に応じて自動展開）
⬇︎
📡 メトリクス送信（Pushgateway経由）
└── Prometheus ← メトリクス収集
└── Grafana ← ダッシュボードで可視化
├── pnlグラフ
├── 取引頻度グラフ
└── 異常再起動アラートなど
⬇︎
🔔 Slack通知
├── エラー発生／異常系リトライ失敗
├── 運用開始・停止ログ
└── 手動検知リマインド
⬇︎
🪪 Secrets管理（APIキー）
├── dev: `.env.test`（ローカル用／.gitignore済）
├── prod: `.env.prod`（本番用）
└── K8s Secret（本番運用時にマウント or 環境変数）
⬇︎
💾 ログ・モデル保存
├── SQLite: `trades.db` にfill記録
├── logs/: Loguruで日別保存
└── S3: 定期バックアップ（monitor.py + cron）
-
-
🛠️開発記録#230(2025/5/14)トレードロジック以外の部分🏁セクション9：この構成で何が得られたか、そして次に進むために
続きを見る
👇ラジオで話したこと
開発記録#168｜Bot開発フローpart.30「自動デプロイ × ダッシュボード連携 × 戦略統合」
こんにちは、よだかです。
このラジオシリーズ「Bot開発フロー」もついに第30回、今回でひと区切りとなります。
最終回のテーマは、
**「Bot運用の自動化と統合」**です。
今日は、以下の3つをわかりやすく解説していきます：
- ① Botの自動デプロイ化（Helmチャート）
- ② ダッシュボード連携（Prometheus + Grafana）
- ③ 複数戦略の統合と切替え
① HelmチャートによるBotの自動デプロイ
まずは「Helm（ヘルム）」です。
これは、Kubernetes環境でBotを簡単に・一括で・繰り返し展開するためのツールです。
Docker Compose の Kubernetes版パッケージマネージャと考えるとイメージしやすいです。
🛠️ Helmチャートの構成
helm-bot-chart/ ├── templates/ │ ├── deployment.yaml │ └── configmap.yaml └── values.yaml
templates/に「Botの設計図」values.yamlに「使いたい通貨ペアや戦略の一覧」を書きます。
例：
bots:
- pair: btcusdt
strategy: breakout
- pair: ethusdt
strategy: ml
この値をもとに、自動でペアごとのBotがKubernetesに展開されます。
🚀 デプロイはたった1行
helm install crypto-bots ./helm-bot-chart
新しいペアを追加したいときは、values.yamlに1行追加するだけ。
コピー＆ペーストの手間はもうありません。
② Prometheus + Grafana で可視化
次に「Botの見える化」です。
🔍 なぜ必要か？
Botが正しく動いているか、損益は出ているか、トレード数はどうか…
感覚や勘ではなく、数字で見るための仕組みが必要になります。
🧰 構成はこの3つ：
- Prometheus：データを収集する側
- Pushgateway：BotからPrometheusに値を届ける中継所
- Grafana：グラフやパネルで可視化するツール
💡 Pythonからメトリクス送信（例）
def push_metrics(pair, pnl, trades):
data = f'''
bot_pnl{{pair="{pair}"}} {pnl}
bot_trades{{pair="{pair}"}} {trades}
'''
requests.post("http://prometheus-push:9091/metrics/job/crypto_bot", data=data)
このコードをBotのループの中に入れるだけで、 損益やトレード数のグラフがリアルタイムで反映されるようになります。
📊 Grafanaパネル例：
bot_pnl{pair="btcusdt"}：ペアごとの損益rate(bot_trades[1h])：1時間あたりのトレード数kube_pod_container_status_restarts_total：再起動回数の監視
数字が目に見えることで、異常もすぐに発見できます。
③ 複数戦略の統合管理
最後は「Botの戦略切替え」です。
🧠 何をやっているのか？
Botごとに戦略を個別に切り替える仕組みを作っておくと、
1つのコードベースで複数戦略を同時に運用できます。
🔁 実装例（Python）
def select_strategy(name):
if name == "breakout":
from strategies.breakout import breakout_signal
return breakout_signal
elif name == "ml":
from strategies.ml import ml_predict_signal
return ml_predict_signal
config.yamlにstrategy: mlなどと書いておけば、
起動時にBotがそれに応じた戦略ロジックを自動選択します。
✨ 応用：自動切り替えも視野に
たとえば、
- 市場のボラティリティが低いとき → 機械学習戦略
- 急変動しているとき → ブレイクアウト戦略
といったように、Bot自身が戦略を切り替える仕組みも組めます。
⏱️ 運用の次フェーズに向けて
ここまでできれば、個人でも「1人DevOpsチーム」が組める状態です。
✅ これから取り組める拡張案
| 項目 | 内容 |
|---|---|
| Helmテンプレの再利用 | 通貨ペアを増やしてBotの量産へ |
| Grafanaのダッシュボード拡張 | ペア別、戦略別の分析パネルをつくる |
| 複数戦略の自動切替 | 市況ベースで戦略をスイッチング |
シリーズを振り返って
ここまでお付き合いいただき、ありがとうございました。
このシリーズは「Botを作りたいけど、どこから手をつけたらいいか分からない」というところからスタートしました。
振り返ると、
- 論文ベースのP&D検出から始まり
.envとMakefileで環境を整備し- Kubernetesに載せて運用の自動化へ
一つ一つ、積み上げてきたものが今、ようやく“完成形の手前”にたどり着いた感じです。
これで終わり…ではなく、
ここからは“運用しながら磨いていくフェーズ”に入ります。
Botは、育てるものです。
これまで聞いてくださった皆さん、本当にありがとうございました。
この開発ログシリーズは一旦これで終了しますが、
今後も追加検証やアップデートがあれば、ブログやXでお知らせしていきます。
それでは──
良き開発と、確かな運用を。
よだかでした。
おまけ1：「なぜPushgatewayが必要なのか？」
Prometheusは“Pull型”（定期巡回）なのに、Botは“Pushしたい”から。
🧠 Prometheusの原則：Pull型メトリクス収集
- Prometheusは基本的に 対象アプリケーションに定期的にアクセスして、
http://your-app:port/metricsというエンドポイントから**自分で値を取りに行く（Pull）**設計になっています。
⛔ でも、Botのようなアプリはこれに向いていない
| 理由 | なぜPullが合わないか？ |
|---|---|
| ⏱️ 短命 | Botが一瞬で起動＆終了することがある ⇒ Prometheusが取りに行く前に消えてる |
| ⛳ 居場所が不定 | 複数のPodにまたがっていて名前やポートが動的に変わることがある |
| 🧭 自分のタイミングで出したい | 取引があった瞬間に「今！」と送りたいのに、Prometheusの巡回待ちがストレスになる |
📨 そこで登場：Pushgateway
| Pushgatewayの役割 | ざっくり例えると |
|---|---|
| 一時的な中継所 | Prometheusが来るまでの“荷物置き場” |
Botが POST で直接メトリクスを投げる先 | 「今これ出たよ」と即報告できる |
| Prometheusがそこから定期的に値をPull | Botが消えてもメトリクスは残るので安心 |
🔁 処理の流れ（例）
- Botがトレードしたらすぐに
push_metrics()でPushgatewayに値をPOST - Pushgatewayはそのデータを保持しつづける（消えない）
- Prometheusが1分おきなどでPushgatewayを見に来てPull
- Grafanaでリアルタイム可視化
✅ まとめ：Pushgatewayは「Pullが難しいアプリの橋渡し役」
| Botの性質 | Pushgatewayの強み |
|---|---|
| ランダムな起動／停止 | メトリクス保持が保証される |
| 自分のタイミングで送りたい | 即座にPOSTできる |
| Podが動的で多い | Prometheusが直接対象を特定しなくて済む |
Kubernetes上で短命・疎結合なBotを運用するなら、
Pushgatewayは“Prometheusに届かない声”を拾うマイクだと思ってもらえればOKです！
おまけ2：🎯 Pushgatewayとは？
Prometheus専用の「中継サーバー（アプリケーション）」です。
🔧 つまり、“Prometheusの仲間”であり、別アプリとして動かす必要があるツールです。
📦 イメージで言うと…
- Prometheus：配達員（値を取りにいく）
- Botたち：短命で動き回るクライアント（取引したら報告したい）
- Pushgateway：コンビニの宅配便預かりボックス（Botがメモを置ける場所）
🧠 Pushgatewayの役割（かんたん説明）
| 機能 | 内容 |
|---|---|
| 中継所として常駐 | 自分自身がずっと動き続け、データを一時保管する |
| BotからPOSTされた値を保持 | curlやPythonから直接送信できる（＝Push型） |
| PrometheusからのPullに対応 | PrometheusはあくまでPull型を維持したまま、Pushgatewayを取りに来る |
📦 Pushgateway は何でできているの？
- 公式が公開している独立アプリケーションです（Go言語製）。
- 公式GitHub からバイナリもDockerイメージも利用可能。
- KubernetesやDocker ComposeでBotと同じようにサービスとしてデプロイします。
🔁 BotとPushgatewayとPrometheusの関係
cssコピーする編集する[ BOT ] → [ Pushgateway ] ← [ Prometheus ]
↑ ↓ ↑ ↑
トレードが 保持した Pull型で
起きたら メトリクス 取りに来る
Pushする を一時保存 Prometheus本体
✅ よくある誤解の整理
| 誤解 | 実際は… |
|---|---|
| PushgatewayはPrometheusに内蔵されている？ | ❌ 別のツールです（別プロセスで動かします） |
| PushgatewayはPullする側？ | ❌ BotがPushします。PrometheusはPullです |
| BotはPushgateway無しでPrometheusに直接Pushできる？ | ❌ PrometheusはPushを受け付けません。Pushgatewayが仲介します |
🏁 まとめ
- Pushgatewayは“Prometheus専用の中継アプリ”
- 短命なBotや非同期なイベントが「今これ起きたよ」と伝えるための一時保管所
- 自分でサーバーとして立ち上げる必要あり（DockerやK8sで簡単に動かせます）