はじめに

システムを構築するとき、機能が正しく動作することはもちろん重要です。

しかし、それだけでは十分ではありません。

例えば、ネットショップで商品を検索したとき、結果が表示されるまでに30秒かかるとしたらどうでしょうか。

正しい検索結果が表示されても、利用者にとって使いやすいシステムとはいえません。

また、普段は快適に動作していても、利用者が急増すると処理が追いつかなくなる場合があります。

そこで重要になるのが、システムの性能評価です。

システムの性能評価では、次のような疑問を数値で確認します。

1秒間に何件の処理ができるのか
操作してから何秒で応答が返ってくるのか
処理がすべて完了するまで何秒かかるのか
CPUにはどれくらいの計算能力があるのか
利用者が増えても安定して動作するのか

今回は、次の内容を学びます。

システムの性能特性と評価
│
├─ システムの性能指標
│   ├─ スループット
│   ├─ レスポンスタイム
│   ├─ ターンアラウンドタイム
│   ├─ MIPS
│   └─ FLOPS
│
├─ システム性能評価の技法
│   ├─ 命令ミックスベンチマーク
│   ├─ SPEC
│   ├─ TPC
│   └─ シミュレーション
│
├─ モニタリング
│   ├─ ソフトウェアモニタ
│   └─ ハードウェアモニタ
│
└─ キャパシティプランニング
    ├─ キャパシティ管理
    ├─ スケールアウト
    └─ スケールアップ

それでは、システムの性能を表す指標から理解していきましょう。

1. システムの性能指標とは

1-1. 性能指標の基本

**性能指標（Performance Metrics）**とは、システムの処理能力や応答速度などを数値で評価するための指標です。

例えば、次のようなものがあります。

性能指標	評価する内容
スループット	一定時間に処理できる仕事の量
レスポンスタイム	要求してから応答が返るまでの時間
ターンアラウンドタイム	処理を依頼してからすべて完了するまでの時間
MIPS	1秒間に実行できる命令数
FLOPS	1秒間に実行できる浮動小数点演算数

これらは、すべてシステムの性能に関係しています。

しかし、何を測定しているのかが異なるため、区別して覚える必要があります。

2. スループット

2-1. スループットとは

**スループット（Throughput）**とは、単位時間当たりに処理できる仕事の量を表す指標です。

例えば、Webサーバが1秒間に100件のリクエストを処理できる場合、スループットは100件/秒です。

Webサーバ

1秒間に処理した要求

要求1   ─┐
要求2   ─┤
要求3   ─┤
  ：     │
要求100 ─┘

スループット：100件/秒

スループットは、一般的に値が大きいほど、多くの処理を実行できることを表します。

2-2. スループットの計算

基本的な計算式は次のとおりです。

スループット = 処理件数 ÷ 処理時間

例えば、あるシステムが10秒間で500件の処理を完了したとします。

処理件数：500件
処理時間：10秒

スループット
= 500 ÷ 10
= 50件/秒

このシステムのスループットは、50件/秒です。

2-3. スループットが重要な場面

スループットは、大量の処理を行うシステムで重要です。

例えば、

Webサイト
データベース
決済システム
バッチ処理
ファイル転送システム

などです。

🍯 はちみつ屋さんで例えると

はちみつ屋さんが1時間に60個の商品を包装できるとします。

この場合、包装作業のスループットは60個/時間です。

新しい包装機を導入して1時間に120個包装できるようになれば、スループットは2倍になります。

つまり、**スループットは「一定時間にどれだけ仕事をこなせるか」**ということです。

3. レスポンスタイム

3-1. レスポンスタイムとは

**レスポンスタイム（Response Time）**とは、システムへ要求を送ってから、応答が返ってくるまでの時間です。

例えば、利用者が検索ボタンを押してから検索結果が表示されるまでの時間が該当します。

利用者                システム
  │                      │
  │── 検索要求 ─────────▶│
  │                      │
  │                   検索処理
  │                      │
  │◀── 検索結果 ─────────│
  │                      │

  ↑                      ↑
  └── レスポンスタイム ──┘

一般的に、レスポンスタイムは短いほど快適です。

3-2. レスポンスタイムの構成要素

レスポンスタイムには、複数の時間が含まれます。

例えば、

ネットワークの通信時間
処理開始までの待ち時間
CPUによる処理時間
ディスクへのアクセス時間
応答を返すための通信時間

などです。

単純化すると、次のように表せます。

レスポンスタイム = 待ち時間 + 処理時間 + 通信時間など

例えば、

通信時間：0.1秒
待ち時間：0.3秒
処理時間：0.5秒
応答通信：0.1秒

であれば、

レスポンスタイム
= 0.1 + 0.3 + 0.5 + 0.1
= 1.0秒

となります。

3-3. レスポンスタイムの注意点

レスポンスタイムを評価するときは、平均値だけでなく、遅い応答にも注目することが重要です。

例えば、100回の検索のうち、99回は1秒以内に完了しても、残り1回に30秒かかる場合があります。

このような状況を把握するために、パーセンタイル値が利用されます。

例えば、95パーセンタイルのレスポンスタイムが2秒であれば、測定対象の約95%の要求が2秒以内に応答したことを意味します。

4. ターンアラウンドタイム

4-1. ターンアラウンドタイムとは

**ターンアラウンドタイム（Turnaround Time）**とは、処理を依頼してから、処理がすべて完了して結果を受け取るまでの時間です。

主に、バッチ処理やジョブ処理などで利用される指標です。

例えば、売上集計処理を考えてみましょう。

売上集計ジョブを投入
        │
        ▼
     処理待ち
        │
        ▼
     集計処理
        │
        ▼
     結果出力
        │
        ▼
     処理完了

ジョブを投入してから結果を受け取るまでが、ターンアラウンドタイムです。

4-2. ターンアラウンドタイムの計算

例えば、

ジョブ投入：10:00
処理開始　：10:05
処理完了　：10:20

という場合、

ターンアラウンドタイム
= 10:20 - 10:00
= 20分

となります。

処理そのものにかかった時間は15分ですが、待ち時間も含めるため、ターンアラウンドタイムは20分です。

5. レスポンスタイムとターンアラウンドタイムの違い

この2つは、応用情報技術者試験でも混同しやすい用語です。

一般的な区別は次のとおりです。

比較項目	レスポンスタイム	ターンアラウンドタイム
主な意味	要求から応答までの時間	依頼から処理完了までの時間
主な用途	対話型システム	バッチ処理・ジョブ処理
重視すること	利用者への応答速度	作業全体の完了時間
具体例	検索結果が表示されるまで	売上集計が完了するまで

具体例

ある利用者が帳票作成を依頼したとします。

10:00:00　帳票作成ボタンを押す

10:00:01　受付完了の応答が返る

10:05:00　帳票作成が完了する

この場合、

レスポンスタイム：1秒

ターンアラウンドタイム：5分

と考えられます。

ただし、レスポンスタイムの測定範囲はシステムの仕様によって異なります。

帳票が完成してから初めて応答を返す同期処理であれば、レスポンスタイムにも帳票作成時間が含まれます。

🍯 覚え方

レスポンスタイムは「返事が来るまで」。

ターンアラウンドタイムは「仕事が全部終わるまで」。

6. MIPS

6-1. MIPSとは

**MIPS（Million Instructions Per Second）**とは、CPUが1秒間に実行できる命令数を、100万命令単位で表した性能指標です。

例えば、1秒間に5億命令を実行できるCPUの場合、

5億命令
= 500,000,000命令

500,000,000 ÷ 1,000,000
= 500 MIPS

となります。

つまり、500 MIPSは1秒間に約5億命令を実行する性能を表します。

6-2. MIPSの計算式

基本的な計算式は次のとおりです。

MIPS = 1秒間の命令実行数 ÷ 10⁶

また、命令数と実行時間が分かっている場合は、

MIPS = 命令数 ÷（実行時間 × 10⁶）

で計算できます。

計算例

あるCPUが、2秒間で8億命令を実行したとします。

命令数：800,000,000
実行時間：2秒

MIPS
= 800,000,000 ÷ (2 × 1,000,000)
= 400

答えは400 MIPSです。

6-3. クロック周波数とCPIから求める方法

CPUの性能を考えるときには、次の用語も重要です。

**CPI（Cycles Per Instruction）**とは、1命令を実行するために必要な平均クロックサイクル数です。

例えば、クロック周波数が2GHz、平均CPIが4の場合、

クロック周波数：2GHz
              = 2,000,000,000Hz

平均CPI：4

1秒間に実行できる命令数は、

2,000,000,000 ÷ 4
= 500,000,000命令/秒

したがって、

MIPS
= 500,000,000 ÷ 1,000,000
= 500 MIPS

となります。

式にすると、

MIPS = クロック周波数（Hz）÷（平均CPI × 10⁶）

です。

※単一の命令実行系列についての基本的なモデルです。実際のCPU性能には、並列実行や命令の種類なども影響します。

6-4. MIPSの注意点

MIPSの値が高ければ、必ず実際のアプリケーションが高速になるわけではありません。

なぜなら、CPUの種類によって命令の内容や複雑さが異なるためです。

例えば、

CPU A：1,000 MIPS
CPU B： 800 MIPS

だったとしても、CPU Aのほうが必ず処理を速く完了できるとは限りません。

実際の性能比較では、アプリケーションの処理内容に近いベンチマークを利用することが重要です。

7. FLOPS

7-1. FLOPSとは

**FLOPS（Floating-point Operations Per Second）**とは、1秒間に実行できる浮動小数点演算の回数を表す性能指標です。

浮動小数点演算とは、小数を含む数値などを扱う計算です。

例えば、

3.14 × 2.5

0.125 + 0.375

のような計算が該当します。

FLOPSは、科学技術計算やAIの計算などで重要な指標です。

7-2. FLOPSの単位

FLOPSには、次のような単位があります。

単位	演算回数
KFLOPS	10³回/秒
MFLOPS	10⁶回/秒
GFLOPS	10⁹回/秒
TFLOPS	10¹²回/秒
PFLOPS	10¹⁵回/秒
EFLOPS	10¹⁸回/秒

例えば、1秒間に2兆回の浮動小数点演算ができる場合、

2,000,000,000,000回/秒

= 2 TFLOPS

となります。

7-3. MIPSとFLOPSの違い

比較項目	MIPS	FLOPS
正式名称	Million Instructions Per Second	Floating-point Operations Per Second
測定対象	命令実行数	浮動小数点演算数
主な用途	CPUの命令実行性能の評価	数値計算性能の評価
単位	100万命令/秒	演算回数/秒

🍯 覚え方

MIPSは「命令を何個実行できるか」。

FLOPSは「小数を扱う計算を何回できるか」。

なお、FLOPSも測定条件によって値が変わります。

単精度・倍精度などの演算精度や、理論上の最大性能と実測性能を区別することが重要です。

8. システム性能評価の技法

ここまでは、性能を表す指標を学びました。

次は、実際にシステムの性能を評価する方法を学びます。

代表的な技法として、次のものがあります。

命令ミックスベンチマーク
SPEC
TPC
シミュレーション

9. 命令ミックスベンチマーク

9-1. 命令ミックスとは

**命令ミックス（Instruction Mix）**とは、CPUが実行する命令の種類と、その出現割合を表したものです。

例えば、あるプログラムで次のような命令が実行されるとします。

命令の種類	出現割合
算術演算命令	40%
データ転送命令	30%
分岐命令	20%
その他	10%

このような命令の組み合わせを利用して、CPUの性能を評価します。

9-2. 命令ミックスベンチマークとは

命令ミックスベンチマークとは、代表的な命令の出現割合と実行時間などを利用して、CPUの性能を評価する方法です。

実際のプログラムでは、命令の種類によって実行に必要な時間が異なります。

そのため、命令ごとの実行時間と出現割合を考慮します。

9-3. 平均命令実行時間の計算

例えば、次のような命令ミックスを考えます。

命令の種類	出現割合	実行時間
命令A	50%	2ns
命令B	30%	4ns
命令C	20%	6ns

nsはナノ秒で、10億分の1秒を表します。

平均命令実行時間は、各命令の実行時間を出現割合で重み付けして求めます。

平均命令実行時間 = Σ（命令の出現割合 × 実行時間）

計算すると、

命令A：0.5 × 2ns = 1.0ns
命令B：0.3 × 4ns = 1.2ns
命令C：0.2 × 6ns = 1.2ns

平均命令実行時間
= 1.0 + 1.2 + 1.2
= 3.4ns

となります。

この平均時間から、単純化したMIPSを計算することもできます。

1秒 = 1,000,000,000ns

1秒間の命令数
= 1,000,000,000 ÷ 3.4
≒ 294,117,647命令

MIPS
≒ 294.1

したがって、約294 MIPSです。

※命令を順次実行する単純化したモデルでの計算です。

9-4. 命令ミックスベンチマークの特徴

メリット

CPUの命令実行性能を評価できる
命令の種類ごとの実行時間を考慮できる
性能計算の考え方を理解しやすい

デメリット

実際のアプリケーションの性能と一致するとは限らない
メモリアクセスやI/Oなどの影響を十分に反映できない場合がある
命令の組み合わせによって評価結果が変わる

そのため、実際の用途に近いベンチマークと組み合わせて評価することが重要です。

10. SPEC

10-1. SPECとは

**SPEC（Standard Performance Evaluation Corporation）**とは、コンピュータシステムの性能評価に関する標準的なベンチマークを開発・提供する団体です。

SPECが提供するベンチマークは、CPUやシステムの性能を比較する際に利用されます。

10-2. SPECベンチマークの特徴

SPECのベンチマークでは、定められたプログラムや測定条件に基づいて性能を評価します。

代表的な評価対象には、

CPUの整数演算性能
CPUの浮動小数点演算性能
サーバの処理性能

などがあります。

例えば、SPEC CPUベンチマークでは、複数のプログラムを実行してCPU性能を評価します。

10-3. SPECを利用するメリット

① 共通条件で比較できる

同じベンチマークと測定ルールを利用することで、異なるシステムの性能を比較しやすくなります。

② 実際のプログラムに近い処理を利用する

単純な命令実行数だけでなく、複数のプログラムを使って性能を評価します。

③ 性能評価の客観性を高められる

定められたルールに従うことで、比較条件を明確にできます。

ただし、SPECのスコアが高くても、すべての業務アプリケーションで同じ性能差が出るわけではありません。

11. TPC

11-1. TPCとは

**TPC（Transaction Processing Performance Council）**とは、データベースなどのトランザクション処理性能を評価するためのベンチマークを策定する団体です。

トランザクションとは、データベースなどで一つのまとまりとして扱う処理のことです。

例えば、ネットショップで注文を確定するときには、

注文情報の登録
在庫数の更新
決済情報の処理

などが関係します。

このような処理の性能を評価する際に、TPCのベンチマークが利用されます。

11-2. 代表的なTPCベンチマーク

TPC-C

TPC-Cは、注文処理などをモデルとしたオンライン・トランザクション処理（OLTP）の性能を評価するベンチマークです。

TPC-H

TPC-Hは、意思決定支援を想定した複雑な問い合わせ処理などの性能を評価するベンチマークです。

11-3. TPCの特徴

TPCのベンチマークでは、処理性能だけでなく、構成やコストなども評価・報告の対象となる場合があります。

例えば、TPC-Cでは、性能指標としてtpmCが利用されます。

tpmCは、TPC-Cで定められた条件に基づく、1分当たりのNew-Orderトランザクション処理性能を表します。

単純な「すべてのトランザクションの合計件数/分」とは異なる点に注意しましょう。

12. SPECとTPCの違い

比較項目	SPEC	TPC
正式名称	Standard Performance Evaluation Corporation	Transaction Processing Performance Council
主な評価対象	CPUなどのコンピュータ性能	DB・トランザクション処理性能
代表的なベンチマーク	SPEC CPU	TPC-C、TPC-H
主な用途	計算処理性能の比較	業務処理・DB性能の比較

🍯 覚え方

SPECは「コンピュータの計算性能」。

TPCは「データベースの業務処理性能」。

ただし、どちらも複数のベンチマークを提供しているため、具体的な評価対象はベンチマークごとに確認する必要があります。

13. シミュレーション

13-1. シミュレーションとは

**シミュレーション（Simulation）**とは、実際のシステムの動作をモデル化し、条件を変えながら性能や挙動を予測する技法です。

例えば、ネットショップで利用者が急増した場合を考えてみましょう。

通常時：100人が利用

セール時：1,000人が利用

大規模イベント時：10,000人が利用

このような状況をモデル化して、システムの性能を予測します。

13-2. シミュレーションの流れ

一般的には、次のような流れで行います。

① システムをモデル化
          │
          ▼
② 条件を設定
          │
          ▼
③ シミュレーション実行
          │
          ▼
④ 結果を分析
          │
          ▼
⑤ 構成を見直す

例えば、利用者数やサーバ台数を変化させ、レスポンスタイムやスループットがどのように変化するかを確認します。

13-3. シミュレーションのメリット

本番システムを変更せずに予測できる
複数の構成を比較できる
将来の利用者増加を想定できる
設備投資の判断材料になる

13-4. シミュレーションの注意点

シミュレーション結果は、モデルや入力条件に依存します。

例えば、実際の利用者の行動や処理負荷を正しくモデル化できていない場合、予測結果が実際の性能と異なる可能性があります。

そのため、実測データを利用してモデルの妥当性を確認することが重要です。

14. モニタリングとは

14-1. モニタリングの基本

**モニタリング（Monitoring）**とは、システムの稼働状況や性能を継続的に監視することです。

システムは構築して終わりではありません。

運用を開始した後も、正常に動作しているかを確認する必要があります。

例えば、

CPU使用率
メモリ使用率
ディスク使用率
ネットワーク通信量
レスポンスタイム
エラー発生数

などを監視します。

14-2. モニタリングの目的

モニタリングには、主に次の目的があります。

① 障害の早期発見

異常な状態を検知し、障害対応につなげます。

② 性能低下の発見

レスポンスタイムの悪化やCPU使用率の上昇などを把握します。

③ 将来の容量不足の予測

ストレージ使用量や利用者数の増加傾向を確認します。

④ 性能改善の効果確認

設定変更や機器増強の前後で性能を比較します。

15. ソフトウェアモニタ

15-1. ソフトウェアモニタとは

**ソフトウェアモニタ（Software Monitor）**とは、ソフトウェアを利用してシステムの稼働状況や性能を監視する仕組みです。

例えば、OSが提供する性能情報を取得する場合などです。

15-2. ソフトウェアモニタの仕組み

┌──────────────────┐
│ アプリケーション │
├──────────────────┤
│ OS               │
├──────────────────┤
│ ハードウェア     │
└────────┬─────────┘
         │
         ▼
 ソフトウェアモニタ
         │
         ▼
 CPU・メモリ・I/O情報

ソフトウェアモニタは、OSやアプリケーションから情報を取得して監視します。

15-3. ソフトウェアモニタの特徴

メリット

導入しやすい
詳細なソフトウェア情報を取得できる
ログや性能情報を分析できる

デメリット

監視ソフトウェア自体がCPUやメモリを消費する
OSが停止すると情報を取得できない場合がある
監視方法によっては測定対象へ影響を与える

15-4. ソフトウェアモニタの例

例えば、Linuxでは次のようなコマンドを利用して状態を確認できます。

コマンド	主な用途
top	CPU・メモリ・プロセスの状態確認
vmstat	CPU・メモリ・I/Oなどの統計確認
iostat	ディスクI/Oの統計確認
sar	システム性能情報の収集・表示

これらは、ソフトウェアによる性能監視の例です。

16. ハードウェアモニタ

16-1. ハードウェアモニタとは

**ハードウェアモニタ（Hardware Monitor）**とは、専用のハードウェアや測定機器などを利用して、システムの動作状況を監視する仕組みです。

ソフトウェアモニタとは異なり、測定対象のOSやアプリケーションに依存せずに情報を取得できる構成があります。

16-2. ハードウェアモニタの仕組み

┌──────────────────┐
│ コンピュータ     │
│                  │
│ CPU・メモリなど  │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│ ハードウェア     │
│ モニタ           │
└────────┬─────────┘
         │
         ▼
     測定結果

専用の測定機器などを利用して、ハードウェアの動作状況を確認します。

16-3. ハードウェアモニタの特徴

メリット

測定対象のOSに依存しない監視が可能な場合がある
ソフトウェアモニタでは取得しにくい情報を測定できる
測定対象へのソフトウェア負荷を抑えられる場合がある

デメリット

専用機器が必要になる場合がある
導入コストが高くなることがある
測定できる項目が機器によって異なる

17. ソフトウェアモニタとハードウェアモニタの違い

比較項目	ソフトウェアモニタ	ハードウェアモニタ
監視方法	ソフトウェアで情報を取得	専用ハードウェアなどで測定
導入	比較的容易	専用設備が必要な場合がある
測定対象への負荷	ソフトウェアの実行負荷が発生	負荷を抑えられる場合がある
得意な情報	OS・アプリケーションの内部状態	ハードウェアの動作状況
注意点	監視処理が性能に影響する場合がある	機器の導入・管理コスト

実際のシステムでは、目的に応じて両方を組み合わせることがあります。

18. キャパシティプランニング

18-1. キャパシティプランニングとは

**キャパシティプランニング（Capacity Planning）**とは、

将来のシステム負荷を予測し、必要な処理能力や資源を計画することです。

例えば、現在100人が利用しているシステムがあるとします。

来年には利用者が500人になる見込みです。

その場合、現在のサーバ構成で対応できるでしょうか。

このような問題を考えるのが、キャパシティプランニングです。

18-2. キャパシティプランニングの流れ

一般的には、次のような流れで進めます。

① 現在の利用状況を把握
           │
           ▼
② 将来の負荷を予測
           │
           ▼
③ 必要な性能を見積もる
           │
           ▼
④ システム構成を検討
           │
           ▼
⑤ 性能を検証
           │
           ▼
⑥ 導入・継続的な見直し

例えば、

現在の利用者数：1,000人

1年後の予測：2,000人

現在の最大スループット：200件/秒

将来必要なスループット：350件/秒

という場合、システムの処理能力を増強する必要があるかもしれません。

ただし、利用者数が2倍になったからといって、必要な処理能力も必ず2倍になるとは限りません。

利用者の行動やアクセス集中の度合いなども考慮する必要があります。

19. キャパシティ管理

19-1. キャパシティ管理とは

**キャパシティ管理（Capacity Management）**とは、システムの処理能力や資源を継続的に管理し、現在および将来の需要に対応できるようにする活動です。

キャパシティプランニングが将来の必要資源を計画する活動であるのに対し、キャパシティ管理は継続的な監視・分析・改善を含む、より広い活動です。

19-2. キャパシティ管理の対象

代表的な管理対象には、次のようなものがあります。

管理対象	主な確認項目
CPU	使用率、処理能力
メモリ	使用量、空き容量
ストレージ	使用容量、I/O性能
ネットワーク	通信量、帯域使用率
アプリケーション	応答時間、処理件数
利用状況	利用者数、アクセス数

これらの情報を継続的に確認します。

19-3. キャパシティ管理の重要性

例えば、ストレージ使用量が毎月100GBずつ増えているとします。

現在の空き容量：500GB

毎月の増加量：100GB

単純計算では、

500GB ÷ 100GB/月
= 5か月

となります。

このままの傾向が続けば、約5か月で空き容量がなくなる計算です。

ただし、実際には余裕を持って容量を確保する必要があるため、5か月後まで何もしないのは適切ではありません。

このように、現在の状態を把握し、将来の問題を予測して対策することがキャパシティ管理の役割です。

20. スケールアップ

20-1. スケールアップとは

**スケールアップ（Scale Up）**とは、既存のサーバのCPUやメモリなどを増強し、処理能力を高めることです。

例えば、

【増強前】

サーバA
CPU：4コア
メモリ：16GB

       ↓

【増強後】

サーバA
CPU：16コア
メモリ：64GB

という構成です。

サーバの台数を増やすのではなく、1台の性能を高めます。

20-2. スケールアップのメリット

サーバ台数を増やさずに性能を向上できる
システム構成を比較的シンプルに保ちやすい
アプリケーションの変更が少なくて済む場合がある

20-3. スケールアップのデメリット

ハードウェアの増強には上限がある
高性能な機器は高額になる場合がある
機器交換や増強時に停止が必要な場合がある

また、1台のサーバに依存する構成では、そのサーバの故障がシステム全体へ影響する可能性があります。

21. スケールアウト

21-1. スケールアウトとは

**スケールアウト（Scale Out）**とは、サーバの台数を増やすことで、システム全体の処理能力を高めることです。

例えば、

【増強前】

    サーバA

       ↓

【増強後】

    サーバA
    サーバB
    サーバC

という構成です。

21-2. スケールアウトの仕組み

Webシステムであれば、ロードバランサを利用して複数のサーバへ処理を振り分ける構成があります。

              利用者
                │
                ▼
         ロードバランサ
                │
       ┌────────┼────────┐
       │        │        │
       ▼        ▼        ▼
    サーバA   サーバB   サーバC

このように、処理を複数のサーバへ分散します。

21-3. スケールアウトのメリット

サーバを追加して処理能力を拡張しやすい
負荷を複数台へ分散できる
構成によっては障害の影響を軽減できる

21-4. スケールアウトのデメリット

負荷分散の仕組みが必要になる場合がある
サーバ間のデータ共有や整合性管理が必要になる
アプリケーションが分散処理に対応している必要がある場合がある

例えば、データベースのようにデータの整合性が重要なシステムでは、単純にサーバを増やすだけで性能が向上するとは限りません。

22. スケールアップとスケールアウトの違い

比較項目	スケールアップ	スケールアウト
増強方法	既存サーバを高性能化	サーバ台数を増やす
主な対象	CPU・メモリなど	サーバ・ノード
構成	比較的シンプル	分散構成が必要
拡張性	1台の上限に制約される	台数を増やして拡張できる
主な課題	ハードウェアの上限・コスト	負荷分散・データ整合性
例	CPUを4コアから16コアへ	Webサーバを1台から3台へ

🍯 はちみつ屋さんで例えると

はちみつ屋さんで、1日に100個の商品を作っているとします。

注文が増えたため、生産能力を高める必要があります。

スケールアップ

現在の作業場に高性能な機械を導入して、1日に300個作れるようにします。

スケールアウト

同じ作業場を新たに2つ増やして、3つの作業場で商品を作ります。

つまり、

スケールアップは「1台を強くする」。

スケールアウトは「台数を増やす」。

23. 性能指標とキャパシティプランニングの関係

ここまで学んだ技術は、実際のシステム運用では組み合わせて利用します。

例えば、Webシステムの性能が低下した場合を考えてみましょう。

利用者からの問い合わせ

「最近、検索が遅い」
          │
          ▼
① レスポンスタイムを確認
          │
          ▼
② CPU・メモリ・I/Oを監視
          │
          ▼
③ ボトルネックを特定
          │
          ▼
④ 将来の負荷を予測
          │
          ▼
⑤ 増強方法を検討
          │
     ┌────┴────┐
     ▼         ▼
スケールアップ  スケールアウト

例えば、CPU使用率が高く、CPU処理能力が不足している場合には、CPUの増強を検討できます。

一方、複数のWebサーバへ処理を分散できる構成であれば、サーバの追加を検討できます。

ただし、性能低下の原因がデータベースやネットワークにある場合、Webサーバだけを増強しても改善しない可能性があります。

そのため、性能指標を測定し、ボトルネックを特定したうえで対策を選ぶことが重要です。

24. 応用情報技術者試験で押さえたいポイント

今回の内容で特に重要なのは、次の違いです。

① スループットとレスポンスタイム

スループット
→ 単位時間当たりの処理量

レスポンスタイム
→ 要求から応答までの時間

② レスポンスタイムとターンアラウンドタイム

レスポンスタイム
→ 応答が返るまで

ターンアラウンドタイム
→ 処理がすべて完了するまで

③ MIPSとFLOPS

MIPS
→ 1秒間の命令実行数（100万命令単位）

FLOPS
→ 1秒間の浮動小数点演算数

④ SPECとTPC

SPEC
→ CPUなどの性能評価

TPC
→ DB・トランザクション処理の性能評価

⑤ スケールアップとスケールアウト

スケールアップ
→ 1台の性能を高める

スケールアウト
→ 台数を増やす

まとめ

この記事で覚えること

スループットは、単位時間当たりの処理量
レスポンスタイムは、要求してから応答が返るまでの時間
ターンアラウンドタイムは、処理を依頼してから完了するまでの時間
MIPSは、1秒間に実行できる命令数を100万命令単位で表す指標
FLOPSは、1秒間に実行できる浮動小数点演算数
命令ミックスは、命令の種類と出現割合を表したもの
命令ミックスベンチマークは、命令の種類や実行時間を利用してCPU性能を評価する方法
SPECは、コンピュータ性能評価のためのベンチマークを提供する団体
TPCは、トランザクション処理性能のベンチマークを策定する団体
シミュレーションは、システムの動作をモデル化して性能を予測する技法
モニタリングは、システムの稼働状況や性能を継続的に監視すること
ソフトウェアモニタは、ソフトウェアを利用して性能情報を取得する仕組み
ハードウェアモニタは、専用ハードウェアなどを利用して性能を測定する仕組み
キャパシティプランニングは、将来の負荷を予測して必要な資源を計画すること
キャパシティ管理は、システムの処理能力や資源を継続的に管理する活動
スケールアップは、既存サーバの性能を高めること
スケールアウトは、サーバの台数を増やすこと

🍯 はちみつメモ

システムの性能評価は「どれだけ処理できるか」「どれだけ速く応答できるか」を数値で確認すること！

スループットは処理量、レスポンスタイムは返事の速さ、ターンアラウンドタイムは仕事が全部終わるまでの時間と覚えよう。

CPU性能では、MIPSは命令数、FLOPSは浮動小数点演算数を表すよ。

そして、性能が不足したときは、スケールアップで1台を強くするか、スケールアウトで台数を増やすかを検討するんだ。

大切なのは、闇雲にサーバを増やすのではなく、性能を測定して原因を特定し、必要な対策を選ぶことだよ！