スケーリング戦略

導入

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

説明

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

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サーバー自体は状態を持たない ステートレス な存在にでき、どのインスタンスが処理しても結果が変わらない、自由にスケールアウトできる構成になります。

具体例

急成長したSNSが、垂直スケールの限界にぶつかった話です。当初はアクセス増のたびにEC2を1つ上のサイズへ載せ替えて（垂直スケール）しのいでいましたが、①最大サイズには上限があり、②載せ替えのたびに停止が発生。ついに頭打ちになりました。

そこで水平スケールへ方針転換——EC2を複数台に増やしAuto Scalingで自動増減。ところが、切り替えた途端に「ログインしたのにすぐログアウトする」不具合が発生しました。

原因はステートフル設計。各EC2がセッション情報を自分のメモリに持っていたため、ロードバランサーが次のリクエストを別のEC2へ振ると、そのサーバーはユーザーを知らずログイン切れに見えたのです。これでは特定サーバーへの固定が必要で、自由にスケールできません。

解決はセッションの外部化。セッションをElastiCache（Redis）に外出しし、どのEC2も同じ場所を見るようにしました。これでWebサーバーは状態を持たないステートレスになり、何台にでも自由にスケールアウトできます。「トラフィック急増に耐える＝水平スケール＋Auto Scaling、その前提＝セッションを外部ストアに出してステートレス化」がSAAの定番解です。

読んでみよう

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