オートスケールグループのヘルスチェックについて調査してみたのでその時のメモ。(ELBのヘルスチェックではない)
オートスケールのヘルスチェックについて
オートスケールのヘルスチェックを利用することで不正なインスタンスを自動でterminateすることができる機能です。
ヘルスチェック（Auto Scaling インスタンス対象)
ELB ヘルスチェックのチェック間隔は ELB で設定します。
EC2 のヘルスチェック間隔は規定値に基づいて行われ、ユーザ側で変更する事はできません。
以下のいずれかの場合にオートスケールは対象のEC2インスタンスを不正なインスタンスとみなし、自動でterminateさせます。
- インスタンスステータスがrunning以外の場合
- システムステータスが impaired である場合
- オートスケーリンググループのElastic Load Balancingの設定を行っており、ヘルスチェックタイプでELBを選び、インスタンスがELBのOutOfServiceとなった場合
- AWS CLI を使用してインスタンスのヘルス状態を設定し、Unhealthyとして設定された場合
インスタンスステータスがrunning以外の場合
オートスケールグループのEC2の状態をstopにするとオートスケーリングのヘルスチェック機能によってterminateさせられます。
ただし、2014年の機能追加でオートスケーリンググループからEC2を取り外すことが出来るようになったので、例えばメンテナンスで一時的にstopにした時にterminateさせられないようにすることが出来るようになりました。
[新機能]Auto Scaling Groupからインスタンスを取り外せるようになりました！
上記ではAuto Scaling Command Line Tool : Developer Tools : Amazon Web Servicesというツールを使っていましたが、現在はAWS CLIで出来るようです。
デタッチ（オートスケーリンググループから出る）
$aws autoscaling detach-instances
[--instance-ids <value>]
--auto-scaling-group-name <value>
--should-decrement-desired-capacity | --no-should-decrement-desired-capacity
アタッチ（オートスケーリンググループに入る）
$aws autoscaling attach-instances
[--instance-ids <value>]
--auto-scaling-group-name <value>
例えばオートスケーリンググループのDescire=2の状態で
$aws autoscaling detach-instances --instance-ids i-3c09d3ce --auto-scaling-group-name TestAutoScale --should-decrement-desired-capacity
とした場合、should-decrement-desired-capacityオプションの指定により、1台のインスタンスがオートスケーリンググループから外れるとともにdesired=1になります。上記によって追加でインスタンスがオートスケールに入ることはありません。また、指定したインスタンスはrunningの状態のままオートスケーリンググループから外れます。
再度オートスケーリンググループに戻す場合には以下のコマンドを実行します。
$aws autoscaling attach-instances --instance-ids i-3c09d3ce --auto-scaling-group-name TestAutoScale
上記によって指定したインスタンスがオートスケールグループのインスタンスに戻りました。また、オートスケールグループのdesiredが2に戻りました。
以下のようにno-should-decrement-desired-capacityオプションを利用してデタッチした場合、
$aws autoscaling detach-instances --instance-ids i-3c09d3ce --auto-scaling-group-name TestAutoScale --no-should-decrement-desired-capacity
desire=2のままとなるのでオートスケールに1台インスタンスが追加されます。
システムステータスが impaired である場合
大きく分けて以下2パターンで確認しているようです。
1.システムステータスのチェック
- ネットワーク接続の喪失
- システム電源の喪失
- 物理ホストのソフトウェアの問題
- 物理ホストのハードウェアの問題
こちらはAWS内部の障害のようなイメージかと思います。
2.インスタンスステータスのチェック
- 失敗したシステムステータスチェック
- 正しくないネットワークまたは起動設定
- メモリの枯渇
- 破損したファイルシステム
- 互換性のないカーネル
こちらはインスタンス内の障害でユーザーの操作によっては発生する可能性があると思います。
オートスケーリンググループのElastic Load Balancingの設定を行っており、ヘルスチェックタイプでELBを選び、インスタンスがELBのOutOfServiceとなった場合
Auto Scaling グループに Elastic Load Balancing ヘルスチェックを追加する
オートスケーリンググループのElastic Load Balancingの設定を行っており、ヘルスチェックタイプでELBを選び、インスタンスがELBのヘルスチェックでOutOfServiceとなった場合、対象のインスタンスをterminateします。
オートスケーリンググループでELBを指定せず、オートスケーリンググループのEC2を手動でELBにひも付けた場合も同様に、ELBのヘルスチェックによってOut of serviceとなってELBから外れ、オートスケーリングの機能により インスタンスは terminateはされます。
オートスケーリンググループでELBを指定している場合でもヘルスチェックタイプでEC2を指定した場合、ELBのヘルスチェクでOutOfServiceになってもインスンスはterminateされません。
AWS CLI を使用してインスタンスのヘルス状態を設定し、Unhealthyとして設定された場合
こちらは利用者がみずから「このインスタンスは不正な状態である」とオートスケールに通知することが出来るものです。例えばオートスケーリンググループを定期的に監視し、いずれかの条件に合致した対象のインスタンスを停止する場合などに使えるのかと思います。
具体的には以下のコマンドで設定が可能です。
$aws autoscaling set-instance-health --instance-id i-123abc45d –-health-status Unhealthy
オートスケーリンググループに設定したHealth Check Grace Period
のタイミングでインスタンスがterminateされます。desiredの値は減らないため、terminateのタイミングで新しいインスタンスがオートスケールグループ内で起動します。