オンプレのサーバー増強といえば、まずCPUやメモリを増やすことを考えるのが普通でした。でも、クラウドに移行すると「スケールアウト」という言葉が頻繁に登場して、「スケールアップと何が違うんだろう」と戸惑った経験はありませんか。
この記事では、スケールアップとスケールアウトの違いを、オンプレ経験者にもわかりやすく解説します。AWSでの具体的なサービス例、コスト感覚、実務での使い分けポイントまで網羅しています。
オンプレとクラウドで「拡張」の考え方が変わった理由
オンプレ環境での拡張は、基本的に「物理サーバーのスペックアップ」が中心でした。CPUのコア数を増やす、メモリを追加する、ストレージを増設する。いわゆる「スケールアップ」が主流で、設備投資に時間もコストもかかるため、事前に十分な余裕を持たせた設計が求められていました。
クラウドに移行すると、状況が一変します。
・仮想マシンのスペック変更がオンラインで可能: 停止せずにスペックを変更できるケースもあります
・サーバーを横に並べる（スケールアウト）が現実的なコストで実現: 1台の高性能サーバーの代わりに、安価なインスタンスを複数起動できます
・需要に合わせて動的にサーバー数を変える（オートスケーリング）: ピーク時だけ台数を増やし、コストを抑えられます
この「拡張の自由度の高さ」がクラウドの本質的な価値の一つです。スケールアップとスケールアウトの違いを理解することは、クラウド設計の基礎中の基礎です。
スケールアップとは？
スケールアップ（Vertical Scaling）とは、既存のサーバー1台のスペックを引き上げる拡張方法です。
1. 具体的なイメージ
オンプレで例えると「4コア・8GBのサーバーを8コア・32GBに交換する」ような操作です。
AWSでは、Amazon EC2のインスタンスタイプを変更することがスケールアップに相当します。
# AWS CLI: EC2インスタンスのタイプ変更（スケールアップ） # ※インスタンスを停止してから実行する # 1. インスタンスを停止 aws ec2 stop-instances --instance-ids i-0abcdef1234567890 # 2. インスタンスタイプを変更（例: t3.medium → t3.xlarge） aws ec2 modify-instance-attribute \ --instance-id i-0abcdef1234567890 \ --instance-type '{"Value": "t3.xlarge"}' # 3. インスタンスを起動 aws ec2 start-instances --instance-ids i-0abcdef1234567890
2. スケールアップの特徴
・シンプルなアーキテクチャ: サーバー1台で動くため、分散処理の複雑さがありません
・アプリケーション変更不要: 既存のシングルスレッドアプリでもそのまま性能向上できます
・停止が必要な場合が多い: EC2はインスタンスタイプ変更のためにいったん停止が必要です
・スペックに上限がある: いくらスケールアップしても物理的な上限があります
・コストが非線形に増加しやすい: ハイスペックインスタンスはコスト単価が高くなります
3. AWSでスケールアップが適するケース
・Amazon RDS（データベース）: データベースはシャーディングなどの対応が複雑なため、まずスケールアップで対応することが多いです
・シングルスレッドの処理: 並列化が難しい処理を高速化したい場合
・移行初期のリフトアンドシフト: オンプレアプリをそのままクラウドへ移行した直後は、スケールアップで性能を確保するケースが多いです
スケールアウトとは？
スケールアウト（Horizontal Scaling）とは、サーバーの台数を増やして処理能力を拡張する方法です。
1. 具体的なイメージ
同一スペックのWebサーバーを1台から3台に増やし、ロードバランサーで負荷を分散する、というのが典型的なパターンです。
AWSでは、Auto Scaling GroupとApplication Load Balancerを組み合わせるのが基本構成です。
# AWS CLI: Auto Scaling Groupの最小・最大・希望台数を変更（スケールアウト） # ※Auto Scaling Groupが事前に作成されていることが前提 # Auto Scaling Groupの台数を更新（例: 最小1台 → 希望3台 → 最大5台） aws autoscaling update-auto-scaling-group \ --auto-scaling-group-name my-web-asg \ --min-size 1 \ --desired-capacity 3 \ --max-size 5
2. スケールアウトの特徴
・無停止で台数を増減できる: 既存サーバーを止めずにインスタンスを追加・削除できます
・理論上はほぼ無限にスケール可能: 台数を増やし続けることで、大きなトラフィックに対応できます
・高可用性の設計と親和性が高い: マルチAZ構成と組み合わせると耐障害性も向上します
・アプリケーションの設計が重要: ステートレスな設計（セッション情報をサーバーに持たせない）が前提になります
・ロードバランサーが必要: 複数台に負荷を振り分けるための仕組みが必要です
3. AWSでスケールアウトが適するケース
・Webアプリケーション層: ステートレスに設計されたWebサーバーやAPIサーバー
・マイクロサービス・コンテナ: Amazon ECSやAWS Fargateによるコンテナの台数スケール
・サーバーレス: AWS Lambdaは自動でスケールアウトするため、スケールアウト設計の究極形とも言えます
スケールアップ vs スケールアウト 徹底比較
| 比較軸 | スケールアップ | スケールアウト |
|---|---|---|
| 拡張の方向 | 縦（スペック向上） | 横（台数増加） |
| 停止の要否 | 原則必要（EC2の場合） | 不要 |
| スケール上限 | インスタンスタイプの上限あり | 実質的に上限なし |
| アプリ設計への影響 | ほぼ不要 | ステートレス設計が必要 |
| コスト効率 | 高スペックほど単価が上がる | 小さいインスタンス×複数台でコストを抑えやすい |
| AWSの典型例 | EC2インスタンスタイプ変更、RDSのインスタンス変更 | Auto Scaling Group + ALB、ECS/Fargate、Lambda |
| 向いているワークロード | DBサーバー、シングルスレッド処理 | Webサーバー、APIサーバー、マイクロサービス |
料金の仕組みとコスト感覚
スケールアップとスケールアウトではコスト構造が異なります。2026年3月時点の東京リージョン（ap-northeast-1）のEC2料金を参考に説明します。
1. スケールアップ時のコスト例
例えば、t3.medium（2vCPU・4GiB）からt3.xlarge（4vCPU・16GiB）へスケールアップすると、料金はおよそ2.5〜3倍程度に跳ね上がります（2026年3月時点のオンデマンド料金参考）。スペックが高いほど割高になる傾向があります。
2. スケールアウト時のコスト例
t3.medium 3台でスケールアウトすると、t3.xlarge 1台より性能面で余裕を持たせながら、コストをほぼ同等かやや抑えられます。さらに、Auto Scalingにより需要が減った夜間はインスタンスを減らせるため、トータルのコスト効率が高くなりやすいです。
3. コスト最適化のポイント
・スケールアウトは変動費化しやすい: ピーク時だけ台数を増やし、閑散時は最小台数に戻せます
・スケールアップはベースコストが固定される: スケールアップしたインスタンスを停止しない限りコストが発生し続けます
・DBはスケールアップが基本: Amazon RDSのスケールアップはメンテナンスウィンドウで計画的に行い、RDSマルチAZやAurora Serverlessで補完する設計が現実的です
実務での使い分けポイント
現場で迷ったときの判断基準をまとめます。
1. まずスケールアップを検討するケース
・既存アプリを修正せずに対応したい: スケールアウトにはアプリ改修が伴う場合があります
・データベース層のボトルネック解消: DBのスケールアウトは設計コストが高いため、まずスケールアップで対応します
・検証・開発環境の一時的な強化: 短期間だけ高スペックが必要な場合は、インスタンスタイプ変更の方がシンプルです
2. スケールアウトを選ぶケース
・Webサーバー・APIサーバーのトラフィック増加: ステートレスに設計されていれば、Auto Scalingで自動対応できます
・無停止でのスケールが必要: サービス停止を避けたい本番環境では、スケールアウトが有利です
・ピーク時間が予測できる: 定時バッチやキャンペーン時間帯など、需要の波が読めるならScheduled Scalingも活用できます
3. 組み合わせて使う（スケールアップ + スケールアウト）
実際の現場では、両者を組み合わせるのが最も多いパターンです。
例えば、Web/App層はスケールアウト、DB層はスケールアップという構成が典型的です。EC2 Auto Scaling GroupとApplication Load Balancerでフロント側を柔軟にスケールしながら、バックエンドのAmazon RDSはインスタンスタイプを段階的にアップしていきます。
インフラ設計の全体像については、姉妹サイトLinuxMaster.JPでサーバー構築の基礎も解説しています。
よくあるトラブルと対処法
1. スケールアウト後にセッション情報が失われる
原因: サーバーのメモリにセッションを持つ設計のまま、複数台構成にした場合、別のサーバーにリクエストが届くとセッションが切れます。
対処法: セッション情報をAmazon ElastiCache（Redis）やAmazon DynamoDBに外出しする「ステートレス設計」に変更します。Application Load Balancerのスティッキーセッション機能を一時的に使う方法もありますが、スケールアウトの恩恵を薄める設計なので注意が必要です。
2. RDSのスケールアップ後に接続エラーが発生した
原因: RDSのインスタンスタイプ変更は再起動を伴うため、その間の数分間、接続できなくなります。
対処法: マルチAZ構成にしておくと、フェイルオーバーにより停止時間を数十秒程度に短縮できます。変更はメンテナンスウィンドウ（低トラフィックな時間帯）に合わせて実施するのが基本です。
3. Auto Scalingで台数が増えたが、デプロイが追いつかない
原因: スケールアウトで新しいインスタンスが起動した際、アプリケーションの最新バージョンがデプロイされていないケースがあります。
対処法: AMI（Amazon Machine Image）に最新のアプリケーションを組み込む「ベイクドAMI」方式か、起動時にコードを自動デプロイする「user data スクリプト」方式のいずれかを整備します。AWS CodeDeployとAuto Scalingの組み合わせが現場では一般的です。
本記事のまとめ
スケールアップとスケールアウトの違いを整理します。
| ケース | 推奨する拡張方法 | AWSの主なサービス・手順 |
|---|---|---|
| DBサーバーのボトルネック解消 | スケールアップ | Amazon RDSのインスタンスタイプ変更 |
| Webサーバーのトラフィック増加 | スケールアウト | Auto Scaling Group + Application Load Balancer |
| アプリ修正なしで即時対応 | スケールアップ | EC2インスタンスタイプ変更 |
| 無停止・コスト効率重視 | スケールアウト | Auto Scaling + ECS/Fargate |
| 需要の波が大きいシステム全体 | 組み合わせ | Web/App層スケールアウト + DB層スケールアップ |
オンプレではサーバー増強=スケールアップが当たり前でしたが、クラウドではスケールアウトを前提にした設計が、コストと可用性の両面で優れています。アプリケーション層から段階的にスケールアウト対応を進めながら、データベース層はスケールアップを中心にしつつAurora Serverlessへの移行も視野に入れると、クラウドの恩恵を最大限に引き出せます。
スケールアウト設計、自分の現場でも使えるか迷っていませんか？
「オンプレのアプリをそのまま持ってきたけど、クラウドらしい設計に直していきたい」という方へ。
オンプレの経験を活かしながら、現場で使えるクラウドスキルを体系的に身につけたい方へ、メルマガで実践的なクラウド活用ノウハウをお届けしています。
コメント