サイジングチートシート

はじめに

インフラエンジニアとして働く上では、サーバーのサインジングを実施する機会も出てくるため、実務に備えて考えを整理しておく。

結論

エンジニアが単独で実施できる見積作業ではない。そのため、顧客側にビジネス的な想定を聞いたうえでサイジングを行う必要がある。
また、クラウドでの構築の機会が多いと思う。そのため、コンピューティングリソースは自由に変更できるため、性能試験にて「限界性能」「長期負荷試験」「最大容量試験」を行いながら最終的なリソース量は見極めるべきとする。

顧客側へのヒアリングシート

No	必須	項目	質問例	回答例	サイジングにおける用途・目的
1		用途・役割	想定するシステムの利用用途を教えてください	Webアプリケーション	システムの処理特性（Web、API、バッチ等）を判断し、**処理の重さ・構成単位（Web/DB分離など）**を見極めるために使用。例えばWebアプリならステートレス設計、バッチならメモリ多め、など要件が変わる。
2	★	想定ユーザー数	ユーザー数、ピーク時同時アクセス数の想定	全体5000人、ピーク100人	TPS（Transactions Per Second）算出のベース。ピーク同時ユーザー × 操作頻度 ＝ TPS を見積もる。
3	★	アクセス頻度	1ユーザあたりの秒間の平均処理(リクエスト)件数	ピーク時0.5回/秒	中心的な指標。1秒間の処理件数から、必要なCPUコア数・インスタンス台数（水平スケール）を逆算する。
4	★	性能要件（応答時間）	目標レスポンスタイム	平均1秒以下	必要とされるレスポンスタイム（RT）とTPSのバランスを取ることで、許容できるリソース上限を調整。リトルの法則で同時処理数との関係も見積可。
5	★	データサイズ	データの総量・年間増加量の目安	50GB（年間増加量20GB）	ストレージ容量（ディスクサイズ）見積もりの基礎。特にDBサーバーのディスク IOPS要件やストレージスケーリング設計に使用。
6		データ処理内容（R/W比）	読み込みと書き込みの比率	読み8：書き2	データベースの読み取り・書き込みの負荷特性の把握に使う。書き込みが多いならIO性能やストレージのWrite耐性強化、読み取りが多いならキャッシュ導入やReadレプリカ検討など設計判断が変わる。
7		セキュリティ要件	特別な要件（暗号化、バックアップ頻度）	暗号化必須、毎日バックアップ	暗号化処理があるとCPU負荷が増える。また、バックアップ頻度に応じて、I/O帯域やディスク使用量の一時的なピークを見積もるために使用。
8		類似システムの実績	参考となるシステムのスペックや負荷状況	CPU 4 vCPU、8GB RAMでCPU 50%程度	初期スペック仮置きの参考。**「そのスペックで何TPS出たか」「CPU使用率はどの程度だったか」**などから、vCPU効率や目標TPSの妥当性を検証。
9	★	将来的な予測	3〜5年後のユーザー数やデータ増加予測	3年後にユーザー数2倍	スペックのスケーラビリティ前提（スケールアウトかスケールアップか）を設計するために使用。 クラウド構成でのリザーブドインスタンス検討にも必要。

サイジング詳細

WEB/APサーバーサイジング

CPUサイジングの大きな流れは以下の通りである。

1. 想定TPS（Peak TPS） を計算
   ↓
2. 必要総vCPUの算出
   ↓
3. 必要台数の算出

CPUのサイジング

1. 想定TPS（Peak TPS） を計算

TPS_peak=同時利用者数×平均操作回数

平均操作回数とは、利用者の平均リクエストと考えれば良い。
たとえば、同時アクセスユーザが100人・平均操作回数が0.5回/秒の時には、TPS_peak=100×0.5=50TPSと算出できる。

2. 必要総vCPUの算出

必要vCPU=(TPS_peak×平均CPUコスト秒)

平均CPUコスト秒(1トランザクションあたりのCPU使用秒数)は、既存の情報があればいいが無い場合には仮置きするしかない。
例えば、DB無の軽量APIの場合は0.01秒・中程度WEBアプリの場合は0.05秒・重めの処理（DBアクセス込み）の場合は0.1秒とする。
平均CPUコスト秒が、0.05の場合には、必要vCPU＝50×0.05=2.5vCPUが全体で必要だと算出できる。

3. 必要台数の算出
   一般的なパブクラでは、2vCPU→4vCPUの選択肢のため、「1台で4vCPUを積む」か「2台でそれぞれ2vCPUを積む」という考え方がある。
   どちらを採用するかは、「コスト」「システム用途」に依存すると考えられる。
   「システム用途」については、マイクロサービスの場合は初めから水平スケールの前提で2台構成とするし、モノシリックなアプリケーションの場合は初めに1台構成とするのも案の1つである。1台で足りなければ、冗長化して水平スケールを段階的にとっていくという考え方がある。
   台数の考え方の詳細は別見出しにも記載

メモリサイジング

基本的にはCPUを軸としたサイジングを行うことが多い認識である。CPUのリソース量とセットとなるメモリサイズが自動的に選択されることになる。
メモリサイズをベースにサイジングを行うこともあるかもしれないため、算出ロジックを記載しておく。

必要メモリ = 同時セッション数 × セッションあたりメモリ消費量

• WEBアプリでの目安：セッション1つあたり10~50MB
• 同時接続数が100、1セッション40MB→100*40MB = 4GB

2台構成ならば、2GB/台となる（余裕をもって4GB/台としてもよい）

ディスクサイジング

ディスク：総データ量 + 年間増加量 × 保存年数（バックアップ分も含む）

DBサーバーサイジング

CPUのサイジング

TPS×クエリ時間

静的ページの閲覧だけならばDBへの接続は発生しないため、TPSはWEB/APのTPS以下になることが多いはず。
そのため、

• Webページ閲覧系（静的コンテンツ中心）→ 10〜30%程度
• 一般的なWebアプリ（ログイン、検索あり）→ 30〜70%程度
• 業務系システム（全操作でDB更新）→ 80〜100%程度

のように仮置きをして、DBにおけるTPSを算出してもよい。

ディスクサイジング

必要ディスク容量(GB) =
  データサイズ(GB)
+ インデックスサイズ（データの30%〜100%想定）
+ 将来増加分（年間増加 × 保存年数）
+ 安全マージン（10〜30%）

各項目の説明は以下の通り。

項目	算出方法	説明
データ本体サイズ	お客様ヒアリング値（例：50GB）	テーブルに格納される生データ本体
インデックスサイズ	データ本体サイズ × インデックス比率（例：30%〜100%）	インデックスによる追加使用量（通常30〜100%程度）
将来増加量	年間データ増加量（GB） × 保存予定年数（年）	将来見込むデータ増加分
安全マージン	(データ本体＋インデックス＋将来増加) × 20%程度	突発的な増加や一時ファイルを吸収するため

データ本体サイズ：50GB、インデックス比率：50%、年間増加量：20GB、保存年数：3年、安全マージン：20%とすると、162GBのディスクを確保しておく必要があると見積できる。

CPUのサイジングで注意する考え方

1TPSに対して1CPU時間(1秒)を消費するという考え方は、情報量が少ない中での簡易算出には使えるが、なるべく避けたい考え方である。
なぜなら、1トランザクションあたり1秒を使うのは一般的ではない。そのため、なるべく1トランザクションあたり0.xx秒など仮置きした算出を行いたい。
また、I/O待ち（DBアクセス・ディスクアクセスなど）が多いアプリは、待ち時間に別の処理を進めることができるため、スループットはCPU数以上に伸ばせることも多い（1トランザクションあたりのCPU時間の短縮）
先ほどのCPU算出を例に挙げると、50TPS*1CPU時間=50vCPUが必要という結論になってしまう。100%間違っているわけではないが、精度が低い可能性があるため後工程での精査は必要である。

1台でCPU/メモリを多く持つか・複数台に分散するか問題

観点	スケールアウト（複数台構成）	スケールアップ（1台高スペック）
冗長性・可用性	✅ 強い（1台故障してもサービス継続可）	❌ 弱い（1台故障でサービス停止のリスク）
運用の柔軟性	✅ 柔軟（負荷に応じて台数増減できる、オートスケール可）	❌ 硬直（性能増強にはVM再起動、スケール限界あり）
コスト効率	🔵 状況による（小型VMをたくさん動かすと管理コスト増も）	🔵 状況による（大型VMは単価高いが台数少ない）
アプリの特性	✅ ステートレスなら最適（Web/APサーバー向き）	🔵 ステートフルや特殊要件（巨大DBサーバ等）なら有効
クラウド設計ベストプラクティス	✅ 基本スケールアウト推奨（Azure/AWS共通）	❌ スケールアップは例外扱い（やむを得ない場合のみ推奨）

1台でスケールアップ方式だと、リソースの増減の度に再起動が発生するため推奨ではない。また、複数台に分散することで、仮に自動スケールで1台増えてもコストの増加は最小限になる。
完全にリクエスト数が読めないことが多い中で、パブリッククラウドを使う構成では水平スケールが利用されることが多いだろう。そもそも、1台構成ではスケールアウトという考え方自体が無いので、可用性の観点も踏まえるとあまり採用されない案だと思う。
DBの場合には、データの一貫性の問題もあるため、まずは1台構成で初めて負荷に応じてリードレプリカを追加する考え方が良さそうである。

Appendix

参考程度に、生成AIにも考え方の補助をしてもらったので原文を載せておく。

原文

了解しました。サーバースペックを決める際のロジックや前提条件の立て方、負荷試験を通じた最適化の考え方など、ゼロベースからの設計プロセスについて調査します。
しばらくお待ちください。

パブリッククラウド初期サーバースペックの決定ガイド

新規プロジェクトをクラウド（AzureやAWSなど）上で立ち上げる際、具体的な用途や負荷が未定の場合でも、サーバーのCPUコア数やメモリ容量といったスペックを仮決めする必要があります。本稿では、限られた情報の中で初期スペックを決定し、その後ベンチマークによって検証・調整するまでのプロセスを体系的に解説します。あわせてTPS（Transactions Per Second）やスループットといった性能指標の定義・算出方法、将来的なスケールアウト/スケールアップを見据えた設計方針、クラウド特有の選択肢（リザーブドインスタンスやオートスケーリング）についても説明します。

前提と課題: 情報不足の中でのサイジング

初期段階では、以下のような重要情報が未定の場合があります。

• サーバーの具体的用途（Webサーバー、APIサーバー、バッチ処理など）
• 想定ユーザー数やアクセス頻度
• システムのアーキテクチャ（モノリスかマイクロサービスか）
• データベースの種類や役割

これらが不明確な状況では**サーバーサイジング（必要スペックの見積もり）**は難しく感じられます。しかしクラウド環境では、後からスペック変更や台数増減が比較的容易です。したがって最初から完璧に当てることより、合理的な仮説に基づく初期設定を行い、実測データをもとに迅速に調整できる設計にすることが重要です。

まずは**「十分小さく始めて、足りなければ拡張する」**のがクラウド利用の基本方針となります。初期スペックは、過去の類似システムの事例や一般的な経験則を参考に仮置きします。その際、お客様本番環境で利用する最小スペック想定のものを基準にすることが推奨されています (サイトに最適なWebサーバーのサイズを決定する方法 - WPBeginner)。例えば一般的なWeb/APサーバーであれば、デュアルコア～クアッドコアのCPU（2～4 vCPU）と4～8GB程度のメモリ、十分なディスク容量（数百GBクラス）といった構成が一つの目安になります (サイトに最適なWebサーバーのサイズを決定する方法 - WPBeginner)。これはあくまで汎用的な初期値であり、以降の検証で適宜見直していきます。

TPSとスループットの基礎知識

初期スペックを見積もる上で、TPSやスループットといった性能指標を正しく理解することが大切です。これらはシステムの処理能力を数量化する指標で、負荷試験やキャパシティプランニングで頻繁に用いられます。

• TPS (Transactions Per Second): 1秒あたりに処理されるトランザクションの数を表します (TPSとスループットの違いとは？理解を深めるためのガイド)。例えばWebシステムであれば、1秒間に完了したHTTPリクエスト数やビジネス処理の件数などがTPSです。TPSは主にデータベースやオンラインサービスの性能評価に使われる用語で、システムがどれだけのユーザー要求をさばけるかを示します (TPSとスループットの違いとは？理解を深めるためのガイド)。

• スループット (Throughput): 単位時間あたりに処理されるデータ量や仕事量を表します (TPSとスループットの違いとは？理解を深めるためのガイド)。一般にはネットワーク帯域のように「ビット毎秒」で測ることもありますが、Webアプリの文脈ではTPSとほぼ同義で使われることも多いです (TPSとスループットの違いとは？理解を深めるためのガイド)。つまり**「1秒間に完了したリクエスト数」**という意味でスループットを捉えて構いません。 (TPSとスループットの違いとは？理解を深めるためのガイド)

TPSとスループットの関係: WebシステムではTPSが高いほど一度に多くのユーザー要求を処理できるためスループット（処理量）も大きくなります。一方でTPSを上げようと負荷をかけすぎると、一件あたりの処理遅延（レイテンシ）が悪化することもあるため、TPS（量）とレイテンシ（応答時間）のバランスを見ることが重要です。理論上はリトルの法則により、「平均同時実行数 = 平均TPS × 平均応答時間」という関係が成り立ちます。この法則からも、平均応答時間を維持しつつTPSを確保することがシステム設計の鍵であるとわかります。

TPSの算出方法: TPSは実測や予測から算出できます。例えば負荷テストで20秒間に1000件のリクエストが完了したなら、平均TPSは1000/20 = 50 TPSとなります。またビジネス要件から逆算することもあります。たとえば「ピーク時に同時利用者100人がいて、それぞれ毎秒1回操作する」ならば、理論上100 TPSの処理が必要です。実際にはユーザー全員が同時に操作するわけではないため、全ユーザー数に対するピーク同時実行率を仮定します。一般にWeb系システムでは「全ユーザーの5%程度が瞬間的に同時アクセスする」といった仮定を置くことがあります。例えば想定ユーザー1000人で、その5%（50人）が同時アクセスすると仮定すれば、約50 TPSの処理能力が必要と見積もります。このように要求TPSを算出し、それを満たすインフラかどうかを検討するわけです。

初期スペック仮決めのプロセス

情報が限られる状況下では、まず経験則と仮定に基づき初期スペックを設定します。その後、負荷試験による検証とフィードバックを行い、最適なスペックへと近づけます。この一連の流れを順を追って説明します。

1. 類似システムの調査・基準設定: まず過去の類似プロジェクトや一般的なサーバースペックの事例を参考にします。たとえば社内に蓄積された「小規模WebサービスならvCPU 2コア・メモリ4GBで概ね足りた」などのナレッジがあればそれを起点にします。またはクラウドプロバイダが提示するインスタンスタイプの中から手頃なサイズ（極端に小さすぎず、かつ過剰でもないもの）を選びます。前述のように2～4 vCPU、4～8GB RAMあたりが多くのWebアプリケーションの最低ラインになります (サイトに最適なWebサーバーのサイズを決定する方法 - WPBeginner)。ディスクについても、余裕を持って数百GB程度（もしくはマネージドDBやオブジェクトストレージを活用）を確保しておきます。

2. 仮定に基づく負荷シナリオ策定: 次に、その初期スペックでどの程度の負荷に耐えられるかを予測します。用途が未定でも、「もしWebサーバーとして動かすなら1台で○○TPSは処理できるはず」「バッチ処理ならメモリがボトルネックになるかも」といった想定シナリオを立てます。TPSの目標値を仮設定し、応答時間の目安（例：平均1秒以内、あるいは90%のリクエストが3秒以内など）も決めておきます。この段階ではあくまで仮の数値ですが、後の検証計画の指標になります。

3. テスト環境の構築（最小構成）: 決定した初期スペックでテスト環境を用意します。本番想定の構成をできるだけ簡素化した最小構成（たとえばWeb/APサーバー1台とDBサーバー1台）で環境を構築します。このとき各サーバーのスペックも決め打ちし、例えば「Web/APサーバー: 2vCPU・4GB、DBサーバー: 4vCPU・8GB」のように設定します。全てクラウド上で用意できるためハードウェア調達は不要ですが、ソフトウェア（Webサーバー、アプリ、DB）のセットアップとテストデータの準備を行います。性能検証用の十分なデータ量やシナリオが用意できると理想的です。

4. 性能特性の把握 (ベンチマーク実施): 用意したテスト環境でベンチマークや負荷試験を実行し、アプリケーションの性能特性を測定します。例えばJMeterや負荷試験サービスを使い、仮定シナリオに沿ってリクエストを徐々に増加させます。具体的には、スレッド（仮想ユーザー）数を段階的に増やし（例: 10, 20, 30,...）、各段階でスループット（TPS）とレスポンスタイムを計測します。重要なのは、負荷を上げていってどの時点でシステムに劣化が生じるかを見極めることです。レスポンスタイムが許容値を超えたりエラー（例: HTTP 503エラー）が発生し始めた段階が、そのサーバー構成での処理限界だと判断できます。

   • 限界TPSの確認: 負荷試験の結果得られた最大TPS（これ以上TPSを上げると性能劣化するポイント）を限界スループットとして記録します。例えば、最小構成の環境で限界TPSが30 TPSだった場合、「このスペックでは秒間30リクエスト前後が処理上限」と言えます。この限界スループットがベースラインとなり、今後のスペック検討時の指標になります。

   • リソース使用状況の分析: 負荷試験中のCPU使用率、メモリ消費、ディスクIO、ネットワーク帯域などのメトリクスも記録します。例えば限界TPS付近でCPU使用率が常時90%以上ならCPUがボトルネックかもしれませんし、メモリが逼迫してスワップが発生していればメモリ不足が原因かもしれません。アプリケーションのログ（例: Apache/Nginxのアクセスログ、GCログ、DBのクエリ実行計画など）も合わせて分析し、ボトルネックとなっている箇所を特定します (Webアプリケーションのサーバーサイジング(スペック見積もり)の考え方についてまとめてみた #パフォーマンス計測 - Qiita)。

5. スペックの調整と再テスト: ボトルネックに応じてサーバーのスペックを**調整（チューニング）**し、再度ベンチマークを行います。調整方法には大きく二つあります。

   • 垂直スケール（スケールアップ）での調整: 単一サーバーのCPUコア数やメモリ量を増強してみます。例えばWeb/APサーバーのCPUコア数を2コア→4コアに倍増させ、再度限界TPSを測定します。次にCPUを元に戻し、今度はメモリを4GB→8GBに増やして同様にテストします。このように一度に一要素ずつ変更して性能の差を見ることで、「CPUを増やすとTPSがどれだけ伸びるか」「メモリ増加の効果はあるか」といった性能特性の変化を確認できます。もしCPUコア増加でTPSが大きく向上するならCPU不足がボトルネックだったと判断できますし、メモリ増加で効果が出ればメモリが足りなかった可能性が高いと言えます。

   • 水平スケール（スケールアウト）での調整: サーバー台数を増やす方法です。例えば同じWebサーバーをもう1台追加し、2台構成でロードバランサ経由の負荷試験を行います。スケールアウトした場合、ほぼ線形にTPSが倍増するのが理想ですが、実際は多少効率低下が起こることもあります（スケールアウトによるオーバーヘッドやセッション分散の影響など）。それでも、単一サーバーの限界TPSと照らし合わせれば概算の必要台数が計算できます。先ほどの例で1台あたり30 TPSが限界だった場合、50 TPSを捌くには2台必要といった具合です（逆に1台で70 TPS出せる見込みなら1台で足ります）。このように必要な水平展開数を見積もることができます。

   調整後の構成で再度負荷試験を行い、目標とするTPS・レスポンスタイムを達成できるか確認します。複数回の試行を経て、**「初期スペックでどこまで耐えられ、将来的にどのリソースを強化すべきか」**が明確になってきます。

6. 本番スペックの決定: ベンチマーク結果と性能要件を突き合わせ、最終的な本番環境のスペックを決定します。例えば「Webサーバー2台（各4vCPU・8GB）で負荷目標をクリアしたので本番もこの構成にする」「DBサーバーはCPUよりメモリ搭載量を優先して選ぶ」など、データに裏付けられた構成案を作成します。必要であればお客様やチームに対し、負荷試験結果を根拠とした説明を行います。実際の本番稼働後も定期的にモニタリングを行い、実負荷に応じた調整（後述のオートスケーリング等も活用）を続けることで、継続的に最適なインフラを維持します。

以上が初期スペックの仮決めから検証・調整までのプロセスです。一言でまとめれば、**「小さく始めて計測し、データに基づいて改善する」**ことがポイントです。

TPS/スループットを活用したキャパシティ計画

上記プロセスの中で特に重要なのが、TPSやスループットの値をどのように使って容量計画を立てるかです。以下にポイントを整理します。

• ベースラインTPSの活用: 最初の負荷試験で測定した限界TPSは、そのスペックで処理できる秒間リクエスト数の上限を意味します。この値をベースラインとして持っておくと、異なるシナリオでも線形近似でざっくりとした見積もりができます。例として「1台で30 TPSなら、60 TPS必要なら単純計算で2台、90 TPSなら3台」といった具合です。ただしシステムには並列化効率の低下やロック・競合なども存在するため、理想通りに比例しない場合もあります。そのため、最終判断前にできれば実機で試す（例えば2台構成で再テストする）ことが望ましいです。

• TPS目標値の設定: ビジネス要件から必要TPSを逆算し、それを満たすよう計画します。前述の同時利用率の仮定などを用いてピーク時TPSを推定します。さらに余裕係数を乗せることも重要です。例えば見積もり50 TPS必要でも、余裕を見て1.5倍の75 TPSをさばけるように設計する、といった考え方です。クラウドの場合は余裕を持ちすぎるとコスト増になるため悩ましいところですが、オートスケーリングで伸縮させる前提であれば、ある程度の余裕を持ったベースライン性能を設定しておくと安心です。

• レスポンスタイムとの兼ね合い: TPSだけでなくレスポンスタイム（応答時間）との関係も見る必要があります。高TPSでもレスポンスが遅ければユーザー体感は悪くなりますし、逆にレスポンス重視で処理を逐次化しすぎるとTPSが出ません。性能試験では、TPSと平均/パーセンタイル応答時間を両方記録しておきます。そして「どのTPS水準までなら応答時間が許容範囲内に収まるか」を見極めます。例えば平均2秒以内の応答を保証したいなら、負荷を上げていって平均2秒を超え始めるTPS値を探します。そのTPSが現実的なピーク要求値より上であればOK、下回るようならスペック強化や構成見直しが必要、という判断になります。

• 複数コンポーネントのバランス: Webシステムでは、Web/APサーバーとDBサーバーなど複数の層があります。それぞれに対してTPSやスループットの目標を設定し、ボトルネックがどこに発生するかをチェックします。例えばDBが1秒間に処理できるクエリ数（TPS）がボトルネックなら、DB側のスペック増強やクエリ最適化が必要になります。逆にDBは余裕だがAPサーバーがCPU100%で頭打ちなら、APサーバーの台数増加やスペック向上を検討します。このようにシステム全体のスループットは最も弱い部分に制約されるため、各コンポーネントの性能指標を把握しバランスを取ることが大切です。

初期スペック推定の具体例

情報が乏しい状況でも、過去の経験や一般的な負荷規模に照らして初期スペックをざっくり推定することが可能です。以下に、想定システム規模に応じた初期スペックの例を表形式で示します。あくまで仮定に基づく一例ですが、検討の出発点として参考になります。

想定システム規模	仮定スペック (vCPU / メモリ)	想定される用途・特徴例
小規模（テスト・試験運用）	2 vCPU / 4 GB	開発・ステージング環境、または本番でも低負荷のサービス。 ユーザー数が数百人以下、1秒間あたり数リクエスト程度の想定。
中規模（標準的なWebサービス）	4 vCPU / 8 GB	一般的な企業サイトやAPIサービスの初期構成。 同時数千ユーザーまで、瞬間的に二桁TPS（10～50 TPS）程度の負荷を想定。
大規模（高トラフィック対応）	8 vCPU / 16 GB	SNSやECサイトなど多数ユーザーが利用するサービス。 ピーク時に三桁TPS（100 TPS以上）も見据え、余裕を持った構成。
超大規模（計画的高負荷）	16 vCPU / 32 GB (以上)	大型キャンペーンや大規模バッチ処理を伴うシステム。 初期から高負荷が見込まれるため強力なマシンスペックで開始し、必要に応じて更にスケール。

※ディスクストレージについては、上記いずれの場合も必要容量+αを見積もって割り当てます（例：現在想定100GBなら300GBを確保など (How to Determine the Ideal Size of a Web Server for Your Website) (How to Determine the Ideal Size of a Web Server for Your Website)）。またストレージ種別も性能に影響するため、DBには高IOPSのSSDを使う、静的ファイルはオブジェクトストレージに置く等の工夫も考慮します。

上記はあくまで初期段階での仮置きです。実際にはこの後の負荷試験で計測されたTPSや使用率データを見ながら、例えば「中規模予定だったが思ったよりCPUに余裕があるので2vCPUに減らそう」「大規模想定だがDBは8vCPUでは足りないかもしれない」といった調整を行っていきます。クラウドの利点は、このようなスペック変更が必要になった際に手軽にリソース追加・変更できる点です。サーバー台数の増減も含め柔軟に試しながら、最適解を探っていきましょう。

スケールアウト/スケールアップを見据えた設計

初期スペックを決める際には、将来的な**スケーラビリティ（拡張性）**も念頭に置く必要があります。システムに負荷が増大した場合、**垂直スケーリング（スケールアップ）または水平スケーリング（スケールアウト）**で対処します。それぞれの特徴を理解し、設計段階からどちらに寄せるか方針を立てておくことが重要です。

• 垂直スケーリング（スケールアップ）: 単一のサーバーに対してCPUやメモリなどのリソースを増強し、処理能力を高める方法です (垂直スケーリングと水平スケーリングの違い #AWS - Qiita)。例えば小さなインスタンスからより高性能なインスタンスへアップグレードする、CPU数を増やす、メモリを追加する、といった対応になります (垂直スケーリングと水平スケーリングの違い #AWS - Qiita)。垂直スケールはアプリケーション構成を大きく変えずに性能向上が見込める利点がありますが、一方で上限があります（クラウドプロバイダが提供する最大サイズ以上にはできない、物理的な限界がある等）。またスケールアップ作業中はサーバー再起動などが必要になるため、ダウンタイムを伴う場合もあります (Autoscaling guidance - Azure Architecture Center | Microsoft Learn)。そのため、自動化されたリアルタイムの拡張手段として使われることは少なく、計画的な増強として位置付けられます。

• 水平スケーリング（スケールアウト）: 負荷に応じてサーバーの台数を追加し、全体として処理能力を上げる方法です (垂直スケーリングと水平スケーリングの違い #AWS - Qiita)。ロードバランサー等を用いてトラフィックを複数サーバーに分散させることで、システム全体でより多くのリクエストを捌けるようにします (垂直スケーリングと水平スケーリングの違い #AWS - Qiita)。水平スケールのメリットは、理論上はサーバー台数を増やし続ける限り処理能力を向上できる点と、各ノード追加時にシステム全体を停止せずに済む点です (Autoscaling guidance - Azure Architecture Center | Microsoft Learn)。特にクラウドでは、新しいVMやコンテナを起動して既存システムに組み込む操作が自動化しやすいため、リアルタイムに近い拡張（オートスケーリング、後述）が可能です。水平スケーリングはマイクロサービスアーキテクチャとも相性が良く、サービスごとに独立したスケールアウトを実現できます (垂直スケーリングと水平スケーリングの違い #AWS - Qiita)。

設計方針としての違い: モノリシックなアプリケーションの場合、まずは垂直スケールで単体性能を上げ、それでも足りなければ冗長化（クラスター化）して水平スケール、という段階的手法を取ることが多いです。一方、マイクロサービスの場合は初めから水平スケール前提で、小さなサービス単位に分割し、それぞれ必要に応じて複数インスタンス動かす設計をします。どちらの方式を採用するにせよ、ステートレスな設計（セッション情報を外部ストレージに出すなど）やデータの分散（例えばデータベースシャーディングやキャッシュ利用）など、スケーラビリティを高めるアーキテクチャ上の工夫が求められます。

スケールアウト/アップ時のTPSの考え方: 先述したように、水平スケールでは理論上TPSは台数に比例します。しかし実際にはスケールアウト時にオーバーヘッドが増える可能性があります。例えばキャッシュの一貫性維持や、分散環境でのネットワーク遅延などです。そのためN台構成にした場合のTPSも余裕があれば負荷試験で確かめておくことが望ましいです。一方垂直スケールでは、例えばCPUコア数を倍にしても単純にTPSが倍になるとは限りません。ソフトウェアがシングルスレッドしか使わない場合は意味がないですし、ロック争いが激化すると効率低下もあります。そこで、性能試験時に得られたスケーラビリティ特性（CPU増による性能向上割合など）を踏まえ、「将来コア数を増やしてもどれくらい効果がありそうか」「台数増でどこまで伸ばせそうか」を予測しておきます。この予測はあくまで計画値ですが、後述するオートスケーリングの閾値設定などの参考にもなります。

クラウド特有の選択肢: リザーブドインスタンスとオートスケーリング

クラウド環境では、インフラ設計においてコスト最適化や自動化のための特有の機能を活用できます。初期スペック決定時にも考慮しておきたい代表的なものがリザーブドインスタンス（またはSavings Plan）とオートスケーリングです。

• リザーブドインスタンス (RI): 例えばAWSのEC2やAzureのVMには、特定のインスタンスを1年または3年といった期間で予約購入することで料金割引を受けられる仕組みがあります (EC2でのオンデマンド、リザーブド、スポットインスタンスの違い)。これは長期間に渡り継続利用することが確定しているサーバーに適用することで、大幅なコスト削減が可能です (EC2でのオンデマンド、リザーブド、スポットインスタンスの違い)。一方で契約期間中は基本的に変更や解約ができず、利用しなくても料金が発生するため、需要予測が外れるとコストの無駄が生じます (EC2でのオンデマンド、リザーブド、スポットインスタンスの違い)。したがって、新規プロジェクトの初期段階では無理にRIを購入せず、**オンデマンド（従量課金）**で開始するのが安全です (EC2でのオンデマンド、リザーブド、スポットインスタンスの違い)。オンデマンドで様子を見て、システムの負荷プロファイルや稼働率が把握できてきたら、常時稼働が見込まれるベース部分にRIを当てるとよいでしょう（例：夜間も停止できない常駐サーバー群にRI適用し、昼間ピークのみ増やす分はオンデマンドやスポットで対応するなど (EC2でのオンデマンド、リザーブド、スポットインスタンスの違い)）。目安として、リソースの年間平均使用率が70%以上であればRIを検討するとコストメリットが出やすいと言われています (Effectively using AWS Reserved Instances)。

• オートスケーリング: クラウドならではの強みである弾力性（エラスティシティ）を活かし、需要に応じて自動でインスタンス数を増減させる仕組みがオートスケーリングです。 (オート・スケーリングとは| IBM)。典型的にはCPU使用率やキューの長さなどのモニタリング指標が一定の閾値を超えたらサーバーを1台追加、逆に閾値以下が続いたら1台削減、といったポリシーを設定します。AWSではAuto Scaling Group, AzureではVirtual Machine Scale Setsなどのサービスが提供されています。オートスケーリングを導入しておけば、予想外のアクセス急増にも自動対応でき、また深夜帯など負荷の低い時間にサーバー台数を絞ってコストを抑えることもできます (オート・スケーリングとは| IBM)。設計段階で考慮すべきは、ステートレスなアプリケーション構成（急にサーバーが増減しても問題ないようにする）、スケール時の初期化処理（新規サーバーが起動時に必要な設定やデプロイが自動で行われるようにする）、そしてスケーリングポリシーの決定（どの指標をトリガーにするか、スケールアウト後のクールダウン時間設定など）です。初期スペックが不足していてもオートスケーリングが適切に機能していれば一時的な凌ぎが可能ですが、常に最大台数張り付きだと遅かれ早かれ限界が来ます。従ってオートスケーリングは魔法の万能薬ではなく、基本性能（ベースライン）を満たした上でのバースト対応策と捉えるとよいでしょう。

以上のように、クラウドでは負荷特性に応じた柔軟なリソース運用ができます。初期設計の段階からこれらを見据えておくことで、後々の運用・コスト最適化がスムーズになります。例えば「将来的に高負荷イベントがあるが常時ではない」という場合、ベースは控えめスペック+オートスケーリングで対応し、安定してきたらRIで費用圧縮、といった戦略が考えられます。逆に「常に一定以上の負荷がかかる基幹システム」であれば、当初から余裕を持ったスペックを確保しRIでコスト最適化する方が安心です。

まとめ

クラウド上で新規プロジェクトのサーバースペックを決定する際は、たとえ要件が不明確でも仮説駆動で進めることが可能です。まずは一般的なスペック（CPUコア数やメモリ量）の範囲から妥当と思われる構成でスタートし、TPSやスループットなどの指標を用いてシステムの性能特性を測定します。そのデータをもとにボトルネックを解消するようスペックを垂直・水平に調整し、必要に応じてサーバー台数も見直します。こうした検証を通じて得られた限界スループットが、最終的な本番インフラ設計の強力な根拠となります。また、将来の負荷増大に備えてスケールアウトしやすい設計を取り入れ、クラウドの機能（オートスケーリングやRI）を駆使することで、性能とコストのバランスを最適化できます。

未知の要素が多い初期段階でも、「計測可能な仮定」さえ置いてしまえば後は検証・調整で軌道修正できます。クラウドの俊敏性を活かし、まずは小さく構築してデータに基づき改善するサイクルを回していきましょう。このアプローチこそが、パブリッククラウド時代におけるサーバーサイジングのベストプラクティスです。