🛠️開発記録#196(2025/4/24)開発ログ「botと開発と稼働を両立させる」

1. そもそも Docker ＋ Kubernetes は「個人 botter」に最適か？

結論

• 当面 10 本以内 の bot を同サーバーで回すなら k3s 1 ノードクラスタ が最もコスパと可用性のバランスが良い。
• フル K8s は「昼夜 20 本以上・負荷分散・自動水平スケールが欲しい」段階で初めて ROI がプラスになる。

2. インフラ・パターン別シナリオ

私の状況（PC 2 台＋費用抑制）なら ↓

推奨ルート： まず A → B の二段ロケット
1️⃣ 低性能 PC に k3s を入れ、helm upgrade だけで bot を再デプロイできる形を固める。
2️⃣ 流量が増えたら同じ k3s マニフェストを 国内 VPS にそのまま載せ替え。コンテナレジストリは GH Packages で共通化。

3. 具体ステップ（90 日プラン）

4. コスト最適化 Tips

1. ノードは 1 vCPU / 2 GB から
   • MMbot ×2 + P&D bot ×1 程度なら余裕。
2. ログは 7 日で Loki に圧縮 → S3/Wasabi
   • Egress 圧縮でストレージ月¥100 未満。
3. CI/CD ランナーは自宅 PC を使い、GitHub Hosted Runner の分を節約。
4. Spot/VPS のミックス
   • 定常 bot: VPS、検証 bot: AWS Spot → terraform destroy で即削除。

5. 運用 & 開発を同時に回すワークフロー

graph LR
  A[VSCode Devcontainer] -->|git push| B[GitHub]
  B --> C[CI lint & test]
  C -->|helm package| D[GH Container Registry]
  D -->|Flux/ArgoCD sync| E[k3s Cluster]
  E --> F[Prom & Grafana Cloud]
  subgraph Local
    A
  end
  subgraph Cloud / VPS
    E
    F
  end

• コード⇄実稼働 の往復を git push 1 回に統一。
• 開発 PC でフルテスト → 運用ノードは自動ローリング更新。
• 外部サーバーに切り替えても Flux/Argo の GitOps パターンを踏襲するので手順変更ゼロ。

最終ジャッジ

スタートはローコスト & シンプルに。
“k3s + GitOps” を骨格に据えておけば、bot 数が 3→10→30 と増えても マニフェスト再利用＋ノード追加だけでスケールでき、開発スピードと運用安定の両方が犠牲にならない。