AWSでアプリケーションを本番運用していると、必ず突き当たるのが「アクセス増加にどう対応するか」という問題です。EC2（Elastic Compute Cloud、AWSの仮想サーバーサービス）を使っている場合、対応方法は大きく2つに分かれます。サーバーの台数を増やす方法と、サーバー自体を大きくする方法です。
この記事は、EC2でアプリケーションやDB（データベース）を運用しているエンジニア・SREの方に向けて書いています。ELB（Elastic Load Balancing、AWSの負荷分散サービス）とAuto Scaling（負荷に応じてインスタンス数を自動調整する仕組み）のどちらを、どんな場面で選ぶべきかを整理しました。判断に迷ったときの参考になれば幸いです。
どんな場面でこの判断が必要になるか
EC2でサービスを動かしていると、トラフィックは一定ではありません。
昼夜で変動したり、キャンペーンで急増したりします。
このとき選択肢は2つです。
1つは「インスタンスの台数」を増減させる方法。
もう1つは「インスタンスのスペック」を大きくする方法です。
どちらを選ぶかで、コスト構造も障害耐性も変わります。
選び方を間違えると、コストが余分にかかったり、逆に落ちやすい構成になったりします。
判断軸1: 変化が短期的か恒常的か
まず確認すべきは、負荷の増加が「一時的なスパイク」か「継続的な成長」かです。
セールやキャンペーンによる数時間〜数日の急増であれば、Auto Scalingによる水平スケーリング（インスタンスの台数を増減させること。scale outは追加、scale inは削減と呼びます）が向いています。
負荷が下がればインスタンスを減らせるので、支払いは使った分だけで済みます。
一方、データ量やユーザー数がじわじわ増え続けているなら、話は別です。
たとえばDBサーバーで、データが100個のデータベースにまたがり10TBに迫っているような状況です。
この場合はインスタンスタイプ（CPU・メモリ・ネットワーク性能の組み合わせ。t3.microやm5.largeなど）自体を大きくする垂直スケーリング（scale upやscale downと呼ばれます）で対応します。
Auto Scalingは「短期的な反応」であり、恒常的なキャパシティ変更ではないという整理は、AWSの設計思想を理解するうえで基本になります。
判断軸2: アプリケーションが状態を持つか
水平スケーリングを選ぶなら、アプリケーションが「ステートレス」（インスタンスごとにセッション状態を持たない設計）かどうかを確認する必要があります。
Auto Scalingグループの前段にELBを置く構成では、リクエストがどのインスタンスに振られるか分かりません。
セッション情報をインスタンスのローカルメモリに保持していると、ユーザーが別インスタンスに振られた瞬間にログイン状態が消えるといった不具合が起きます。
対策としては、セッションをRedisやDynamoDBなど外部ストアに持たせる設計に変えることが一般的です。
この設計変更なしにAuto Scalingを導入すると、台数を増やすほど不具合が増えるという逆効果になりかねません。
DBサーバーのように単一インスタンスで状態を持つことが前提の構成では、そもそも水平スケーリングと相性が悪く、垂直スケーリングを軸に考えることになります。
判断軸3: 単一障害点を許容できるか
垂直スケーリングには見落とされがちな弱点があります。
インスタンスを1台大きくするだけの構成は、そのインスタンスが単一障害点（SPOF）になる点です。
どれだけスペックを上げても、そのインスタンスが落ちればサービス全体が止まります。
ELBを使った水平スケーリングであれば、1台が不調になっても他のインスタンスが処理を引き継げます。
可用性（サービスが継続して使える状態を保てるかどうか）を重視する本番のWebアプリケーション層では、垂直スケーリングだけに頼る構成は避けたほうが安全です。
判断軸4: コスト構造をどう管理したいか
最後の軸はコストです。
垂直スケーリングは大きいインスタンスタイプに切り替えるだけなので、構成としてはシンプルです。
ただし、そのインスタンスは常に大きいサイズの料金がかかり続けます。
水平スケーリングは、Auto Scalingのポリシー設定（CPU使用率やリクエスト数などのしきい値に応じて台数を調整するルール）次第で、閑散期には最小構成まで縮小できます。
構成管理の手間は増えますが、コストの弾力性は高くなります。
| 観点 | 水平スケーリング (Auto Scaling) | 垂直スケーリング (インスタンスタイプ変更) |
|---|---|---|
| 向いている負荷変化 | 短期的なトラフィックスパイク | 継続的なデータ・処理量の増加 |
| 前提条件 | ステートレスなアプリ設計 | 単一インスタンスでの状態保持でも可 |
| 単一障害点 | 回避しやすい (ELB併用) | 残りやすい |
| コスト特性 | 需要に応じて弾力的 | 常時そのスペック分の固定費 |
ケース別の推奨
次のように整理すると、自分のケースに当てはめやすくなります。
- ステートレスなWebアプリで、日中と深夜のアクセス差が大きいなら、ELB + Auto Scalingを軸にする
- キャンペーンやセールで数時間だけ跳ねるトラフィックがあるなら、Auto Scalingのスケーリングポリシーで対応する
- DBサーバーでデータ量が増え続けており、クエリが遅くなってきたなら、まずインスタンスタイプの引き上げ（垂直スケーリング）を検討する
- 単一のバッチ処理サーバーで処理時間短縮が目的なら、台数を増やすより大きいインスタンスタイプに変える方が構成がシンプルになる
あえて見送るべき条件
すべてのケースでAuto Scalingが正解というわけではありません。
セッション管理を外部化する改修コストが見合わないほど小規模なシステムであれば、無理に水平スケーリング構成にする必要はありません。
インスタンスタイプを1段階上げるだけで十分な余裕が生まれるなら、まずはそちらを試すほうが手軽です。
逆に、垂直スケーリングだけで乗り切ろうとするのも危険です。
インスタンスタイプにはAWSが用意する上限があり、際限なく大きくできるわけではありません。
いずれ天井にぶつかることを見越して、早い段階からステートレス化を進めておく判断も選択肢に入ります。
またAuto Scalingを導入する前提として、AMI（Amazon Machine Image、OSと必要なソフトウェアをまとめた起動テンプレート）を事前に作り込んでおく必要があります。
カスタムAMIが整備されていないと、新しいインスタンスの起動が遅れたり、設定漏れが起きたりします。
AWSマネジメントコンソールの「AMI」画面で、現在の構成が最新のAMIとして保存されているかを確認しておくと安心です。
まとめ
EC2のスケーリング判断は、次の4つの軸で整理できます。
- 負荷変化が短期的か恒常的か
- アプリケーションがステートレスかどうか
- 単一障害点を許容できるか
- コストを固定費で持つか弾力的に持つか
まずはAWSコンソールで、現在のEC2インスタンスがAuto Scalingグループに属しているか、単体で動いているかを確認するところから始めてみてください。
単体運用であれば、ELBの配下に置く構成変更が最初の一歩になります。
すでにAuto Scalingグループがある場合は、スケーリングポリシーのしきい値が実際の負荷傾向と合っているか、見直すタイミングかもしれません。