Bot

開発記録#150(2025/3/25)「論文ベースのbot開発フローpart.12 セキュリティ強化」

2025年3月25日

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

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

参考

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

🔒 セキュリティ強化 (APIキーの安全な管理と監視機能の強化)

次のステップでは、システムのセキュリティを強化するために、以下の2点に取り組みます。

✅ APIキーの安全な管理
✅ 監視機能の強化 (Prometheus + Grafana)

1. APIキーの安全な管理

🔎 なぜSecretsが重要か？

  • APIキーや認証情報がconfig.yamlや環境変数に直接記載されていると、リスクが高まります。
  • KubernetesのSecretsを活用することで、APIキーなどの機密情報を安全に管理できます。

(1) Kubernetes Secretsの作成

Secrets作成コマンド

kubectl create secret generic api-keys \
  --from-literal=BYBIT_API_KEY='your_bybit_api_key' \
  --from-literal=BYBIT_API_SECRET='your_bybit_api_secret'

✅ 確認コマンド

kubectl get secrets
kubectl describe secret api-keys

(2) deployment.yaml の修正

環境変数をSecretsから読み込む

apiVersion: apps/v1
kind: Deployment
metadata:
  name: crypto-bot
spec:
  replicas: 3
  selector:
    matchLabels:
      app: crypto-bot
  template:
    metadata:
      labels:
        app: crypto-bot
    spec:
      containers:
      - name: data-collector
        image: crypto_bot:latest
        env:
        - name: BYBIT_API_KEY
          valueFrom:
            secretKeyRef:
              name: api-keys
              key: BYBIT_API_KEY
        - name: BYBIT_API_SECRET
          valueFrom:
            secretKeyRef:
              name: api-keys
              key: BYBIT_API_SECRET

✅ Secretsの再適用

kubectl apply -f deployment.yaml

2. 監視機能の強化 (Prometheus + Grafana)

🔎 なぜ監視が重要か？

  • システムのパフォーマンスや異常を早期発見
  • トレードシステムではAPIエラーや急激なトラフィック増加が致命的になるため、監視は不可欠です。

(1) Prometheus + Grafanaのインストール

PrometheusはKubernetesのPodやNodeのメトリクスを収集します。
Grafanaはこれらのデータを可視化します。

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

Prometheusのインストール

helm install prometheus prometheus-community/prometheus

Grafanaのインストール

helm install grafana grafana/grafana

✅ Grafanaの初期パスワード確認

kubectl get secret --namespace default grafana -o jsonpath="{.data.admin-password}" | base64 --decode

✅ Grafanaダッシュボードへのアクセス

kubectl port-forward svc/grafana 3000:80

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

(2) メトリクスの設定

  1. Exporter導入 (Node Exporter)
    • KubernetesのPodやCPU、メモリの使用状況を監視するためのエクスポーターを追加
  2. Custom Metricsの設定
    • Botの取引件数、エラー率、APIレスポンス時間などのカスタムメトリクスをPrometheusに追加

(3) metrics.py (Botのメトリクス収集)

from prometheus_client import start_http_server, Gauge
import time
import random

# メトリクス定義
trade_success = Gauge('crypto_bot_trade_success', 'Successful trades')
trade_failure = Gauge('crypto_bot_trade_failure', 'Failed trades')

# サンプルメトリクスデータ
def generate_metrics():
    while True:
        trade_success.set(random.randint(10, 100))  # 成功トレード数
        trade_failure.set(random.randint(0, 10))     # 失敗トレード数
        time.sleep(5)

if __name__ == '__main__':
    start_http_server(8000)  # ポート8000でメトリクスを提供
    generate_metrics()

✅ deployment.yamlへの追加

- name: metrics
  image: crypto_bot:latest
  command: ["python", "metrics.py"]
  ports:
  - containerPort: 8000

✅ Prometheusのターゲット設定

scrape_configs:
  - job_name: 'crypto-bot'
    static_configs:
      - targets: ['metrics:8000']

3. 完了後の確認

✅ Secretsの確認

kubectl get secrets

✅ Prometheusのターゲット確認

kubectl get pods -l app=prometheus

✅ Grafanaダッシュボードの確認

  • CPU使用率、メモリ使用率、APIエラー、取引数の可視化

4. 次のステップ

これで、システムの構築とセキュリティ強化が完了しました。

次は、システムの本番稼働に向けた最終準備として、以下のタスクに取り組みます。

✅ 運用ルールの確立：Botの稼働スケジュールや障害対応フローの策定
✅ 最終パフォーマンスチェック：シミュレーションと実運用の比較検証
✅ デプロイ後の安定性確認：サーバー監視とログの確認

Yodaka

次の記事では、システムの安定稼働を確保することについてまとめます。

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

続きを見る

解説：Kubernetes Secrets

今回はKubernetesで秘密情報――いわゆるSecretsをどうやって扱うか、その基本をお話しします。

さて、みなさん、APIキーやパスワードってどう管理してますか？
たとえば、仮想通貨の自動取引Botを動かすときなんか、取引所のAPIキーを使いますよね。
でも、それをコードにベタ書きするのは…やっぱりセキュリティ的に危険です。

そこで登場するのが「Kubernetes Secrets」。
これは、機密情報を安全に管理・利用できるKubernetesの機能なんです。

たとえば、以下のコマンドを実行すると：

kubectl create secret generic api-keys \
  --from-literal=BYBIT_API_KEY='your_bybit_api_key' \
  --from-literal=BYBIT_API_SECRET='your_bybit_api_secret'

何が起こるかというと、BYBIT_API_KEYとBYBIT_API_SECRETという名前の機密情報をKubernetesに登録できます。
このときの "your_bybit_api_key" や "your_bybit_api_secret" には、本物のAPIキーを入れるわけですね。

ここで重要なのは、この情報は暗号化されてKubernetes内部に保存されるということ。
Pod（コンテナ）を立ち上げるときに、このSecretsを環境変数として読み込ませることで、コードに書かずにセキュアに扱えるようになります。

このように、Kubernetesを使うと、システムの自動化とセキュリティ管理を両立できるんですね。

解説：deployment.yaml の修正

次は、それを実際のアプリケーションにどう組み込むのか、その実践編です。

使うのは、Kubernetesの**deployment.yaml**という設定ファイル。
ここに少し手を加えることで、Secretsに登録したAPIキーをコンテナ内で利用できるようになります。

たとえば、以下のように設定します：

env:
- name: BYBIT_API_KEY
  valueFrom:
    secretKeyRef:
      name: api-keys
      key: BYBIT_API_KEY
- name: BYBIT_API_SECRET
  valueFrom:
    secretKeyRef:
      name: api-keys
      key: BYBIT_API_SECRET

これ、何をしているかというと――
環境変数 BYBIT_API_KEY と BYBIT_API_SECRET を、それぞれSecretsで定義した値から読み込むように指定しています。

secretKeyRefというのは、「この環境変数の中身は、Secretsという箱から取ってきてね」という合図。
name: api-keys は、そのSecretsの名前。
key: には、Secrets内に保存されたキー名を指定します。

こうすることで、Botが立ち上がるたびに、APIキーが自動的に安全に環境変数として読み込まれるようになるわけです。

そして、設定ファイルを変更したあとは、いつものようにコマンドを一発：

kubectl apply -f deployment.yaml

これで、修正内容がKubernetesに反映されて、BotがSecretsつきで再起動します。

まとめると、Secretsを使って安全にAPIキーを管理するには：

  1. kubectl create secretでSecretsを作成
  2. deployment.yaml に環境変数の設定を追加
  3. kubectl apply で再適用

たったこれだけです。

セキュリティを意識した設計って、最初はちょっと面倒に見えるかもしれませんが、一度仕組みを作ってしまえば安心感がぜんぜん違います。
Botが誤ってAPIキーを漏らすなんてことも防げるので、これは本番環境での必須技とも言えるでしょう。

以上、今回はKubernetesでSecretsをアプリに組み込む方法について解説しました。
今後はこのSecretsをConfigMapと組み合わせて応用する方法などについても触れていけたらと思います。

解説：Prometheus + Grafana

さて、Botがちゃんと動いているかどうか、どうやって把握してますか？
「とりあえずログを見ればいいや」って思いがちなんですが、それじゃ間に合わないときがあるんです。

たとえば、APIが急に返事しなくなったり、異常なトレードが発生したり、メモリがパンパンになったり…。
Botって、止まるときは本当に一瞬です。だからこそ、監視の仕組みが命綱になります。

🔎 なぜ監視が重要か？

とくに仮想通貨のトレードシステムでは、以下のような致命的なトラブルが起こるリスクがあります：

  • APIの障害で注文が通らない
  • 異常なトラフィックでBotがフリーズ
  • メモリリークでコンテナが落ちる

こうした問題をリアルタイムで検知するには、監視ツールの導入が欠かせません。

🛠️ Prometheus + Grafana の導入

そこで登場するのが、Prometheus（プロメテウス）とGrafana（グラファナ）。
この二つを使えば、メトリクス収集と可視化があっという間にできます。

▼ インストール手順（Helmを使用）

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm install prometheus prometheus-community/prometheus
helm install grafana grafana/grafana

PrometheusはKubernetesの内部を監視してくれる"収集係"。
Grafanaはそのデータを"見える化"してくれるダッシュボードです。

▼ Grafanaの初期パスワード確認

kubectl get secret --namespace default grafana -o jsonpath="{.data.admin-password}" | base64 --decode

▼ ダッシュボードへのアクセス

kubectl port-forward svc/grafana 3000:80

ブラウザで http://localhost:3000 にアクセスすれば、リアルタイムのシステム状況を一目で確認できます。

📊 メトリクスの設定

ここまで来たら、次は「何を監視するか」です。

▼ Node Exporter の導入

これはCPUやメモリ使用率など、基本的なリソース情報を拾うための仕組み。

さらに、自作Bot特有の情報――つまり「カスタムメトリクス」も取りましょう。

🧠 metrics.py（Botのメトリクス収集）

from prometheus_client import start_http_server, Gauge
import time
import random

# メトリクス定義
trade_success = Gauge('crypto_bot_trade_success', 'Successful trades')
trade_failure = Gauge('crypto_bot_trade_failure', 'Failed trades')

# ダミーデータを生成（本番ではリアルなデータに置き換える）
def generate_metrics():
    while True:
        trade_success.set(random.randint(10, 100))
        trade_failure.set(random.randint(0, 10))
        time.sleep(5)

if __name__ == '__main__':
    start_http_server(8000)  # メトリクスをポート8000で公開
    generate_metrics()

このコードはBot内部で成功・失敗トレード数を監視メトリクスとして提供します。

🧩 deployment.yaml への追加

metrics.pyをBotに組み込むには、以下のようにdeployment.yamlに記述します：

- name: metrics
  image: crypto_bot:latest
  command: ["python", "metrics.py"]
  ports:
  - containerPort: 8000

📡 Prometheusのターゲット設定

最後に、Prometheusがこのメトリクスを収集できるように、以下のような設定をします：

scrape_configs:
  - job_name: 'crypto-bot'
    static_configs:
      - targets: ['metrics:8000']

これで、Prometheusがmetrics.pyから定期的に情報を取得し、Grafanaで可視化できるようになります。

🎙️ まとめ

  1. Prometheusで情報を収集
  2. Grafanaでビジュアルに可視化
  3. metrics.pyでBotの挙動を数値化
  4. deployment.yamlとPrometheus設定でKubernetesと連携

ここまでやれば、Botがこっそり死んでたり、異常を起こしていてもすぐに気付ける体制が整います。

解説：Prometheus と Grafana

ここでは、システム監視の世界でとてもよく使われている２つのツールをご紹介します。

その名も、Prometheus（プロメテウス）とGrafana（グラファナ）。

この２つ、よくセットで使われるんですが、それぞれに役割があります。
ざっくり言うと、Prometheusはデータを集める人、Grafanaはそのデータを見やすく整える人です。

🔧 Prometheusってなに？

Prometheusは、システムやアプリケーションのパフォーマンス情報を定期的に収集するツールです。
たとえばこんなことができます：

  • CPUの使用率
  • メモリの使用量
  • ネットワークの負荷
  • 自分で定義した独自の指標（たとえばトレードBotの成功数や失敗数）

これらの情報を、時系列データとして保存してくれるのがPrometheusです。
特徴は、プッシュ型ではなくプル型ということ。
つまり、対象のサーバーやアプリに「君の状態を教えて！」と自分から定期的に取りに行く仕組みなんですね。

🎨 Grafanaってなに？

一方、Grafanaは可視化ツールです。
Prometheusが集めたデータを使って、グラフやダッシュボードを作ることができます。

たとえば：

  • 「Botのエラー率が急増してる」
  • 「APIのレスポンスがいつもより遅い」
  • 「CPUの使用率が限界を超えそう」

こうした状況を、リアルタイムにビジュアルで確認できるようになります。
しかも、Grafanaはアラート機能もあるので、設定しておけばSlackに通知を飛ばすこともできるんです。

🎯 なぜこの２つが重要か？

Botを動かしていると、知らないうちにトラブルが起きることがあります。
APIが落ちていたり、メモリが足りなくなっていたり、場合によっては注文が通っていないなんてことも。

でもPrometheusとGrafanaを使えば、そういった異常を早期に検知できるんです。

たとえば、「トレードBotの成功数がゼロになった」→「通知が飛んでくる」→「すぐに原因をチェック」
こういった対応ができるようになります。

📦 まとめ

ツール役割
PrometheusシステムやBotの動きをモニタリングして、数値として収集する
Grafanaその数値を見やすく表示し、異常があれば通知してくれる

この２つは、まさに**「見える化」の最強コンビ**です。
仮想通貨Botの運用だけでなく、サーバー監視やアプリの安定運用にも大活躍します。

おまけ：その他のシステム監視ツール５選

Botやアプリ、サーバーがちゃんと動いてるかどうかを見守る――それが「システム監視」の役割です。

Prometheus + Grafanaは有名ですが、今日はそれ以外の選択肢も含めて、いくつかご紹介していきます。

✅ 1. Zabbix（ザビックス）

昔からあるオールインワンの監視ツールです。
GUIも比較的わかりやすくて、SNMP対応やトラップ監視、メール通知など機能が豊富。

🔍 向いている場面：

  • 大規模ネットワークの監視
  • 細かく監視条件を設定したい場合

📌 ただし：
インストールや設定がやや重め。軽快な使い心地というよりは「ガッチリ系」。

✅ 2. Datadog（データドッグ）

こちらはクラウドベースの監視SaaS。
ダッシュボードも洗練されていて、導入がとにかく楽。
メトリクス収集、ログ管理、トレース分析など全部まとめてできます。

🔍 向いている場面：

  • クラウドネイティブなアプリケーション
  • 開発スピード重視のチーム

📌 ただし：
有料です。特にBotが複数あるような環境だとコストが積み上がりがち。

✅ 3. New Relic（ニュー・レリック）

Datadogと同じくSaaS型の監視サービスで、特にアプリケーション内部のパフォーマンス分析（APM）に強いです。

🔍 向いている場面：

  • PythonやNode.jsなどのアプリケーションの内部挙動を詳しく見たいとき
  • フロントエンド〜バックエンドまでを一気通貫で監視したいとき

📌 ただし：
こちらも有料。無料枠もありますが、本格的に使うならプラン選定が必要です。

✅ 4. Elastic Stack（旧ELK）

Elasticsearch + Logstash + Kibana、略してELK。
最近はBeatsやFleetなども加えて「Elastic Observability」と呼ばれています。

🔍 向いている場面：

  • ログ監視に特化したいとき
  • 複雑なクエリでデータを分析したい場合

📌 ただし：
初期構築やスケーリングがちょっと大変。ログ基盤を自前で持ちたい人向け。

✅ 5. VictoriaMetrics（ビクトリアメトリクス）

実はこれ、Prometheusの互換ツールなんですが、大規模なメトリクス処理に強いんです。
大量のBotやサーバーを扱うとき、Prometheusではスケールに限界がありますが、VictoriaMetricsはそれを補います。

🔍 向いている場面：

  • 高頻度・大量のメトリクス監視が必要なケース
  • Prometheus互換でスムーズに移行したい場合

🎯 まとめ表

ツール名特徴向いている用途備考
Zabbixオールインワン、古参サーバー監視、SNMP監視重めの構築が必要
Datadogクラウド型、UIが使いやすいクラウド運用、SaaS監視有料
New Relicアプリ内部のAPMに強いWebアプリ、API監視有料
Elastic Stackログ中心の監視エラー分析、ログの可視化構築に技術が必要
VictoriaMetricsPrometheus互換・高性能大量メトリクスの集約拡張用途向け

🎙️ まとめ

Prometheus + Grafanaはすばらしい組み合わせですが、目的や規模に応じて他のツールも視野に入れるとより最適化できます。
特に、ログを重視するか、アプリ内部の挙動を見たいか、クラウドかオンプレか――このあたりで選び方が変わってきます。

🔍おまけ： メトリクスとは？

一言で言うと、メトリクスとは“数値化された観測データ”のことです。

たとえば、仮想通貨のトレードBotを運用しているとしましょう。
そのBotの挙動を「ちゃんと動いてるかな？」「異常はないかな？」と監視するためには、何かしらの数字的な指標が必要ですよね。

そのときに使われるのが「メトリクス」なんです。

📊 具体例でいうと…

  • CPUの使用率 → cpu_usage: 72%
  • メモリの消費量 → memory_usage: 512MB
  • 1秒間あたりのAPI呼び出し数 → api_calls_per_sec: 13
  • 成功したトレードの数 → trade_success: 48
  • エラーの発生回数 → error_count: 3

こういった数値は、Botの健康状態を示す“体温”や“脈拍”のようなものなんです。

⚙️ なぜメトリクスが大事か？

たとえば、人間だって体調を把握するには体温や血圧が必要ですよね？
それと同じで、Botやサーバー、アプリも、メトリクスがあることで**「今どうなってるか」**が分かります。

  • 異常を検知できる
  • パフォーマンスを最適化できる
  • トラブルの原因を特定できる

つまり、メトリクスがあると「見えないはずの状態が見える」ようになるんです。

🧠 技術的な一歩

監視ツール（たとえばPrometheus）は、このメトリクスを定期的に集めて保存します。
そしてGrafanaのような可視化ツールを使うことで、それがグラフやチャートとして目に見える形に変わるんです。

🎯 まとめ

言葉意味
メトリクスシステムやアプリの状態を数値で表したもの
例CPU使用率、トレード回数、エラー数など
使い道異常検知・監視・パフォーマンス分析など

🎙️というわけで、**「メトリクス＝システムのバイタルサイン」**と思っていただければOKです。

-Bot