Auto Scalingについて勉強
AWS 認定ソリューションアーキテクト – アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
- Auto Scalingとは
- 希望する容量（Desired Capacity）を目標とする
- スケールの具体的な方法
- オートスケールできる機能
- CloudWatch×Auto Scalingによる最適化の実現
- スケールイン時にどの Auto Scaling インスタンスを削除するかを制御
- よくある質問
Auto Scalingとは
リソースの使用状況をモニタリングし、その使用状況に応じてEC2インスタンスを自動でスケールアウトしたり、スケールインするサービス。あらかじめ設定したAMIからEC2を起動するので、AMIを最新化しておかないと、断面ずれが起きる可能性がある。
ユーザデータを利用してS3やGitからソースやスクリプトを取得することで、EC2インスタンスを最新の状態にすることができる。
特徴は、スケーラビリティの確保になる。
ELBでトラフィックの分散をして可用性を担保していたとしても、その分散を超えるアクセスが来た場合に対処ができないため、大量アクセスなどが発生した場合にそれに合わせてEC2を台数の増減などを行うことができる。
希望する容量（Desired Capacity）を目標とする
希望容量は、現実のEC2などの軌道台数との差を監視し、常に希望台数と合致するようにインスタンス数などを増減する仕組みのこと。
20191002 AWS Black Belt Online Seminar Amazon EC2 Auto Scaling and AWS Auto Scaling from Amazon Web Services Japan
Auro scaling group
スケールするインスタンスの最大数などの基本情報を設定する。- 起動インスタンスの最大数と最小数を設定する
- 希望容量になるようにインスタンスを起動・終了を調整する
- 軌道台数をAZ間でバランシングする
- AZ障害時に障害のないべつのAZにその分のインスタンスを起動する（AZの障害も見れる）
Auro scaling groupを利用することで、スケールアウトさせるときにAZを判断して最も少ないAZに新規起動させるなどもできる。
AZ間で偏りが発生しないように均等に配置することができる。
ミックスインスタンスグループ
オンデマンドインスタンスとスポットインスタンスをひとつのAutoScalingGroupで管理することが可能：オンデマンド：スポット＝９：１といった指定ができる。
オートスケーリングの起動設定
起動時のEC2インスタンス情報の定義。・使用するAMI
・インスタンスタイプ
・セキュリティグループ
・キーペア
などEC2を構築するときの必要なパラメータを設定してスケールアウトのインスタンス内容を決める
スケーリングプラン
以下でAuto Scalingを実行する条件を定義。サイズの維持：固定された希望容量に対し、障害などで停止するとの固定容量になるように維持する
- 手動スケーリング：希望容量を手動で変更して、スケールアウト/インを行う
- 自動スケーリング：CloudWatch Alarmなどが実行するとスケーリングポリシーに準じて自動で希望容量が変更されてスケールアウト/インを行う
- 予測スケジュール：予測された需要増時期に合わせたスケジューリングポリシーに準じてスケールアウト/インを行う
また、予測スケジュールと自動スケーリングを組み合わせることによって、アクセスされるピーク時までスケールさせて（予測スケジュール）さらに想像以上の台数が来た場合に、動的に希望容量を変えるということも可能になる。
スケールの具体的な方法
スケーリングのプランについては上に記載の通りだが、具体的にどのようにスケーリングするのかについては以下となる。
- 動的なスケーリング
- 予測スケーリング
- スケジュールスケーリング
動的なスケーリング
簡易スケーリング
EC2のみに使用できる。ひとつのCloud Watchメトリクスに対しひとつのスケーリング条件を指定する。
（CPU使用量50%超えたら1台追加など）
現在は非推奨。ステップスケーリングに切り替えることがおすすめされる。
ステップスケーリング
ひとつのCloud Watchメトリクスに対し複数のひとつのスケーリング条件を指定する。（CPU使用量50%超えたら1台追加、60%超えたら2台、70%超えたら3台など、複数設定可能）
CPU使用量によって台数を変化させるため、急激にCPU使用量が増加した場合、設定した台数よりも多く（少なく）スケールされる可能性がある。
（具体例としてはCPU50％超えたのでインスタンスを起動させていているが、70%を超えたので3台追加すると計4台追加してしまうため、想定の3台よりも1台多く起動されてしまう）
その問題に対応するためウォームアップ期間を設定して対応する。
その間は次のスケーリングの条件に合致して場合、立ち上げ中のものをカウントしてくれる仕組み。
デフォルト300秒。
ターゲット追跡スケーリング
ひとつのCloud Watchメトリクスに対し目的地を指定する。（CPU使用量を40％に維持し続けるなど）
この設定値を実施することでAutoScalingで自動でリソースが調整するようになる。
予測スケーリング
EC2のみに使用できる。2週間分のCloudWatchメトリクスを分析し、次の2日間のピークの需要予測をしてくれる。
24時間ごとに次の48時間の予測値を作成する。
予測するための基準時刻は毎時0分。そのため、10時に負荷のピークがくる場合に、10時ちょうどだと間に合わないため、その前に実行するように調整ができる。
デフォルトは5分前。
ただしこの機能はAutoScalingGroupを作成してすぐに実行することができない。
最低24時間分のデータが必要になる。
スケジュールスケーリング
一度限り、もしくは定期的なスケジュールを指定可能。ある程度事前にアクセスのピークなどがわかっている場合はスケジュールを事前に実施することでその時間前にスケールしてくれる。
具体的には設定上でMaxキャパシティとMinキャパシティを設定することによってその時点の容量が希望容量でなかった場合にスケールアウト/インする。
ケース１：ある時刻での希望容量にMinキャパシティに超えていない場合、スケールアウトして希望容量に併せる。
ケース2：ある時刻での希望容量がMaxキャパシティを超過している場合、スケールインして希望容量に併せる。
ケース3：ケース１とケース２両方やる。
20191002 AWS Black Belt Online Seminar Amazon EC2 Auto Scaling and AWS Auto Scaling from Amazon Web Services Japan
オートスケールできる機能
20191002 AWS Black Belt Online Seminar Amazon EC2 Auto Scaling and AWS Auto Scaling from Amazon Web Services Japan
EC2がメインだがその以外にも以下についても管理することができる。
CloudWatch×Auto Scalingによる最適化の実現
上記スケーリングプランに記載されているCloudWatchのメトリクスを利用することで、理興コストを抑えたシステム構築が可能。
例えばCPU使用率のメトリクスの閾値を超過したことをトリガーにAuto Scalingを起動し、スケールアウト・インを実施することが可能。
またピークがある程度予測できるのであれば、ピーク時の処理に合わせてリソースを拡張。過ぎたらリソースを縮小する。
業務上、新しいサービス展開した初日等、想定できるのであれば最適化を行うことで最適化することができる。
スケールイン時にどの Auto Scaling インスタンスを削除するかを制御
デフォルトの終了ポリシーでは、Auto Scaling グループの動作は以下のようになります。
1.インスタンスが最も多く、スケールインから保護されていないインスタンスが最低 1 つあるアベイラビリティーゾーンを決定します。
インスタンスが最も多いアベイラビリティーゾーンから選択する保護されていないインスタンスが複数ある場合は、以下の条件に基づいて (示されている順に適用)、終了するインスタンスが選択されます。2.[複数のインスタンスタイプと購入オプションを使用する Auto Scaling グループ のみの場合]
残りのインスタンスが、終了するオンデマンドインスタンスまたはスポットインスタンスの配分戦略、現在選択されているインスタンスタイプ、N 個の最低価格のスポットプールへの分散に合うように、終了するインスタンスを決定します。このようなインスタンスが 1 つある場合、そのインスタンスを終了します。それ以外の場合は、次の条件を適用します。3.[起動テンプレートを使用する Auto Scaling グループの場合]
いずれかのインスタンスが最も古い起動テンプレートを使用しているかどうかを判断します。このようなインスタンスが 1 つある場合、そのインスタンスを終了します (例外が 1 つあります。グループがもともと起動設定を使用していた場合です。Amazon EC2 Auto Scaling は、その起動設定を使用するインスタンスを終了してから、最も古い起動テンプレートを使用するインスタンスを終了します)。4.[起動設定を使用する Auto Scaling グループの場合]
いずれかのインスタンスが最も古い起動設定を使用しているかどうかを判断します。このようなインスタンスが 1 つある場合、そのインスタンスを終了します。5.2 から 4 のすべての基準を適用した後で、終了する保護されていないインスタンスが複数ある場合は、どのインスタンスが次の課金時間に最も近いかを判別します。このようなインスタンスが 1 つある場合、そのインスタンスを終了します (次の課金時間に最も近いインスタンスを終了すると、時間単価のインスタンスを最大限に活用できます)。
スケールイン時にどのAuto Scalingインスタンスを終了するかを制御する - Amazon EC2 Auto Scaling (日本語)
基本的にAZで偏らないようにスケールインする。
例えばインスタンス3台を2AZで設定している場合、デフォルト終了ポリシー上で1台終了させると、2台存在するAZからスケールインする。
またスケールインするうちの2台は古いもの。
ターミネーションポリシー
スケールインでインスタンスを削除するときなどどういうルールで実施するかを設定できる。①：OldesrInstance/NewestInstance：最も古いor最新起動時間のインスタンスの終了
②：OldestLaunchConfiguration：最も古い起動設定（AutoScaling側）のインスタンスの終了
③ClosestToNextInstanceHour：次の課金まで一番短いものを削除
④デフォルト：②と③の順に適用。その結果希望容量よりも多ければランダムに1台終了する
よくある質問
スポットインスタンスを使用して安く済ませたい
ミックスインスタンスグループを活用する。速やかにスケールアウト/インしてくれなくて困っている
インスタンスのCloudWatchの詳細モニタリングを有効にして、メトリクスと1分程度にすることで速やかにスケールすることが可能。（ただし有料）正常動作しない（起動に失敗した）インスタンスを自動で置き換えたい
AutoScalingではふたつのヘルスチェックにて確認することが可能。- EC2ヘルスチェック
- ELBヘルスチェック
EC2ヘルスチェック
デフォルトで有効。ELBヘルスチェック
ELBヘルスチェックはELBとEC2の組み合わせをしているときに有効にすることで確認可能になる。デフォルトのEC2ヘルスチェックに加えて、ELBに備わっているEC2へのヘルスチェックに応答しない場合も速やかに入れ替える。
スケールアウト/インを繰り返していつまでたってもインスタンスが追加されない
ヘルスチェックの猶予期間の設定を見直す。起動したばかりでまだELBやAutoScalingのヘルスチェックに対して応答できない場合ある（簡単に言うとOSが立ち上がっているときにマウス操作しても何の応答もないと同じ）
その場合はAutoScaling側で失敗とみなすので、立ち上げ中であることを知らせるためにヘルスチェックの猶予時間を設定する。
デフォルトは5分。
一時的にスケールアウト/インをやめたい
スケーリングプロセスの中断することで一時的に動作を停止することができる。動作のおかしいインスタンスがいるから止めたいという場合は、AutoScalingグループから外す。
AutoScalingから外す方法は主にふたつ
- スタンバイ
- デタッチ
スタンバイ
トラブルシューティングを行うために一時的に外す（生きている扱いとなる）。この場合、ヘルスチェック対象からも外れるため、その間に原因を特定して修正することが可能。
