##1.AWS Auto Scaling##
アプリケーションの負荷を処理するのに適切な数のAmazon EC2インスタンスが生成、維持されます。
##2.スケールアウト・スケールイン##
- スケールアウト：インスタンスを追加されること
- スケールイン：インスタンスが削除されること
##3.必要な設定##
-
起動設定:何を立ち上げるのか、起動する要素を決めます。
-
AMI
-
インスタンスタイプ
-
セキュリティグループ
-
ロール
-
Auto Scaling グループ:どこで行うか、デプロイの範囲を決めます。
-
デプロイ設定
-
VPCとサブネット
-
ロードバランサー
-
最小・最大インスタンス数
-
キャパシティ
-
Auto Scaling ポリシー：いつトリガーとして実行するのか決めます。
-
ポリシー設定
-
スケジュール
-
オンデマンド
-
スケールアウト・インポリシー
##4.料金##
Auto Scaling 設定そのものは無料です。
##5.ヘルスチェック##
EC2ヘルスチェックにするか、ELBヘルスチェックにするか？
前者にすると、EC2インスタンスが正常に稼働しているかを調べるため、アプリケーションが正常に稼働しているかまではわからない。
なので、後者であれば、アプリケーションレベルの応答を持って正常と判断できる。
- EC2ステータス:インスタンスのステータスがrunning以外の状態を異常と判断
- ELB:ELBのヘルスチェック機能を活用する。
・猶予時間が短い場合、どのような問題が生じるのでしょうか.
ヘルスチェックの猶予期間はインスタンスの起動～アプリケーションデプロイ～サービス組み込み、までに要する時間よりも長くとっておく必要があります。
猶予期間が短い場合、インスタンスの構成が終わっていない状態でヘルスチェックが開始してしまい、結果ヘルスチェックに失敗→Terminateという動きになってしまいます。
場合によってはインスタンスが追加されないことで再度アラームが起き続け、インスタンス起動～削除の無限ループに陥ってしまう可能性もあるので注意してください。
##6.AMIかuser-dataか##
AMIはアプリケーションがき見込まれているため、起動が早い。ただし、アプリケーションを変更するたびに毎回AMIを作り直す必要がある。
ユーザーデータはアプリケーションは組み込まないため、変更時に手間がない。しかし、配備するたびにアプリケーションをインストールすす必要があるため、起動に時間がかかる。
変更の少ない部分はAMIで、変更の多いソースコードなどの部分や外部パラメータなどは、ユーザーデータで実装することは推奨されています。
##7.注意##
- データベースサーバーやファイルサーバーなどデータをローカルに保存する用途には向いていない。
- ステートフルな実装を求める。AMIから復旧するので、消えてしまうデータはRDS,S3などにおく構成にする。
- EC2,アプリケーションの起動に数分かかる。突発的なアクセスには向いていないので動的スケーリングではなく、スケジュールスケーリングを利用する。
##8.demo##
Auto Scalling demo
Auto Scaling を試してみた
##9.プラン##
| プラン | |
|---|---|
| 手動スケーリング | 設定外で予期せぬスケーリングが必要となった場合に手動でスケーリングを実施 |
| スケジュールベース | 予測された需要増時期にあわせたスケーリングスケジュールを設定 |
| 動的スケーリング | 予測不能なケースにスケーリングポリシーにスケール方針を設定して、動的にスケールアウトを実施 |
スケジュールを設定し、スケジュール設定を超過したら動的スケーリングにするといったように組み合わせることも可能です。
##10.設計のポイント##
- インスタンスの最大値／最小値の設定は慎重に設定する
- ステートフルなアプリケーションへの設定には、AutoScaling Groupでの自動設定が必要
- ライフサイクルフック（起動時または削除時にインスタンスを一時停止してカスタムアクションを実行）を使用、つまりターミネーション時に直ぐに削除していいものかを検討する。
- Auto-Scalingスラッシング（急なスケールインによる影響）を避ける
##11.スケールインポリシー##
需要減に基づくスケールインの際にどのインスタンスから終了するかを設定
| 1.OldestInstance | 古いインスタンスから終了する | インスタンスタイプを変更する時 |
| 2.NewestInstance | 新しいインスタンスから終了する | 新しい起動設定をテストしたい時 |
| 3.OldestLaunchConfiguration | 古い起動設定を使用しているインスタンスから終了する | Auto Scaling groupをアップデートして、以前のlaunch configurationを利用するインスタンスを置き換えたい時 |
| 4.ClosestToNextInstanceHour | 次の請求時間に最も近いインスタンスを終了する | インスタンスの利用量を最大化しつつコストを抑えたい時 |
| 5.デフォルト設定 | 3.4の順 その後、複数インスタンスが残った場合はランダムに終了する | Auto Scaling groupに1個以上のスケーリングポリシーを関連づけている時 |
##12.クールダウン##
スケーリング動作が完了してから別の動作が開始できるまでの秒数。
短期間にスケールアウトとスケールインを繰り返してしまう場合に利用する。
##13.予測スケーリング##
-
予測スケーリングとは
-
その名の通り、予測される需要に応じてAuto Scaling グループを事前に拡大/縮小することができる。
-
どんな時に利用するのか？
-
朝の始業時のスパイクなど、スリープ需要の変更のパターンが繰り返し発生するアプリケーションに適切です。