スケーリング戦略｜AWS SAA（ソリューションアーキテクト）学習コース BecomeCoder

導入

アクセスが急増したとき、あなたのシステムはどう対応しますか。「もっと強いサーバーに入れ替える」のか、「同じサーバーを何台も並べる」のか。この2つの方向性の違いが、SAAの性能設計の出発点です。

説明

スケーリングには2つの方向があります。

方式	内容	限界
垂直スケール（スケールアップ）	1台のインスタンスのスペック（CPU/メモリ）を上げる	ハードウェアの上限があり、切り替え時に停止が必要になりやすい
水平スケール（スケールアウト）	同じ役割のインスタンスの台数を増やす	理論上ほぼ無制限、ダウンタイムなしで拡張できる

flowchart LR
    subgraph 垂直スケール
      S1["小さいサーバー"] --> S2["大きいサーバー"]
    end
    subgraph 水平スケール
      H1["サーバー"] --> H2["サーバー×N台"]
    end

クラウドの可用性・拡張性を最大限に活かすには、基本的に 水平スケール を選びます。Auto Scalingと組み合わせれば、需要に応じて台数を自動で増減でき、レッスン44の高可用性構成ともそのまま両立します。

ただし水平スケールを実現するには、前提条件があります。それが ステートレス設計 です。もしWebサーバーが「どのユーザーがどのサーバーにログインしたか」という セッション情報 を自分のメモリ上に持っていたら（ステートフル）、そのユーザーの2回目以降のリクエストは必ず同じサーバーに届かなければならず、自由に台数を増減できません。

flowchart TD
    A["ステートフル: セッションをサーバー内に保持"] -->|"問題"| B["特定サーバーへの固定が必要<br/>→ 水平スケールしにくい"]
    C["ステートレス: セッションを外部化"] -->|"解決"| D["どのサーバーが応答してもよい<br/>→ 自由に水平スケール可能"]

セッション情報などの「状態」をサーバーの外（ElastiCache や DynamoDB）に持たせることで、Webサーバー自体は状態を持たない ステートレス な存在にでき、どのインスタンスが処理しても結果が変わらない、自由にスケールアウトできる構成になります。

読んでみよう

「トラフィックの急増に耐えたい」「ダウンタイムなく拡張したい」と出たら水平スケール＋Auto Scalingが基本解です。選択肢に「セッションをローカルディスク/メモリに保存」とあれば、それはスケールアウトを妨げる設計なので要注意。「セッションを外部ストア（ElastiCache/DynamoDB）に持たせる」がステートレス化の定番の答えです。