こんにちは。「クロジカサーバー管理」 IT/テックライターのkait78です。
企業のホームページやECサイトを動かしているWebサーバー。Webサイトを運営する際は、適切なサーバースペックを選定することが非常に重要です。サーバースペックが低いと、Webサイトのレスポンスが悪くなるだけでなく、Webサイトがダウンしてしまう恐れがあります。逆に、サーバースペックが過剰の場合、Webサイト運営は問題なく動きますが、余計な費用が掛かってしまいます。
総務省の「政府情報システムの整備の在り方に関する研究会 最終報告書」では、政府情報システムは、サーバーマシン台数の削減を仮想化技術を用いて柔軟かつ効率的に実施すべきとされています。
今回は、Webサイトのサーバースペックを決める際の目安や確認方法についてご紹介します。
Webサイトのサーバーで確認する項目
はじめに、Webサイトのサーバースペックを決めるに当たり、確認しておくべき項目をご紹介します。これらの項目は、サーバーにログインして確認するか、監視システムから確認が可能です。クラウドサーバーを利用している場合は、無料で使用状況の可視化機能が提供されている場合があります。
CPU
サーバーのCPU使用率を確認しましょう。CPUはサーバーの中心的な演算処理を担当します。また、Webサイトのアクセス数やデータの処理量に応じて負荷が変わるため、導入時と現在ではCPU使用率も変化がみられているはずです。Webサイトの特性にもよりますが、CPU使用率が40%から70%程度の範囲内にあると、余裕を持った適正スペックと言えます。
メモリー
サーバーのメモリー使用率も確認する必要があります。メモリーはサーバーがデータを処理をする際に必要なデータを一時的に保存する役割を持っています。Webサイトの内容によって異なりますが、CPUと同様にメモリー使用率が40%から70%程度であれば、余裕のある適切なスペックといえます。
ストレージ
ストレージはWebサイトのコンテンツやデータを保存する領域です。
ストレージはCPUやメモリーとは異なり、Webサイトの一時的なアクセス数には影響されず、主にデータの蓄積によって増加します。一般的な企業サイトであれば増減は少なくなりますが、会員サイトや社内データの保管に利用されるサーバーの場合は、右肩上がりにストレージ使用率が上昇します。ストレージの増設や、不要なファイルは定期的に削除するなどして、使用率が100%にならないように調整しましょう。
その他サーバー以外の項目
サーバー以外にも、確認しておくべき項目があります。
サーバーとインターネットをつなぐ、ネットワーク帯域幅やデータの転送速度などです。これは、サーバースペックの変更後、ネットワーク帯域幅を見直しておらず、ネットワーク帯域幅がボトルネックとなってしまう可能性があるためです。
また、Webサイトの利用ユーザー数も確認が必要です。一般的には、CPUやメモリーの増加率と同様の傾向になるはずですが、システムの特性によるためユーザー数も確認しておきましょう。Webサイトのアクセス解析ツールなどで確認できます。
サーバースペックが適正か確認する方法
次に、上記で挙げた項目が適正かどうか確認する方法をご紹介します。
Webサイトのユーザー数推移を確認する
Webサイトのアクセス解析を活用して、ユーザーアクセス数の傾向を把握しましょう。時間別のアクセス数が急激に減っている場合は、サーバーがアクセスを受け付けていない場合があります。定期的に発生している場合は、サーバーのスペック不足の可能性があります。もちろん、プログラムのバグやサイバー攻撃の可能性もあるため、サーバー側の原因調査もしておきましょう。
年・月・日を通してサーバーの負荷、リソースを確認する
サーバーの各種値は、1度確認するだけでは不十分です。年・月・日を通して確認が必要です。例えば、日本のECサイトの場合は、20時から22時前後のゴールデンタイムにアクセスが集中します。
そのような状況で、14時頃のCPU使用率を確認しても、そのデータは意味がありませんよね。また、平日や休日、月などの違いによってもWebサイトの利用頻度は変わるはずです。そのため、サーバーの各項目は年・月・日など一定期間を確認しましょう。システムの特性にもよりますが、確認したデータの中で、5分間の平均使用率が80%や90%になっている場合はサーバースペックが合っていない状態となります。
また、CPUやメモリーの月・年単位の増加率から今後サーバースペックを上げるべきか、そのままで良いかの大まかな判断がつきます。オンプレミスサーバーの場合、5年～7年前後でリプレース（買い替え）が発生します。増加率から回帰分析を行い、数年先の予測までしておくと安心です。
サーバーの適正スペックを提案してくれるサービスも
Webサイトで使用しているサーバーの適正スペックを提案してくれるサービスもあります。AWS(Amazon Web Service)では、AWS Compute Optimizerというサービスを提供しており、CPUやメモリーの使用率などのメトリクスを分析し、最適なスペックを提案してくれます。
Webサイトを未だ動かしていない場合
ちなみに、Webサイトを未だ動かしていない場合はCPUやメモリーの使用率が取得できていません。その場合は、Webサイトの想定アクセス数を模した負荷テストをサーバーに実施します。
「Apache Bench」や「Apache JMeter」が負荷テストが可能な代表的なツールです。コマンドやアプリで動かすツールであるため、自身のスキルにあったツールを使用しましょう。
ケース別のサーバースペックの目安
続いては、「月間10万PVのWordPressブログサイト」、「BtoB 製品カタログサイト（商品数500点・月間15万PV）」という具体的な2つのケースを想定した際のサーバースペックの選定イメージをお伝えします。今回はAWS（クラウドサーバー）を例にして、サーバースペックの選定手順を解説します。
まずは、前述した章で見たとおり、CPU・メモリは普段40〜70%の範囲を目安に、5分平均が80〜90%に張り付くようなら要注意。という考え方で進めていきます。この考え方は、クラウド（AWS）でサーバーを選ぶときも同じです。
つまり、下記の順で進めると、コストと安定性のバランスが取りやすくなります。また未稼働のサイトは、先に簡易負荷試験（ab / JMeter）で “目標の同時アクセスに耐えられるか” を確認してから本番に進みましょう。
- 小さく始める（最小構成でスタート）
- 見える化する（CloudWatch 等でCPU/メモリ、応答時間、エラーを計測）
- 必要なときだけ増やす（スケールアップ／台数追加）
月間10万PVのWordPressブログサイト
| 前提条件（月間10万PVのWordPressブログサイト） | |
|---|---|
| 月間PV / ピーク同時接続 | 10万PV / 〜100ユーザー |
| 使うもの | WordPress（プラグインは必要最小限） |
| 配信 | CloudFront（画像・CSS・JSをCDN経由） |
| データ | MySQL互換、1日1回バックアップ |
| 監視 | CPU・メモリ・エラー（5xx）を 5分平均 で確認 |
このケースの考え方
- WordPressはPHPの処理とDBアクセスが重くなりやすい
- まずは 2 vCPU / 4GB を基準に、ページキャッシュとオブジェクトキャッシュでさばく
- 稼働後、CPU/メモリが普段40〜70%で収まっていればOK。超えるならサーバーを少し大きくするか、キャッシュを強化
| おすすめ初期構成（AWS・東京） | |
|---|---|
| Web（EC2） | t4g.medium（2 vCPU / 4GB） ※ Graviton（AWSの省エネCPU） を使います。プラグインなどの相性で難しい場合は t3.medium を選んでください。 EBS（gp3）50〜100GB |
| DB（RDS for MySQL） | db.t4g.small（2 vCPU / 2GB, Single-AZ）／gp3 50〜100GB（必要に応じて db.t4g.medium に拡張） |
| 静的ファイル | S3 + CloudFront（画像・CSS・JS） |
| キャッシュ（任意） | ElastiCache for Redis t4g.small（オブジェクトキャッシュ） |
| 監視 | CloudWatch（CPU・メモリ※Agent、エラー数、遅いアクセス時の応答時間） |
| 伸びしろ | Webを t4g.large に拡張、または ALB + Auto Scaling（最小1／最大3） |
動かしながらの見直しポイント
- 次のいずれかが続いたらサーバー増強やチューニングを検討
- CPU/メモリの5分平均 > 70%
- p95 応答時間 > 500ms
- スロークエリ増加やDBバッファヒット率の低下
- Compute Optimizer の“縮小/拡大”提案も参考にする。
BtoB 製品カタログサイト（商品数500点・月間15万PV）
| 前提条件（BtoB 製品カタログサイト：商品500点・月間15万PV） | |
|---|---|
| 月間PV / ピーク同時接続 | 15万PV / 〜150ユーザー |
| ページ特性 | 一覧・詳細・検索（絞り込み）中心 |
| 画像・資料 | S3 に保存、CloudFront で配信 |
| DB | MySQL互換（商品テーブル約500件） |
| 監視 | DBのメモリ（Buffer Pool）とクエリ遅延を重点監視 |
このケースの考え方
- 一覧表示や検索はDBの読み取りが多くなる。インデックスとキャッシュでDBを楽にする
- Web側のテンプレート処理も少し重いので、Web 2 vCPU / 8GB、DB 4GBから始めると安心
- 使ってみて、指標が越えたらWebを台数で増やす（オートスケール）か、DBのメモリを増やす
| おすすめ初期構成（AWS・東京）— BtoB製品カタログ | |
|---|---|
| Web（EC2） | t4g.large（2 vCPU / 8GB）※ Graviton（AWSの省エネCPU） ／ EBS（gp3）100GB |
| DB（RDS for MySQL） | db.t4g.medium（2 vCPU / 4GB, Single-AZ）／gp3 100GB ※ 検索が重い場合は db.m7g.large（2 vCPU / 8GB相当）へ |
| 画像・資料 | S3 + CloudFront（画像最適化：WebP/AVIF 推奨） |
| キャッシュ（推奨） | ElastiCache for Redis t4g.small（一覧APIやカテゴリページの短期キャッシュ） |
| 監視 | CloudWatch + Performance Insights（上位の遅いクエリ、DBのメモリの効き具合、CPU、ディスク待ちを確認） |
| 将来の伸張 | ALB + Auto Scaling（最小1／最大3）でWebを自動増減／DBはリードレプリカやメモリ拡張 |
動かしながらの見直しポイント
- Buffer Cache Hit（DBメモリの当たり具合）が90%未満で続く
- p95 応答 > 500ms が続く
- 検索時にCPUスパイクやクエリ待ちが多い
→ DBのメモリ拡張やキャッシュ強化、必要ならリードレプリカを追加。
サーバースペックの変更方法
ここまでで「まずは小さく始める」「CPU・メモリはふだん40〜70％を目安に見る」という考え方を共有しました。では、運用中に「重くなってきた」「逆に余裕がありすぎる」と分かったとき、どのようにサーバースペックを調整するのがよいのでしょうか。
この章では、オンプレミスサーバー、レンタルサーバー、クラウドサーバー（AWS）それぞれでのスペック変更の方法を簡単に解説します。
オンプレミスサーバー
オンプレミスの場合、新規にサーバーを購入するしかありません。物理サーバーは数百万円程度の費用、納品にも1か月以上かかることが一般的です。オンプレミスサーバーの買い替えは半年から1年前から購入計画を組む必要があります。企業によっては予算承認から必要なため、さらに時間が必要です。
レンタルサーバー
レンタルサーバーのスペック変更は提供サービスによって異なりますが、一般的には一から契約をし直す方式となります。また、月額料金制のため申請しても翌月からの適用になる場合や、手動のデータ移行が必要な場合があります。他にも、上位スペックには上げられますが、下位スペックの変更ができないなどの制限もあるため注意が必要です。
このようにレンタルサーバーにおけるサーバースペック変更には多数の検討事項があります。そのため自社で適切なサーバー会社の選定が難しい場合は、まずは専門業者への問い合わせを検討してもよいでしょう。
▼レンタルサーバーとクラウドサーバーの違いについての解説記事はコチラ
企業のWebサイト担当者必見！レンタルサーバーとクラウドサーバーの違い
クラウドサーバー
クラウドサーバーの場合、他の環境よりも簡単にサーバースペックの変更が可能です。AWSの場合、サーバーを一度停止後にサーバースペックを変更、再度立ち上げをするだけで変更できます。下位スペックや月単位の制限もありません。データ移行も不要です。また、Auto Scalingという機能を使えば、サーバーの負荷に応じてサーバー台数を自動で増減させることも可能となります。
Webサイトのアクセス数が増える時間帯にサーバー数を増加、閑散期はサーバーを減らすなど、コストを抑えた運用が可能です。サーバースペックの確認・変更に関しては、クラウドサーバーが最も利用しやすいと言えます。
サーバー移行作業費 無料
クロジカサーバー管理
- 18年以上の保守実績から最適なプランをご提案
- 24時間365日の障害対応＆監視体制で安心運用
- 専門家によるセキュリティ対策も提案可能
- 現在のサーバースペックに合わせて提案可能
ここまで、Webサイトを動かすサーバーの適正スペックの選定方法についてご紹介してきました。Webサイトのサーバースペックを変更や適正なスペックの選定は、専門のスキルや経験が必要です。Webサイトの担当者にそのようなスキルがない場合や、時間が取れない場合は、サーバー管理に特化した企業に外部委託することをおすすめします。
「クロジカサーバー管理」では、サーバー管理に関するトータルサポートを提供しています。
上場企業や自治体、教育機関など、さまざまな業界・企業様のサーバーを管理してきた経験を活かし、クラウドサーバーの選定やオンプレミス環境からの移行、負荷分散の最適化など、トータルでご提案します。クラウドサーバーの移行やサーバースペックの見直しをしたいとお考えの場合は、ぜひお気軽に「クロジカサーバー管理」へご相談ください。
ライター：kait78
元大手通信事業者のインフラエンジニア。ネットワーク・サーバー・AWS領域でIT/テック記事に特化した記事を執筆。Webサーバーにまつわる課題や悩みに対して実務経験を基にした、現場社員目線の課題解決となるアイデアを提供します。
監修者：クロジカサーバー管理編集部
コーポレートサイト向けクラウドサーバーの構築・運用保守を行うサービス「クロジカサーバー管理」を提供。上場企業や大学、地方自治体など、セキュリティ対策を必要とするコーポレートサイトで250社以上の実績があります。当社の運用実績を踏まえたクラウドサーバー運用のノウハウをお届けします。
コーポレートサイトをクラウドでセキュアに
サーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカサーバー管理の主な機能
- 導入事例
- 導入までの流れ
