オートスケーリンググループ
Auto-Scaling Group
オートスケーリンググループ(ASG)は、需要に基づいてスケーリングを行うことで、アプリケーションのパフォーマンスを維持しコストを最小化するために、EC2インスタンスなどのコンピューティングリソースを自動的に調整します。
Auto-Scaling Groupとは?
Auto-Scaling Group(ASG)は、クラウド環境におけるコンピューティングリソース(通常はAmazon EC2インスタンス)の論理的なグループです。ASGは、実行中のインスタンス数を自動的に調整することで、安定した予測可能なアプリケーションパフォーマンスを維持しながら、コストを最小化します。この弾力性は、リアルタイムの需要、ヘルスステータス、または事前定義されたスケーリングポリシーに応じて、スケールアウト(インスタンスの追加)またはスケールイン(インスタンスの削除)を行うことで実現されます。
ASGは、手動介入なしに、インスタンスの起動、監視、終了を含む完全なライフサイクルを管理します。Auto-Scaling Groupは、弾力的で回復力があり、コスト最適化されたクラウドアーキテクチャの基盤であり、変動するワークロードを持つアプリケーションに不可欠です。
主要コンポーネント
起動テンプレート / 起動設定
- ASGによって起動されるインスタンスの設定を指定
- AMI、インスタンスタイプ、ストレージ、ネットワーキング、セキュリティ設定、IAMロール、ブートストラップスクリプトを含む
- 起動テンプレートは柔軟性があり、バージョニングと混合インスタンスポリシーをサポートするため推奨
- 起動設定は古く、柔軟性が低い
スケーリングポリシー
- ASGがいつ、どのように容量を変更するかを定義
- タイプ:ターゲット追跡、ステップスケーリング、シンプルスケーリング、スケジュールスケーリング
- メトリクス:CPU、メモリ、ネットワークI/O、リクエスト数、またはカスタムCloudWatchメトリクス
ヘルスチェック
- Amazon EC2ステータスチェックと、オプションでELBを使用してインスタンスのヘルスを継続的に監視
- 異常なインスタンスは自動的に終了され、希望容量を維持するために置き換えられる
希望容量、最小容量、最大容量
- 希望容量:ASGが維持しようとするインスタンスの目標数
- 最小容量:グループが持つインスタンスの最小数
- 最大容量:過剰プロビジョニングを防ぐ上限
インスタンスタイプと購入オプション
- 複数のインスタンスタイプ:ASGは複数のインスタンスタイプを混在させることが可能
- 購入モデル:オンデマンド、リザーブド、スポットインスタンスをサポート
アベイラビリティーゾーン(AZ)
- 高可用性のため、リージョン内の複数のAZにインスタンスを分散
- ASGは各有効なAZ内のインスタンス数をバランス
Elastic Load Balancing(ELB)統合
- 受信トラフィックを正常なASGインスタンス全体に分散
- タイプ:Application Load Balancer(ALB)、Network Load Balancer(NLB)、Classic Load Balancer(CLB)
- 新しいインスタンスは自動的に登録され、終了したインスタンスは登録解除される
ライフサイクルフック
- インスタンスライフサイクルの特定のポイントでカスタムスクリプトやロジックの実行を可能にする
- 設定、ドレイニング、またはクリーンアップタスクを処理
タグとメタデータ
- 追跡、自動化、コスト配分、ガバナンスのためにASGとインスタンスにキー・バリューペアを割り当て
Auto-Scaling Groupの動作方法
初期化
- ASGは起動テンプレート/設定に従って、希望容量に達するまでインスタンスを起動
- 指定されたアベイラビリティーゾーン全体にインスタンスを分散
ヘルス監視と置き換え
- 定期的なヘルスチェック(EC2および/またはELB)により異常なインスタンスを特定
- 異常なインスタンスは終了され、容量を維持するために置き換えられる
スケーリングアクション
- スケールアウト:監視対象メトリクスがしきい値を超えると、ASGは追加のインスタンスを起動
- スケールイン:メトリクスが下限しきい値を下回ると、ASGはインスタンスを終了
- スケジュールスケーリング:定義されたスケジュールに基づいて容量を調整
- 予測スケーリング:履歴パターンと機械学習を使用して需要を予測
例: 大規模イベント(例:ライブストリーミング)中、ASGは負荷の急増を検出し、より多くのインスタンスを起動します。イベント終了後、コストを最適化するためにスケールインします。
Elastic Load Balancing統合
- ロードバランサーは新しく起動された正常なインスタンスにトラフィックをルーティング
- 削除されるインスタンスの登録を解除
混合インスタンスと購入戦略
- コスト効率と可用性のためにオンデマンドとスポットインスタンスを組み合わせ
- スポットフリートの割り当て戦略(例:容量最適化、最低価格)
ライフサイクル管理
- ライフサイクルフックは設定、状態保存、またはクリーンアップのための自動化をトリガー
クロスAZバランシング
- ASGは回復力のためにAZ全体にインスタンスを均等に分散
- AZに障害が発生した場合、正常なAZで置き換えインスタンスが起動される
主な利点
弾力性
- 変動するワークロード需要に容量を一致させる
コスト効率
- 過剰プロビジョニングを削減し、支出を最適化
高可用性
- ヘルスチェックとクロスAZ分散により耐障害性を確保
運用効率
- 容量管理を自動化し、手動介入を削減
回復力
- インスタンスまたはAZ障害からの迅速な回復
一般的なユースケース
Webアプリケーション
- 変動するトラフィックを持つEコマース、SaaS、ストリーミングプラットフォーム
ビッグデータ処理
- 一時的なコンピューティングフリートを必要とするバッチジョブ(例:ETL、ログ分析)
マイクロサービスとコンテナ
- マイクロサービスごとにASGを割り当てて独立したスケーリングを実現
CI/CDパイプライン
- ビルド/テスト環境を動的にプロビジョニング
APIバックエンド
- リクエスト量に基づいてAPIサーバーをスケール
イベント駆動型ワークロード
- キャンペーン、製品発売、またはバイラルイベントのための迅速なスケーリング
業界の例:
- Netflix:グローバルマイクロサービスのスケーラビリティにASGを使用
- Airbnb:旅行シーズンのピーク時にリソースをスケール
設定のベストプラクティス
基本的なセットアップ手順
- 起動テンプレート/設定を定義
- Auto-Scaling Groupを作成:希望容量、最小容量、最大容量を設定し、アベイラビリティーゾーンを選択
- ロードバランサーをアタッチ:トラフィックとヘルス監視のためにELBを統合
- スケーリングポリシーを設定
- ヘルスチェックを有効化:EC2および/またはELBヘルスチェックを選択
- タグを適用:コスト配分、自動化、ガバナンスのため
- ライフサイクルフックを実装(オプション)
- スケーリングイベントをテスト
ベストプラクティス
- 柔軟性と高度な機能のために起動テンプレートを使用
- 回復力のために複数のAZに分散
- コスト削減のために混合インスタンスポリシーを活用
- 使用状況とSLAに基づいて現実的な容量制限を設定
- ユーザーエクスペリエンスとワークロードに合った関連メトリクスを選択
- ステートレス設計:セッション/状態を外部に保存
- 重要なワークロードにインスタンス保護を有効化
- 監視と調整:CloudWatch、Datadog、または類似のツールを使用
- 自動化のためにライフサイクルフックを実装
- コストを定期的にレビュー
課題と考慮事項
設定の複雑さ
- テンプレート、ポリシー、ヘルスチェックの正確な設定が必要
- 設定ミスはリソースのスラッシングやコスト増加を引き起こす可能性
アプリケーション設計の制約
- アプリケーションは水平スケーリングとステートレス動作をサポートする必要がある
クロスリージョンの制限
- ASGはリージョン単位。クロスリージョン冗長性には別々のASGが必要
メトリクス選択の課題
- 不適切なメトリクス選択は非効率的なスケーリングにつながる可能性
スケーリングの遅延
- インスタンスの起動/ウォームアップにより、急激な急増時のスケーリングが遅れる可能性
スポットインスタンスの中断
- スポットインスタンスは中断される可能性があり、容量リバランシングを使用
制限とクォータ
- AWSはリージョン、グループ、アカウントごとにクォータを適用
他のサービスとの統合
- フルスタック自動スケーリングには調整された設定が必要
よくある質問
Auto-Scaling Groupは複数のリージョンで使用できますか?
- いいえ、ASGはリージョンスコープです
- クロスリージョン高可用性のためには、各リージョンでASGを個別に作成・管理する必要があります
Elastic Load BalancingはASGとどのように連携しますか?
- ELBは正常なASGインスタンス全体にトラフィックを分散
- インスタンスが追加または削除されると、自動的に登録/登録解除されます
ASG内のスポットインスタンスが中断されるとどうなりますか?
- ASGは容量を維持するために置き換えインスタンスの起動を試みます
- 容量リバランシングは、リスクのあるスポットインスタンスを事前に置き換えます
同じASG内で異なるインスタンスタイプを使用できますか?
- はい、起動テンプレートと混合ポリシーを使用すると、ASGは複数のインスタンスタイプを起動できます
ASGの設定における一般的な落とし穴は何ですか?
- 不適切なメトリクス選択、非現実的な容量制限、ステートレス設計の欠如、AZ全体への分散の失敗
参考文献
- Amazon EC2 Auto Scalingドキュメント
- AWS: 最初のAuto Scaling Groupを作成する(チュートリアル)
- Spot.io: EC2 Auto Scaling Groupsの理解
- IBM: オートスケーリングとは?
- CloudZero: AWS Auto Scaling 101
- Datadog: オートスケーリングとは?
- Graph AI: Auto Scaling Groups
- Spot.io: EC2 Auto Scalingベストプラクティス
- AWS: ASGとのELB統合
- Spot.io: 容量リバランシング
- AWS: 混合インスタンスポリシー
- Amazon EC2
- CloudWatch
- Spot.io: マルチAZ vs マルチリージョン
関連用語
Infrastructure as Code (IaC)
Infrastructure as Code(IaC)は、ネットワーク、仮想マシン、ロードバランサーなどのITインフラストラクチャをコードと自動化を使用して定義・管理する手法です。そのメリット、ツール...