

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

# リスクがあるスポットインスタンスを置き換えるための Auto Scaling でのキャパシティの再調整
<a name="ec2-auto-scaling-capacity-rebalancing"></a>

Auto Scaling でのキャパシティの再調整は、中断のリスクがあるスポットインスタンスをプロアクティブに置き換えることで、ワークロードの可用性を維持するのに役立ちます。

スポットインスタンスの中断リスクが高い場合、Amazon EC2 スポットサービスは、Amazon EC2 Auto Scaling に EC2 インスタンスの再調整レコメンデーションを送信します。キャパシティの再調整を有効にすると、Auto Scaling は、EC2 インスタンスの再調整レコメンデーションを受け取ったグループ内のスポットインスタンスをプロアクティブに置き換えようとします。これは、ワークロードを中断リスクが低い新しいスポットインスタンスに再調整する機会を提供します。

キャパシティの再調整が無効化されていると、Auto Scaling は、Amazon EC2 スポットサービスがインスタンスを中断し、それらのヘルスチェックが失敗するまでスポットインスタンスを置き換えません。Amazon EC2 は常に、インスタンスを中断する前に EC2 インスタンスの再調整レコメンデーションと、スポットインスタンスの中断 2 分前の通知の両方を提供します。

**Topics**
+ [概要:](#capacity-rebalancing-overview)
+ [キャパシティーの再調整の動作](#capacity-rebalancing-behavior)
+ [考慮事項](#capacity-rebalancing-considerations)
+ [キャパシティの再調整を有効にして、リスクがあるスポットインスタンスをプロアクティブに置き換える](enable-capacity-rebalancing-console-cli.md)

## 概要:
<a name="capacity-rebalancing-overview"></a>

Auto Scaling グループでキャパシティの再調整を使用するための基本的な手順は、以下のとおりです。

1. 複数のインスタンスタイプとアベイラビリティーゾーンを使用するように Auto Scaling グループを設定します。そうすることで、Amazon EC2 Auto Scaling は各アベイラビリティーゾーンでスポットインスタンスの利用可能なキャパシティを検討できるようになります。詳細については、「[複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ](ec2-auto-scaling-mixed-instances-groups.md)」を参照してください。

1. 必要に応じてライフサイクルフックを追加して、再調整通知を受け取るインスタンス内でアプリケーションを正常にシャットダウンします。詳細については、「[Amazon EC2 Auto Scaling のライフサイクルフック](lifecycle-hooks.md)」を参照してください。

   以下は、ライフサイクルフックを使用するいくつかの理由です。
   + Amazon SQS ワーカーの正常なシャットダウンのために
   + ドメインネームシステム (DNS) からの登録解除を完了するには
   + システムログまたはアプリケーションログをプルし、Amazon Simple Storage Service (Amazon S3) にアップロードするには

1. ライフサイクルフックのカスタムアクションを開発します。カスタムアクションを呼び出すには、インスタンスの終了の準備が整ったタイミングを知る必要があります。インスタンスのライフサイクル状態を検出することでタイミングを確認します。
   + インスタンスの外部でアクションを呼び出すには、EventBridge ルールを作成し、イベントパターンがルールに一致したときに実行するアクションを自動化できます。
   + インスタンス内でアクションを呼び出すには、シャットダウンスクリプトを実行し、インスタンスのメタデータを介してライフサイクルスの状態を取得するようにインスタンスを設定します。

   カスタムアクションが 2 分以内に終了するように設計することが重要です。これにより、インスタンス終了前にタスクを完了するのに十分な時間が確保されます。

これらの手順を完了すると、キャパシティの再調整を使用できるようになります。

## キャパシティーの再調整の動作
<a name="capacity-rebalancing-behavior"></a>

キャパシティの再調整では、インスタンスが再調整レコメンデーションを受け取ると、Amazon EC2 Auto Scaling は次のように動作します。
+ 新しいスポットインスタンスの起動時、Amazon EC2 Auto Scaling は、新しいインスタンスがヘルスチェックに合格するまで待機してから、以前のインスタンスを終了させます。複数のインスタンスを置き換える場合、以前の各インスタンスの終了は、新しいインスタンスが起動され、ヘルスチェックに合格してから開始されます。
+ Amazon EC2 Auto Scaling は以前のインスタンスを終了する前に新しいインスタンスの起動を試みるため、指定された最大キャパシティに到達している、またはそれに近い状態は、再調整アクティビティを妨げたり、それらを完全に停止させる可能性があります。この問題を回避するために、Amazon EC2 Auto Scaling は一時的にグループの最大サイズを必要なキャパシティの最大 10% まで超過できます。
+ Auto Scaling グループにライフサイクルフックを追加しなかった場合、Amazon EC2 Auto Scaling は、新しいインスタンスがヘルスチェックに合格すると同時に以前のインスタンスの終了を開始します。
+ ライフサイクルフックを追加した場合は、前のインスタンスの終了を開始するまでの時間が、ライフサイクルフックに指定したタイムアウト値だけ延長されます。
+ スケーリングポリシーまたはスケジュールされたスケーリングを使用している場合、スケーリングアクティビティは並行して実行されます。スケーリングアクティビティが進行中で、Auto Scaling グループが新しい希望キャパシティを下回っている場合、Amazon EC2 Auto Scaling はまずスケールアウトを行ってから、以前のインスタンスを終了します。

あるアベイラビリティーゾーンに該当するインスタンスタイプのキャパシティがない場合、Amazon EC2 Auto Scaling は他の有効なアベイラビリティーゾーンで成功するまでスポットインスタンスの起動を試行し続けます。

最悪のシナリオでは、新しいインスタンスの起動に失敗するか、ヘルスチェックに失敗すると、Amazon EC2 Auto Scaling はインスタンスの再起動を試行し続けます。　 新しいインスタンスの起動試行中、以前のインスタンスは最終的に中断され、2 分間の中断通知により強制的に終了されます。

## 考慮事項
<a name="capacity-rebalancing-considerations"></a>

キャパシティの再調整を使用する場合は、次の点を考慮してください。

**スポットの中断に耐えられるようにアプリケーションを設計する**  
アプリケーションはインスタンス数の動的な変化と、スポット インスタンスが早期に中断される可能性に対処する必要があります。例えば、Auto Scaling グループが Elastic Load Balancing ロードバランサーの背後にある場合、Amazon EC2 Auto Scaling は、インスタンスがロードバランサーから登録解除されるまで待機してから、終了ライフサイクルフックを呼び出します。インスタンスの登録解除とライフサイクルアクションの完了にかかる時間が長すぎる場合、Amazon EC2 Auto Scaling がインスタンスを終了させる前にライフサイクルアクションの完了を待機する間に、インスタンスが中断される可能性があります。  
2 分間のスポットインスタンス中断通知の前に、Amazon EC2 が再調整のレコメンデーションシグナルを送信できるとは限りません。場合によっては、再調整のレコメンデーションシグナルが、2 分間の中断通知と同時に到着する可能性があります。この場合、Amazon EC2 Auto Scaling はライフサイクルフックを呼び出し、新しいスポットインスタンスをすぐに起動しようとします。

**代替スポットインスタンスが中断されるリスクの増大を回避する**  
`lowest-price` 割り当て戦略を使用している場合、代替スポットインスタンスが中断されるリスクが高くなることがあります。これは、代替スポットインスタンスが起動後すぐに中断される可能性が高い場合も、その時点で利用可能なキャパシティを持つ最低料金のプールでインスタンスを起動することが原因です。中断のリスクが高まるのを避けるため、`lowest-price` の割り当て戦略を使用しないことを強くお勧めします。代わりに、`price-capacity-optimized` の使用をお勧めします。この戦略では、中断される可能性が最も低く、可能な限り低価格のスポットプールで代替スポットインスタンスを起動します。したがって、近い将来に中断される可能性は低くなります。

**Amazon EC2 Auto Scaling は、可用性が同じかそれ以上の場合にのみ、新しいインスタンスを起動します**  
キャパシティ再調整の目的の 1 つは、スポットインスタンスの可用性を改善することです。既存のスポットインスタンスが再調整のレコメンデーションを受け取った場合、Amazon EC2 Auto Scaling は、新しいインスタンスが既存のインスタンスと同等かそれ以上の可用性を提供する場合にのみ新しいインスタンスを起動します。新しいインスタンスの中断のリスクが既存のインスタンスよりもひどい場合、Amazon EC2 Auto Scaling は新しいインスタンスを起動しません。ただし、Amazon EC2 Auto Scaling は引き続き Amazon EC2 スポットサービスから提供された情報に基づいてスポットキャパシティプールを評価し、可用性が向上した場合は新しいインスタンスを起動します。  
Amazon EC2 Auto Scaling が新しいインスタンスをプロアクティブに起動しないと、既存のインスタンスが中断する可能性があります。中断が発生すると、Amazon EC2 Auto Scaling は、スポットインスタンスの中断通知を受け取ると直ちに新しいインスタンスの起動を試みます。これは、新しいインスタンスが中断されるリスクが高いかどうかに関係なく起こります。

**キャパシティーの再調整は、スポットインスタンスの中断率を増加させるものではありません**  
キャパシティの再調整を有効にしても、[スポットインスタンスの中断率](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html) (Amazon EC2 がキャパシティを取り戻す必要があるときに再利用されるスポットインスタンスの数) は増加しません。ただし、インスタンスに中断のリスクがあることをキャパシティの再調整が検出した場合、Amazon EC2 Auto Scaling は直ちに新しいインスタンスの起動を試みます。したがって、リスクのあるインスタンスが中断された後に Amazon EC2 Auto Scaling が新しいインスタンスを起動するのを待つ場合よりも多くのインスタンスが置き換えられる可能性があります。  
キャパシティの再調整が有効になっているインスタンスをさらに置き換える可能性がありますが、事後対応ではなくプロアクティブに対応できるというメリットがあります。これにより、インスタンスが中断される前にアクションを実行できる時間が増えます。[スポットインスタンスの中断通知](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html)では、通常、インスタンスを正常にシャットダウンするための猶予期間が最大 2 分しかありません。キャパシティの再調整で新しいインスタンスが事前に起動されるため、リスクのあるインスタンスで既存のプロセスを完了できる可能性が高まります。また、インスタンスのシャットダウン手順を開始し、リスクのあるインスタンスで新しい作業がスケジュールされないようにしたり、新しく起動したインスタンスがアプリケーションを引き継ぐように準備することもできます。キャパシティの再調整のプロアクティブな置き換えにより、正常な継続性の恩恵を受けることができます。  
次の理論的な例は、キャパシティの再調整を使用するリスクとメリットを示しています。  
+ 午後 2 時 – インスタンス A に対する再調整のレコメンデーションを受け取りました。Amazon EC2 Auto Scaling が直ちに代替インスタンス B の起動の試行を開始するため、ユーザーはシャットダウン手順を開始する時間を確保できます。
+ 午後 2 時 30 分 – インスタンス B の再調整のレコメンデーションを受け取り、インスタンス C に置き換えられました。これにより、ユーザーはシャットダウン手順を開始する時間を確保できます。
+ 午後 2 時 32 分 – キャパシティの再調整が有効になっておらず、インスタンス A のスポットインスタンスの中断通知が午後 2 時 32 分に受信されていたとすれば、アクションを実行するための猶予時間は最大でも 2 分だけでした。ただし、インスタンス A はこの時点まで実行され続けていたはずです。