Scale-upとScale-out

1. スケーリングはボトルネックから考える

ワークロードの需要が現在のキャパシティを超えると、リソース使用率上昇、処理待ち、レイテンシー悪化、タイムアウトやエラーへつながります。しかし、負荷が高いという理由だけでリソースを増やしても、制約になっているコンポーネントが別なら性能は改善しません。

ウェブ階層 CPU 25%
アプリケーション階層 CPU 40%
データベース CPU 95%
データベース接続上限付近

→ ウェブ / アプリケーションを増やしてもデータベースボトルネックは残る

最初に判断するのは「何を増やすか」ではなく「どこがシステムキャパシティを制限しているか」です。

2. スケールアップ / スケールダウンとスケールアウト / スケールイン

垂直スケーリング
小規模リソース → スケールアップ → 大規模リソース

水平スケーリング
ノード A + ノード B → スケールアウト → ノード A + B + C + D

3. 垂直スケーリング

垂直スケーリングは既存リソースそのもののキャパシティを増減する方式です。CPU不足ならvCPU、メモリ不足ならメモリ、データベースキャパシティ不足ならより大きなDBインスタンスクラスなど、単一リソースの能力を高めます。

アプリケーションを複数ノードへ分散する必要がないため、アプリケーションアーキテクチャを大きく変更せずキャパシティを増やしやすい場合があります。

特に、ローカル状態へ強く依存するレガシーアプリケーション、複数ノードへ処理を分散しにくいワークロード、ソフトウェアライセンスなどの理由でノード数を増やしにくいワークロードでは、スケールアップが現実的な選択肢になることがあります。

4. 垂直スケーリングにはキャパシティ上限がある

スケールアップは無限には続けられません。インスタンスタイプ / インスタンスクラス、CPU / メモリ、ストレージスループット、サービスクォータやサービス固有の上限など、単一リソースには上限があります。

小規模
↓
中
↓
大規模
↓
最大サイズ
↓
これ以上スケールアップできない

したがって、今スケールアップできることと、将来の需要にもスケールアップだけで対応できることは別です。

5. スケールアップ時は変更による可用性影響も確認する

リソースサイズの変更では、サービスによって再起動や停止が必要になることがあります。例えばAmazon EBSをルートボリュームに使用するAmazon EC2インスタンスでインスタンスタイプを変更する場合、インスタンスを停止する必要があります。

キャパシティ不足
+
停止不可
↓
単純なスケールアップが要件を満たすか再評価

「大きいリソースへ変更できるか」だけでなく、変更操作による可用性影響を許容できるかまで確認します。

6. 水平スケーリング

水平スケーリングは、同じ役割を持つリソース数を増減して処理を分散する方式です。

             ワークロード分散先
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
    ノード A       ノード B       ノード C

1リソースだけを大きくするのではなく、ワークロードを複数リソースへ分散することがスケールアウトの中心です。

7. スケールアウトは障害影響も変える

1つの巨大リソースへ処理が集中していると、そのリソースの障害で大きな割合のキャパシティを失います。複数の小さいリソースへ分散すれば、1ノード障害で失われる割合を小さくできます。

大規模ノード × 障害
→ キャパシティの大部分を失う

ノード A / B / C / D
ノード C × 障害
→ 残りのノードで処理を継続

ただし、複数リソースが同じ障害ドメインへ集中していれば共通障害を防げません。信頼性目的なら、複数リソース + 障害ドメインの分離まで考えます。

8. リソースを増やすだけではスケールアウトにならない

同じ役割のリソースを複数作成しても、トラフィックやジョブが1台へ集中していれば合計キャパシティは活用できません。

クライアント
  │
  ▼
ノード A ← 100% トラフィック
ノード B ← 0%
ノード C ← 0%

ウェブリクエストならロードバランシング、非同期処理ならキュー、データワークロードならパーティショニングなど、追加リソースへ実際にワークロードを分散する仕組みが必要です。

9. スケーラビリティと伸縮性

8台まで増設できても、管理者が毎回手作業で変更するだけならスケーラブルではありますが、需要に連動した自動伸縮性は実装されていません。

通常 2 インスタンス
昼   10 インスタンス
夜    2 インスタンス

需要に追従して自動増減 → 伸縮性のあるアーキテクチャ

10. 伸縮性はスケールアウトだけでなくスケールインまで考える

伸縮性では需要増加時にキャパシティを追加するだけでなく、需要減少後に不要なキャパシティを削減します。

需要増加 → キャパシティ追加
需要減少 → キャパシティ削減

ピークキャパシティを常時維持すると余剰リソースコストが発生します。一方でスケールインするリソースにローカル状態が残っているとデータやセッションを失う可能性があります。そこで状態管理が重要になります。

11. スケーリングには反応時間がある

スケーリングを要求した瞬間に新しいキャパシティが利用可能になるとは限りません。リソース起動、アプリケーション初期化、ヘルスチェック完了などに時間がかかるワークロードでは、キャパシティ不足を検出してからスケールアウトしても間に合わない場合があります。

トラフィック急増
↓
スケールアウト開始
↓
リソース起動・初期化
↓
ヘルスチェック通過
↓
キャパシティとして利用可能

急激な需要変化では、スケーリングに必要な時間 + トラフィック増加速度 + キャパシティ余裕を合わせて確認します。「最終的に何台まで増やせるか」だけでなく、必要になる前にキャパシティを利用可能にできるかが重要です。

12. ステートレスワークロード

ステートレスワークロードでは、各リクエストの処理が特定アプリケーションノード内に保存された過去の状態へ依存しません。

リクエスト 1 → ノード A
リクエスト 2 → ノード C
リクエスト 3 → ノード B

どのレプリカでも処理可能

そのためノードの追加・削除・交換を行いやすく、水平スケーリングと相性がよい設計です。

13. ステートレスは「データを持たない」という意味ではない

ステートレスとは、永続データが存在しないことではありません。重要なのは、リクエスト間で特定ノードのローカルディスクやメモリ上の状態へ依存しないことです。

アプリケーションノード
→ リクエスト処理

状態 / 永続データ
→ ノードの外で共有

状態をアプリケーションノードのライフサイクルから分離すると、任意レプリカでリクエストを処理しやすくなります。

14. ステートフルワークロード

ステートフルワークロードでは、処理継続に過去のアプリケーション / セッション状態が必要です。例えばユーザーセッションを各アプリケーションインスタンスのローカルメモリだけに保持している場合、次リクエストが別ノードへ送られると必要な状態が存在しないことがあります。

リクエスト 1 → ノード A → セッションをノード Aへ保存
リクエスト 2 → ノード B → セッションがない

ローカル状態がノード ライフサイクルへ結び付いていると、ノードの追加・削除・交換がアプリケーション状態へ影響するため、水平スケーリングの制約になります。

15. ステートフルだからスケールアウトできないわけではない

ステートフルワークロードだからスケールアップしか選べないわけではありません。アプリケーションノード内の状態を共有可能な外部状態保管先へ分離したり、データ階層でレプリケーション、読み取りスケーリング、パーティショニング / シャーディング、分散型ストレージなどワークロードに合った方式を利用できる場合があります。

アプリ A ─┐
アプリ B ─┼── 共有状態
アプリ C ─┘

重要なのは状態をどこで管理し、どの単位なら独立してスケールできるかです。

16. アプリケーションノードと状態のライフサイクルを分離する

状態をアプリケーションノードから分離すると、ノードの追加・削除だけでなく障害時のノード交換もしやすくなります。

ノード B 障害
↓
ノード Dを追加
↓
共有状態を利用

アプリケーションノードのライフサイクルとアプリケーション状態のライフサイクルを分離することが、交換可能でスケールしやすいコンピューティング階層につながります。

17. 階層ごとにスケーリング戦略を変える

アーキテクチャ全体を「スケールアップ アーキテクチャ」または「スケールアウト アーキテクチャ」のどちらか1つへ統一する必要はありません。

ステートレスアプリケーション階層
→ 水平スケーリング

ステートフルデータ階層
→ 垂直スケーリングまたはサービス固有スケーリング

コンポーネントごとに状態、整合性要件、障害影響、サービス特性を評価してスケーリング戦略を選択します。

18. ボトルネックは推測せず観測する

「CPUが高いからEC2を増やす」のように1 メトリクスだけで決めず、ワークロードに応じてCPU、メモリ、ネットワーク、ストレージ IOPS / スループット、接続数、リクエスト率、キュー深度、レイテンシー、エラー率などを確認します。

負荷テスト
↓
どのメトリクスが先に限界へ達するか
↓
レイテンシー / エラーはどこから増えるか
↓
ボトルネック特定
↓
スケーリング戦略選択

19. スケールアウトにもキャパシティ上限がある

水平スケーリングでも無制限にリソースを増やせるわけではありません。

コンピューティングをスケールアウト → サブネット IP不足
アプリケーションをスケールアウト → データベース接続上限
ワーカーをスケールアウト → 下流が飽和
リソースを増やす → サービスクォータ到達

IPアドレス、サービスクォータ、ネットワーク、下流キャパシティ、外部APIの上限など、別の制約が次のボトルネックになります。

20. スケールアップとスケールアウトの比較

21. スケーリング戦略の判断軸

22. 障害モード

スケーリングするコンポーネントを間違える

データベースがボトルネックなのにウェブ階層だけをスケールアウトすると、データベース負荷がさらに増えることがあります。

ステートフルアプリケーションを無条件にスケールアウトする

ローカルセッションを持つノードを無条件に増減すると、セッション損失やルーティング制約につながります。

スケールアップだけに依存する

短期的には簡単でも、最大リソースサイズへ到達すると次のスケーリング選択肢がなくなります。

スケールアウトなら無制限と思う

IP、クォータ、ネットワーク、データベースなど下流側が新しいボトルネックになります。

複数ノードを同じ障害ドメインへ集中させる

単一ノード障害には強くても、共通障害ドメインを失うとまとめて影響を受けます。

23. 混同ポイント

24. SAP-C02判断フロー

キャパシティ / パフォーマンス要件
            │
            ▼
      ボトルネックはどこ？
            │
            ▼
   対象コンポーネントは分散可能？
      ┌─────┴─────┐
     いいえ      はい
      │             │
      ▼             ▼
スケールアップ評価状態は？
              ┌────┴────┐
          ローカル状態ステートレス / 状態分離可能
              │             │
              ▼             ▼
       状態管理再設計スケールアウト評価
              │             │
              └────┬────────┘
                   ▼
           需要は変動する？
                   │
                   ▼
       伸縮性 / スケーリング遅延
       / 余裕を評価
                   │
                   ▼
      クォータ / ネットワーク / 下流
      / 障害ドメインを確認
                   │
                   ▼
          スケーリング戦略決定

スケールアップとスケールアウトから始めるのではなく、ボトルネック → 状態 → ディストリビューション → 需要 → 障害影響 → 制約の順で判断します。

25. まとめ

スケールアップ   → 1リソースを大きくする
スケールダウン → 1リソースを小さくする
スケールアウト  → リソース数を増やす
スケールイン   → リソース数を減らす

ステートレスワークロードは任意レプリカで処理しやすく水平スケーリングと相性がよい一方、ステートフルワークロードではローカル状態がスケーリング制約になり得ます。

伸縮性では需要に合わせた自動的なキャパシティ増減に加え、スケーリング遅延と余裕も確認します。

最適アーキテクチャは各コンポーネントの状態・ボトルネック・障害影響・需要特性から選択します。

26. 主要AWS公式資料

• AWS Certified Solutions Architect - Professional (SAP-C02) — ドメイン 1 / タスク 1.3
• AWS Well-Architected 信頼性の柱 — 設計原則
• AWS Well-Architected — 可能な場合はシステムをステートレスにする
• AWS Well-Architected — 追加リソースが必要と判断したらリソースを取得する
• Amazon EC2 ユーザーガイド — インスタンスタイプの変更