AWS EC2 オートスケーリング

現代のクラウド コンピューティング環境では、特にトラフィックが大きく変動する場合、企業は変化するビジネス ニーズに迅速に対応できる必要があります。 Amazon Web Services (AWS) が提供する EC2 Auto Scaling 機能は、開発者や企業に効果的なソリューションを提供します。 AWS EC2 Auto Scaling は、コンピューティングリソースのサイズを自動的に調整することで、実際の負荷に基づいてインスタンスの数を自動的に増減し、コストを最適化して効率的なシステム運用を実現します。トラフィックのピークや谷に関係なく、自動拡張によりアプリケーションの安定性と可用性が確保され、ビジネスの継続性と柔軟性が大幅に向上します。

  • Amazon EC2 Auto Scaling は、需要に基づいてアプリケーションの EC2 インスタンスの数を変更します。
  • Auto Scaling グループは、EC2 インスタンスのグループを制御するために作成されます。
  • 設定できる内容:
    • インスタンスの最小数: これはグループの最小数です。
    • インスタンスの最大数: これは、グループが持つことができるインスタンスの最大数です。
    • 必要な容量: グループはこの数のインスタンスを保持しようとします。
  • 需要に応じて、スケーリング ポリシーによってインスタンスが自動的に追加または削除される場合があります。

例: 次のコンテンツを含む Auto Scaling グループ:

  • 最小サイズ: 6インスタンス
  • 必要な容量: 8インスタンス
  • 最大サイズ: 14インスタンス
  • このスコープ内のインスタンスは、設定した基準に基づいてスケーリング ポリシーによって変更されます。

 

  • スケーラビリティと管理を容易にするために、Amazon EC2 の自動スケーラビリティでは、EC2 インスタンスを Auto Scaling グループにグループ化します。
  • Auto Scaling グループは、起動テンプレートまたは起動構成を使用してインスタンスを構築します。

 

  • 健康モニタリング: EC2 ヘルスチェックを使用してインスタンスのヘルスを自動的に検証および維持します。必要な容量を維持するために、障害が発生したインスタンスまたは終了したインスタンスは置き換えられます。
  • カスタムヘルスチェック: 一部のアプリケーション要件については、独自のヘルス チェックを設計できます。これらのチェックが満たされない場合、インスタンスは置き換えられます。
  • バランスの取れた容量: 可用性と適応性を向上させるために、インスタンスは複数のアベイラビリティゾーンに均等に分散されます。
  • 複数のインスタンスタイプ: さまざまなインスタンスタイプと購入オプション (予約済み、オンデマンド、スポット) を 1 つのグループでサポートし、経費を削減します。
  • スポットインスタンスの自動置換: 中断されたスポットインスタンスを自動的に置き換えます。停止が発生した場合、容量の再調整によってスポットインスタンスを置き換えることができます。
  • 負荷分散: Elastic Load Balancing と統合して、正常なインスタンス間でトラフィックを均等に分散できるようにします。インスタンスが大きくなると、自動的に登録および登録解除されます。
  • スケーラビリティ: グループ サイズを手動で選択すると、変化する負荷に応じて自動的に調整されます。
  • インスタンスの更新: 起動テンプレートまたは AMI が変更されるたびに、インスタンスはローリング デプロイメントまたはカナリア デプロイメントを通じて更新されます。
  • ライフサイクルフック: インスタンスの起動時または終了時にカスタムアクションを実行できるため、イベント駆動型アーキテクチャに役立ちます。
  • ステートフルワークロードのサポート: ライフサイクル フック、拡張保護、または独自の終了ポリシーを使用して、ステートフル アプリケーションの実行を継続します。

 

  • 自動スケーリングの再バランス: EC2 インスタンスがアベイラビリティーゾーン (AZ) 間で均等に分散されていない場合、Auto Scaling (AS) によって自動的に再調整されます。
  • リバランス操作他のアベイラビリティーゾーンから余分なインスタンスを削除し、インスタンス数が少ないアベイラビリティーゾーンで新しいインスタンスを起動します。

 

  • 可用性ゾーンは、Auto Scaling に追加したり、Auto Scaling から削除したりできます。
  • EC2 インスタンスは ASG から手動で終了します。
  • インスタンスの分散は、アベイラビリティーゾーンの容量の増減によって影響を受けます。

 

  • EC2 が動作している必要があります。
  • EC2 は引き続き同じ AMI を使用して起動する必要があります。
  • インスタンスを別の ASG 内に含めることはできません。
  • インスタンスと ASG は同じ AZ に存在する必要があります。
  • インスタンスを追加すると ASG の最大容量を超える場合、リクエストは失敗します。
  • 手動分離: ASG から EC2 インスタンスを削除するには、CLI または AWS コンソールを使用します。
  • 別れた後: 切り離されたインスタンスは別の ASG に転送したり、個別に管理したりできます。
  • 必要な容量調整: インスタンスをデタッチするときに、ASG の必要な容量を減らすことを選択できます。
    • そうでない場合、ASG は新しいインスタンスを起動します。
  • ASGの削除: ASG を削除すると、すべての EC2 インスタンスが終了し、その機能はゼロにリセットされます。
    • ASG を破棄する前に EC2 インスタンスをデタッチして保存します。

 

  • ELB を ASG に接続する: 同じリージョンと VPC 内にある限り、ELB を ASG に追加できます。
  • ELB は、新規と既存の両方のすべての EC2 インスタンスを ASG に自動的に登録します。

 

  • 健康チェックのカテゴリー: EC2 および ELB のステータス チェックに基づいて、EC2 インスタンスは正常または異常に分類されます。
  • ヘルスチェック設定: Auto Scaling はデフォルトで EC2 ステータス チェックを使用します。
    • ELB および EC2 ヘルスチェックを使用するように設定できます。
  • 猶予期間: ヘルスチェックを実行する前のデフォルトの猶予期間は 300 秒に設定されています。
    • インスタンスがサービス開始されると、猶予期間をゼロに設定してその健全性がチェックされます。
    • 猶予期間中は、不健全な状態はすべて無視されます。
  • 不健全なインスタンス処理: ASG は猶予期間後に代替インスタンスを展開し、異常なインスタンスを強制終了します。
  • Elastic IP と EBS: 新しいインスタンスに接続し、終了したインスタンスから手動でデタッチします。

 

  • SNS通知: ASG は次の場合に電子メール通知を送信します:
    • インスタンスが開始されました。
    • インスタンスは終了しました。
    • インスタンスの起動に失敗しました。
    • インスタンスの終了に失敗しました。

 

  • マージは AWS CLI (AWS コンソールではない) を使用してのみ実行できます。
  • 複数の Single-AZ ASG を組み合わせて、Multi-AZ ASG を作成できます。
  • 拡張機能: 追加の EC2 インスタンスを起動します。
  • 減らす: EC2 インスタンスを終了します (スケールアウト イベントごとにスケールダウン イベントを生成することをお勧めします)。
  • EC2メトリクスはクラウドウォッチASG インスタンスを監視します。
    • 基本的な監視: 300秒ごと(無料)。
    • 詳細な監視: 60 秒ごと (課金対象、AWS CLI を使用する場合はデフォルトで有効)。

 

  • ASG では、EC2 インスタンスを手動でスタンバイ モードにすることができます。
  • スタンバイインスタンスの管理にはAuto Scalingがまだ使用されていますが、
    • 使用中のインスタンスと同様に、課金されます。
    • ワークロードにアクセス可能な EC2 インスタンスはそれらの影響を受けません。
    • スタンバイ インスタンスはヘルス チェックの対象ではありません。

 

  • 手動拡張: EC2 インスタンスの数を手動で変更できます。
  • ダイナミックな拡張: 条件付きアラートとリアルタイムアラート。
    • ターゲット追跡: メトリックの予想値に基づいてグループをスケーリングします (家庭用サーモスタットの変更など)。
    • シンプルズーム: アラートに応じてグループのサイズを 1 回変更します (300 秒のクールダウン期間付き)。
    • ステップズーム: 設定されたステップ サイズに応じてスケールし、アラーム違反のサイズに応じてスケールを調整します。ウォームアップ タイマーはサポートしますが、クールダウン タイマーはサポートしません。

 

  • 予測の拡張: 機械学習を使用して、毎日および毎週の負荷パターンを予測し、インスタンスの調整を計画します。
  • 計画された拡張: 予測される負荷変動に対応するために、特定の時間と容量に対してスケーリング操作をスケジュールできます。スケジュールされた操作の日時は一意である必要があります。
  • サイクル延長: 計画された拡張と同様に、履歴データを使用して将来の拡張のニーズを予測します。

 

  • アラートとポリシーは、スケーリング ポリシーによって使用され、いつスケーリングするかを決定します。
  • スケーリングの変更は、ASG の最小容量または最大容量を超えることはできません。
  • 最適なアプリケーションパフォーマンスを確保するには、慎重な計画が必要です。拡大と収縮のプロセス。

 

  • トラフィック レベルに基づいて Web サーバーの EC2 インスタンスを自動的にスケーリングし、アプリケーションが人間の支援なしにスパイクを管理できるようにします。
  • 特定の時間内に大規模なデータセットを処理するには、データ処理要件に基づいてインスタンスをスケーリングします。
  • サイバー マンデーやブラック フライデーなどの需要が集中する期間中は、インスタンスをスケールアップして、アプリケーションがより多くのユーザーを処理できるようにします。
  • プレイヤーのアクティビティに基づいてマルチプレイヤー バックエンド サーバーを自動的に拡張し、忙しい時期でもスムーズなゲームプレイを実現します。

 

  • ELB と Auto Scaling を併用すると、インスタンス間でトラフィックを均等に分散できます。
  • 異常なインスタンスを迅速に識別して置き換えるには、適切なヘルスチェック パラメータを設定します。
  • 少数の最小限のインスタンスから始めて、トラフィック パターンを確認してから徐々にスケールアップします。
  • 頻繁にテストを実施して、さまざまなトラフィック シナリオでスケーリング ポリシーが期待どおりに機能することを確認します。
  • 予測スケーリングを活用して、予測可能なトラフィック パターンを持つワークロードの履歴データに基づいてスケーリング アクションを予測します。

 

要約する

AWS EC2 の自動スケーリングは、特に動的負荷環境におけるクラウド コンピューティング アーキテクチャの不可欠な部分です。他の AWS サービスとの緊密な統合により、自動拡張によりリソース使用率が向上し、運用・保守コストが削減されるだけでなく、ユーザーエクスペリエンスも向上します。企業の高可用性と柔軟性に対する需要が高まり続ける中、AWS EC2 の自動スケーリングは間違いなくこれらの目標を達成するための強力なツールです。

さらに詳しく

何が必要か教えてください