Auto ScalingはAWSの重要な基本サービスです。Amazon CloudWatchによって収集蓄積されたシステム若しくはユーザー定義されたメトリックを契機として、必要に応じてAmazon EC2インスタンスを起動、終了することによって負荷の変化に反応する高い拡張性と弾力性のあるアプリケーションを構築するために使用することができます。
本日、Auto scalingにAuto Scaling Groupに管理されたEC2 インスタンスを制御する3つの機能を追加したことをお知らせいたします。ライフサイクルフック機能を使うことで、インスタンスの停止と起動のプロセスを追加制御することができます。デタッチインスタンス機能は、Auto Scaling Groupからインスタンスを取り除く機能です。スタンバイステート機能は、トラブルシューティングやメンテナンスのため、インスタンスをStandby状態にすることもできます。
ライフサイクルアクション &フック機能
Auto Scaling Group内のそれぞれのEC2インスタンスは生存期間中での遷移の状態、状態定義を保ちます。スケールアウトイベントに反応して、インスタンスが起動され、グループに追加され、利用ができる状態になります。その後、イベントでの事象に反応して、インスタンスはグループから除外され、削除されます。本日の新機能によって、以下のようなインスタンスライフサイクルの追加制御が可能になりました。:
- EC2インスタンスが起動後、グループに追加されるまで(Auto Scaling ではPending状態と呼びます)についてです。これは、インスタンスを完全に用意するために初期化処理が必要なときに効果的な機会です。この際に、ソフトウェアのインストールや設定、EBSボリュームの作成、初期化、アタッチ、メッセージキューイングへの接続、等が可能になりました。
- EC2がグループから除外後、削除されるまで（Auto Scaling ではTerminating状態と呼びます）についてです。インスタンスを完全に消去するために追加処理を入れることができます。この処理の進行中に、最後に取得したEBSスナップショットを記録したり、ログを耐久性の高いストレージに退避したり、デバッグ目的で起動しないインスタンスをグループ外で保持したり、といったことが可能になりました。
Auto Scaling Groupそれぞれに対して、ライフサイクルアクションのセットを設定できます。メッセージには、グループ（SQSキューやSNSのトピック）の通知対象にインスタンスがPending状態かTerminating状態に入るたびに送信されます。アプリケーションが、メッセージをハンドリングし、適切や初期化処理や削除処理を構成することができます。
メッセージが送信された後、インスタンスは適切に、 Pending:Waitか Terminating:Waitという状態になります。一度、インスタンスがこの状態に入ったら、アプリケーションは制御するために60分間与えられます。もし、その制御処理が60分以上かかるのであれば、Auto Scalingに“ハートビート”を発行することで、アプリケーションは時間を延ばすことができます。時間（既存60分、または拡張時間）が切れた場合、インスタンスは待ち状態から解放されます。
インスタンスが準備または削除された後に、アプリケーションはAuto Scaling にライフサイクルが完了したこと、次の状態に遷移したこと、を伝える必要があります。これを行うには、インスタンスにPending:Proceedか Terminating:Proceedを設定します。
Command Line Interface (CLI) または Auto Scaling APIからライフサイクルフックを作成、管理できます。こちらが最も重要な機能です。:
PutLifecycleHook- Auto Scaling Group向けにライフサイクルフックを作成、更新します。インスタンスが起動、停止するときに作用するフックを作成するために、この機能をコールします。CompleteLifecycleAction- ライフサイクルフックにライフサイクルアクションの完了を知らせます。フックがインスタンスを設定または廃棄するのに成功した際にこの機能をコールします。RecordLifecycleActionHeartbeat- ライフサイクルアクションのハートビートを記録します。ライフサイクルアクションのタイムアウトを延長するために、この機能をコールします。
スタンバイステート機能
InService状態からStandby状態にインスタンスを移動させ、更に状態を戻すこともできるようになりました。インスタンスがスタンバイ状態になったとき、これはまだAuto Scaling Groupによって管理下にある状態を示しますが、InService状態に戻る段階まではサービスからは取り除かれます。 この機能は、インスタンスを更新、修正、トラブルシュートする際に使用することができます。 特定のイベント後にインスタンスの状態を確認でき、重要なログや他のデータを取り出すために、隔離して割当することができます。
もし、Auto Scaling Groupに関連付けされたElastic Load Balancerがあれば、スタンバイ状態へ遷移により、ロードバランサからインスタンスを登録解除します。ロードバランサのConnection Draining機能を有効にしている場合、トラフィックが停止するまで、遷移が有効になりません。これには時間がかかる場合があります。
デタッチインスタンス機能
Auto Scaling Groupからインスタンスを取り除き、独立して管理することができるようになりました。インスタンスはそのまま非アタッチされた状態で利用することもできますし、必要であれば、別のAuto Scaling Groupにアタッチすることもできます。DetachInstances機能をコールする際に、Auto Scaling Groupの希望のキャパシティ （初期起動数）の変更要求することも可能です。
2つの違った用途でこの新機能を使用することできます。1つは、構成変更や更新を実施するために、インスタンスを1つのAuto Scaling Groupから別のAuto Scaling Groupに、インスタンスを移動することが可能な点です。もう1つは、アプリケーションに最適な構成を見つけるためにインスタンスを追加削除しながら、異なるEC2インスタンスタイプを混在させて検証することが可能な点です。
Auto Scalingの全体的な概念を理解する際に、検証や手っ取り早く操作経験を得る目的でこの機能は使用できます。CreateLaunchConfigurationを使って起動設定を、CreateAutoScalingGroupを使って新しいAuto Scaling Groupを作成し、両方のケースで既存のEC2インスタンスのインスタンスIDを使用します。テストを実施後にAuto Scaling Groupからインスタンスを取り除くために、DetachInstancesをコールします。
区分を目的とした「インスタンスファクトリ」を作成することでも、この新しいデタッチインスタンス機能を使えます。例えば、アプリケーションは、ログインした際にそれぞれのユーザーは完全に初期化された新しいEC2インスタンスにアサインされる仕様と仮定します。恐らく、アプリケーションは初期化するために時間を要しますが、ユーザーはこの処理が完結するのを待つことを望まないでしょう。そこで、Auto Scaling Groupを作成し、想定されるログイン数を元にしていくつかのインスタンスを常に予約状態に維持する構成にできます。ユーザーがログインした際に、その処理のためにインスタンスを割当でき、Auto Scaling Groupからインスタンスをデタッチし、そのユーザーに即時に占有させます。Auto Scalingは、予約されたキャパシティの希望数を維持するために、グループに新しいインスタンスを追加するでしょう。
今すぐ利用できます
これらの新機能は3つ全て、今すぐ使用でき、本日からご利用頂けます。 AWS Command Line Interface (CLI) と Auto Scaling APIのみからアクセスできます。
-- Jeff;
この記事はAWSシニアエバンジェリスト Jeff BarrのAmazon Web Services Blogの記事、 を 平山毅 (Facebook, Twitter)が翻訳したものです。