【比較】水平スケールと垂直スケールの違い¶

概要¶

システムの処理能力を増やす方法は大きく 2 つあります。水平スケール（スケールアウト / scale out）はインスタンス（ノード）の台数を増やすこと、垂直スケール（スケールアップ / scale up）は 1 台のリソース（CPU・メモリ等）を増強することです。どちらも「能力を上げる」点が同じなので混同されますが、増やす対象（台数 vs サイズ）が違い、その結果として可用性・上限・ダウンタイム・コストの性質が大きく変わります。

Microsoft の Azure Well-Architected Framework は、水平スケールを「あるリソース種のインスタンスを追加するアプローチ」、垂直スケールを「既存リソースに計算能力を追加するアプローチ」と定義しています。AWS の Well-Architected Framework は設計原則として「水平にスケールしてワークロード全体の可用性を高める：1 つの大きなリソースを複数の小さなリソースに置き換え、単一障害がワークロード全体に与える影響を減らす」と挙げています。両者は二者択一ではなく、組み合わせて使うのが実務の基本です。

例えるなら：レジ係を増やすか、ベテラン 1 人に替えるか¶

水平スケール … 混雑したスーパーで「レジを 1 台 → 5 台」に増やす。多少の故障が出ても他のレジで捌け、上限も伸ばしやすい。ただし整理員（ロードバランサ）と、どのレジでも同じ会計ができる仕組み（ステートレス）が要る。
垂直スケール … レジ 1 台のまま「スキャンの速いベテラン店員」に交代する。仕組みはシンプルだが、人間の速度に限界（ハード上限）があり、交代の間はそのレジが止まる（ダウンタイム）。

詳細比較¶

比較軸	水平スケール（スケールアウト）	垂直スケール（スケールアップ）
増やす対象	インスタンス／ノードの台数	1 台あたりの CPU・メモリ・I/O などのサイズ
上限	実質的に伸ばしやすい（台数を足し続けられる）	ハードウェア／インスタンスタイプの上限で頭打ち
ダウンタイム	原則不要（稼働中に台数を増減できる）	多くの場合インスタンス再起動・再デプロイで発生しうる
可用性・耐障害性	高い（1 台故障しても他で継続、単一障害点を分散）	低い（その 1 台が単一障害点になりやすい）
アプリ側の要件	ステートレス設計＋ロードバランサがほぼ必須	原則不要（コード変更なしで増強できることが多い）
運用の複雑さ	高い（分散・整合性・LB・ヘルスチェック）	低い（構成がシンプルなまま）
コスト特性	必要量に応じて細かく増減しやすい（Auto Scaling と相性良）	大型インスタンスは割高になりがち、増減の粒度が粗い
適性	Web/API 層、ステートレスなワーカー	リファクタ困難な単一 RDB、共有メモリ前提の処理

よくある誤解¶

誤解1：「水平スケールと垂直スケールはどちらか一方を選ぶもの」 — 排他ではありません。実務では Web 層は水平スケール、DB は当面垂直スケールで凌ぎつつ将来シャーディングへ、という併用が一般的です。Azure WAF も「これらの戦略を組み合わせて設計することを検討せよ」と述べています。
誤解2：「インスタンスを増やせば（水平スケールすれば）どんな性能問題も解決する」 — 解決しません。Azure WAF は「スケールアウトはすべての性能問題を直さない。バックエンド DB がボトルネックなら Web サーバを増やしても無意味」と明言しています。ボトルネック（多くは状態を持つ部分）を先に特定・解消する必要があります。
誤解3：「垂直スケールはダウンタイムなしでいつでもできる」 — 多くの場合できません。Azure WAF は「自動の垂直スケールは追加の独自自動化が必要で、対象リソースによってはダウンタイムを引き起こしうる」としています。インスタンスタイプ変更には再起動・再デプロイを伴うのが一般的です。
誤解4：「水平スケールはアプリを変えずに台数を増やすだけ」 — 設計要件があります。Azure WAF は「システムは水平スケール可能に設計せよ。インスタンスアフィニティを仮定するな。実用的な範囲でステートレスに設計せよ」としています。セッションをローカル保持するアプリは、まずステートレス化が必要です。

実務での選び分け¶

まず垂直スケールで時間を稼ぐ：トラフィック増の初期や、ステートレス化が間に合わない既存システムは、インスタンスタイプを一段上げる垂直スケールが最短。設計変更不要で即効性がある。
恒常的な負荷・高可用性が要る → 水平スケール：単一障害点を避け、Auto Scaling で需要に追従させたい層（Web/API）はステートレス化＋ロードバランサで水平に。
状態を持つコンポーネント（RDB など）：すぐ水平にできないため当面は垂直スケール、将来的にリードレプリカ／シャーディング／パーティショニングで水平化を計画する。
コスト最適化の軸：水平スケールは「必要なときだけ台数を増やして使い終わったら減らす（早めにスケールイン）」がコスト効率の鍵。大型インスタンス常時起動の垂直スケールは割高になりやすい。
判断の軸：①ハード上限に当たるか ②ダウンタイムを許せるか ③ステートレス化できるか。①②が厳しく③が可能なら水平、③が困難で当面の即効性が要るなら垂直。

ひとことまとめ¶

水平スケールは「台数を増やして上限を伸ばし可用性を上げる（要ステートレス＋LB）」、垂直スケールは「1 台を増強する（シンプルだが上限とダウンタイムあり）」。二者択一ではなく、ステートレスな層は水平、状態を持つ層は当面垂直、と組み合わせるのが定石です。

出典・参考¶

Microsoft Azure Well-Architected Framework「Architecture strategies for designing a reliable scaling strategy」（垂直＝既存リソースに計算能力を追加 / 水平＝同種リソースのインスタンスを追加。ステートレス設計の必要、自動垂直スケールはダウンタイムを起こしうる、スケールアウトはボトルネックを直さない、戦略の組み合わせ）: https://learn.microsoft.com/en-us/azure/well-architected/reliability/scaling
AWS Well-Architected Framework「Design principles」（設計原則 "Scale horizontally to increase aggregate workload availability"：1 つの大きなリソースを複数の小さなリソースに置き換え、リクエストを分散して共通の単一障害点を持たせない）: https://docs.aws.amazon.com/wellarchitected/latest/framework/rel-dp.html