※本記事にはアフィリエイト広告(プロモーション)が含まれています。

ボットは正常に動いているのに、ある日突然「ディスクに空き容量がありません」というエラーで止まる――これは24時間稼働させているVPSで実際に起こりうる典型的な障害パターンです。CPUやメモリと違って、ディスク容量は普段は意識されにくく、気づいた頃には手の施しようがないところまで積み上がっていることがあります。この記事では、ディスクが圧迫される典型的な原因と、ログローテーション・容量監視の基本的な考え方を一般的な技術解説として整理します。

なぜディスクは静かに圧迫されるのか

CPU使用率やメモリ使用量は監視していても、ディスク容量までは見ていないという運用は少なくありません。しかもディスクの圧迫は、CPUスパイクのように一瞬で起きるものではなく、何週間、何ヶ月とかけて少しずつ進行します。典型的な原因を挙げます。

• アプリケーションのログファイル: ボット自体が出力するログが際限なく肥大化する
• Dockerコンテナのログドライバ: デフォルト設定では、コンテナの標準出力がホスト側に無制限に蓄積される
• システムログ(journald/syslog): OS自体のログも、設定次第では際限なく増え続ける
• バックテスト用のOHLCVデータやキャッシュ: 検証のために蓄積したデータファイルが徐々に積み重なる
• パッケージ管理のキャッシュ: aptやpipのキャッシュも、長期運用の中で地味に容量を使う

アプリケーション側のログ出力の設計そのものについてはログ設計の記事で扱っているので、ここではVPS・OS・Dockerというインフラ側の観点から整理します。

logrotateでシステムログを管理する

Linuxの多くのディストリビューションにはlogrotateという仕組みが標準で入っており、/etc/logrotate.d/以下に設定ファイルを置くことで、指定したログファイルを定期的に分割・圧縮・削除できます。

# /etc/logrotate.d/trading-bot の例
/var/log/trading-bot/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

• daily: 日次でローテーションする
• rotate 14: 直近14世代(この例では14日分)だけ保持する
• compress: 古いログを圧縮してさらに容量を抑える
• copytruncate: ファイルをコピーしてから元ファイルを空にする方式。ボット側でファイルハンドルを開きっぱなしにしていても安全に使える

設定後は次のコマンドでドライラン(実際には実行せず動作確認のみ)できます。

logrotate -d /etc/logrotate.d/trading-bot

多くのディストリビューションではlogrotate自体がcronやsystemdタイマーで自動的に毎日実行されるよう最初から組み込まれています。自分で設定ファイルを置くだけで動き出すことが多いので、まずは現在のOSでlogrotateがどう動いているかを確認するとよいでしょう。

Dockerのログドライバにも上限を設定する

Dockerでボットをデプロイする記事で触れたとおり、コンテナのログはデフォルトではjson-fileドライバによってホスト側にそのまま蓄積されます。この設定にはデフォルトでサイズ上限がないため、標準出力に流しているログが多いボットほど、気づかぬうちにディスクを圧迫しやすくなります。

docker-compose.ymlでログドライバに上限を設定しておくと安全です。

services:
  bot:
    image: trading-bot:latest
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

この設定では、ログファイル1つあたり最大10MB、最大5世代までしか保持されません。古いログは自動的に削除されるため、ディスクが無制限に増え続けることはなくなります。すべてのコンテナに同じデフォルトを適用したい場合は、/etc/docker/daemon.jsonにlog-optsを記述してDockerデーモン全体のデフォルトを変更することもできます。

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "5"
  }
}

※Dockerのバージョンやログドライバの種類によって設定可能な項目は変わるため、実際に設定する際は利用しているDockerのバージョンに合った公式ドキュメントを確認してください。

journald(systemdのログ)の容量上限

多くのLinuxディストリビューションでは、OS自体のログがsystemdのjournaldによって管理されています。これも設定次第では際限なく蓄積されるため、上限を決めておくと安心です。

# 現在のjournalログの使用量を確認
journalctl --disk-usage

# 使用量を手動で一定サイズまで削減する
sudo journalctl --vacuum-size=200M

恒常的に上限をかけたい場合は/etc/systemd/journald.confに以下のような設定を追加し、systemctl restart systemd-journaldで反映します。

[Journal]
SystemMaxUse=200M

ディスク使用量を定期的に監視する

ローテーションや上限設定でログの増加を抑えても、何らかの想定外の要因(ダンプファイルの残留、取得したOHLCVデータの蓄積など)でディスクが圧迫されることはあります。最終的には「今どれだけ使っているか」を定期的に把握する仕組みが欠かせません。

# ディスク全体の使用率を確認
df -h /

# ディレクトリごとの使用量を調べる(容量が大きい順)
du -sh /var/log/* /var/lib/docker/* 2>/dev/null | sort -rh | head -10

これをcronで定期実行し、閾値を超えたら通知を送る、という簡単な仕組みを組んでおくとより安心です。

#!/bin/bash
# disk_check.sh: 使用率が90%を超えたら通知する例
THRESHOLD=90
USAGE=$(df / --output=pcent | tail -1 | tr -dc '0-9')

if [ "$USAGE" -ge "$THRESHOLD" ]; then
    echo "警告: ディスク使用率が${USAGE}%です"
    # ここでDiscordなどへの通知処理を呼び出す
fi

Discordへの通知の具体的な実装はDiscord通知ボットの作り方の記事にまとめているので、このスクリプトと組み合わせると、ディスク容量の異常にも気づける監視体制になります。こうした定期チェックを他の監視項目と合わせてどう運用に組み込むかは、毎日の監視ルーティンの記事も参考になります。

VPS選定時にも容量は確認しておく

ログやデータの蓄積ペースは、動かしているボットの数や取得するデータ量によって変わります。複数のボットを1台のVPSで動かす、あるいは長期間のOHLCVデータをローカルに保存する運用であれば、想定よりも早くディスクを使い切ることがあります。どのプランを選ぶかの判断材料についてはVPS徹底比較の記事、24時間運用全般の注意点はVPSでの24時間運用の記事で扱っているので、容量に余裕のあるプランを選んでおくことも結果的に運用の手間を減らします。

まとめ

• ディスク容量の圧迫はCPU・メモリと違って静かに進行し、気づいた頃には手遅れになりやすい
• システムログはlogrotate、journaldはSystemMaxUseで上限を設定できる
• Dockerのログドライバはデフォルトで無制限なので、max-size/max-fileで上限を設定する
• df/duによる定期チェックをcronなどで自動化し、閾値超えを通知する仕組みを用意する
• 複数ボットの運用やデータ蓄積が多い場合は、VPS選定時点で容量に余裕を持たせておく

ログローテーションやディスク監視は、トラブルが起きてから初めて重要性に気づく分野です。ボットのロジック自体の改善と同じくらいの優先度で、早い段階から仕組みを整えておくことをおすすめします。