Bot

開発記録#151(2025/3/25)「論文ベースのbot開発フローpart.13 本番環境への移行」

2025年3月25日

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

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

参考

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

🚀 最終確認結果のレビューと調整

次のステップとして、以下の内容を進めます。

✅ 最終確認結果のレビュー
✅ パラメータやエラーハンドリングの微調整
✅ 本番環境の安定稼働開始

1. 最終確認結果のレビュー

✅ 確認チェックリスト

チェック項目内容ステータス
データ収集Bybit APIから正しくデータが取得できるか✅
P&Dイベント検出実際の市場データでP&Dイベントが検出されるか✅
取引執行逆張りモードとリスク回避モードが正確に機能するか✅
Slack通知エラー発生時やBot停止時に通知が送信されるか✅
GrafanaダッシュボードCPU/メモリ使用状況やBotの取引データが確認できるか✅
再接続機能ネットワーク障害発生後に自動再接続ができるか✅

2. パラメータとエラーハンドリングの最終調整

✅ パラメータの最適化

項目旧値最適値説明
STOP_LOSS_PERCENT3%4.2%小さな変動への対応強化
TAKE_PROFIT_PERCENT5%6.8%過剰な利益確定を防止
TRADE_AMOUNT$100$150取引単位を増加し利益幅の最大化
CPUリミット500m600mBotの負荷増加に対応
メモリリミット512Mi1Giデータ増加時の安定稼働確保

上記は、Botを本番運用する前に行ったパラメータの最適化例です。
相場の変動に柔軟に対応できるよう、損切りや利確の幅を調整し、1回の取引金額も見直しました。
また、Botが安定して稼働するように、CPUやメモリの使用上限も引き上げています。
これらの調整によって、Botがムダな取引を減らしつつ、トラブル時にも落ちにくくなりました。

参考

Kubernetesのリミットとリクエストについて理解する

Kubernetesの基礎知識

✅ エラーハンドリングの調整

エラータイプ旧動作新動作
APIタイムアウト再試行3回 → 停止再試行5回 → Slack通知 → 停止
データ取得エラーデータ欠損時に停止データ再取得 → エラーログ記録
Bot停止即座に再起動Slack通知 → 5分後に再起動

本番運用では、突発的なエラーが起こってもBotが安定して動き続けることが重要です。
そのため、エラー時の挙動を見直し、単に停止するのではなく、リトライや通知、再起動までの猶予時間を設けるようにしました。
これにより、軽微なトラブルでBotが止まるリスクを下げつつ、必要な情報はSlack経由で即時に把握できるようになっています。

3. 本番環境の安定稼働開始

✅ デプロイ手順

  1. イメージのビルドとプッシュ
docker build -t your_dockerhub_username/crypto_bot:latest .
docker push your_dockerhub_username/crypto_bot:latest
  1. Kubernetes環境へデプロイ
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f hpa.yaml
kubectl apply -f configmap.yaml
  1. 最終稼働確認
kubectl get pods
kubectl get services
  1. 監視確認 (Prometheus/Grafana)
kubectl port-forward svc/grafana 3000:80

ブラウザで http://localhost:3000 にアクセス

✅ 稼働状況の監視

リアルタイムログ確認

kubectl logs -f <POD_NAME>

CPU/メモリ監視

kubectl top pods

Slack通知確認

  • 取引成功/失敗
  • エラー発生
  • Bot再起動

4. 次のステップ

今後の運用に向けて、以下のタスクに取り組みます。

✅ 稼働状況の定期確認
✅ バックアップ戦略の構築 (データの自動保存と復旧手順の整備)
✅ トレード戦略の継続的な改善 (AIや機械学習モデルの組み込み)

Yodaka

次の記事では、運用開始後の最初のチェックポイントの設定に取り組みます。

関連
開発記録#152(2025/3/25)「論文ベースのbot開発フローpart.14　本番稼働前の最終チェックと運用ルールの確立」

続きを見る

おまけ：噛み砕いた説明

前回の放送では、仮想通貨Botの安全な運用のために
「APIキーの安全管理」や「監視機能（Prometheus + Grafana）」の話をしました。

今回はその続きとして、Botがいよいよ本番環境に移行する段階に入った話、
そしてマーケットの不正行為「パンプ＆ダンプ」を検出する機能の実装についてお届けします。

🧪 まずは「動作確認」から

Botを本番に持っていく前に、テスト環境で最終確認を行います。
ざっくり言うと、以下の6つのポイントをチェックします。

  • データ取得：Bybitという取引所から価格データが正しく取れているか？
  • P&Dの検出：パンプ＆ダンプの兆候が市場データからちゃんと検知できているか？
  • 取引実行：逆張り戦略とリスク回避モードがうまく機能しているか？
  • 通知機能：Botが止まったときにSlackへ通知が飛ぶか？
  • 監視画面：GrafanaでBotの動きや負荷状況が可視化できているか？
  • 再接続：ネットワークが切れても自動で復帰できるか？

どれも✅クリア。
これで「Botが壊れずにちゃんと働いてくれる」っていう保証が取れたことになります。

⚙️ 本番に向けた微調整

次にやるのが、パラメータとエラーハンドリングの調整です。

たとえば：

  • 損切り幅（STOP_LOSS）を3% → 4.2%に
  • 利益確定幅（TAKE_PROFIT）を5% → 6.8%に
  • 1回の取引金額を100ドル → 150ドルに

これは、Botが「小さなノイズで売り買いしすぎる」のを防ぐためのチューニングです。

あと重要なのがエラーへの対応。

旧バージョンではAPIがタイムアウトしたらすぐ停止していたんですが、
新バージョンでは「5回までリトライ → それでもダメならSlackに通知 → それから停止」という流れに変更。

これでBotが「ちょっとした不調」で止まるのを防ぎつつ、ちゃんと通知も来るようになります。

🐳 いざ、本番環境へ！Docker & Kubernetes の話

さて、いよいよ本番です。
ここで出てくるのが Docker（ドッカー）とKubernetes（クバネティス） というツール。

ここで「？？？」となる方もいると思うので、ざっくり説明します。

🔧 Dockerって何？

Dockerは、「Botの実行環境をそのままパッケージ化できるツール」です。
例えるなら、「このBotを動かすための小さな部屋（仮想の箱）をまるごと作る」ようなもの。

この部屋を作る作業が、

docker build -t your_dockerhub_username/crypto_bot:latest .

というコマンドです（これを「ビルド」と言います）。

そして、その部屋をクラウド上にアップロードするのが「プッシュ」です。

docker push your_dockerhub_username/crypto_bot:latest

🏗 Kubernetesって何？

Kubernetesは、その「部屋（コンテナ）」をたくさん並べて、いい感じに運用してくれる管理人のような存在です。

たとえば：

  • Botが止まったら自動で再起動してくれる
  • 複数のBotを並行して動かしてくれる
  • 負荷が上がったら自動的に数を増やしてくれる（スケーリング）

つまり、「たくさんのBotを安定して動かすための司令塔」なんですね。

💡 本番のデプロイ手順（これが全体の流れ）

ここまでを一連の流れで見てみると：

  1. Botの環境をDockerでパッケージ化
  2. それをDocker Hubにアップ
  3. Kubernetesにデプロイして運用開始

具体的にはこんなコマンドを打ちます：

kubectl apply -f deployment.yaml  # Botの配置
kubectl apply -f service.yaml     # 通信の設定
kubectl apply -f hpa.yaml         # 自動スケーリング
kubectl apply -f configmap.yaml   # 設定の注入

そして最終確認。

kubectl get pods         # Botが起動しているか確認
kubectl logs -f <POD名>  # ログで挙動確認

さらに、Grafanaで監視するためのポートフォワード：

kubectl port-forward svc/grafana 3000:80

これでブラウザから http://localhost:3000 にアクセスすれば、Botの稼働状況がグラフィカルに見えるようになります。

🔮 そして次のステップへ

Botが本番稼働したら終わり、じゃありません。
むしろここからが始まりです。

次のステップとしては：

  • 稼働状況の定期確認
  • 万が一に備えてのバックアップ戦略の構築
  • そして何より、トレード戦略の改善です。

このトレード戦略の部分、今後はAIや機械学習の技術を取り入れて、
より「賢いBot」に育てていく予定です。

というわけで、今回は「Botの本番移行とP&D検出の導入」についてお話しました。

次回は、バックアップとAIによるトレード改善の話に進みます。

おまけ：✅ パラメータの最適化：詳しい解説

仮想通貨Botが市場でうまく立ち回るためには、戦略パラメータとシステムリソースの両方を調整する必要があります。以下はその具体例です。

🛑 STOP_LOSS_PERCENT（損切り幅）

  • 旧値：3% → 新値：4.2%
  • 意味：「エントリー価格から3%下がったら損切りする」→「4.2%下がるまで耐える」

💡 解説：

損切りが早すぎると、「ただの一時的な揺れ」でもすぐに損を確定してしまいます。
特に暗号通貨はボラティリティ（価格変動）が大きいため、少し余裕を持たせることで、ムダな損切りを減らすことができます。

💰 TAKE_PROFIT_PERCENT（利確幅）

  • 旧値：5% → 新値：6.8%
  • 意味：「5%の利益が出たら売る」→「もう少し待って6.8%まで利益を引っ張る」

💡 解説：

利確が早すぎると「伸びるチャンスを逃す」ことになります。
Botが「上昇の勢いがある」と判断したときに、過剰な早売りを防いで利益を最大化するための調整です。

📈 TRADE_AMOUNT（1回の取引金額）

  • 旧値：100ドル → 新値：150ドル

💡 解説：

Botが「これはチャンス！」と判断した時のエントリー額です。
1回の取引額を上げることで、利益額そのものも大きくなる可能性があります（もちろんリスクも上がりますが）。
今回はバックテストの結果、「150ドルまでなら許容範囲」と判断したわけです。

🧠 CPUリミット（プロセッサ使用量の上限）

  • 旧値：500m → 新値：600m
  • 単位：500mは「500ミリコア」＝0.5 CPU相当

💡 解説：

Botが複雑なロジックを処理したり、多くのデータを扱うとき、CPUを多く使います。
リミットが小さいと「処理落ち」してしまう可能性があるため、余裕を持たせて処理遅延やタイムアウトを防ぐための調整です。

🧠 メモリリミット（RAM使用量の上限）

  • 旧値：512Mi → 新値：1Gi
  • 単位：Miは「メビバイト」＝ 約1.05MB、1Gi＝ 約1024Mi

💡 解説：

Botが価格データやトレード履歴を多く保持する場合、RAM（メモリ）を多く使います。
Botの稼働が長時間にわたると、キャッシュの蓄積などでメモリ不足になるケースがあるため、1GiBに増やして安定性を確保します。

補足

「1Gi」は英語で一般的に次のように発音されます：

"one gibibyte"（ワン・ギビバイト）

そして「Mi」は：

"mebibyte"（メビバイト）

つまり、

1Gi = 約1024Mi は
“One gibibyte equals approximately 1024 mebibytes”（ワン・ギビバイト イクォールズ アプロキシマトリー ワンサウザンドトゥエンティフォー メビバイツ）
と読み上げます。

「ギビバイト？なにそれ？」と思った方もいるかもしれません。
これは「ギガバイト（GB）」と似てるけど、1024倍進数の正確な単位です。

  • ギガバイト（GB）：1GB = 1000MB（10の3乗）
  • ギビバイト（GiB）：1GiB = 1024MiB（2の10乗）

つまり、コンピュータが本来使っている「2進数」に忠実な単位がGiやMiなんですね。
技術者の間では、こちらの方が正確なのでよく使われています。

🔧 総まとめ：なぜこれが重要？

これらのパラメータ調整は、Botの本番稼働にとって 非常に重要な「地ならし」 です。

  • 取引面では → 損失の削減と利益の最大化
  • システム面では → 処理の安定性と再起動回避

を目的とした調整です。

-Bot