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まで​ご相談ください。

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

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