性能 vs スケーラビリティ
Performance vs Scalability
「速さ」(性能)と「混んでも捌けること」(スケーラビリティ)は別問題。リソースを足した分だけ性能が伸びるなら、そのシステムはスケーラブルだと言える。
たとえ話で理解する
ラーメン屋を想像してください。
- 性能(Performance)問題: お客さんが1人しかいないのに、1杯作るのに30分かかる。これは『調理が遅い』という根本的な問題です。店が空いていても遅い。
- スケーラビリティ(Scalability)問題: 1人なら5分で出せるのに、行列ができると待ち時間が1時間になる。これは『混雑を捌けない』問題です。
この2つはまったく別の話で、対策も違います。調理が遅いならレシピや手順を見直す(=チューニング)。混雑を捌けないなら店員や調理台を増やす(=リソース追加)。混雑問題に対して『1杯を速く作る練習』をしても根本解決にはなりません。
スケーラブルとは何か
リソースを追加した分に比例して性能が向上するなら、そのサービスはスケーラブルである。
つまり「サーバーを2倍にしたら、捌けるリクエストも約2倍になる」のが理想。ここが崩れる(サーバーを足しても頭打ち)と、どこかにボトルネックがあるサインです。
図を描画中...
つまずきポイント
- 「性能が良い = スケーラブル」ではない。1人には爆速でも、混雑時に崩壊するシステムは珍しくない。
- 逆に、1リクエストはそこそこ遅くても、台数を増やせば全体のスループットを上げられる設計はスケーラブル。
- 性能向上には2つの意味がある: ①より多くの作業を捌く(同じ仕事を高速に) ②より大きな作業を扱う(データ量が増えても破綻しない)。
📊 図解
図解: 性能とスケーラビリティの4象限
「1人で使ったときの速さ(横軸)」と「混雑したときの捌け方(縦軸)」は別の軸。右上=理想、左下=要改善。性能が良くてもスケールしないこと(右下)がある点に注意。
図を描画中...