AWS Auto Scaling で実現する需要追従型インフラ - スケーリングポリシーの設計と最適化
ターゲット追跡・予測・スケジュールドの 3 種類のポリシーを使い分け、混合インスタンスポリシーでスポットを活用したコスト最適化を実現する手法を紹介します。
Auto Scaling の概要
Auto Scaling はリソースを需要に応じて自動的にスケーリングするサービスです。トラフィックが増加するとインスタンスを追加し、減少すると削除します。過剰プロビジョニングによるコスト浪費と、不足によるパフォーマンス低下の両方を防止します。ターゲット追跡、ステップ、予測の 3 種類のスケーリングポリシーを提供し、ワークロードの特性に応じて使い分けます。Auto Scaling は EC2 だけでなく、ECS サービス、DynamoDB テーブル、Aurora レプリカ、SageMaker エンドポイントなど幅広いリソースに適用できますが、本記事では最も一般的な EC2 Auto Scaling Group に焦点を当てます。
スケーリングポリシーの設計
ターゲット追跡スケーリングは最も推奨されるポリシーで、CPU 使用率 70% や ALB リクエスト数 1000/分などの目標値を設定するだけで、Auto Scaling が自動的にキャパシティを調整します。内部的にはスケールアウト用とスケールイン用の 2 つの CloudWatch Alarm を自動生成し、メトリクスが目標値から乖離すると段階的にインスタンスを増減します。予測スケーリングは過去 14 日間のトラフィックパターンを ML で分析し、将来の需要を予測してスケジュールベースでキャパシティを事前確保します。毎朝 9 時にトラフィックが急増するパターンでは、8:50 にスケールアウトを開始します。ウォームプールは AMI からの起動とアプリケーションの初期化を事前に完了したインスタンスを待機させ、スケールアウト時に即座にサービスインさせます。ステップスケーリングはメトリクスの逸脱度合いに応じて異なるスケーリング量を設定でき、CPU 70% 超で 1 台追加、90% 超で 3 台追加といった段階的対応に適しています。
予測スケーリングとスケジュールドスケーリング
予測スケーリングは過去 14 日間のメトリクスパターンを機械学習で分析し、将来の需要を予測してスケーリングアクションを事前に実行します。ターゲット追跡ポリシーの反応遅延 (メトリクス収集からインスタンス起動完了まで数分) を補完し、急激なトラフィック増加にも対応できます。スケジュールドスケーリングは、毎日の営業時間開始前やセール開始時刻など、予測可能な需要変動に対して事前にキャパシティを確保します。予測スケーリングとスケジュールドスケーリングを組み合わせ、定常的なパターンは予測で、イベント的な需要はスケジュールでカバーする設計が効果的です。予測スケーリングには forecast only モードがあり、まずは実際のスケーリングを行わず予測精度だけを確認してから本番有効化する段階的導入が可能です。 スケーリングの設計と構築を深く理解するには、専門書籍 (Amazon)が役立ちます。
Auto Scaling のコスト最適化
Auto Scaling グループでスポットインスタンスと混合インスタンスポリシーを活用すると、オンデマンド比で最大 90% のコスト削減が可能です。複数のインスタンスタイプを指定し、キャパシティ最適化の配分戦略でスポットの中断リスクを分散します。最小キャパシティをオンデマンドで確保し、超過分をスポットで賄う構成が安定性とコストのバランスに優れています。ウォームプールを設定すると、事前に初期化済みのインスタンスをプールしておき、スケールアウト時の起動時間を短縮できます。CloudWatch のカスタムメトリクス (キューの深さ、アクティブ接続数) をスケーリングポリシーに使用し、CPU 使用率だけに頼らない精度の高いスケーリングを実現します。
設計の落とし穴とアンチパターン
Auto Scaling の設計で頻出する問題を把握しておくことで、本番障害を回避できます。第一に、スケールインが速すぎて進行中のリクエストが中断される問題があります。これは ALB のデレジストレーション遅延 (connection draining) をデフォルトの 300 秒から適切に設定し、インスタンスのライフサイクルフックで graceful shutdown を実装することで対処します。第二に、ヘルスチェックの設計ミスがあります。EC2 ステータスチェックだけでは「OS は正常だがアプリケーションがフリーズ」した状態を検出できないため、ELB ヘルスチェックを有効化し、アプリケーションレベルの /health エンドポイントで判定させます。第三に、スケールアウトとスケールインの閾値を対称に設定すると、メトリクスが閾値付近で振動するフラッピングが発生します。スケールイン閾値はスケールアウト閾値より十分に低く (例: アウト 70%、イン 40%) 設定し、スケールインのクールダウンを長め (300 秒以上) にします。第四に、単一 AZ でのスケーリングは可用性の観点で脆弱です。必ず複数 AZ に分散し、AZ リバランシングを有効化します。
Kubernetes HPA/Karpenter との使い分け
コンテナワークロードでは、EC2 Auto Scaling の代わりに EKS の Horizontal Pod Autoscaler (HPA) + Karpenter (ノードオートスケーラー) が選択肢になります。HPA は Pod レベルの水平スケーリングを行い、Karpenter は Pod のリソース要求に基づいて適切なインスタンスタイプのノードを自動プロビジョニングします。EC2 Auto Scaling は事前にインスタンスタイプの候補リストを定義する必要がありますが、Karpenter は Pod の要件から最適なインスタンスを動的に選択するためインスタンス選定の手間が削減されます。一方、EC2 Auto Scaling は非コンテナワークロード (AMI ベースのアプリケーション、GPU ワークロード) に適しており、ウォームプールや予測スケーリングなど EKS にはない機能を持ちます。Lambda は完全にマネージドでスケーリング設計が不要ですが、実行時間 15 分の制限や VPC 接続時のコールドスタートなどの制約があるため、長時間処理やステートフルなワークロードには EC2 Auto Scaling が適切です。
まとめ
Auto Scaling はターゲット追跡、ステップ、予測の 3 種類のスケーリングポリシーで需要に追従するインフラを構築します。予測スケーリングの forecast only モードで精度を確認してから本番化し、混合インスタンスポリシーでスポットインスタンスを活用してコストを最適化します。デレジストレーション遅延、ELB ヘルスチェック、非対称閾値の設定でフラッピングや中断を防止し、安定した運用を実現します。