Auto Scalingは仕様上は非常にシンプルに見えます。トラフィックが増えればEC2インスタンスを追加し、減れば削除する。しかし、本番環境ではまさにその瞬間から問題が発生し始めます。

Auto Scalingの失敗の多くは「スケーリング機能」そのものが原因ではありません。問題は、システムがそもそも「インスタンスが自由に増減する」前提で設計されていないことにあります。

例えば：

• マシン間で設定がずれている
• データがローカルディスクに依存している
• ロードバランサーが早すぎるタイミングでトラフィックを流す
• 新しいインスタンスの挙動が既存と異なる

スケーリングが発動した瞬間、これらの弱点が一斉に表面化します。

安定したEC2 Auto Scaling環境は、次の前提に依存しています。

「どの仮想マシンも、いつでも置き換え可能である」

以下では、この前提を現実の本番環境で成立させるための実践的な設計判断を整理します。

 

1. インスタンス選定と分類

Auto Scalingは誤ったインスタンス選択を修正してくれません。それを「増幅」するだけです。

新しいインスタンスは、実際に処理能力を増加させなければなりません。新たなボトルネックを作ってしまえば意味がありません。

インスタンス選定は以下から始めるべきです：

• 実際の本番負荷での挙動
• CPU・メモリ・ネットワーク使用傾向
• 過去の慣習や単純なコスト比較ではなく、実測値
   

主なインスタンスファミリー比較

本番稼働後は、CloudWatchメトリクスやAWS Compute Optimizerを使い、サイズを再評価すべきです。想定と実測はほぼ必ずズレます。

バースト型（T）インスタンスの注意点

CPUベースのAuto Scalingでは、T3/T4gは注意が必要です。

• CPUクレジット枯渇後に性能が急落
• ヘルスチェックは正常でも実際は応答遅延
• その状態でスケールアウトすると、遅いインスタンスが増えるだけ

結果として、負荷が軽減せず悪化するケースがあります。

Mixed Instances Policy

Auto Scaling Groupでは、Mixed Instances Policyを活用すべきです。

メリット：

• On-Demand（基礎負荷）＋ Spot（変動負荷）の組み合わせで70～90%コスト削減
• 複数の同等インスタンスタイプ（例：m5.large / m5a.large）を利用し、AZ単位のキャパシティ不足リスクを軽減

 

2. AMI管理とイミュータブルインフラ

「いつでも置き換え可能」という前提があるなら、設定はインスタンス内部に存在してはいけません。

手動修正や例外対応が始まった瞬間、マシンは徐々に不整合を起こします。通常時は問題にならなくても、スケール時に顕在化します。

AMIをデプロイ単位とする

変更は常に新しいAMIを作成して行います。

• インプレースパッチは禁止
• 設定の暗黙的継承なし
• 置き換えは制御された操作にする
   

ハードニング

• OSアップデート
• セキュリティパッチ
• 不要サービス削除

すべてAMI内で完結します。

エージェント統合

• Systems Manager
• CloudWatch Agent
• ログ転送ツール

起動直後から観測・管理可能な状態になります。

バージョニング

AMIは明確にバージョン管理。ロールバックはバージョン切替で実施します。

 

3. ステートレス設計とストレージ戦略

 

ローカル状態は置き換え前提と矛盾します。

よくある誤り：

• ローカルディスクにデータ保存
• キャッシュを永続扱い
• 再起動後もファイルが残る前提

Auto Scaling下では成立しません。

EBSとgp3

• ブート用途や一時用途には適切
• 永続システム状態には不適切
• gp3は性能と容量が分離され予測可能
   

永続データの外部化

• 共有ファイル → Amazon EFS
• 静的アセット → Amazon S3
• データベース → RDS / DynamoDB
   

終了は正常動作

守るべきはインスタンスではなくアーキテクチャです。

 

4. ネットワークとロードバランシング設計

ネットワークは「障害は通常発生するもの」と仮定すべきです。

マルチAZ構成

最低3AZに跨る設計です。
1AZ障害でもサービス継続します。

ヘルスチェック猶予期間

起動直後のウォームアップ中に異常判定されるのを防ぎます。
例：300秒

セキュリティグループ設計

• 直接公開しない
• ALB経由のみ許可
• 暗黙的信頼を排除

 

5. 高度なAuto Scalingメカニズム

CPUのみの閾値ベース制御は不十分です。実際のトラフィックは不規則です。

Dynamic Scaling（Target Tracking）

• CPUやリクエスト数を目標値で制御
• 固定閾値より安定
• 過剰・不足スケールを抑制

詳細モニタリング（1分粒度）は必須です。

Predictive Scaling

過去14日以上のデータを基に事前スケール、起動時間が長いワークロードに有効です。

Warm Pools

• 停止状態で待機
• スケール時に即In-Service
• 実行中容量を増やさず高速化

 

6. テストと調整

「置き換え可能」であるなら、実際に置き換えをテストする必要があります。

負荷テスト

Apache JMeter等でスパイクを再現します。

観察ポイント：

• スケール後に安定するか
• レイテンシ悪化しないか

強制終了テスト

インスタンスを意図的に削除し、ASG自己修復確認します。

クールダウン調整

過敏なポリシーによるスラッシング（頻繁な増減）を防止します。

 

結論

Auto Scalingは「インスタンスの置き換えを例外ではなく通常操作として扱う」場合にのみ安定します。この前提がシステム全体で徹底されていれば、スケーリングは不安定な要素ではなく、制御可能な仕組みになります。

現在AWSでAuto Scalingを運用中で、以下という場合は、ぜひHaposoftまでご相談ください。

• 本当に置き換え可能な設計になっているか確認したい
• 負荷下での挙動を検証したい

現状構成のレビューや負荷環境での検証支援を実務視点でサポートいたします。