Auto Scaling グループでのインスタンスの更新の仕組み - Amazon EC2 Auto Scaling
仕組み重要な概念ヘルスチェックの猶予期間インスタンスタイプの互換性制限事項

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Auto Scaling グループでのインスタンスの更新の仕組み

このトピックでは、インスタンスの更新がどのように機能するかを説明し、インスタンスを効果的に活用するための基礎知識について紹介します。

仕組み

Auto Scaling グループのインスタンスを更新するには、アプリケーションの最新バージョンと、実行するその他の更新を含む新しい設定を定義できます。

インスタンスの更新では、インスタンスを更新するための 2 つの戦略がサポートされています。

  • ローリング戦略 (デフォルト) — 設定に従ってインスタンスを終了し、新しいインスタンスをバッチで起動します。これにより、Auto Scaling グループは更新プロセス全体で希望する容量と可用性を維持できます。

  • ルートボリュームの置き換え戦略 — インスタンスを終了せずにルートボリュームのみを置き換えることで、インスタンスを更新します。これにより、インスタンスネットワークインターフェイス、非ルート EBS ボリューム、インスタンスストアデータが保持されます。

ルートボリュームの置き換え戦略の要件:

  • Auto Scaling グループは混合インスタンスポリシーを使用する必要があります

  • 混合インスタンスポリシーのすべてのオーバーライドでは、 を指定する必要があります。 ImageId

  • AMIs には 1 つのルートボリュームのみを含める必要があります

  • すべてのインスタンスは、グループの起動テンプレート設定と一致する必要があります

  • ImageId オーバーライドを含む混合インスタンスポリシーを使用して、必要な設定でインスタンスの更新を開始する必要があります。

スキップマッチングを有効にすると、Auto Scaling は各インスタンスの現在の AMI ID を目的の設定の AMI IDs と比較します。AMI IDs が一致しないインスタンスのみを置き換えるため、更新済みのインスタンスはスキップできます。

インスタンスの更新を実行する

インスタンスの更新を開始し、その設定に基づいて既存のインスタンスを新しいインスタンスに置き換えます。

  1. 新しい起動テンプレートを作成するか、新しい Amazon マシンイメージ (AMI) などの必要な設定変更で既存のテンプレートを更新します。詳細については、「Auto Scaling グループの起動テンプレートを作成する」を参照してください。

  2. Amazon EC2 Auto Scaling コンソール AWS CLI、または SDK を使用してインスタンスの更新を開始します。

    • 作成した新しい起動テンプレートまたは起動テンプレートのバージョンを指定します。これは、新しいインスタンスを起動するために使用されます。

    • 適切な最小正常率と最大正常率を設定します。この設定により、同時に置き換えられるインスタンスの数と、古いインスタンスを終了する前に新しいインスタンスを起動するかどうかが制御されます。

    • 必要に応じて、以下の設定を行います。

      • チェックポイント – 一定割合のインスタンスが置き換えられた後、インスタンスの更新を一時停止して、進行状況を確認します。

      • ベイク時間 – インスタンスの更新が完了とみなされる前に、インスタンスの更新の終了時に一時停止してインスタンスのヘルスを検証します。

      • スキップマッチング – 古いインスタンスを新しい設定と比較し、一致しないインスタンスのみを置き換えます。コンソールからインスタンスの更新を開始すると、スキップマッチングはデフォルトで有効になります。

      • 複数のインスタンスタイプ – 希望する設定の一部として、新規または更新された混合インスタンスポリシーを適用します。

インスタンスの更新が開始されると、Amazon EC2 Auto Scaling は次のようになります。

  • 最小正常率および最大正常率に基づいて、バッチ内のインスタンスを置き換えます。

  • 最小正常率が 100% に設定されている場合、古いインスタンスを終了する前に新しいインスタンスを起動します。これにより、希望するキャパシティが常に維持されます。

  • インスタンスのヘルスステータスを確認し、ウォームアップ時間を確保してから、残りのインスタンスを置き換えます。

  • 異常が見つかったインスタンスを終了して置き換えます。

  • インスタンスの更新が成功すると、新しい設定変更で Auto Scaling グループ設定が自動的に更新されます。

  • ウォーム プール内のインスタンスの前に、InService インスタンスを置き換えます。

次のフロー図は、最小正常率を 100% に設定した場合の、終了前の起動動作を示しています。

最小正常率が 100% に設定されている場合のインスタンスの更新の仕組みを示す図。
注記

インスタンス更新の最小正常率と最大正常パーセンテージは、インスタンスメンテナンスポリシーを設定していない場合、または既存のポリシーを上書きする必要がある場合のみ指定する必要があります。詳細については、「インスタンスメンテナンスポリシー」を参照してください。

同様に、インスタンス更新のインスタンスウォームアップ期間を指定する必要があるのは、デフォルトのウォームアップを有効にしていない場合、またはデフォルトを上書きする必要がある場合のみです。詳細については、「Auto Scaling グループに対するインスタンスのデフォルトウォームアップを設定する」を参照してください。

重要な概念

開始する前に、以下の インスタンス更新の主要概念を理解してください。

最小正常率

最小正常率は、更新を続行できるように、インスタンスの更新中に稼働状態を維持し、正常な状態で使用できる状態に維持する必要があるキャパシティの割合です。例えば、最小正常率が 90% で、最大正常率が 100% の場合、キャパシティの 10% が一度に置き換えられます。新しいインスタンスがヘルスチェックに合格しなかった場合、Amazon EC2 Auto Scaling が終了してインスタンスを置き換えます。インスタンスの更新で正常なインスタンスを起動できない場合、最終的に失敗し、グループの残りの 90% はそのままになります。新しいインスタンスが正常な状態を維持してウォームアップ期間が終了した場合、Amazon EC2 Auto Scaling は他のインスタンスの置き換えを続行できます。

インスタンスの更新では、インスタンスを 1 つずつ、複数ずつ、またはすべてを一度に置き換えることができます。一度に 1 つのインスタンスを置き換えるには、最小正常率と最大正常率の両方を 100% に設定します。この変更により、終了する前にインスタンスの更新の動作が起動するように変更され、グループのキャパシティが希望するキャパシティを下回ることが防止されます。すべてのインスタンスを一度に置き換えるには、最小正常率を 0% に設定します。

最大正常率

最大正常率は、インスタンスを置き換えるときに Auto Scaling グループが増加できる、適切なキャパシティの割合です。最小と最大の差分は 100 を超えることはできません。範囲を大きくすると、同時に置き換えることができるインスタンスの数が増えます。

インスタンスのウォームアップ

インスタンスのウォームアップとは、新しいインスタンスの状態が InService に変更されてから、初期化が完了したとみなされるまでの期間です。インスタンスの更新中、インスタンスがヘルスチェックに合格した場合、新しく起動されたインスタンスが正常であると判断した後、Amazon EC2 Auto Scaling はすぐに次のインスタンスの置き換えに進みません。ウォームアップ期間を待機してから、次のインスタンスの置き換えに進みます。これは、アプリケーションがリクエストに応答するまでにまだ初期化時間が必要な場合に役立ちます。

インスタンスのウォームアップは、デフォルトのインスタンスのウォームアップと同じように機能します。したがって、同じスケーリングに関する考慮事項が適用されます。詳細については、「Auto Scaling グループに対するインスタンスのデフォルトウォームアップを設定する」を参照してください。

必要な設定

必要な設定は、Amazon EC2 Auto Scaling が Auto Scaling グループ全体にデプロイする新しい構成です。例えば、インスタンスに新しい起動テンプレートおよび新しいインスタンスタイプを指定できます。インスタンスの更新中に、Amazon EC2 Auto Scaling は Auto Scaling グループを希望の設定に更新します。インスタンスの更新中にスケールアウト イベントが発生した場合、Amazon EC2 Auto Scaling は、グループの現在の設定ではなく、希望の設定で新しいインスタンスを起動します。インスタンスの更新が成功した後、Amazon EC2 Auto Scaling は Auto Scaling グループの設定を更新し、インスタンスの更新の一環として指定した新しい必要な設定を反映します。

スキップマッチング

スキップマッチングは、既に最新の更新が適用されているインスタンスを無視するように Amazon EC2 Auto Scaling に指示します。これにより、必要以上のインスタンスを置き換えることはありません。これは、Auto Scaling グループが特定バージョンの起動テンプレートを使用し、異なるバージョンを使用するインスタンスのみを置き換えることを確認したいときに役立ちます。

チェックポイント

チェックポイントとは、インスタンスの更新が指定した時間のみ一時停止する時点のことです。インスタンスの更新には、複数のチェックポイントを含めることができます。Amazon EC2 Auto Scaling は、チェックポイントごとにイベントを発行します。したがって、EventBridge ルールを追加し、チェックポイントに到達したときに Amazon SNS などのターゲットにイベントを送信して通知できます。チェックポイントに到達した後で、デプロイを検証する機会があります。問題が特定された場合、インスタンスの更新をキャンセルまたはロールバックできます。更新プログラムを段階的にデプロイできることは、チェックポイントのキーの利点です。チェックポイントを使用しない場合、ローリング置換は継続的に実行されます。

インスタンスの更新を開始するときに設定できるすべてのデフォルト設定の詳細については、「インスタンスの更新のデフォルト値について説明する」を参照してください。

ヘルスチェックの猶予期間

Amazon EC2 Auto Scaling は、Auto Scaling グループが使用するヘルスチェックのステータスに基づいてインスタンスが正常かどうかを判断します。詳細については、「Auto Scaling グループでのインスタンスのヘルスチェック」を参照してください。

これらのヘルスチェックをできるだけ早く開始するには、グループのヘルスチェック猶予期間を高く設定しすぎないでください。ただし、ELB ヘルスチェックでターゲットがリクエストを処理できるかどうかを判断できるほど高く設定してください。詳細については、「Auto Scaling グループにヘルスチェックの猶予期間を設定する」を参照してください。

インスタンスタイプの互換性

インスタンスタイプを変更する前に、起動テンプレートで動作することを確認することをお勧めします。これにより、指定した AMI との互換性を確認できます。例えば、準仮想化 (PV) AMI から元のインスタンスを起動したが、ハードウェア仮想マシン (HVM) AMI でのみサポートされている現行世代のインスタンスタイプに変更したいとします。この場合、起動テンプレートで HVM AMI を使用する必要があります。

インスタンスを起動せずにインスタンスタイプの互換性を確認するには、次の例で示すように、「run-instances」コマンドを --dry-run オプションとともに使用します。

aws ec2 run-instances --launch-template LaunchTemplateName=my-template,Version='1' --dry-run

互換性の判断方法については、「Amazon EC2 ユーザーガイド」の「インスタンスタイプ変更の互換性」を参照してください。

制限事項

  • 合計持続時間: インスタンスの更新がインスタンスをアクティブに置き換えることができる最大時間は、14 日間です。

  • 加重グループ固有の動作の違い: 混合のインスタンスグループがグループの必要キャパシティ以上のインスタンス分量に設定されている場合、Amazon EC2 Auto Scaling はすべての InService インスタンスを一度に置き換えることがあります。このような状況を回避するには、インスタンスの重みを使用するように Auto Scaling グループを設定する トピックの推奨事項に従ってください。Auto Scaling グループで分量を使用するとき、最大の分量よりも大きい必要キャパシティを指定します。

  • 1 時間のタイムアウト: インスタンスの更新がスタンバイ状態またはスケールインから保護されているインスタンスを置き換えるために待機しているため、置き換えが続行できない、あるいは新しいインスタンスがヘルスチェックに合格しない場合、Amazon EC2 Auto Scaling は再試行を 1 時間続行します。加えて、問題の解決に役立つステータスメッセージが表示されます。1 時間経っても問題が解決しない場合は、オペレーションは失敗となります。1 時的な問題が発生した場合に、回復する時間を与えることを意図しています。

  • ユーザーデータによるコードのデプロイ: スキップマッチングは、ユーザーデータスクリプトからデプロイされたコードの変更をチェックしません。ユーザーデータを使用して新しいコードを取得し、これらの更新を新しいインスタンスにインストールする場合は、起動テンプレートのバージョン更新がない場合でも、すべてのインスタンスが最新のコードを受信できるように、スキップマッチングをオフにすることをお勧めします。

  • 更新制限: 目的の設定でインスタンスの更新が実行中に Auto Scaling グループの起動テンプレート、起動設定、または混合インスタンスポリシーを更新しようとすると、これらのリクエストは失敗し、次の検証エラーが発生します。An active instance refresh with a desired configuration exists. All configuration options derived from the desired configuration are not available for update while the instance refresh is active.

  • 属性ベースのインスタンス選択: Auto Scaling グループが属性ベースのインスタンス選択を使用 (混合インスタンスポリシーで InstanceRequirements を指定) している場合、次のインスタンスの更新パラメータはサポートされません。

    • SkipMatching: InstanceRequirements が設定されている Auto Scaling グループで SkipMatching パラメータを使用してインスタンスの更新を開始すると、インスタンスの更新は失敗します。

    • DesiredConfiguration: InstanceRequirements が設定されている Auto Scaling グループで DesiredConfiguration パラメータを使用してインスタンスの更新を開始すると、インスタンスの更新は失敗します。

    属性ベースのインスタンス選択を使用して Auto Scaling グループでインスタンスの更新を実行する必要がある場合、これらのパラメータを指定せずにインスタンスの更新を開始します。

  • ルートボリュームの置き換えは Elastic Load Balancing をサポートしていません。