Bot

開発記録#149(2025/3/25)「論文ベースのbot開発フローpart.11 本番環境の最適化」

2025年3月25日

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

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

参考

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

Horizontal Pod Autoscalerウォークスルー
→Horizontal Pod Autoscaler (HPA) のDocs

Helmの公式HP

🚀 本番環境の最適化 (Auto Scalingとリソース制御の導入)

次のステップとして、Kubernetesを活用した本番環境の最適化に取り組みます。
以下の3つのタスクを順に進めます：

  1. リソース制限の導入
  2. Horizontal Pod Autoscaler (HPA) の導入
  3. Helmを活用したデプロイの効率化

1. リソース制限の導入

🔍 目的

  • 各Podが無制限にリソースを使用しないように制御
  • CPUとメモリの使用上限を設定し、サーバー全体の安定性を確保
Yodaka

以下は、過去の記事で紹介したコードの修正版です。

修正後の deployment.yaml (リソース制限追加)

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
        command: ["python", "data_collector.py"]
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

      - name: pnd-detector
        image: crypto_bot:latest
        command: ["python", "pnd_detector.py"]
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

      - name: trade-executor
        image: crypto_bot:latest
        command: ["python", "trade_executor.py"]
        resources:
          requests:
            cpu: "200m"
            memory: "256Mi"
          limits:
            cpu: "600m"
            memory: "1Gi"

      - name: monitoring-system
        image: crypto_bot:latest
        command: ["python", "monitoring_system.py"]
        ports:
        - containerPort: 5000
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

これは、4つの役割を持ったボットを、クラスタ上で安定的にスケーリング・管理するための設定です。

まず冒頭の apiVersion は、Kubernetesのバージョンを指定しています。ここでは "apps/v1"、つまりアプリケーション管理向けの最新APIバージョンを使っています。

次に kind は "Deployment"。
これは、アプリケーションを安定的にデプロイし、指定した数だけ常に稼働させてくれるリソースです。ここでは replicas: 3 とあるので、全体として3つの同じPodが常に動作するように設定されています。

metadata の name は "crypto-bot"。このDeploymentの名前を表しています。

さて、ここからが本題。spec.template.spec.containers の中には、4つのコンテナが定義されています。それぞれの役割を見ていきましょう。

🟢 1つ目は "data-collector"
このコンテナは、data_collector.py を実行する役割を担います。
仮想通貨の価格や注文板のデータなど、マーケットの情報を定期的に収集している部分ですね。

🟡 2つ目は "pnd-detector"
ここでは pnd_detector.py を起動しています。
P&D、つまり「パンプ・アンド・ダンプ」と呼ばれる急騰・急落イベントを検知するロジックが動いています。

🔴 3つ目は "trade-executor"
名前の通り、trade_executor.py を使って実際の取引を執行する部分です。
他と比べてリソースの割り当てが大きく、特にメモリやCPUを多めに確保しているのが特徴です。これは、取引実行には即時性や高精度が求められるためですね。

🔵 4つ目は "monitoring-system"
最後は monitoring_system.py。ポート5000番を開放していることから、おそらくウェブベースのダッシュボードか、ヘルスチェック用のAPIエンドポイントを提供しています。

💡全体としてのポイント
この構成のポイントは、1つのPodの中に複数の機能を持ったコンテナを協調動作させている点にあります。
しかもそれを3セット同時に動かすことで、システムの信頼性やスループットを向上させています。

さらに、各コンテナごとにリソース制限が設けられており、Kubernetesが自動的に最適なスケジューリングを行ってくれます。これにより、クラスタ全体の効率的な運用が実現されています。

噛み砕いた解説(初心者向け)

仮想通貨の自動売買ボットをどんなふうに動かしているのかを、
実際の設定ファイルをもとに、やさしく解説していきます。

Yodaka

「難しそう…」と思った方も、安心してください。
ここではなるべく専門用語を使わずに説明します。

📦 まず最初に
このファイルは、Kubernetes（クーバネティス）というシステムに、
「このプログラムをこうやって動かしてね」とお願いするための設計図です。

中でも、Deployment（デプロイメント） というものを使って、
ボットをいつでも安定して動かせるようにしています。

🔁 このボットは、同じものを3つ同時に動かすようになっています。
こうすることで、1つが止まっても他がカバーしてくれたり、
処理を分担して効率よく動かせたりします。

さて、今回のボットには4つの役割があります。
それぞれの役割は、**「コンテナ」**という箱の中に分けて動いています。

ひとつずつ、紹介していきますね。

🟢 1つ目のコンテナは、「データコレクター」
ここでは data_collector.py というプログラムを動かして、
仮想通貨の値段やチャートなど、マーケットの情報を集めています。

🟡 2つ目は、「P&D検出器」
P&D、つまり「Pump and Dump（ポンプ・アンド・ダンプ）」と呼ばれる、
価格が急に上がって、すぐに下がる怪しい動きを見つけるためのプログラムです。

これが pnd_detector.py ですね。

🔴 3つ目は、「取引の実行者」
集めた情報をもとに、実際に売買をするプログラムです。
trade_executor.py と呼ばれていて、
このボットの中でも特に重要な部分です。

なので、CPUやメモリなどのリソースが他より多く割り当てられています。
つまり、それだけパワーが必要ということですね。

🔵 4つ目は、「モニタリングシステム」
これは、ボット全体がうまく動いているかを監視したり、
必要があれば画面に表示したりするためのプログラムです。

monitoring_system.py という名前で、
5000番という番号のポートを使って外部とやりとりしています。

💡 まとめると…
このボットは、情報を集めて、異常を見つけて、取引をして、監視もする。
そんな4つの役割を、それぞれ別のコンテナで動かしています。

それを3セット同時に動かして、トラブルにも強くしている。
しかも、どの作業にどれだけの力（リソース）を使うかも、しっかり設定してあります。

2. Horizontal Pod Autoscaler (HPA) の導入

🔍 目的

  • 負荷の増減に応じて、自動でPod数をスケールアウト/スケールイン
  • CPU使用率が70%以上に達した場合に、Pod数を増加させる

HPAの定義ファイル (hpa.yaml)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: crypto-bot-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: crypto-bot
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
Yodaka

ここでは、Kubernetesの自動スケーリングの仕組み、
Horizontal Pod Autoscaler（HPA） の設定ファイルについて、
ひとつひとつ丁寧に解説していきます。

🧾 このファイルは何をするの？

この設定は、「仮想通貨のボット」を動かしているアプリが、
忙しいときは自動でPodの数を増やし、
落ち着いているときは減らす、という仕組みを作っています。

🔍 それでは上から順に見ていきましょう。

✅ apiVersion: autoscaling/v2

これは、この設定が「自動スケーリング」のためのものであり、
その中でも バージョン2（v2） を使っている、という意味です。
v2では、より柔軟なメトリクスの指定ができます。

✅ kind: HorizontalPodAutoscaler

ここでは、「これは HPA の設定ですよ」とKubernetesに伝えています。

✅ metadata.name: crypto-bot-hpa

これは、このHPAに「crypto-bot-hpa」という名前をつけている部分です。
HPAを他の設定と区別するためのラベルのようなものですね。

✅ scaleTargetRef

ここがとても重要です。

scaleTargetRef:
  apiVersion: apps/v1
  kind: Deployment
  name: crypto-bot

この部分で、「どのアプリを自動でスケーリングしたいのか」を指定しています。

  • apiVersion: apps/v1 は、そのアプリがDeploymentで動いていることを表し、
  • kind: Deployment で、対象がDeploymentであることを指定。
  • name: crypto-bot で、スケーリング対象の名前を crypto-bot にしています。

つまり、「crypto-botというDeploymentのPodを、自動で増減させてね」と指示している部分です。

✅ minReplicas: 3

最低でも 3個のPod は常に動かすように設定しています。
負荷が少なくても、3つは残しておく、ということです。

✅ maxReplicas: 10

最大で 10個のPod まで増やせるようにしています。
たとえば、取引量が増えてサーバーに負荷がかかったとき、最大10個まで自動でスケールアウトしてくれます。

✅ metrics

ここで、「どんな条件でPodの数を調整するのか」を決めています。

- type: Resource
  resource:
    name: cpu
    target:
      type: Utilization
      averageUtilization: 70

これは、「CPUの使用率」をもとにスケーリングする、という意味です。

たとえば、Podの平均CPU使用率が70％を超えたら、Podの数を増やす。
逆にそれより下がったら、必要に応じて減らす。という感じです。

🧠 まとめ

このHPAの設定では、

  • 「crypto-bot」というアプリを対象に、
  • 最低3個、最大10個のPod を、
  • CPU使用率が70％を超えたら 自動で調整してくれるようになっています。

Yodaka

これで、HPAの基本設定の意味がしっかりわかるようになりましたね。
Kubernetesにおいて、自動スケーリングはパフォーマンスとコストのバランスをとる鍵になります。

HPAの適用コマンド

kubectl apply -f hpa.yaml

HPAの確認コマンド

kubectl get hpa

3. Helmによるデプロイの効率化

🔍 目的

  • Kubernetesマニフェストをより柔軟に管理
  • バージョン管理と環境ごとの変数設定を一元化

Helm Chart構成

/helm
 ├── Chart.yaml
 ├── values.yaml
 ├── templates
 │   ├── deployment.yaml
 │   ├── service.yaml
 │   └── hpa.yaml

ここでは、Helm（ヘルム）というツールで使われる
「チャート」と呼ばれるパッケージの中身について、
実際のフォルダ構成をもとに、わかりやすく説明していきます。

📌 Chart.yaml（チャート情報）

このファイルは、チャートの自己紹介カードみたいなもの。

  • アプリの名前は何か
  • バージョンはいくつか
  • どんな用途のチャートなのか

などが書かれています。
たとえば、仮想通貨Botなら「crypto-bot」みたいな名前が入ります。

⚙️ values.yaml（設定ファイル）

このファイルは、アプリの設定値をまとめて書く場所です。

たとえば：

  • どのDockerイメージを使うか
  • Podの数はいくつにするか
  • CPUやメモリの制限はどうするか
  • HPAのターゲットは何パーセントか

などなど。

これを変えるだけで、同じアプリでも開発用・本番用に切り替えができます。
とっても便利です！

🧩 templatesフォルダ（テンプレートの置き場）

この中には、実際にKubernetesにデプロイされる
YAMLファイルの「テンプレート」が入っています。

🔹 deployment.yaml
これは、アプリの本体を動かす設定。
何個のPodを動かすか、どんなコンテナを使うかなどが書かれています。

🔹 service.yaml
これは、外部からアクセスできるようにするための設定。
たとえば、BotのモニタリングページやAPIを外部に公開したいときに使います。

🔹 hpa.yaml
これは、Horizontal Pod Autoscaler の設定。
CPUの使用率などに応じて、Podの数を自動で増やしたり減らしたりする仕組みです。

💡 まとめると…

このHelmチャートは、アプリの**設定（values.yaml）と、
その設定をもとに作られるテンプレート群（templates）**でできています。

「Chart.yaml」は名刺代わり、
「values.yaml」はカスタマイズの中心、
「templates」は実際に動くKubernetesのレシピです。

Helmを使えば、これらを1つにまとめて、
コマンド一発でアプリをまるごとデプロイできます。

Chart.yaml

apiVersion: v2
name: crypto-bot
description: A Helm chart for Crypto Trading Bot
version: 0.1.0
appVersion: "1.0"

ここでは、Helmチャートの基本となるファイル、
Chart.yaml の内容を解説していきます。

このファイルは、Kubernetes上で動かすアプリの名刺のようなものです。

✅ apiVersion: v2

これは、Helmチャートの仕様バージョンを表しています。
Helmにはバージョン1と2があり、
ここで v2 と書かれているのは、Helm 3以降で使える最新の形式という意味です。

✅ name: crypto-bot

このチャートの名前を表しています。
ここでは、「crypto-bot」、つまり仮想通貨ボットのアプリですね。

あとで helm install crypto-bot といったコマンドで使われる名前でもあります。

✅ description: A Helm chart for Crypto Trading Bot

この行は、このチャートがどんなものかを簡単に説明する部分です。

「これは仮想通貨のトレーディングボット用のHelmチャートですよ」と書かれています。

✅ version: 0.1.0

これは、チャートそのもののバージョン番号です。
アプリではなく、「このパッケージの内容がどのくらい更新されたか」を示します。

たとえば設定やテンプレートに変更を加えたときは、
この番号を「0.1.1」や「0.2.0」に上げていきます。

✅ appVersion: "1.0"

こちらは、チャートの中でインストールされる実際のアプリのバージョンです。

ここでは、「このチャートで動かす仮想通貨Botは、バージョン1.0です」と書いてあります。

つまり：

  • version: チャート（設計図）のバージョン
  • appVersion: 実際のアプリ（Bot本体）のバージョン

この2つは似てるけど、別物なので覚えておくと便利です。

🎙️ まとめ

この Chart.yaml ファイルは、Helmチャートの名刺。
誰が、何を、どんなバージョンで動かそうとしているのかを、
Kubernetesに伝えるための「自己紹介書」です。

Helmチャートを作るときには、このファイルが必ず必要になります。

values.yaml

replicaCount: 3

image:
  repository: your_dockerhub_username/crypto_bot
  tag: latest
  pullPolicy: IfNotPresent

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

hpa:
  enabled: true
  minReplicas: 3
  maxReplicas: 10
  cpuTarget: 70

ここでは、Helmチャートの中にある values.yaml ファイルの内容について、
実際の設定を見ながら、解説していきます。

このファイルは、アプリの動かし方をカスタマイズするための設定集です。
書き換えることで、同じアプリを開発用や本番用に切り替えたりできます。

では、ひとつずつ見ていきましょう。

✅ replicaCount: 3

この設定は、アプリの Pod（ポッド）をいくつ動かすか を決めています。
ここでは、常に3つのPodを動かすという意味です。

たとえば仮想通貨ボットなら、3つのBotが同時に取引している、というイメージですね。

✅ image

image:
  repository: your_dockerhub_username/crypto_bot
  tag: latest
  pullPolicy: IfNotPresent

ここでは、どのDockerイメージを使ってアプリを動かすか を指定しています。

  • repository: Docker Hub などにあるイメージの場所
  • tag: どのバージョンを使うか（ここでは "latest"）
  • pullPolicy: イメージを引っ張ってくるときのルールです

IfNotPresent は、「すでにローカルにある場合は再ダウンロードしない」という意味で、よく使われる設定です。

✅ resources

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

これは、Podごとに使えるリソース（CPUとメモリ）の量を決めています。

  • requests: 最低限これだけください、というリクエスト
  • limits: 最大でもこれ以上は使いません、という制限

この設定により、他のアプリとリソースを公平に分け合うことができます。

✅ hpa

hpa:
  enabled: true
  minReplicas: 3
  maxReplicas: 10
  cpuTarget: 70

ここでは、Horizontal Pod Autoscaler（HPA）を有効にするかどうかを設定しています。

  • enabled: true は、HPAを使う、という意味。
  • minReplicas: 最低3つはPodを動かす
  • maxReplicas: 最大10個まで増やせる
  • cpuTarget: CPUの使用率が70％を超えたらスケールアウトする

これにより、アプリの負荷に応じて自動でPodの数を調整できるようになります。

🎙️ まとめ

この values.yaml ファイルは、Helmチャートで動かすアプリのカスタム設定集です。

  • replicaCount でPodの数を決め、
  • image でどのDockerイメージを使うか指定し、
  • resources でリソースの使い方を制限し、
  • hpa で負荷に応じた自動スケーリングを可能にしています。

こうして設定された値は、テンプレートファイルの中で参照され、
実際のKubernetesの構成に反映されます。

Helmデプロイ手順

  1. Helmチャートのインストール
helm install crypto-bot ./helm
  1. アップデート (パラメータ変更時)
helm upgrade crypto-bot ./helm
  1. ステータス確認
helm status crypto-bot

4. 完了後の確認

✅ Pod数の確認

kubectl get pods

✅ リソース使用状況の確認

kubectl top pods

✅ HPAのスケール状況確認

kubectl get hpa

5. 次のステップ

次は、セキュリティ強化 (APIキーの安全な管理と監視機能の強化) に進みます。
具体的には以下を実施します：

✅ APIキーの安全な管理：Kubernetes Secretsの活用
✅ 監視機能の強化：Prometheus + Grafanaを使用したシステム監視

Yodaka

次の記事では、システムのセキュリティを強化についてまとめます。

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

続きを見る

おまけ：🎙️ 〜HPAってなに？やさしく解説〜

ここでは、Kubernetesの中でもとっても便利な機能、
Horizontal Pod Autoscaler（HPA） について、
初心者の方でもイメージしやすいようにお話しします。

💡 HPA、ひとことで言うと？
Horizontal Pod Autoscaler、略して HPA は、
アプリの負荷に合わせて、自動で「Podの数」を増やしたり減らしたりしてくれる仕組み です。

「Pod」というのは、Kubernetesで動いている小さなアプリの単位のこと。
それを、必要に応じて横に増やしていく から、「Horizontal」なんです。

📈 たとえば、こんなときに活躍します。

仮想通貨の価格が急に動いて、Botがたくさんの注文をさばかないといけないとき。
CPUの使用率が上がって、「これはちょっと1台じゃキツいぞ」となったら、
HPAが自動でPodを増やして、負荷を分散してくれます。

逆に、夜中などトラフィックが少ない時間帯には、
使ってないPodを減らして、無駄なリソースを省いてくれます。

⚙️ どうやって動くの？

HPAは、CPUやメモリの使用率を見ながら動きます。
たとえば「CPUが70％を超えたらPodを増やす」というように、
ルールを決めておけるんです。

こんな感じの設定で使います：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: crypto-bot-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: crypto-bot
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

ここでは、最低3個、最大10個までPodを自動で調整してくれるように設定しています。

✨ つまり、HPAを使うと…

  • 常に適切なパフォーマンスが保てる
  • ムダなリソースを使わずにすむ
  • システムがよりスマートで安定的に動くようになる

というわけです！

🎙️ここでは、Kubernetesの便利機能「Horizontal Pod Autoscaler」、
通称 HPA をやさしく紹介しました。

Yodaka

「Kubernetesってなんだか難しそう…」と感じる方も、
ひとつずつ仕組みを知っていけば、すごく頼れる相棒になってくれますよ。

おまけ2：🎙️ 〜Helmってなに？やさしく解説〜

ここでは、Kubernetesをもっと便利に使うためのツール、
Helm（ヘルム） について、やさしくお話ししていきます。

🚢 まず、ひとことで言うと…？

Helmは、Kubernetesのパッケージマネージャーです。
つまり、Kubernetes上にアプリを簡単にインストールしたり、アップデートしたりできる道具です。

たとえば、スマホでアプリをダウンロードするときに使う「App Store」や「Google Play」みたいなもの。
それのKubernetes版が「Helm」なんです。

📦 どうして必要なの？

Kubernetesでアプリを動かすときって、
Deployment、Service、ConfigMap、Secret、Ingress…
いろんな設定ファイルを書かないといけませんよね？

1個1個手作業でやると、すごく面倒だし、ミスもしやすい。
しかも、何百行ものYAMLファイルを管理するのって大変です。

そこで登場するのが、Helm。

🧙‍♂️ Helmを使うと、何ができるの？

Helmには、Chart（チャート） と呼ばれるテンプレートパッケージがあります。

このChartの中に、アプリを動かすための全部の設定が入っていて、
「Helm install ○○」とコマンドを打つだけで、
複雑なKubernetesアプリが一発で動くようになるんです。

💡 たとえば…

helm install my-bot ./crypto-bot-chart

こうするだけで、仮想通貨Botを動かすためのPodやService、HPAなどがぜんぶまとめてデプロイされます。

しかも、設定の値は values.yaml というファイルで簡単に変更できます。
同じアプリでも、本番用、開発用、テスト用に切り替えるのも楽ちん。

📚 どんなときに使うの？

  • チームでアプリを共有したいとき
  • 環境ごとに設定を変えたいとき
  • よく使うアプリを何度もデプロイしたいとき
  • 複数のリソースを一括管理したいとき

まさに、「Kubernetesを賢く、自動化して使いたい」人には、必須のツールです。

🔍 たとえるなら？

Helmは、「レストランのシェフ」が用意してくれる「レシピ」のようなもの。

材料（設定ファイル）をひとつひとつ集めるんじゃなくて、
「このレシピでお願いします」と言うだけで、
全部いい感じに作ってくれるんです。

🎙️ まとめ

Helmは、Kubernetesアプリのパッケージ管理ツールです。
アプリをまとめてデプロイしたり、設定を簡単に切り替えたり、
運用をスムーズにしてくれる、まさに頼れるアシスタントです。

Yodaka

Kubernetesに少し慣れてきたら、Helmを使いこなせるようになると、
便利さがグッと広がりますよ。

-Bot