自動スケーリンググループのEC2インスタンスをシャットダウンする際の欠点はありますか？
EC2インスタンスを24時間後に自動終了させたい。
これは、インスタンスの起動時に実行されるスクリプトを使用して行います。
shutdown | at now + 24 hours
インスタンスがシャットダウンすると、インスタンスがシャットダウンし、EBSボリュームが終了するため、問題ありません。
コンソールでは、インスタンスは、終了したと宣言されるまで、しばらくの間到達不能として示されます。この方法でインスタンスをシャットダウンするのは悪い習慣ではないのでしょうか。また、AWSCLIでインスタンスを終了する方がよいのではないでしょうか。
docs 言う：
Terminal-instancesコマンドを使用してEC2インスタンスを終了すると、OSレベルで以下が登録されます。
APIリクエストは、ボタンを押すイベントをゲストに送信します。
ボタンを押すと、さまざまなシステムサービスが停止します。 systemdは、システムの正常なシャットダウンを処理します。グレースフルシャットダウンは、ハイパーバイザーからのACPIシャットダウンボタンの押下イベントによってトリガーされます。
- ACPIシャットダウンが開始されます。
- グレースフルシャットダウンプロセスが終了すると、インスタンスはシャットダウンします。構成可能なOSシャットダウン時間はありません。
インスタンスは、REST Webサービスを実行する自動スケーリンググループに含まれているため、実行されたばかりのリクエストが存在する可能性があります。
- まだ実行中のリクエストはどうなりますか？ （RESTサービスには30秒のタイムアウトがあるため、リクエストはそれより長く実行されません。）
shutdownを使用した終了は、AWS CLIを使用した場合よりも順序が悪くなりますか、それとも自動スケーリンググループによる終了ですか？
シャットダウンの1〜2分前に、detach-instances apiを使用して、自動スケールグループからインスタンスを削除します。 detach-instances apiは、アタッチされている場合、ロードバランサーからインスタンスも削除します。 https://docs.aws.Amazon.com/en_pv/autoscaling/ec2/userguide/detach-instanceを参照してください。詳細については、-asg.html を参照してください。
例：
aws autoscaling detach-instances --instance-ids i-05b4f7d5be44822a6\--auto-scaling-group-name my-asg --should-decrement-desired-capacity
ロードバランサーからインスタンスを削除しない場合、インスタンスで実行されている実行中のリクエストはエラーになります。これは、リスニングプロセスがインスタンスのOSによってtcp接続が閉じられたときに、ロードバランサーが接続を閉じたイベントを認識するためです。終了しました。
そうです、シャットダウンによる終了は、ASGから切り離すよりも秩序がありません。