【図解】Webシステムのハードウェア性能設計｜CPU・メモリ・ストレージのサイジング

はじめに
ハードウェア性能の全体像
1. ハードウェアはシステム構成と合わせて考える
2. ハードウェアサイジングの前に構成とリソース配置を決める
CPUの性能設計
メモリの性能設計
NIC・ネットワークの性能設計
ストレージの性能設計
ハードウェアサイジングの考え方
障害・縮退時の性能設計
性能試験とハードウェアボトルネックの確認
1. サイジングとトラブルシューティングをつなげる
まとめ
参考資料

はじめに

Webシステムの性能は、アプリケーションやデータベースの設定だけで決まりません。CPU、メモリ、ストレージ、NICなどのハードウェアリソースがワークロードに対して十分な処理能力を持ち、ピーク時や障害による縮退時にも必要な処理能力を確保できることが重要です。

本記事では、CPU・メモリ・NIC・ストレージの性能を何で捉え、どのようにサイジングと性能試験へつなげるかを解説します。

LinuxベースのWebシステムを想定します。特定製品の推奨値ではなく、ハードウェア選定・サイジング・性能試験に共通して使える考え方を中心に扱います。

性能設計では、単にCPU使用率やメモリ使用量を見るのではなく、利用者から見たレスポンスタイム、単位時間あたりのスループット、リソースの使用率、処理待ちが発生している飽和状態、そしてエラーを対応付けて考えることが重要です。本記事では、これらの指標を使いながらハードウェアの性能を整理します。

ハードウェア性能の全体像

ハードウェアの性能設計では、「高性能なサーバを選ぶ」こと自体が目的ではありません。想定するワークロードに対して、必要なレスポンスタイムとスループットを維持できるリソースを用意し、どこまで負荷が増えても要件を守れるかを確認することが目的です。

Webシステムを支える主なハードウェアリソースは、次のように整理できます。

上図のように、Webシステムはクライアントからネットワーク機器、サーバ、ストレージまで複数のハードウェア要素で構成されます。本記事では、このうち特にサーバ内部のCPU・メモリ・NICと、データを保持するストレージを中心に、性能設計・サイジング・性能確認までを一通り解説します。ネットワーク機器についても、ハードウェア性能に関係する帯域・パケット処理・ドロップの観点を取り上げます。

リソース	主な性能要素	代表的な確認観点
CPU	コア、スレッド、クロック、IPC、キャッシュ	処理能力、並列性、実行待ち
メモリ	容量、帯域、レイテンシ、NUMA	必要容量、メモリ圧迫、配置
ストレージ	IOPS、スループット、レイテンシ	I/O特性、Queue、応答時間
NIC	帯域、パケット処理能力	帯域、パケットレート、ドロップ

CPUだけを増強しても、ストレージI/Oがボトルネックならレスポンスタイムは改善しません。メモリ容量が十分でも、NUMA構成やメモリ帯域がワークロードに合わなければ、期待した性能が出ない場合があります。ハードウェア性能は、各リソースを独立したスペック値ではなく、処理の流れの中でどのリソースが仕事を受け持つかという観点で捉えます。

ハードウェアはシステム構成と合わせて考える

Webシステムでは、サーバだけでなく、ロードバランサ、ネットワーク機器、ストレージなど複数の要素が処理経路を構成します。オンプレミス環境では、導入後にCPUソケット数やストレージ構成を大きく変更するには追加コストや作業が必要になることがあります。そのため、初期サイジングでは現在の負荷だけでなく、将来の増加や障害時の残存サーバの処理能力も考慮します。

一方で、必要以上に大きなハードウェアを選べばよいわけでもありません。CPUコア数がソフトウェアのライセンス費用へ影響する製品もあり、余剰リソースはコスト増加につながります。性能要件、ワークロード、コストを合わせて判断します。

ハードウェアサイジングの前に構成とリソース配置を決める

ハードウェアサイジングでは、CPUコア数やメモリ容量を計算する前に、どの単位でリソースを配置し、どのように冗長化するかを整理します。同じ総リソース量でも、サーバ台数やリソース共有の方法によって、通常時と障害時の性能は変わります。

性能要件 → システム構成 → 冗長化・リソース配置 → CPU / メモリ / ストレージサイジング → 性能試験の順で考えると、構成設計とサイジングを対応付けやすくなります。

特に確認したいのは、リソースを共有したときの競合と、1台停止したときの残存サーバの処理能力です。重要なワークロードを必ず物理サーバへ分離する、という固定的な考え方ではなく、必要なリソース分離と処理能力を確保できる構成かを性能試験で確認します。

CPUの性能設計

CPUの性能を考えるとき、「コア数が多いほど速い」と単純化しないことが重要です。CPU性能には、コア数、スレッド数、クロック、1クロックあたりに実行できる処理量、キャッシュ、メモリアクセスなど複数の要素が関係します。

コアとスレッドを区別する

物理コアは実際に命令を実行するハードウェアリソースです。SMT（Simultaneous Multithreading。Intel製CPUではHyper-Threadingとして知られる方式）を利用すると、1つの物理コアを複数の論理CPUとしてOSから扱える場合があります。

ただし、論理CPUが2倍になっても、物理コアそのものが2倍になるわけではありません。実行リソースやキャッシュなどを共有するため、性能向上の程度はワークロードによって変わります。サイジングでは論理CPU数だけではなく、物理コア数とワークロード特性を確認し、実測で効果を検証します。

クロックだけでCPU性能を比較しない

クロック周波数はCPU性能を構成する重要な要素ですが、GHzだけで異なるCPUの処理能力を比較することはできません。CPUアーキテクチャ、IPC（Instructions Per Cycle）、キャッシュ、メモリアクセス、コンパイラやアプリケーションの処理内容によって、同じクロックでも実行できる仕事量は変わります。

また、Webシステムでは単一スレッドの処理時間だけでなく、多数のリクエストを並列に処理したときのスループットも重要です。少数コア・高クロックが有利なワークロードと、多数コアによる並列処理が有利なワークロードは分けて考えます。

CPUキャッシュも性能に影響する

CPUは、メインメモリより高速なキャッシュを利用してデータや命令へのアクセスを高速化します。一般的にはL1、L2、L3キャッシュがあり、CPUに近いキャッシュほど小容量で高速です。

ワーキングセットがキャッシュへ収まりやすい処理と、メモリアクセスが多い処理では、同じコア数でも性能特性が異なります。CPU使用率だけでは、キャッシュミスやメモリアクセスによる停滞を直接判断できません。詳細分析が必要な場合はハードウェア性能カウンタなども利用します。

CPU性能は実績とベンチマークを組み合わせて比較する

CPUの候補を比較するときは、コア数やクロック周波数だけでなく、類似システムの実績とベンチマークを組み合わせます。既存システムで「どのワークロードを、何コアで、どの程度のCPU使用率とレスポンスタイムで処理しているか」が分かれば、新システムのCPU処理能力を見積もる出発点になります。

SPECintとは

異なる世代や機種のCPUを比較するとき、コア数やクロック周波数だけでは処理能力を単純に比較できません。その際の比較材料として利用されてきた代表的なベンチマークが、SPEC（Standard Performance Evaluation Corporation）のCPUベンチマークです。

SPECintは、整数演算を中心としたCPU性能を評価する指標として広く使われてきた名称です。現在のSPEC CPUでは指標名が変わっており、2026年時点のSPEC CPU 2026では、整数演算系としてSPECspeed 2026 IntegerとSPECrate 2026 Integerが提供されています。

指標	見る性能	Webシステムでの見方
SPECspeed 2026 Integer	1つの処理を完了するまでの速さ	CPUの処理時間を比較する参考
SPECrate 2026 Integer	単位時間あたりの処理量	多数の処理を並列実行する場合の比較材料

SPECspeedは処理時間を基準とした指標で、SPECrateは単位時間あたりにどれだけ仕事を処理できるかというスループットを評価します。多数のリクエストを並列に処理するWebシステムでは、SPECrateの考え方が比較材料の一つになります。

ただし、SPEC CPUはCPUだけでなく、キャッシュやメインメモリなどのメモリ階層、コンパイラの影響も受ける計算負荷中心のベンチマークです。Webシステムではネットワーク、ストレージI/O、ロック、データベース処理なども性能へ影響するため、SPECのスコア比をそのままWebシステムの性能比として扱うことはできません。

メモリの性能設計

メモリ設計では、まずアプリケーション、OS、ミドルウェア、キャッシュなどが必要とする容量を確保します。ただし、メモリ性能は「何GB搭載するか」だけでは決まりません。メモリ容量に加えて、帯域、レイテンシ、NUMAなども性能へ影響します。

必要なメモリ容量を見積もる

必要メモリ量は、OS、ミドルウェア、アプリケーションヒープ、データベースメモリ、ページキャッシュなど、利用する領域を積み上げて見積もります。さらに、ピーク時の同時処理数、データ量増加、プロセス数の増加なども考慮します。

ただし、「見積もった容量の一律2倍」のような固定倍率だけで余裕を決めるのではなく、実測したピーク使用量、増加傾向、障害時の挙動、増設の容易さ、コストから性能余力を設計します。

帯域とレイテンシも考える

CPUが大量のデータを連続して読み書きするワークロードでは、メモリ容量が余っていてもメモリ帯域が制約になることがあります。また、キャッシュミスが多い処理ではメインメモリへのアクセスレイテンシがCPU処理時間へ影響します。

一般的なWebアプリケーションでは最初からメモリ帯域を細かく見積もる必要がない場合もありますが、CPUを増やしてもスループットが伸びない、CPU内部の待ちが多いといった状況では、メモリ側の制約も候補になります。

NUMAを意識する

複数ソケットのサーバでは、NUMA（Non-Uniform メモリアクセス）構成になることがあります。CPUから近いローカルメモリと、別のNUMAノードに接続されたリモートメモリではアクセスコストが異なります。

大きなメモリを使うアプリケーションやデータベースでは、CPUとメモリの配置によって性能が変化する可能性があります。単に「メモリが空いているか」だけでなく、NUMAノードごとのCPU・メモリ配置も確認します。

NIC・ネットワークの性能設計

Webシステムでは、サーバのCPUやメモリに余裕があっても、NICやネットワークが処理量の上限になることがあります。ハードウェア性能の観点では、主に帯域、パケット処理量、ドロップ、エラーを確認します。

観点	意味	確認すること
帯域	単位時間あたりに転送できるデータ量	リンク速度に対して通信量が逼迫していないか
パケット処理量	単位時間あたりに処理するパケット数	小さいパケットが大量に発生していないか
ドロップ	処理できず破棄されたパケット	NICやOS、ネットワーク機器で廃棄が発生していないか
エラー	送受信時の異常	インターフェースのエラーカウンタが増加していないか

1Gbpsや10Gbpsといったリンク速度だけで判断せず、実際の通信量やパケット数、ドロップの有無を確認します。また、冗長構成では片系障害時に残った経路へ通信が集中しても必要な帯域を確保できるかを性能試験で確認します。

ストレージの性能設計

ストレージを選定するときは、容量だけでなくI/O性能を見積もります。特に重要なのが、IOPS、スループット、レイテンシの3つです。

IOPSだけでストレージを比較すると、I/OサイズやRead / Write比率、ランダム / シーケンシャル、Queue Depth（同時に待機・処理されるI/O数）などの違いを見落とします。たとえば4KBランダムReadと1MBシーケンシャルReadでは、同じIOPSでも必要なスループットやストレージ内部の処理は大きく異なります。

カタログ値ではなくワークロード条件をそろえる

ストレージ製品の公称IOPSやスループットは、特定のI/Oサイズ、Read / Write比率、Queue Depth（同時に待機・処理されるI/O数）などの条件で測定された値です。実際のアプリケーションと条件が異なれば、同じ値が得られるとは限りません。

既存システムから移行する場合は、ピーク時のIOPS、スループット、レイテンシに加えて、I/OサイズやRead / Write比率も確認します。新規システムでは、想定ワークロードを使った性能試験によってストレージが要件を満たすか確認します。

SSDとHDDは要件で使い分ける

低レイテンシや高いランダムI/O性能が必要なオンライン処理では、フラッシュストレージ / SSDが有力な選択肢です。一方、大容量のバックアップやアーカイブなどでは、性能要件とコストによってHDDが適する場合もあります。

メディアの種類だけでなく、コントローラキャッシュ、接続方式、冗長化、ストレージ内部のデータ配置なども性能へ影響します。「SSDだから十分」と判断せず、ストレージ装置単体の値だけではなく、アプリケーションからストレージまでの処理経路全体でI/Oレイテンシを確認します。

RAIDは性能・容量効率・冗長性のトレードオフで選ぶ

RAIDは複数のドライブを組み合わせ、性能、容量効率、冗長性を設計する方式です。RAIDレベルによって、利用可能容量、障害耐性、Read / Write時の処理特性が異なります。

更新の多いオンラインDBではRAID10が候補になることがありますが、常にRAID10が最適とは限りません。ストレージ製品の内部実装、キャッシュ、ドライブ種類、データ保護方式、コストなどを含めて判断します。同様に、バックアップ用途でも容量効率だけでなく、バックアップ時間帯内に必要なスループットを確保できるか確認します。

重要なのは、「どのRAIDレベルが速いか」という一般論だけで決めず、対象ワークロードで必要なレイテンシ・IOPS・スループットと、必要な障害耐性を満たす構成を選ぶことです。

異なるI/Oワークロードの干渉を考える

共有ストレージでは、異なるI/O特性を持つワークロードが同じリソースを利用することで、互いの性能へ影響することがあります。例えば、オンラインDBのランダムI/Oとバックアップの大容量シーケンシャルI/Oを同時に実行すると、オンライン処理のレイテンシが悪化する可能性があります。

ワークロード	主なI/O特性	確認する指標
オンラインDB	小さいランダムI/O、同期Write	レイテンシ、IOPS
バックアップ	大容量シーケンシャルI/O	スループット
バッチ / スキャン	大量Read	スループット、レイテンシ

異なるワークロードを必ず物理的に分離する必要があるわけではありません。ストレージプール、ボリューム、RAIDグループなどの構成と製品特性を踏まえ、同時実行時にも必要なIOPS・スループット・レイテンシを維持できるかを確認します。

ハードウェアサイジングの考え方

ここでいうサイジングとは、性能要件と想定ワークロードから、必要なCPU・メモリ・ストレージ・ネットワークの規模を見積もることです。各リソースのスペックを個別に積み上げるだけではなく、利用者から見た性能要件から逆算します。

性能要件 → ワークロード → 必要な処理能力 → ハードウェアリソース → 性能余力 → 性能試験という流れで考えると、サイジングの前提と検証方法を対応付けやすくなります。

類似システムの実績を出発点にする

類似する業務・アプリケーション・データ量を持つ既存システムがあれば、その実績は有力なサイジング材料になります。平均値だけでなく、ピーク時のリクエスト数、レスポンスタイム、CPU使用率、メモリ使用量、IOPS、スループット、レイテンシ、Queue（処理待ち）などを確認します。

ただし、「サーバ台数が同じだから同じ性能」とは限りません。CPU世代、コア数、メモリ、ストレージ、ソフトウェアバージョン、処理内容などの差を整理し、必要に応じてベンチマークを比較材料として利用します。

CPUサイジングの簡単な例

例えば、既存システムがピーク時に300 requests/sを処理し、そのときのCPU使用率が60%だったとします。新システムで450 requests/sを想定する場合、まずワークロードが1.5倍になることをサイジングの出発点にします。

項目	既存システム	新システム
ピーク負荷	300 requests/s	450 requests/s
負荷比	1.0	1.5
CPU使用率	60%	初期見積もり後に性能試験で確認

単純化すれば必要なCPU処理能力も1.5倍程度を一つの出発点として考えられますが、実際にはCPU世代、IPC、キャッシュ、メモリ性能、並列性などが異なります。そのため、同じ種類のSPEC指標などで新旧CPUの処理能力差を補正し、初期サイジングを行います。

既存サーバと新サーバのCPU性能をベンチマーク値とCPU使用率から比較するサイジング例

この計算はあくまで初期サイジングのための概算です。CPU使用率とベンチマーク値が常に単純な比例関係になるわけではありません。最終的には、本番に近いアプリケーションとワークロードを使った性能試験で確認します。

性能試験でサイジングを補正する

類似システムの実績、ベンチマーク、各リソースの積み上げから得られる値は初期サイジングです。実際のアプリケーションでは、CPU効率、キャッシュヒット率、I/Oパターン、同時実行数などが組み合わさるため、計算だけで本番性能を正確に予測することは困難です。

類似システムの実績＋ベンチマーク＋積み上げ → 初期サイジング → 性能試験 → サイジング補正という流れで、見積もりと実測の差を確認します。

性能試験では本番に近いワークロードを与え、レスポンスタイム、スループット、エラー率と、CPU・メモリ・ストレージ・ネットワークの状態を同時に観測します。想定より早く飽和する場合はリソース量や構成を見直し、十分な余裕がある場合は過剰サイジングになっていないかも確認します。

性能余力は固定値ではなく条件から決める

ハードウェアには性能余力が必要ですが、「CPUは必ず70%以下」「メモリは必ず2倍」といった一律の基準だけでサイジングするのは適切ではありません。

性能余力は、想定ピークを超える負荷変動、将来の利用者・データ量の増加、障害による縮退、増設やスケールアウトに必要な時間などを吸収するために確保します。

考慮する条件	確認すること
負荷変動	想定ピークを一時的に超える負荷を処理できるか
将来増加	利用者数・リクエスト数・データ量の増加を吸収できるか
障害・縮退	一部リソース停止時も必要な性能を維持できるか
増設までの時間	リソース追加が完了するまで余力を維持できるか

性能試験では負荷を段階的に増やし、レスポンスタイムやエラー率が悪化し始める地点、スループットが伸びなくなる地点、Queueが増え始める地点を確認します。その結果と運用条件を合わせて、必要な性能余力を決めます。

障害・縮退時の性能設計

通常時に性能要件を満たすだけでは、十分な性能設計とはいえません。冗長構成を採用する場合は、サーバやネットワーク機器などが故障した状態でも、必要なサービスレベルを維持できるか確認します。

例えば3台のアプリケーションサーバで負荷分散しているシステムを考えます。通常時に3台でピーク負荷を処理できても、1台停止すると残り2台へ負荷が集中します。この状態でレスポンスタイムとエラー率の要件を守れるかが重要です。

通常時：3台で負荷分散 → 1台停止：残り2台へ負荷集中 → 縮退状態でも性能要件を満たすか確認

状態	稼働台数	確認すること
通常時	3台	ピーク負荷で性能要件を満たすか
1台停止	2台	残存サーバの処理能力で必要な負荷を処理できるか
復旧時	3台へ復帰	再接続やキャッシュのウォームアップで一時的な負荷が発生しないか

障害時に通常時とまったく同じ性能を要求するか、レスポンスタイムの一時的な悪化を許容するかはサービス要件によって異なります。重要なのは、縮退時にどこまで性能を維持するかを要件として決め、その条件で試験することです。

また、障害時には稼働を継続するサーバのCPUだけでなく、ロードバランサ、ネットワーク、ストレージ、データベースなど別の共有リソースへ負荷が集中する可能性があります。台数計算だけで終わらせず、クライアントからネットワーク、サーバ、データベース、ストレージまでの処理経路全体で縮退時の性能を検証します。

性能試験とハードウェアボトルネックの確認

設計時の見積もりが正しかったかは、性能試験や本番運用で確認します。ハードウェアのボトルネックを調査するときは、利用者側のレスポンスタイムやスループットと、リソース側の使用率・飽和・エラーを対応付けます。

リソース	主な観測項目	Linuxでの確認例
CPU	コア別使用率、実行待ち、コンテキストスイッチ	top、mpstat、pidstat、perf
メモリ	Available、Swap、Reclaim、メモリ圧迫、NUMA	free、vmstat、sar、numastat
ストレージ	IOPS、スループット、レイテンシ、Queue	iostat、sar
ネットワーク	帯域、パケット、ドロップ、Error	ip、sar、ethtool、nstat

ここで注意したいのは、値が高いリソースを見つけること自体が目的ではない点です。CPU使用率が高くてもレスポンスタイムとスループットが要件内なら、直ちに問題とは限りません。逆にCPU使用率が低くても、ストレージI/Oやロック、下流サービスを待っていればアプリケーションは遅くなります。

どのリソースの制約が、どのQueueや待ちを作り、その待ちが利用者のレスポンスタイムやスループットへどう影響しているかを確認します。

サイジングとトラブルシューティングをつなげる

性能試験でハードウェアのボトルネックが見つかった場合、その結果は単なる障害情報ではなく、サイジングを改善する材料になります。例えばCPUの飽和が450 requests/s（1秒あたり450リクエスト）付近から発生することが分かれば、必要なピーク負荷と比較して性能余力を再検討できます。

ストレージレイテンシが特定のIOPSを超えると急増するなら、その値はストレージ選定や監視のしきい値を見直す材料になります。性能設計では、設計・試験・運用で得た情報を次のサイジングや監視設計へ反映します。

性能設計 → サイジング → 性能試験 → ボトルネック確認 → 設計・監視へフィードバックというサイクルを回すことで、机上の見積もりだけでは分からない実際の限界点を次の設計へ反映できます。

まとめ

ハードウェアの性能設計では、CPUコア数やメモリ容量など、単一のスペックだけで性能を判断しないことが重要です。ワークロードに対して必要な処理能力を整理し、CPU・メモリ・ストレージそれぞれの特性を踏まえてサイジングします。

CPU：コア・スレッド・クロック・IPC・キャッシュを分けて考え、ベンチマークだけでなく対象ワークロードで検証する。
メモリ：容量だけでなく、帯域・レイテンシ・NUMAも性能要素として捉える。
ストレージ：IOPS・スループット・レイテンシをワークロード条件と合わせて評価し、異なるI/Oワークロードの干渉も確認する。
NIC・ネットワーク：帯域だけでなく、パケット処理量・ドロップ・エラーと、障害時の残存帯域も確認する。
サイジング：性能要件とワークロードから必要リソースを見積もり、類似システム・ベンチマーク・性能試験で初期サイジングを補正する。
性能余力：一律の固定値ではなく、負荷変動・成長・増設時間・障害時の残存サーバの処理能力から決める。
縮退時：1台故障などの条件でも必要なレスポンスタイム・スループット・エラー率を維持できるか試験する。
ボトルネック調査：リソースの値だけを見るのではなく、Queue（処理待ち）・待ちと利用者側の性能を対応付ける。

ハードウェア性能設計で重要なのは、個々のスペックを大きくすることではなく、想定ワークロードに対して必要な性能を満たし、ピーク時や障害時にも許容範囲内で処理を継続できる構成を作ることです。初期サイジング、性能試験、本番での観測をつなげ、実測結果を次の設計へ反映することで、過剰投資と性能不足の両方を避けやすくなります。