前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。
本記事では「暗号通貨のパンプ＆ダンプスキームの検出」に関する論文をベースにbot開発の過程をまとめていきます。
Detecting Crypto Pump-and-Dump Schemes: A Thresholding-Based Approach to Handling Market Noisehttps://t.co/ctCJEV1MBs
— よだか(夜鷹/yodaka) (@yodakablog) March 22, 2025
🚀 運用ルールの確立と本番稼働準備
次のステップでは、システムの安定稼働を確保するために、以下の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()
🔍 解説ポイント
このスクリプトでは、次のような動作を行っています：
URLに指定したアドレス（ここではローカルの http://localhost:5000）に対してHTTPリクエストを送信- リクエストの前後で
time.time()を使って時間を測定 - サーバーからの応答が正常（ステータスコード200）だった場合は、かかった**応答時間（秒）**を表示
- そうでない場合は「サーバー応答エラー」と表示
▶ 実行方法
✅ スクリプトの実行
このスクリプトは、ターミナルやコマンドラインで以下のように実行できます：
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. 本番稼働の最終手順
- ✅ すべてのPodの起動確認
- ✅ 異常発生時の通知確認
- ✅ 実際の取引結果とシミュレーション結果の比較
- ✅ APIエラーやデータ欠損のリカバリー動作確認
5. 次のステップ
- 🟩 最終確認結果のレビュー
- 🟩 必要に応じて、パラメータやエラーハンドリングの微調整
- 🟩 完了後、本番環境の安定稼働開始 🚀
次回の記事では、最終確認結果のレビューと調整についてまとめます。
-
-
開発記録#153(2025/3/25)「論文ベースのbot開発フローpart.15 運用開始後のチェックポイント」
続きを見る
ラジオで話したこと
前回の放送では、「本番環境への移行」というテーマで、Botの最終確認レビューや、パラメータ・エラーハンドリングの調整例、そしてDockerとKubernetesを使った本番環境へのデプロイまでお話ししました。
今回はその続きとして、いよいよ本番稼働に向けての最終チェックと運用ルールの確立をテーマに進めていきます。
🚀 まずは「運用ルールの確立」から
Botはただ動けばいいわけじゃなくて、いつ動かすか、異常があったらどう対応するか、そういった「運用のルール」を決めておくことが安定稼働の第一歩です。
✅ 稼働スケジュールの例
たとえばこんな感じで時間帯ごとに役割を分けています：
- 平日 9:00〜22:00：フル稼働（通常取引と監視）
- 深夜 22:00〜6:00：軽量モード（P&Dイベント検出だけ）
- 週末：Botを止めるか、最小構成でゆるく回す
このように、Botの負荷とリスクに合わせて稼働パターンを調整しておくことで、無駄なエラーや暴走も減らせます。
🛠️ 異常時の対応ルールも事前に決めておきます
- APIエラー → 自動再試行3回 → 失敗したらSlack通知 → 手動で再起動
- データ異常 → 欠損データをロギングして再取得
- CPU過負荷 → Kubernetesのオートスケーリングで自動対応
- 重大エラー（APIキー無効など） → 即Slack通知 → 手動で鍵の更新
こういった異常時フローが事前に定義されているだけで、安心感がまるで違うんです。
🧪 次に「最終パフォーマンスチェック」
Botがちゃんと動いているかどうかを数字で測るのがこのステップ。
ここでは、以下のような項目をチェックします：
- シミュレーション通りの取引精度が出てるか？
- APIの応答が遅くなってないか？
- ネットワーク障害後、何秒で復旧するか？
- ログはちゃんと記録されているか？
たとえば簡単な応答速度テストには、こんなPythonスクリプトを使いました：
import requests, time
URL = "http://localhost:5000"
def test_response_time():
start = time.time()
res = requests.get(URL)
end = time.time()
if res.status_code == 200:
print(f"✅ レスポンス: {end - start:.2f}秒")
else:
print("❌ エラー")
これを python performance_test.py で実行すれば、今のサーバーがちゃんと反応してるかどうかが一目でわかります。
📡 そして「デプロイ後の安定性チェック」
Kubernetesでデプロイしたあとも、きちんと動いてるかを確認する必要があります。
✅ 主なチェックコマンドはこんな感じ：
kubectl get pods：Podがちゃんと動いてるかkubectl logs <POD_NAME>：エラーログの確認kubectl top pods：CPUやメモリの使用状況- Grafanaダッシュボードで、Botの挙動やAPIエラーが可視化されているか
- Slack通知が届くかどうかのチェックも重要です
Botが停止したり、異常が起きたときにSlack通知が飛ぶように設定しておくと、気づける仕組みができあがるので非常におすすめです。
✅ 本番稼働前の最終確認項目
- すべてのPodが正常に起動しているか
- 通知系（Slack）が正しく動いているか
- 実際のトレード結果と、過去のシミュレーション結果の差を比較
- 異常時の自動リカバリーが機能しているか
これらを一通りクリアできたら、いよいよ本番稼働のスタートラインです。
🧭 次回予告：確認結果のレビューと最終調整
次回の放送では、今回の確認を経て明らかになった改善点や調整ポイントについて共有していきます。
また、稼働後に見えてきた課題や、リアルタイムでの挙動監視から得られたインサイトも少しずつ紹介できればと思っています。
以上、仮想通貨Bot開発記録 Part.14でした。
「ルールの設計」と「本番前チェック」――この2つがしっかりできていれば、Botは安心して任せられます。
🎙️ おまけ：初心者向けKubernetesチェックコマンド講座！
さてさて、ここでちょっとしたおまけです。
Botの監視や本番運用の話をしてきましたが、「Kubernetes（K8s）ってなにそれ美味しいの？」って方もいるかもしれません。
そんな方のために、これだけ覚えておけばOK！というKubernetesの超基本コマンドをご紹介しておきます。
🧾 1. Podの状態を確認するコマンド
kubectl get pods
Kubernetesで動かしてるBotが「今、生きてるかどうか」がわかります。STATUS列がRunningになっていればOKです。
📜 2. ログを確認するコマンド
kubectl logs <POD名>
Botが「何してるのか」「エラーが出てないか」を中身から確認できます。
わからないことがあったら、まずはログを見る癖をつけましょう。
🧠 3. リソース使用状況の確認
kubectl top pods
これは「CPU」や「メモリ」が使いすぎていないかを見るためのコマンドです。
Botが調子悪そうなときは、リソース不足が原因のことも多いので、これもよく使います。
🎙️ 補足：kubectlってなに？
「kubectl（クーブコントロールと読むことが多い）」は、Kubernetesとやりとりするためのコマンドツールです。
“k8sに話しかける魔法の言葉”と思っておけばOKです！
🎁 もうひとつのおまけ：応答速度テスト以外にやっておくべきチェック
さて、先ほどPythonでの応答速度テストをご紹介しましたが、それ以外にもやっておくと安心できるチェックポイントがあります。
✅ 1. データベース接続の確認
BotがPostgreSQLやRedisにアクセスしているなら、ちゃんと接続できているかチェック。
Pythonなら try/except で接続テストする簡単なスクリプトも用意しておきたいところです。
✅ 2. 通信相手のヘルスチェック
たとえば、取引所のAPIサーバーがメンテナンス中とか、遅延が起きてることもあります。
APIの /ping エンドポイントや /status を定期的に確認して、外部サービスの状態もチェックしておくのが吉です。
✅ 3. タイムゾーンの確認
Botを海外サーバーで動かしてる場合、タイムゾーンがズレていると取引タイミングが狂うことも。
Pythonなら datetime.now().astimezone() とかで、想定どおりの時刻が出てるか確認しておきましょう。
🎙️ まとめ：おまけが命を救う！？
Botって、トラブルの原因がコードそのものじゃなくて「設定ミス」や「環境のズレ」にあることも多いです。
だからこそ、**ちょっとしたチェックスクリプトや確認コマンドが、運用トラブルを未然に防いでくれる“命綱”**になるんですね。
次回の放送でも、こうした「ちょいネタおまけコーナー」をどんどん入れていきますので、楽しみにしていてください。
聞きながら「あ、それやってなかったかも」と思ったら、ぜひ今日から取り入れてみてくださいね。
🎁 おまけコーナー：初心者向け Kubernetes お守りコマンド集
Kubernetes（K8s）を使い始めたばかりの方にとって、「何を見たらいいのか分からない…」というのはよくある話。
でも大丈夫。ここではBot開発や運用の現場でよく使う “お守りコマンド” をまとめてご紹介します。
🟢 Podの状態を確認する
kubectl get pods
何が動いてるか・止まってるかを一覧で表示します。STATUS列が Running になっていれば、Podは正常に動作中です。
📦 個別のPodの中身を詳しく見る
kubectl describe pod <POD名>
Podの詳細情報を表示。
再起動回数やエラー理由、イベントログなども見れるので、トラブル時にまず見るべきコマンドです。
📜 ログを確認する（Botの出力やエラー）
kubectl logs <POD名>
Botの「つぶやき」をチェック！
Pythonで書かれたBotなら print() や logging.info() の出力がここに表示されます。
💥 落ちた原因が知りたいとき（クラッシュ対策）
kubectl logs --previous <POD名>
前回クラッシュしたときのログを確認できます。
Botが一度落ちてすぐ再起動した…というときには特に有効です。
📊 リソース使用状況を確認（CPUやメモリ）
kubectl top pods
Botがどれくらいのリソースを使ってるかを確認できます。
使用率が高すぎる場合は、リミットの見直しやスケーリングの検討を。
🔄 Deploymentの再起動（軽く叩き直す）
kubectl rollout restart deployment <Deployment名>
Podの中身を変更せずにDeploymentごと再起動します。
軽い不具合のときに一発で直ることもある「おまじない」。
🧼 リソース削除（開発環境の整理に）
kubectl delete pod <POD名>
Podを強制的に削除。Deploymentがあればすぐ再作成されます。
クラッシュ状態で固まってるときに便利です。
🌐 サービスにポートフォワード（ローカルからアクセス）
kubectl port-forward svc/<サービス名> 3000:80
たとえば、GrafanaやAPIサーバーに**http://localhost:3000**でアクセスできるようにします。
ローカルからUIを見たいときのお助けコマンド。
📌 お守りリストまとめ表
| コマンド | 目的 |
|---|---|
kubectl get pods | Podの状態を一覧表示 |
kubectl describe pod <POD名> | Podの詳細・トラブル確認 |
kubectl logs <POD名> | 実行中のBotのログを確認 |
kubectl logs --previous <POD名> | クラッシュ前のログを確認 |
kubectl top pods | CPU・メモリの使用状況を確認 |
kubectl rollout restart deployment <名前> | Deploymentの再起動 |
kubectl delete pod <名前> | 問題のあるPodを削除 |
kubectl port-forward svc/<サービス> 3000:80 | ローカルからサービスにアクセス |
✅ おまけのまとめ
- Kubernetesは最初はとっつきにくいけど、「使えるコマンド数個」だけで運用はかなり回せるようになります。
- 上記のコマンドをメモ帳にコピペしておくだけでも、いざという時に超便利です。
- 困ったときは、「Podの状態」「ログ」「リソースの使用状況」を見る――この3点セットを思い出してください。
以上、初心者向け Kubernetes お守りコマンド集でした！
今後は、Botの監視に役立つ「Grafanaのおすすめダッシュボード設定」や「Slack通知連携の手順」なんかもご紹介できればと思っています。