この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Auto Scalingのキーワード
Auto Scalingを理解する上で理解が必要なキーワードについてご紹介します。パート2
アラーム（Alarm）
Amazon CloudWatchアラームは、メトリクスを監視し、その状態によって値が変更され、処理を実行します。 アラームを作成するには、Amazon CloudWatchのPutMetricAlarmを実行してください。 （メトリクスのための閾値、評価する期間の数、アラームの状態が変わったときに実行するAmazon SNS処理（オプション指定）を指定します。）
アラームには３つの状態があります。
- OK：メトリクスは定義された閾値内です。
- ALARM：メトリクスは定義された閾値外です。
- INSUFFICIENT_DATA：メトリクスは使用不可能、または、状態をOKにするのに十分なデータが足りない状態です。
アラームが状態を変更し、その状態が残り期間内にあるとき、動作は呼び出されます。 この変更は、OKからALARM、ALARMからINSUFFICIENT_DATAなどかもしれません。 状態変更は指定する期間の間は維持されなければなりません。 Auto Scalingポリシーとともに、CloudWatchメトリクスが事前に定義された閾値に達したとき、 Auto Scalingの動作を実行するためにアラームを設定できます。 この機能は以前"トリガー"と呼びましたよね。
スケジュールされたアップデート（Scheduled Update）
スケジュールされたアップデートは将来予定されているAuto Scalingへの呼び出しです。 現在、アップデートは、最小（mix-）と最大（max-）、そして指定された容量だけサポートしています。 詳しくは、PutScheduledUpdateGroupAction APIを確認してください。
スケーリングアクティビティ（Scaling Activity）
スケーリングアクティビティは、グループのサイズを変えるなどのAuto Scalingへの変更を実装した、長期間動作するプロセスです。 それは、インスタンスを置き換えるとか、サービスによってサポートされた処理を長時間実行するプロセスだったりするかもしれません。
Auto Scalingによるインスタンスの終了（Auto Scaling Instance Termination）
Auto Scalingは、TerminateInstanceInAutoScalingGroupやその他のスケーリングアクティビティによってAmazon EC2 を終了させることができます。例えば、Availability Zoneへの振り分けをし直す（リバランス）ときや、Auto Scalingグループのサイズを減らすときなどです。 Auto Scalingは、Auto Scalingグループ内のインスタンスを終了させる場合、以下の条件から選択します。
- Auto Scalingは、最新の起動コンフィグを持っているものを保持しようと試みます。言い換えれば、Auto Scalingグループが最新のものとの異なる起動コンフィグを持ったAmazon EC2インスタンスを保持する場合、Auto Scalingは現在はAuto Scalingグループに関係づけられていないとみなして終了させようと試みます。もし、上記のようなインスタンスが複数ある場合、Auto Scalingは請求時間が最も古い（ランニング時間ではないです）インスタンスを終了させます。
- Auto Scalingは、Availability Zoneを超えてバランスを維持するために、特定のAvailability Zoneからインスタンスを終了させるかもしれません。
Auto Scalingが、どの特定のインスタンスを終えたらよいかを決定した後に、そのインスタンスがELB(Elastic Load Balancing)グループ の一部であるか確認します。もし、そうであれば、Auto Scalingは、Elastic Load Balancingグループからインスタンスを取り除くように ELBへ指示して、完了するのを待ちます。もし、インスタンスが、Elastic Load Balancingグループの一部でないなら、Auto Scalingは、 システムのシャットダウンスクリプトを実行することによってインスタンスの終了を試みます。
クールダウン（Cooldown）
クールダウンは、Auto Scalingがスケーリングアクティビティを開始した後に、他のアクティビティが動けない期間です。 クールダウン期間によって、スケーリングアクティビティの効果は元々アクティビティのトリガーとなったメトリクスで見えるようになります。 この期間は変更可能で、容量に影響するどんな新しいスケーリングアクティビティ（スケールアウト/スケールイン）にも働いて、適応するシステム時間を与えます。
クールダウンを無視してスケーリングアクティビティを行いたい場合は、SetDesiredCapacityを使うことができます。 SetDesiredCapacityはデフォルトでクールダウンを無視し、一般的に２つの使い方があります。 Auto Scaling によってシステムをトリガーする場合と、他に、開発者が自分自身でシステムをトリガーする記述をした場合です。両方のユースケースがクールダウンに関連していると言えます。
１つ目の使い方は、Auto Scalingがシステムをトリガーした場合、SetDesiredCapacityはクールダウン期間に関係なくAuto Scalingグループのサイズを変更します。これは便利で、例えば、Auto Scalingに予想外の出来事が行ったときに使います。 もし、クールダウンが１０分間だとすると、１０分の間Auto Scalingグループのサイズ変更要求を受け付けません。 SetDesiredCapacityコマンドは、クールダウン期間が終わるまでこの制限を回避して、Auto Scalingグループのサイズを変更します。
２つ目の使い方は、システムが自分自身をトリガーする場合、Auto Scalingグループのサイズを制御するために SetDesiredCapacityを使うことができます。もし、Auto Scalingの指示によるクールダウン処理を受付けたいなら、SetDesiredCapacityコマンドのHonorCooldownパラメータをtrueにすることによって、クールダウンを受け入れるかどうか設定することができます。
一時停止のプロセス（Suspendable Processes）
もしかしたら、手動操作や緊急時に自動操作をオフにするために、自動化されたスケーリングのプロセスを停止したいかもしません。 これらの要求を満たすために２つの方法を提供しています。 一時停止プロセス（SuspendProcesses）と再開プロセス（ResumeProcesses）です。 いつでも一時停止できますし、準備が整えば、一時停止したプロセスをいつでも再開できます。 もし、Auto Scalingグループの全てのスケーリングプロセスを一時停止させたなら、Auto Scalingはどんな理由でもそのグループに対してスケーリングアクティビティを作成しません。 （ちなみに、一時停止する前に既に進行中のスケーリングアクティビティは、完了するまで処理が続きます。）
SetDesiredCapacityとUpdateAutoScalingGroupへの呼び出しで、Auto Scalingグループへ行われた変更は、すぐに反映されます。 しかし、希望する数とインスタンスの実際の数に違いがあるとき、Auto Scalingは新しいスケーリングアクティビティを作成しません。
SuspendProcessesの呼び出しでAuto Scalingのプロセスタイプを以下のように指定することによって一時停止することができます。
- AlarmNotifications：全てのAmazon CloudWatch通知を無視する。
- AZRebalance：Availability Zone間のリバランスをしません。しかし、Auto Scalingが他の理由でインスタンスの起動か終了をするときは動きます。あるAvailability Zone内のインスタンス数が不足しているときか過剰なときです。
- HealthCheck：自動的にヘルスチェックをしません。しかし、SetInstanceHealthによって健康ではないと判断されたインスタンスは置き換えられます。
- Launch：新しいインスタンスを起動しません。これを有効にすると、AZRebalanceとReplaceUnhealthyプロセスは一時停止します。
- ReplaceUnhealthy：不健康とマークされたインスタンスを置き換えません。しかし、Auto Scalingは不健康であると判断したインスタンスにマークを付け続けます。
- ScheduledActions：スケジュールされたアクションを実行を一時停止します。一時停止中に起こるスケジュールされたアクションを全て無断に破棄します。
- Terminate：どんな理由であっても、新しいインスタンスを終了させません。これを有効にすると、AZRebalanceとReplaceUnhealthyプロセスは一時停止します。
プロセスタイプの指定無しにSuspendProcessesを呼び出すことによって、全てのAuto Scalingプロセスタイプを一時停止することができます。
Auto Scalingは時々インスタンスの起動に連続して失敗するAuto Scalingグループに対する一時停止します。 これは管理された一時停止としてしられており、実行しているインスタンスがゼロのグループ、24時間以上インスタンスを起動しようとしているグループ、そしてその間どのインスタンスを起動にも成功していないグループに対して適用されます。
重要なことですが、プロセスの再開には、一時停止が手動か管理されたものだったかに関わらず手動で行う必要があります。ResumeProcessesを使ってください。
アベイラビリティゾーン と リージョン
Auto Scalingは、１つのリージョン内の複数のアベイラビリティゾーンを跨いだAuto Scalingグループによって、 地理的な冗長化による安全性と信頼性を得ることができます。 もし、１つのアベイラビリティゾーンが不健康な状態になると、Auto Scalingは、 影響を受けていないアベイラビリティゾーンでインスタンスを起動します。 もし、不健康なアベイラビリティゾーンが健康な状態に戻ったら、Auto Scalingは、自動的に均等に全てのアベイラビリティゾーンに渡ってインスタンスを再配置します。
複数ゾーンに渡ったインスタンスの配分とバランス
Auto Scalingは、Auto Scalingグループ内における複数のアベイラビリティゾーンで、インスタンスの均等な配分を試みます。 Auto Scalingは、最小のインスタンス構成でアベイラビリティゾーン内のインスタンス起動を試みます。もし、起動に失敗すると、 Auto Scalingは、他のアベイラビリティゾーンで起動するまで試みます。 何かしらの操作や状態によって、Auto Scalingグループ内のバランスが保たれなくなったとき、Auto Scalingは、以下のような状態のときにリバランスによって釣り合いを取ります。
- Auto Scalingグループのためにアベイラビリティゾーンを変える要求を出した場合。
- TerminateInstanceInAutoScalingGroupによってバランスを失った場合。
- 不十分な容量のアベイラビリティゾーンが、回復して利用可能な容量を得た場合。
Auto Scalingは、古いインスタンスを終了させる前に新しいインスタンスを起動するため、リバランスにおいてアプリケーションの性能に悪影響を及ぼすことはありません。
再大容量を超えて複数ゾーンに渡ったインスタンス数について
Auto Scalingは、常に古いインスタンスを止める前に新しいインスタンスを起動するため、 最大容量に近づくとリバランスを妨害したり処理を止めてしまうかもしれません。 この問題を避けるために、システムは一時的にリバランスの間、１０％だけ（または１インスタンス）指定された最大容量を超えることができます。 マージンは、Auto Scalingグループが最大容量に近くてリバランスをする必要の時だけ拡張されます。 または、ユーザ要求によるゾーン変更か、アベイラビリティゾーンの問題により釣り合いを取るときに同じく拡張されます。 この拡張は、必要に応じて通常数分間続きます。
まとめ
Auto Scalingは、複数のアベイラビリティゾーンに渡ってインスタンスを正常に継続的に運用するために最も必要な仕組みであることがよくわかりました。必ず使いましょう！
3
