2025年、サーバーやVPSには実際にどれくらいのRAMが必要なのでしょうか？

RAMの容量設定は、ワークロードの計算に基づくものであり、ベンチマークではありません。過剰に設定すると、未使用の容量に対して料金を支払うことになります。不足すると、プロセスが強制終了されたり、データベースがメモリではなくディスクからデータを読み出したり、コンテナの処理が制限されたりします。 本ガイドでは、最も頻繁に見られるワークロード（Webホスティング、データベース、仮想化、コンテナ、AI推論、ゲームサーバー）に対する具体的なRAMの推奨範囲に加え、リストにないワークロードの容量設定を行う際のルールについても解説します。

サーバーにおけるRAMの役割

RAMには、サーバーが現在処理中のすべてのデータが格納されます。Webサーバー、データベースエンジン、バックグラウンドデーモンのプロセスメモリ。OSレベルのページキャッシュやディスクI/Oバッファ。アプリケーションやコンテナの実行時メモリ。そして、仮想マシンやコンテナのワークロードに割り当てられたメモリ領域です。

RAMの容量設定がCPUの容量設定と異なる点は、障害の発生様式にあります。CPUリソースが不足すると、プロセスの処理速度が低下します。一方、RAMが不足すると、カーネルはスワップ（処理が遅くなる）を行うか、OOMキラーが対象プロセスを選択して強制終了させます。前者の場合も不快ですが、 後者ではデータが失われます。RAMに余裕を持たせてプロビジョニングすることは、単なる「あれば良い」というものではなく、負荷がかかった際にシステムが崩壊するのを防ぐための必須条件なのです。

ワークロード別のRAM

Webサーバーおよびアプリケーションサーバー

• 軽量なLAMPまたはLEMPスタック：1～2 GB
• キャッシュ機能（例：Redis）を備えたWordPressまたはCMS：2～4 GB
• ECサイト（Magento、WooCommerce）：4～8 GB
• Node.js、Django、またはRailsアプリケーション：2～6 GB

RedisやVarnishのようなキャッシュ層には、アプリケーションのベースラインに加えて専用のRAMが必要です。PHP-FPMワーカー、データベース接続、リバースプロキシはいずれも同時にメモリを消費するため、重要なのはアイドル時のメモリ使用量ではなく、ピーク時の並行処理数です。

データベースサーバー（SQLおよびNoSQL）

• MySQL または PostgreSQL（小規模）：4～8 GB
• MySQL または PostgreSQL（大規模または高トラフィック）：16～64 GB
• MongoDB または Redis（インメモリ重視）：32～128 GB 以上
• Elasticsearch または OpenSearch ノード：ノードあたり 32 ～ 128 GB

目標は、ワーキングセット、インデックス、および頻繁にアクセスされる行をRAM内に保持することです。これらの一部でもディスクに書き出されると、SSDがどれほど高速であっても、レイテンシは桁違いに増加します。

仮想化ホスト（Proxmox、VMware、Hyper-V）

• 軽量Linux VM：1台あたり2～4 GB
• Windows VM：1台あたり8～12 GB
• ホスティングパネル（cPanel、Plesk、DirectAdmin）：インスタンスあたり4～8 GB
• KVMまたはLXCコンテナホスト：32～128 GB以上

ゲストへの割り当て量に加えて、ホストOS自体用に常に4～8 GBを確保してください。コンテナはフルVMに比べてワークロードあたりのRAM使用量は少ないですが、スケーリングの特性が異なるため、コンテナごとのサイズではなく、密度とバースト時の余裕を考慮して計画を立ててください。 ホストがZFSを使用している場合は、ARCも考慮してください。ARCはデフォルトでシステムRAMの最大半分を黙って占有し、ゲストへの割り当てと競合します（当社のZFS ARCチューニングガイドでは、ハイパーバイザーワークロードに適した上限値について解説しています）。

コンテナおよびマイクロサービス（Docker、Kubernetes）

• シンプルな Docker スタック（Web、アプリ、DB）：8～16 GB
• Docker Swarm または K3s のエッジノード：16～32 GB
• Kubernetes ワーカーノード：32～128 GB
• CI/CDランナーおよびビルドエージェント（GitLab、Jenkins）：ランナーあたり8～32 GB

長時間実行されるコンテナでは、メモリリークに注意してください。KafkaやElasticsearchのようなJVMベースのワークロードは、ヒープが許容範囲内で自由に拡大するため、予想以上に大きなメモリを消費する傾向があり、より高いベースライン設定が必要です。

AIおよびML推論

• 小規模モデル（量子化BERT、Llama 7B）：16～32 GB
• 中規模モデル（13B～30B、量子化済み）：64～128 GB
• 大規模モデル（40B以上、または非量子化の中規模モデル）：128～512 GB以上
• GPU による推論（Stable Diffusion、Whisper）：オフロード状況に応じて 32 ～ 128 GB

量子化により、メモリへの負荷がGPUからCPUのRAMへと移行するため、GPU上でfp16を処理するか、CPU上で4ビットを処理するかによって、システム仕様は大きく異なります。バッチサイズやプロンプトの長さによっても、必要なメモリ容量は増加します。AI推論ホスティングに関する当社のガイドでは、モデルサイズに適したハードウェアの選定についてさらに詳しく解説しています。

ゲームサーバー

• Minecraft（バニラ版）：2～4 GB
• Minecraft（MOD適用版）：6～16 GB
• Rust、ARK、または7 Days to Die：8～16 GB
• マルチインスタンスホスティングノード：32～64 GB

特殊なワークロード

• 動画トランスコーディング（FFmpeg、Plex）：16～64 GB
• バックアップまたはスナップショットサーバー：8～16 GB（重複排除エンジンを実行する場合はさらに多く）
• ファイアウォールまたはIDS（pfSense、Suricata）：2～8 GB、NetFlowやフルパケットロギングを行う場合はさらに多く

スワップメモリに依存しない

スワップはRAMよりも10～100倍遅いです。スワップは、メモリ負荷が急上昇した際にカーネルが逃げ場を確保するための安全策として存在しており、使用可能なメモリを拡張する手段ではありません。通常の負荷下でサーバーがスワップを使用している場合、そのサーバーのメモリ割り当ては不足している、それだけのことです。 「Linuxのスワップ、OOMキラー、およびcgroupsの相互作用」では、こうした障害モードについて詳しく解説しています。

RAMの容量を正確に算出する方法

1. 平均値ではなく、ピーク値を測定してください。 htop, free -m, vmstat 1、またはKubernetesのメトリクスを使用して、トラフィックの全サイクルにわたるピーク使用量を特定してください。日ごとのピーク、週ごとのバッチ処理、月ごとの課金サイクルはすべて重要です。
2. 成長を見越して余裕を持たせてください。アプリケーションのスケーリングには20％～50％の余裕を確保します。データベースについては、リクエストレートではなくデータセットのサイズに応じてメモリをスケールさせてください。マルチテナントプラットフォームの場合は、クライアントごとのリソース使用量を算出し、それを乗算してください。
3. 許容できる障害モードを想定して計画を立ててください。読み取りレプリカのRAMが不足するとパフォーマンスが低下します。データベースのプライマリでRAMが不足すると、クエリが破損し、アプリケーション全体がダウンする可能性があります。影響範囲が最も広い部分にRAMを割り当ててください。

RAMは、不足した場合の悪影響が過剰な場合よりも大きいスペックです。メモリを追加してもCPUがボトルネックとなっているアプリケーションの速度は向上しませんが、メモリが不足しすぎると安定性が損なわれます。実際の監視データとテスト済みのピーク値に基づいて容量を決定し、余裕を持たせてください。

FDCでは、複数のリージョンで高RAM構成と無制限の帯域幅を備えた専用サーバーおよびVPSを提供しています。