スケールアップとスケールアウト すけーるあっぷとすけーるあうと
簡単に言うとこんな感じ！
スケールアップは「1台のサーバーを強化する」こと、スケールアウトは「サーバーの台数を増やす」こと。クラウドではスケールアウトを前提に設計するのが基本で、「もっと大きい1台」より「普通の台数」が鉄則だよ。
スケールアップとスケールアウトとは
スケールアップ（Scale Up）とは、既存のサーバーのCPU・メモリ・ストレージなどのリソースを増強することで処理能力を高める手法です。「垂直スケーリング（Vertical Scaling）」とも呼ばれます。たとえば、EC2インスタンスをt3.microからm7i.4xlargeに変更することがこれに当たります。
スケールアウト（Scale Out）とは、同じ処理を行うサーバーの台数を増やすことで処理能力を高める手法です。「水平スケーリング（Horizontal Scaling）」とも呼ばれます。Webサーバーを1台から10台に増やすイメージです。
クラウドネイティブな設計では、スケールアウトを前提にしたステートレスアーキテクチャが推奨されます。どのインスタンスが処理してもOKな設計にしておくことで、インスタンスを何台でも並べられるようになります。
比較表
| 項目 | スケールアップ | スケールアウト |
|---|---|---|
| 別名 | 垂直スケーリング | 水平スケーリング |
| やること | 1台を強化（サイズ変更） | 台数を増やす |
| 停止の要否 | 一般的に停止が必要 | 停止不要 |
| 上限 | ハードウェアの最大スペックで頭打ち | 理論上は無制限 |
| コスト特性 | 大きいほど単価が高い傾向 | 台数×単価で線形増加 |
| 適したワークロード | DB（ステートフル）、レガシーアプリ | Webサーバー、APIサーバー |
| 設計の複雑さ | 低い | 高い（ロードバランサー必要） |
スケールアウトを実現するための設計要件
| 要件 | 内容 |
|---|---|
| ステートレス設計 | セッション情報をサーバーに持たない（外部DBやキャッシュに保存） |
| 共有ストレージ | ファイルを外部ストレージ（S3等）に保存 |
| ロードバランサー | 複数台に均等にリクエストを振り分け |
| ヘルスチェック | 異常なインスタンスを自動排除 |
歴史と背景
1990〜2000年代のオンプレミス環境では、スケールアップが主流でした。「モジュラー型のサーバーにCPUボードやメモリを追加する」ことが一般的な性能増強手段でしたが、ハードウェアの上限に達すると手詰まりになる問題がありました。
2000年代にGoogleが大量の安価なサーバーを並列で動かすことで超大規模な検索サービスを実現し、「スケールアップではなくスケールアウト」という考え方が広まりました。クラウドの登場でスケールアウトがオートスケーリングと組み合わさり、「負荷に応じて自動で台数を変える」動的なインフラが標準になっています。
スケールアップ vs スケールアウトの概念図
関連する規格・RFC
スケーリングに特定の規格はありませんが、以下の概念が関連します。
| 資料 | 内容 |
|---|---|
| The Twelve-Factor App | スケールアウト前提のアプリ設計原則 |
| CAP定理 | 分散システム設計の理論的制約 |
関連用語
- オートスケーリング — スケールアウトの自動化
- ロードバランサー — スケールアウト時の必須要素
- インスタンスタイプの選び方 — スケールアップ時のサイズ選定
- 高可用性（HA） — スケールアウトが支える可用性