今日は、cloudpack の battle programmer Sebastianです。

AWSにはautoscalingと呼ばれる機能があります。
何それって人はgoogle先生にきくと良いよ
簡単に言うとサーバーが勝手に増えたり減ったりしてくれる機能です

AutoScalingはAMIのImageからLaunch Configurationに従ってEC2 instanceを立ち上げます
立ち上がったEC2 InstanceはElastic Load Balancing(ELB)の下にぶら下がりservice serverの一つとして動く事で負荷が大きい時に分散して行くわけです

下は、AutoScaleの基本的な流れ

AutoScaleの基本的な流れ

Sclae-out時は以下の流れ

  1. Amazon CloudWatch、もしくはSchedule-baseでEventのtriggerが発生
  2. instanceが起動(launched)
  3. 起動したinstanceを新たにAutoScalingGroupへ登録

Scale-in時は以下の流れ

  1. Amazon CloudWatch、もしくはSchedule-baseでEventのtriggerが発生
  2. 起動したinstanceを新たにAutoScalingGroupから解除
  3. instanceが削除(instance terminated)

ここで、問題です
AutoScalingは自動でInstanceを立ち上げます
正しく起動しましたか？
ELBは配下にぶら下がったInstanceをHelth Checkした後に問題がなければbalancingの対象として扱います
しかし、その際にServerの状態は完全な状態で起動した保証は何かあるでしょうか？
追加する前に確認したくなりませんか？

そういう時にちょっと便利な機能としてLifecycle Hookがあります

AutoScaleのLifecycle

AutoScaleにて起動するinstanceはInstanceの管理とは別途にAutoScale上にStatusを持ちます。
これはAutoScale上で今instanceがどのような状態に在るかを示すStatusで、AWSではこのStatusの遷移をLifecycleと呼んでいます。

以下がLifecycleの流れです。

LifeCycleの流れ

Scale-outの遷移

  1. Scale-outのtriggerが発生します。
  2. 新たなinstanceのStatusがPengingになります。起動を待つ状態です。
  3. AutoScalingGroupにinstanceを追加します。
  4. instanceが起動を終了するとELBへinstanceを追加します
  5. StatusがInServiceに遷移します。

Scale-inの遷移

  1. Scale-inのtriggerが発生します。
  2. StatusがTerminatingに遷移します。
  3. instancをELBからinstanceを削除します
  4. AutoScalingGroupからinstanceを削除します。
  5. instanceを削除します
  6. 削除後、StatusがTerminatedへ遷移します。

Lifecycle hook？

簡単に言うとLifecycle HookはAutoScalingにてInstanceの起動時と終了時にちょっと停めます。
停めて、通知します。
通知内容はAmazon SQS,Amazon SNSを用います。

Scale-outのlifecycle hook

Scale-outのlifecycle hook

Scale-outの遷移
  1. Scale-outのtriggerが発生します。
  2. 新たなinstanceのStatusがPengingになります。起動を待つ状態です。
  3. StatusがPending:waitとなります
  4. 指定した通知を送ります。
  5. ユーザーが通知を受け取り通知内容に記載されるuuidからwaitの解除を行います。
  6. wait解除を行うとStatusがPending:Proceedに遷移します。
  7. AutoScalingGroupにinstanceを追加します。
  8. instanceが起動を終了するとELBへinstanceを追加します
  9. StatusがInServiceに遷移します。

このように前述のLifecycleの流れの途中にPending:waitが入りユーザーの操作が含まれる様になります。
このwait状態時は6以降の処理は全て待機状態となり行われません。
AutoScalingGroupのタグも付きませんしELBにぶら下がる事もありません。
ただ、instanceの起動時に行われる処理はAutoScalingとは全く異なるので/etc/init.d/以下の処理は最後まで実行されsshにてログインも可能です。

Scale-inのlifecycle hook

Scale-inのlifecycle hook

Scale-inの遷移
  1. Scale-inのtriggerが発生します。
  2. StatusがTerminatingに遷移します。
  3. instanceをELBからinstanceを削除します
  4. StatusがTerminating:waitとなります
  5. 指定した通知を送ります。
  6. ユーザーが通知を受け取り通知内容に記載されるuuidからwaitの解除を行います。
  7. wait解除を行うとStatusがTerminating:Proceedに遷移します。
  8. AutoScalingGroupからinstanceを削除します。
  9. instanceを削除します
  10. 削除後、StatusがTerminatedへ遷移します。

このように前述のLifecycleの流れの途中にTermnating:waitが入りユーザーの操作が含まれる様になります。
このwait状態時は8以降の処理は全て待機状態となり行われません。
AutoScaleingGroupのタグはついたままです。
instanceのTerminate処理そのものが実行されていないのでinstanceの終了スクリプトは実行されておらずsshにてログインも可能です。

元記事は、こちらです。
「AutoScaling の Lifecycle Hook の流れ」