※本記事はアフィリエイト広告を含みます。
小さな検証用サーバーでも、画面を開いた直後は軽快に動くのに、CSVの取込みやバックアップを始めると処理が止まってしまうことがあります。容量を選ぶときは、平常時の使用量だけでなく、重い処理が重なったときにどの資源をどれだけ使うかまで確認する必要があります。
本記事では、Webアプリやデータベースを動かす小規模な検証環境を想定し、メモリ、CPU、保存領域、通信を見積もる手順を整理します。数値例は計算方法を示すための仮定であり、製品の最低要件や実測値ではありません。環境の置き場所をまだ決めていない場合は、検証環境の選び方から確認してください。
広告：さくらのVPSの公式案内
まず、同時に動く処理を書き出す
アプリ本体だけを見て容量を決めると、OS、データベース、ログ、更新処理などが抜け落ちがちです。サーバー上で動かすものをすべて書き出し、どの処理がいつ重なるのかを並べて確認します。
| 処理 | 確認する資源 | 同時実行で注意する点 |
|---|---|---|
| Web画面・API | メモリ、CPU、通信 | 同時利用者や大きな応答で負荷が変わる |
| CSV取込み・集計 | メモリ、CPU、一時領域 | 読み込んだデータの展開や中間ファイルが増える |
| データベース | メモリ、保存領域、ディスクI/O | データ以外に索引やログも必要 |
| バックアップ | CPU、通信、保存領域、ディスクI/O | 通常処理と重ねるか、時刻を分けられるか |
| OS・更新・監視 | メモリ、保存領域 | アプリが停止していても消費する |
同時利用者の人数だけでは、必要なCPUやメモリは決まりません。同じ人数でも、短い検索を繰り返す場合と大量集計を実行する場合では負荷が異なります。利用者数と、そのとき実行する操作の組合せを対にして記録します。
保存領域は「増加量×保存期間」から積み上げる
はじめに、保存するデータごとに増加量と保存期間を決めます。対象はデータベースのサイズだけではありません。元ファイル、処理済みファイル、ログ、一時ファイル、同じサーバーに置くバックアップも含めます。
計算の入口は、1日当たりの保存量に保存日数を掛けることです。ただし、これで求まるのは対象データの単純な累積量にすぎません。索引、圧縮、ファイルシステム、データベース内部の管理領域などは、別に確認します。
次の表は、架空の検証環境を想定した見積もり例です。単位は10進のMB・GBとし、1GB＝1,000MBで計算しています。
| 保存するもの | 仮定 | 単純計算の結果 |
|---|---|---|
| 取込み元CSV | 200MB/日を30日保存 | 6,000MB＝6GB |
| 処理ログ | 50MB/日を30日保存 | 1,500MB＝1.5GB |
| 集計結果 | 10MB/日を90日保存 | 900MB＝0.9GB |
| 上記の小計 | ほかの領域を含めない | 8.4GB |
この小計から、8.4GBのディスクがあればよいという結論は出せません。OS、アプリ、データベース、取込み中の一時領域、バックアップ、更新作業のための空き容量が、まだ含まれていないためです。さらに、バックアップの世代数を増やせば保存量も変わります。バックアップ設計と合わせて決めてください。
保存量の上限を決めたら、削除や世代更新が実際に動くことも確かめます。「30日保存」と書いていても、削除処理がなければデータは増え続けます。
メモリは起動直後とピーク時を分けて確認する
必要なメモリは、起動直後の使用量だけでは判断できません。CSVを読み込む、集計結果を組み立てる、複数の利用者が同時に操作するなど、負荷が高い場面を実際に試します。測定はアプリ単体ではなく、OSと同時に動くほかのプロセスも含めて行います。
| 測定場面 | 確認する内容 |
|---|---|
| 起動後の待機 | OS・アプリ・DBを起動した状態の使用量 |
| 通常操作 | 想定するデータ量と操作での増加 |
| 大きなデータの取込み | メモリの最大使用量、処理時間、エラー |
| 複数操作の重なり | 同時処理時の応答、メモリ不足による停止 |
| バックアップ・更新 | 通常処理へ与える影響と追加の使用量 |
一定の倍率を掛けておけば必ず足りる、という基準はありません。最大データ量や同時処理数が未定であれば、測定した条件を明記し、その範囲でしか判断できない旨を記録に残します。
コンテナを使う場合も、資源の上限が自動で適切に決まるわけではありません。Dockerの公式資料では、既定では資源の制限がなく、ホスト側で利用できる資源を消費し得ると説明されています。メモリ不足によるプロセス停止や、スワップの利用による性能への影響も考慮が必要です。制限を設定する場合は、アプリが必要とする量を確かめたうえで決めます。
CPU・ディスク・通信を切り分ける
処理が遅いとき、メモリを増やせば改善するとは限りません。何を待っているのかを切り分けます。
| 観測すること | 次に確かめる点 |
|---|---|
| 集計中にCPU使用率が高い | 処理量、並列実行数、計算方法 |
| メモリ不足のエラーやプロセス停止がある | 最大使用量、同時処理、制限値 |
| 読み書き中に待ちが増える | ディスクI/O、データ配置、同時バックアップ |
| ファイル転送だけが遅い | 回線、サービス側の制限、相手側の応答 |
| 容量不足で保存できない | データ・ログ・一時ファイル・世代数の内訳 |
この表は原因を絞り込むための入口です。単独の指標だけで断定せず、処理の開始・終了時刻と資源の変化を対応させて確認します。
候補構成を選び、同じ条件で試す
検証の前に合格条件を決めておくと、プラン名や数字の大きさだけに引かれずに比較できます。たとえば「指定した量のダミーデータを取り込める」「想定する共同利用中にエラーが出ない」「検証終了までの保存量を確保できる」といった条件です。許容する処理時間は用途に応じて決めます。
記録には、OS・アプリのバージョン、構成、データ量、同時操作数、測定時刻、処理時間、資源の最大使用量、エラーを残します。試していない条件は、未確認と明記します。ここで示した手順は評価方法の提案であり、本記事で特定のサービスを負荷試験したものではありません。
VPSの変更条件まで含めて選ぶ
さくらのVPSなどを候補にする場合は、公式仕様でCPU、メモリ、保存領域、料金を同じ条件で比較します。地域や支払い方法の違いも確認してください。
さくらのVPSのスケールアップ手順では、Linux版VPSの対象バージョンや、変更できる組合せに条件があります。操作にはサーバーの停止が必要で、ストレージ容量の縮小や、リージョン・ゾーンをまたぐ変更はできません。構成によっては、変更後にディスクの拡張作業も必要です。将来小さく戻したい場合は、単純なプラン変更で済むとは考えず、移行方法まで確認しておきます。
また、お試し期間の案内では外向き通信に10Mbpsの制限があります。試用時に測った転送結果を、通常利用時の性能として扱わないようにします。
容量選定の成果は、選んだプラン名だけではありません。どのデータ量と同時処理まで確認できたのか、そして何が増えたら再評価するのかを残しておけば、検証の規模が大きくなったときにも判断を引き継げます。
広告：さくらのVPSの公式案内