なぜ速いサーバーを買っても遅くなるのか（応用情報視点）

性能改善というと、
「サーバーを速くすれば解決する」という発想に
なりがちです。

応用情報技術者試験では、
この発想が必ずしも正しくないことを
前提として問題が作られます。

この回では、
なぜ速いサーバーを買っても遅くなることがあるのかを、
応用情報視点で整理します。

サーバー性能が効く場面

CPUやメモリの性能向上は、

• 計算量が多い処理
• メモリ不足が原因の処理

では、確かに効果があります。

応用情報でも、
ボトルネックがどこにあるかを
見極める視点が前提になります。

効かない場面が多い理由

一方で、処理が遅い原因が

• I/O待ち
• ネットワーク遅延
• ロック競合
• 外部サービス待ち

にある場合、
CPUを速くしても体感はほとんど変わりません。

応用情報では、
この「待ち時間」に注目できるかが重要です。

応用情報での典型的な出題意図

午後問題では、

• CPU使用率は低い
• しかしレスポンスが遅い

といった条件が提示されます。

ここで、
ハードウェア増強を選ぶと、
誤答になる構造です。

本当に見るべきなのは、
どこで処理が止まっているかです。

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

速いサーバーを買うという判断は、
スケールアップにあたります。

しかし、

• 同時処理数が多い
• 待ちが支配的

な場合は、
スケールアウト（台数を増やす）の方が
効果的なこともあります。

応用情報では、
この選択理由を説明できるかが問われます。

実務での考え方

実務では、

• CPU使用率
• 待ち時間
• 処理の流れ

を観測し、
どこに手を入れるべきかを判断します。

応用情報は、
その判断を感覚ではなく、
構造として考える訓練です。

まとめ

• 速いサーバーは万能ではない
• 待ち時間が性能を支配することが多い
• 応用情報はボトルネック思考を問う

性能問題では、
「何を速くしたいのか」
ではなく、
「何が遅くしているのか」
を先に考えることが重要です。

次回予告

次回は、
「バッチ処理とオンライン処理の思想差」
を扱います。

処理方式の締めに入ります。