WindmillのVPS要件：RAM・CPU・ストレージの目安

Windmillは、スクリプトをWebhook、ワークフロー、cronジョブ、社内向けUIに変えるオープンソースの開発者向けプラットフォームです。静的サイトのホスティングではなく、RetoolやTemporalの対抗として位置づけられています。コミュニティ版のライセンスはAGPL-3.0で、エンタープライズ版はライセンスキーの先にあります。

サイジングの考え方は一般的なWebアプリとは異なります。容量の単位がアプリケーションではなくワーカーだからです。

スペックを決めるアーキテクチャ

公式のdocker-compose.ymlは7つのサービスを起動します。

この表のなかで、特に重要な点が2つあります。

Redisはありません。 WindmillはPostgreSQLをキューとして使います。第三者のガイドの多くがRedisコンテナとREDIS_URLを足していますが、公式のcomposeファイルにはどちらも存在せず、そうしたガイドを写すとWindmillが一度も接続しないサービスを動かし続けることになります。

コストの中心はワーカーです。 サーバー本体は比較的暇です。実際にお金を払っている対象はワーカーの処理能力です。

RAMとCPU：ワーカー単位で決める

実務上の目安はvCPU1つにつきワーカー1つ、それぞれに1〜2GBのRAM、加えてPostgresとサーバーの分の余裕です。

ネイティブワーカーは知っておく価値のある例外です。軽量なジョブを約0.1 CPUと128MBで実行するため、標準構成は追加のコアを求めずに標準ワーカーの隣へ1つ置けます。

誰も予測できない変動要因が依存関係のインストールです。pandasを取り込むPythonジョブや、ロックファイルの大きいTypeScriptジョブは、定常状態の数値をかなり上回るメモリを一時的に使います。初回の実行だけ失敗して次から成功するなら、RAMが足りないなかで依存キャッシュが構築されている場面を見ているわけです。

ストレージ：増えるのは依存キャッシュ

データベースは長いあいだ小さいままです。ジョブのメタデータ、スクリプト、フロー、ログはいずれもテキストです。増えていくのはworker_dependency_cacheで、ジョブが取り込んだPythonのwheelやnpmパッケージが、次回の実行でインストールを省くために保存されます。

40GBから始めてください。リサイズの判断はデータベースではなくキャッシュのボリュームを見て行い、NVMeまたはSSDを選びます。Postgresはここでストレージ役だけでなくキュー役も担うため、I/Oのレイテンシに敏感です。

この要件を満たすVPSプラン

Windmillは、1GBのプランが自動的に失格にならない数少ないセルフホストアプリの1つです。ネイティブワーカー1つなら実際に収まります。ただしそこに標準ワーカーは置けないため、依存関係を伴うPythonやTypeScriptのジョブは動かせません。つまり運用ではなくデモの位置づけになります。

スケールさせる

Windmillは1つのプロセスを大きくするのではなく、ワーカーのコンテナを増やして水平にスケールします。処理量を倍にしたいなら、同じDATABASE_URLを指す2つ目のwindmill_workerサービスを追加し、サーバーにもう1コア与えてください。

これはVPS選びに実際的な結論をもたらします。ここでは速いコアより多いコアが勝ちます。Contaboの税別5.50 EURの4 vCPUはワーカー4つ分の並列性を買え、HetznerのCX23はほぼ同じ価格で2つ分です。ワークロードが少数の重いジョブではなく多数の小さなジョブなら、この比率が判断のすべてになります。

• リサイズの前にdocker statsで、どのワーカーが飽和しているかを確認してください。
• ワーカーをタグでグループ分けし、重いジョブがそれ用にサイジングしたマシンへ届くようにしてください。
• キューを担っているのはPostgresです。メモリを足す前に、まず速いディスクを与えてください。

各社のプランをより広く見比べたい場合は、VPS比較の全体版をご覧ください。