月€8のVPS 1台で自動処理を60本動かした実測（Contabo・41日連続稼働）

構成：月€8のVPS 1台に全部乗せている

使っているのはContaboのアジア・シンガポール拠点のVPSで、料金は月€8.00です。スペックはCPU 4コア、メモリ7,941MB、ディスク72GB。OSはUbuntu 24.04で、Apache 2.4 / PHP 8.3 / MariaDB という構成です。

この1台に乗っているものは、大きく分けて2種類あります。

• cronに登録した自動処理：60本
• Webサイト4つ（WordPress 2つ、Node.jsアプリ2つ）

自動処理の内訳は、SNS自動運用が50本、YouTube関連が13本、ブログ記事の自動生成・投稿が3本です。この内訳を単純に足すとcron 60本という数と一致しません。1本のジョブが複数の用途にまたがっているのか、私の数え方がずれているのか、正確なところは把握できていません。ここは「分かっていない」とだけ書いておきます。

実測：CPUもメモリもディスクも余っている

41日間動かしたあとの数字がこちらです。

uptime      : 41日（無停止）
memory      : 1,442MB / 7,941MB 使用
disk        : 72GB のうち 22% 使用
load average: 1.34 / 1.76 / 1.92（4コア）

メモリは7,941MB中1,442MBしか使っておらず、約6.3GBが手つかずで残っています。ディスクも72GBの22%です。load averageは1.34〜1.92で、4コアに対してこの値なので、CPUも張り付いてはいません。

「60本」でも同時に動いているのは2つだけ

数字が思ったより低かったので、実際に走っているPythonプロセスを数えてみました。結果は2つです。

理由は単純で、60本を24時間に散らして登録しているからです。cronの本数は「登録数」であって「同時実行数」ではありません。ここを混同すると、必要以上のスペックを買うことになります。60本という数字だけ見ると重そうに感じますが、実行タイミングをずらしていれば、瞬間的な負荷は数本分にしかなりません。

唯一、明確にサーバーを重くしたのは ffmpeg

ここまで余裕がある構成でも、1つだけ実害が出た処理があります。動画生成のffmpegです。

ffmpegはCPUを素直に使い切りにいくので、放っておくと動画の書き出し中に、同じサーバーに同居しているWebサイトの表示が遅くなりました。自動処理のためにサイトの応答が犠牲になるのは本末転倒です。

対策として、実行時に使うコアと優先度を落としました。

taskset -c 0-1 nice -n 10 ffmpeg ...

taskset -c 0-1 で4コアのうち2コアに限定し、nice -n 10 で優先度を下げる。この2つを付けただけで、書き出し中にWebサイトが遅くなる症状は出なくなりました。残り2コアがWebサイトの応答用に空くこと、そして優先度が低いのでApacheやPHPに割り込まれることが効いています。

本当のボトルネックはサーバーではなかった

41日運用してはっきりしたのは、詰まる場所はCPUでもメモリでもなく、各サービスのレート制限だったということです。

メモリは6.3GB余り、ディスクは78%空いていて、同時実行のPythonプロセスは2つ。この状態で「もっと本数を増やせるか」を考えると、増やせない理由はサーバー側にはありません。投稿先・取得先の各サービスが受け付けてくれる回数が上限で、それ以上叩けないから間隔を空けている、というのが実態です。

この構成で言えること／言えないこと

• 4コア / 7,941MB / 72GB の1台で、cron 60本とWebサイト4つを41日間無停止で回せた
• ジョブを24時間に散らせば、同時実行は2プロセス程度に収まった
• ffmpegは taskset と nice で同居先のWebサイトへの影響を消せた

• cron 60本と内訳（50 / 13 / 3）の対応関係は、正確には把握できていない
• 41日より長期で、あるいは同時実行がもっと増えたときにどうなるかは未検証
• 各サービスのレート制限の具体的な数値は、この記事では扱っていない

結論として、月€8のVPS 1台は、この規模の自動処理では余っていました。ただしそれは「安いサーバーで何でもできる」という話ではなく、CPUを食う処理を1つだけ隔離した結果であり、かつ本数の上限をサーバーではなく外部サービスが決めていたから成立している、というのが実際のところです。