[アップデート] EC2 Auto Scalingで「インスタンスの最大起動時間」に基づいてインスタンスを置き換えることができるようになりました
みなさん、こんにちは!
AWS事業本部の青柳@福岡オフィスです。
EC2 Auto Scaling において、「インスタンスの最大起動時間 (Maximum Instance Lifetime)」に基づいてインスタンスを置き換えることができるようになりました。
Amazon EC2 Auto Scaling Now Supports Maximum Instance Lifetime
スケールイン時の終了ポリシー「OldestInstance」と何が違うの?(明確に違いました)
今回のアップデートを聞いた時、最初「あれ? なんか似たようなのがあったな?」と思いました。
スケールイン時にどの Auto Scaling インスタンスを終了するかのコントロール - Amazon EC2 Auto Scaling (日本語)
スケールイン時に指定できる「終了ポリシー」の中にある「OldestInstance」は、Auto Scalingグループ内で最も古い (つまり起動時間が最も長い) インスタンスを終了するというポリシーです。
なんだか似ている気がしますが、明確に違うものでした。
終了ポリシーの「OldestInstance」:
スケールインが発生した際に、優先的に終了するインスタンスを選択する基準
今回のアップデート「Maximum Instance Lifetime」:
スケールインに関係なく、稼働時に起動時間が一定を超えると新しいインスタンスに置き換えられる
違いが分かったところで、実際に試してみます。
設定してみた
ドキュメントに沿って設定を行いました。
Replacing Auto Scaling Instances Based on Maximum Instance Lifetime - Amazon EC2 Auto Scaling
マネジメントコンソールから設定する場合、Auto Scalingグループの新規作成ウィザードで「Maximum Instance Lifetime」を設定することはできません。
Auto Scalingグループを作成した後に、「操作」→「編集」から設定を行います。
「詳細の編集」ダイアログの下の方に「Max Instance Lifetime」の項目がありますので、時間を「秒」単位で指定します。
なお、指定できる範囲は「604800秒 (7日)」から「31536000秒 (365日)」までです。
設定を保存すると、Auto Scalingグループの詳細の表示からも設定内容を確認することができます。
一方、AWS CLIで設定する場合は、Auto Scalingグループの新規作成時に設定することができます。
まず、AWS CLIを最新バージョンにアップデートしましょう。
(私が試した際は以下のバージョンでした:2019年11月21日現在)
$ aws --version aws-cli/1.16.287 Python/3.6.7 Linux/4.4.0-18362-Microsoft botocore/1.13.23
設定内容を以下のようにJSONで記述します。
{ "AutoScalingGroupName": "example-asg", "LaunchTemplate": { "LaunchTemplateName": "example-launch-template", "Version": "1" }, "MinSize": 2, "MaxSize": 2, "MaxInstanceLifetime": 604800, "VPCZoneIdentifier": "subnet-01e25db25685791b5,subnet-043c872f466cb1320", "Tags": [] }
以下のコマンドを実行してAuto Scalingグループを作成します。
aws autoscaling create-auto-scaling-group --cli-input-json file://asg-config.json
なお、既存のAuto Scalingグループの「Maximum Instance Lifetime」を変更する場合は、以下のコマンドを実行します。
aws autoscaling update-auto-scaling-group --auto-scaling-group-name example-asg --max-instance-lifetime 604800
実際の動作を確認する (予定)→確認しました!
さて、設定を行いましたので、実際にどのような動作をするのか確認したいと思いま・・・したが、「Maximum Instance Lifetime」で設定可能な時間は、最短で「604800秒 (7日)」です。
したがって、現時点では実際の動きを確認することができません。
今回は最短の「604800秒 (7日)」に設定しましたので、1週間後に実際の動作を確認したいと思います!
2019/12/01追記:確認しました!
1週間 (+数日) が経過しましたので、どのように動作したのかを確認しました。
Auto Scalingグループの「アクティビティ履歴」を見てみます。
(下から上に向かって時系列が新しくなっています)
2019/11/21 06:37:20
AutoScalingグループを作成した日です。2台のインスタンスがほぼ同時刻に起動されています。
2019/11/28 06:25:23 (起動から「6日と23時間48分3秒」が経過)
1台のインスタンスが停止しています。
「原因」は「an instance was taken out of service in response to a maximum instance lifetime limit..」となっていて、「Maximum Instance Lifetime」の制限時間によって停止させられたことが分かります。
2019/11/28 06:25:26 (起動から「6日と23時間48分6秒」が経過)
新たに1台のインスタンスが起動しています。
「原因」は「an instance was launched in response to a maximum instance lifetime limit..」となっていて、これも「Maximum Instance Lifetime」による動作であることが分かります。
2019/11/28 06:30:57 ~ 06:31:00 (起動から「6日と23時間53分37秒」が経過)
同様に、もう1台のインスタンスが停止して、新たに1台のインスタンスが起動しています。
ドキュメントには「Maximum Instance Lifetime」の動作について以下のように記述されています。
- インスタンスは設定された最大稼働時間に近付くと停止する。(稼働期限よりも前に停止する)
- インスタンスは1台ずつ停止~起動が行われる。(すべてのインスタンスが同時に置き換わることを避ける)
今回の動作結果もこの内容に合致していることが分かります。
考慮すべきこと
「Maximum Instance Lifetime」の設定時間を調整して、休日や夜間のタイミングでインスタンスが停止・起動するようにしたいと考える方がいるかもしれません。
確かに、今回の動作結果を見ると「Maximum Instance Lifetime」の設定時間の数分前に停止が発動しましたので、そのような運用ができそうに思えます。
しかし、停止するタイミングが稼働期限の直前であるとは保証されていないようですので、気を付けるべきです。
ドキュメントには「Maximum Instance Lifetimeを設定してすぐにインスタンスの置き換えが発生する場合もある」と書かれています。
さすがにそこまで極端な例はそうそう無いでしょうが、いつ停止が発生してもよいように設計しておく必要があると思います。
おわりに
今回のアップデートが、どんな目的で使えるのだろうか? と考えてみましたが、例えば「セキュリティ観点から、古いインスタンスを長期間稼働し続けないようにする」という場面が考えられるのかなと思いました。
もちろん、他にも使いどころがあるアップデートだと思います。
今回は実際の動作まで確認することができませんでしたが、引き続きチェックしたいと思います。
(確認できました!)