Auto Scalingは仕様上は非常にシンプルに見えます。トラフィックが増えればEC2インスタンスを追加し、減れば削除する。しかし、本番環境ではまさにその瞬間から問題が発生し始めます。
Auto Scalingの失敗の多くは「スケーリング機能」そのものが原因ではありません。問題は、システムがそもそも「インスタンスが自由に増減する」前提で設計されていないことにあります。
例えば：
スケーリングが発動した瞬間、これらの弱点が一斉に表面化します。
安定したEC2 Auto Scaling環境は、次の前提に依存しています。
「どの仮想マシンも、いつでも置き換え可能である」
以下では、この前提を現実の本番環境で成立させるための実践的な設計判断を整理します。
Auto Scalingは誤ったインスタンス選択を修正してくれません。それを「増幅」するだけです。
新しいインスタンスは、実際に処理能力を増加させなければなりません。新たなボトルネックを作ってしまえば意味がありません。
インスタンス選定は以下から始めるべきです：
|
インスタンス種別 |
技術特性 |
主な用途 |
|
Compute最適化（C） |
高CPU比率 |
データ処理、バッチ、高トラフィックWeb |
|
Memory最適化（R/X） |
高メモリ比率 |
Redis、SAP、Java系アプリ |
|
汎用（M） |
バランス型 |
バックエンド、標準アプリ |
|
バースト型（T） |
短時間CPUバースト |
Dev/Staging、断続的負荷 |
本番稼働後は、CloudWatchメトリクスやAWS Compute Optimizerを使い、サイズを再評価すべきです。想定と実測はほぼ必ずズレます。
CPUベースのAuto Scalingでは、T3/T4gは注意が必要です。
結果として、負荷が軽減せず悪化するケースがあります。
Auto Scaling Groupでは、Mixed Instances Policyを活用すべきです。
メリット：
「いつでも置き換え可能」という前提があるなら、設定はインスタンス内部に存在してはいけません。
手動修正や例外対応が始まった瞬間、マシンは徐々に不整合を起こします。通常時は問題にならなくても、スケール時に顕在化します。
変更は常に新しいAMIを作成して行います。
すべてAMI内で完結します。
起動直後から観測・管理可能な状態になります。
AMIは明確にバージョン管理。ロールバックはバージョン切替で実施します。
ローカル状態は置き換え前提と矛盾します。
よくある誤り：
Auto Scaling下では成立しません。
守るべきはインスタンスではなくアーキテクチャです。
ネットワークは「障害は通常発生するもの」と仮定すべきです。
最低3AZに跨る設計です。
1AZ障害でもサービス継続します。
起動直後のウォームアップ中に異常判定されるのを防ぎます。
例：300秒
CPUのみの閾値ベース制御は不十分です。実際のトラフィックは不規則です。
詳細モニタリング（1分粒度）は必須です。
過去14日以上のデータを基に事前スケール、起動時間が長いワークロードに有効です。
「置き換え可能」であるなら、実際に置き換えをテストする必要があります。
Apache JMeter等でスパイクを再現します。
観察ポイント：
インスタンスを意図的に削除し、ASG自己修復確認します。
過敏なポリシーによるスラッシング（頻繁な増減）を防止します。
Auto Scalingは「インスタンスの置き換えを例外ではなく通常操作として扱う」場合にのみ安定します。この前提がシステム全体で徹底されていれば、スケーリングは不安定な要素ではなく、制御可能な仕組みになります。
現在AWSでAuto Scalingを運用中で、以下という場合は、ぜひHaposoftまでご相談ください。
現状構成のレビューや負荷環境での検証支援を実務視点でサポートいたします。
