Kamalはサーバー上ではなく、自分のマシンやCIランナーで動くデプロイツールです。ですから「KamalのVPS要件」とは、実際にはKamalがデプロイする先のマシンについての話になります。そのマシンは、アプリケーションのコンテナ、kamal-proxy、宣言したアクセサリ、そしてロールバック用に保持される数日分の古いイメージを載せる必要があります。
Kamal自身がホストで消費するリソースはゼロです。見積もるべきはそれ以外のすべてです。
ホスト上でリソースを使うもの
kamal setupのあと、サーバーでは3つが動きます。
- kamal-proxy：80番と443番ポートを保持する、Go製の小さなHTTPプロキシ
- アプリのコンテナ：
config/deploy.ymlのロールごとに1組 - アクセサリ：Postgres、Redis、その他宣言したサービス
見積もりに効いてくるのは真ん中の2つだけです。kamal-proxyは単一の静的バイナリで、実際のアプリケーションの傍らでは存在感がありません。
RAM
見落とされがちなのは定常時のメモリではなく、デプロイ重複分です。Kamalは旧コンテナがトラフィックを処理したまま新コンテナを起動し、新しい方がヘルスチェックを通ってから旧コンテナを停止します。したがってメモリのピークは、通常の使用量にアプリコンテナおよそ1つ分を足した値になります。
- 実用上の下限：2 GB。データベースを別に持たない小さなアプリ向け
- 余裕のある構成：4 GB。一般的なWebアプリとPostgres、そしてデプロイ重複分を賄えます
- 4 GBのホストにはスワップを追加：デプロイの途中でスワップが始まったホストは、ヘルスチェックの猶予を逃すほど遅くなることがあり、すると一見理由のないままデプロイがロールバックされます
Postgresをマネージドサービスではなくアクセサリとして動かすなら、その分を明示的に見積もってください。マシン上で最も食うのはKamalではなく、そちらです。
CPU
妥当な下限は2 vCPUですが、その理由は定常時の負荷とは関係ありません。デプロイ中のホストは、イメージの取得、コンテナの起動、ヘルスチェック、そして旧コンテナからのトラフィック処理を同時に行います。1 vCPUではこの競合がデプロイ時間を引き伸ばします。
- 最小：1 vCPU。低トラフィックのアプリで、デプロイが遅くなるのを許容できるなら使えます
- 推奨：2 vCPU
- 本当にそれ以上が要るのは、VPS上でイメージをビルドする場合だけです。手元のノートPCがarm64で、VPSが唯一のamd64マシンなら、ビルドは与えたコアをすべて使い切ります
ストレージ
Kamalの挙動が数字を実際に変えるのはここです。Kamalはkamal rollbackがレジストリから取得せずに以前のバージョンを起動できるよう、古いコンテナとイメージをサーバーに残し、既定では3日後に整理します。
つまりディスクが抱えるのは次のものです。
- アプリケーション自身のデータとボリューム
- 現行のイメージに加えて、およそ3日分の以前のバージョン
- 何世代保持しても1度しか保存されない共有ベースレイヤー
1 GBのイメージを1日数回デプロイする程度なら、40 GB NVMeで問題ありません。25 GBのディスクに3 GBのイメージなら1週間で埋まります。障害の出方は知っておく価値があります。ディスクが埋まって壊れるのは、それを埋めたデプロイではなく次のデプロイなので、原因と症状のあいだに数日の開きが生じます。
デプロイの頻度が高いなら、kamal prune allで3日の猶予を待たずに溜まった分を掃除できます。
VPSプロバイダーと価格
| プロバイダー | 月額 | 主な特徴 | アフィリエイトリンク |
|---|---|---|---|
| Contabo | €5.99 | 400 GBのディスク。イメージ履歴が制約になりません | Contabo |
| Hetzner Cloud | €5.49 | 2 vCPU / 4 GB / 40 GB NVMe。危ないデプロイの前にスナップショット | Hetzner Cloud |
| DigitalOcean | $6 USD | Kamalが扱わないホスト側の設定について最も明快なドキュメント | DigitalOcean |
| Vultr | $5 USD | リージョンの選択肢。アプリを利用者の近くに置きたいときに効きます | Vultr |
| Linode (Akamai Cloud) | $5 USD | 価格が読みやすく、ネットワーク構成も素直 | Linode |
選択肢を一通り見るには、VPS比較をご覧ください。
入口として最も楽なのはDigitalOceanです。KamalはDockerより先のホスト管理を意図的に行わないため、ファイアウォール、スワップ、自動更新は自分の担当として残り、DigitalOceanのドキュメントはその3つをすべて押さえています。その設定を自分でやることに抵抗がなければ、Hetznerのほうが同じ金額でRAMとディスクを多く得られます。
運用上のヒント
- サーバーに開けるのは22番、80番、443番だけにしましょう。TLSはkamal-proxyが自分で終端するので、ほかに外から届く必要のあるものはありません。
- ロールバックを当てにする前に
kamal app containersを確認してください。戻す先がまだディスク上にある必要があります。 - 空きディスク容量は、メモリと同じ仕組みで監視しましょう。静かにやってくる種類の障害です。
- 同じホストへの2つ目のアプリのデプロイはKamal 2でサポートされており、kamal-proxyがホスト名で振り分けます。ただしコンテナ数とイメージ履歴が倍になるため、ディスクは両方を見込んで用意してください。
まとめ
単一アプリの構成であれば、2 vCPU・4 GB RAM・40 GBのSSDまたはNVMeがあれば、アプリ、データベース、デプロイ重複分、3日分のロールバック用イメージまで収まります。RAMより先にディスクを増やしてください。メモリ不足は自己申告してくれますが、イメージの蓄積は黙っています。ほかの選択肢は、VPS比較で構成に合うものを探してみてください。
Frequently asked questions
Kamalのデプロイ先となるVPSにはどれくらいのRAMが必要ですか？
アプリ本体、そのアクセサリ、そしてアプリコンテナのもう1つ分をまかなえる量です。デプロイ中は旧コンテナと新コンテナが同時に動くため、メモリのピークは定常時の使用量にアプリコンテナ1つ分を足した程度になります。1 GBのアプリなら4 GBのホストで余裕がありますが、きついようならスワップを追加してください。
Kamal自体はサーバーのCPUやメモリを消費しますか？
いいえ。Kamalは自分のマシンやCIで実行するgemであり、デプロイが終われば終了します。ホストに恒久的に加わるのはkamal-proxyだけです。これはGoで書かれた小さなHTTPプロキシで、実際のアプリケーションと比べれば消費量は無視できる水準です。
Kamalのホストはなぜ時間とともにディスクが足りなくなるのですか？
Kamalはロールバック時にレジストリから取得せずに済むよう古いコンテナとイメージを保持し、既定では3日後に整理します。大きなイメージを頻繁にデプロイすると急速に蓄積し、しかもディスクが埋まるのは原因となったデプロイではなく、後日のデプロイの途中であることがほとんどです。