利用者が10人のときに作ったサーバー構成が、10万人になっても同じように動くとは限りません。どんなシステムも、使う人が少ないうちは問題なく動きます。問われるのは増えたときです。
スケーラビリティは、利用者、データ、処理量が増えたときに、システムの性能や容量を広げていける性質です。普段は20席で足りる飲食店でも、繁忙期には席が足りなくなります。テーブルを足せる余地がある店は需要に合わせられますが、間取りが固定されていて増やせない店は、混雑したところで限界が来ます。システムでも、増加に合わせてサーバーを足したり、クラウドの資源を増やしたりできる設計になっているかが問われます。
部屋を広げるか、テーブルを増やすか
広げ方には、大きく分けて2種類あります。
| 垂直スケーリング（スケールアップ） | 水平スケーリング（スケールアウト） | |
|---|---|---|
| やること | 1台のサーバーの CPU やメモリを強化する | サーバーの台数を増やして処理を分ける |
| 店でいうと | 引っ越さずに部屋をリフォームして広げる | テーブルを増やす |
| 得意なこと | 設定の変更が簡単 | 台数を足していけるので、大きく伸ばしやすい |
| 気をつけること | 1台で強化できる量には限界がある | 複数台をまとめる仕組みと、複数台で動かせる作りが要る |
水平スケーリングでは、振り分け役のロードバランサーが欠かせません。そして、ログイン状態をどのサーバーでも引き継げるか、データをどう共有するかといった、アプリ側の作りが前提になります。クラウドサーバーには、負荷に応じてサーバーを自動で増減させる「オートスケーリング」機能を持つものもあります。
最初から大きく作らない
スケーラビリティは、常に最大の規模で備えておくことではありません。必要になったときに必要な分だけ広げられる余地と仕組みを持っておくことです。最初から過剰に大きな構成にすると、コストが無駄にかさみ、仕組みも複雑になります。
広げるときも、全体を一律に大きくするとは限りません。処理が詰まっている箇所（ボトルネック）を特定し、そこを重点的に広げます。特定の処理だけが重いなら、その部分だけを切り出して拡張する方法もあります。キャンペーンや年末のようにアクセスが集中する時期が分かっているなら、その期間だけ資源を増やすのも一つの手です。
広げられないシステムは、負荷が急に増えたときに落ちやすく、稼働率にも響いてきます。