VPSのスペックを見積もる:CPU・メモリ・ストレージ・転送量を用途から逆算する

スペックは常駐するものの合計から逆算する

VPSのプラン表にはCPUコア数・メモリ・SSD容量・転送量が並ぶ。この4つは独立した数字ではなく、動かすプロセスの性質によってどれが先に枯渇するかが決まる。個人開発の用途では、最初に足りなくなるのはたいていメモリだ。CPUは平均使用率が低くてもピークで詰まり、ストレージはログとバックアップで静かに埋まっていく。

見積もりの順番は決まっている。まず常時動かすプロセスを列挙する。次にそれぞれの常駐メモリを足し、OSとファイルキャッシュ用の余白を乗せる。そのうえでピーク時に同時処理したい本数からコア数を決め、配信するデータ量から転送量を確認する。この順に考えると、プラン表のどの行を見るべきかが自然に絞られる。

メモリ:常駐プロセスの合計に5割の余白

メモリはプロセスごとの常駐サイズを足し算するだけで概算できる。設定次第で大きく変わるが、既定設定に近い状態での目安は次のとおり。

合計に対して5割ほどの余白を確保する。余白はページキャッシュに使われ、ディスクI/Oを減らして体感速度を上げる。空きメモリが無駄という考え方は当てはまらない。

すでに動いているサーバーがあるなら推測は不要だ。free -h の available 列が実際に使える量を示し、ps -eo rss,comm --sort=-rss | head で消費上位のプロセスがわかる。スワップは領域を確保しておく価値があるが、日常的に使われている状態は容量不足のサインで、特にデータベースでは応答が目に見えて劣化する。

CPUコア数:速さではなく同時実行数を決める値

コア数は1件の処理を速くする値ではなく、同時に走らせられる本数を決める値だ。Webアプリのリクエスト処理は大半がデータベース応答や外部API待ちなので、CPUは遊んでいる時間が長い。個人開発規模のWebサービスなら1〜2コアで足りることが多い。

コアを増やす価値があるのは、CPUを連続して使う処理を抱える場合だ。画像や動画の変換、フロントエンドのビルド、暗号化・圧縮、機械学習の推論がこれにあたる。こうした処理を裏で回しながらWebを応答させるなら、最低でも2コア、変換が頻繁なら4コア以上を検討する。

足りているかの判定には uptime のロードアベレージをコア数と比べる。値がコア数を継続的に上回っていれば待ち行列ができている。vmstat 1 の r 列は実行待ちプロセス数を直接示すので、より判断しやすい。なお多くのVPSはCPUを他の利用者と共有しており、公称コア数がそのまま専有性能を意味しない。CPU負荷が主役になる用途では、CPU専有プランや占有率の明示があるプランを選ぶ。

ストレージ:アプリ本体より運用データが効く

アプリのコードが占める容量は通常わずかで、実際に容量を食うのはOS、データベース、ログ、バックアップ、コンテナイメージだ。OSとミドルウェアで5〜10GB、ここにデータベースの実データとその2〜3倍の作業領域を見込む。同一サーバーにバックアップを置くなら、世代数ぶんの容量をさらに加える。

ディスク枯渇はサービス停止に直結する。データベースは書き込めなくなり、ログ出力の失敗が連鎖する。df -h で使用率を、du -sh /var/* で内訳を定期的に確認し、logrotate や journalctl --vacuum-size=500M でログの上限を先に決めておく。Dockerを使うなら未使用イメージの蓄積も無視できない。

転送量:画像と動画でほぼ決まる

転送量は概算しやすい。1ページあたりの総ダウンロードサイズに月間PVを掛ければよい。1MBのページを月10万PV配信すれば約100GBになる。テキスト主体のサイトでこの規模に達することは少なく、超えるのは画像・動画・ファイル配信を伴う場合だ。

国内のVPSには転送量無制限、または十分に大きい上限を掲げるプランが多い。一方でクラウド事業者のインスタンスは外向き通信が従量課金になるのが一般的で、想定外の配信量が請求に直結する。料金体系は事業者ごとに異なり変更も頻繁なため、契約前に公式サイトの料金ページで確認する。実測には vnstat が使いやすい。転送量が問題になりそうなら、静的ファイルをCDNやオブジェクトストレージへ逃がすほうが、上位プランに移るより費用対効果が高い。

ワークロード別の出発点

以下は最初に借りるプランの目安で、実測後の調整が前提となる。

足りなくなったとき:まずスケールアップ

個人開発の規模では、上位プランへの移行(スケールアップ)を優先する。台数を増やす(スケールアウト)には、セッションの共有先、アップロードファイルの置き場所、データベースの接続先といった状態管理の設計が必要になり、監視とデプロイの手間も台数ぶん増える。この追加コストは、1台の上限に届く前に払う価値がない。

スケールアウトが妥当なのは三つの場合だ。単一サーバーの最上位プランでも余裕がない場合、1台の障害で止められない可用性要件がある場合、そして性質の違う処理が互いを邪魔している場合である。

三つ目は個人開発でも現実に起きる。重いバッチがCPUを占有してWebの応答が遅れる、データベースのメモリ不足でアプリが道連れになる、といった状況だ。この場合は同じ役割のサーバーを並べるのではなく、役割ごとに分ける。データベースを別サーバーやマネージドDBへ移す、バッチ専用サーバーを立てる、という分け方は、負荷分散の仕組みを作らずに済むぶん導入が容易で、効果もはっきり出る。

契約後に変えられるもの・変えられないもの

多くのVPSでは、上位プランへの変更と追加ディスクの接続が管理画面から実行できる。ただし無停止ではなく、サーバーの停止と再起動を伴うのが一般的だ。OSの再インストールも可能だが、当然ながらデータは消える。

変更しにくい、あるいは変更できない項目のほうが選定への影響は大きい。ディスク容量は増やせても減らせないことがほとんどで、下位プランへのダウングレードを認めない事業者もある。サーバーを設置するリージョンやデータセンターは後から変えられず、移設すればIPアドレスも変わる。CPUが共有か専有かはプランの種類そのものなので、移行が必要になる。長期契約の割引を選ぶと、期間内の解約や減額が制限される点も見落としやすい。

したがって契約前に確認すべきは、プラン変更が管理画面で完結しデータが保持されるか、ダウングレードが可能か、追加ボリュームを後付けできるか、そして最低契約期間があるかの四点になる。これらの扱いは事業者ごとに異なり、条件も更新されるため、必ず公式サイトの仕様ページと利用規約で確認する。

最初の1台の決め方

初期構成は精密に当てにいく必要がない。実測できる状態を早く作り、そこから調整するほうが正確だ。判断基準は三つに絞れる。第一に、常駐プロセスの合計メモリに5割の余白を足した容量を満たすこと。第二に、CPUを連続して使う処理があるかどうかで2コア以上を選ぶこと。第三に、上位プランへ管理画面から移行できる事業者を選び、ディスクは後から減らせない前提で控えめに始めること。

契約後は、稼働1週間の free -h、ロードアベレージ、df -h の推移を記録する。この3つの数字が、次にどのリソースへ投資すべきかを教えてくれる。