AWS re:Invent 2015: All You Need To Know About Auto Scaling (CMP201)
ELB
Auto Scaling group
- Auto scalingの主なコンセプト
- minimum capacity:ずっと動かしたいインスタンス
- maximam:最大数(予算のコントロールに使う)
望む数 参考
- 増減の振り幅?
AZ間のキャパシティーバランスを保つ
Lounch Configration
- どんなサーバを立ち上げるか
- AMI, instance type, size
- Security groupsm, SSH keys, IAM instance profile
- User data
- etc
- AZとsubnetを除いたインスタンス立ち上げ時に必要な情報をすべて設定する
Golden image approch
- Webサーバとかアプリとか設定とか全部作ったAMIを使う
- 変更しまくるとAMIだらけになる
- どれがどのバージョンかわかるようにする必要がある
- OSのバージョンアップとかでもAMIをアップデートする必要がある
おすすめ
- ベースAMIを作る
- Webサーバとかログのエージェントとかいれとく
- のこりはuserDataでやる
- あとはChefとかpuppetとか
- CodeDeployも
- UserDataでcodedeployをインストールする感じ
- CodeDeployも
- あとはChefとかpuppetとか
- バランスはチームの文化とかツールに依存する
インスタンスをターミネイトする時
- 猶予期間だけセッションがはけるのをまつ
どのインスタンスたターミネイトされるか
- Termination Policies
- 常にAZ間のバランスを保つ
- その上でどうターミネイトするか
- Longest running:一番古くローンチされたやつ
- Oldest launch configration:設定が古いやつ(AMI変えるとか)
- Closest to full billing hour:次の課金が近いやつ
- これは請求が1秒単位になったことでなくなったりしたのかな?[参考]:(https://dev.classmethod.jp/etc/amazon-ec2-ebs-billing-per-seconds/)
- ドキュメントにはまだ書いてある
いつスケールされるか
Scaling Plans
- いつローンチされていつターミネイトするか
- desired capacityよりローンチ済みのインスタンスが少なければ増えるし、多ければ減る
ELBとASGのインテグレーション
- トラフィックの分散
- アプリケーションのエンドポイントを1つに
- Connection drainingで登録解除中のインスタンスにリクエストを送らない
- ELBのメトリクスでスケール
- 複数のELBとあわせ動作できる
- インスタンスの登録と解除をターミネーションとあわせて自動で行う
- Auto Scaling groupでELBヘルスチェックを使える
- Scaling policyでELBメトリクスが使える
AutoScalingの利点
- 需要にあわせて自動でキャパシティを設定
- 信頼性
- インスタンスやAZの死亡に抗う
可用性と信頼性
- Health check
- 定期的に動く
- インスタンスがいい感じかチェック
- ダメなら交換
Health Checkの種類
- EC2 instance status: EC2のステータス
- ELB health check: ELBからのリクエストに対するレスポンスでチェック参考
- Manual: 自分で定義したヘルスチェック
- ディスクフルとかいろいろ
## AZごと死んだら * desired capacityを満たすように偏ることもある * AZが生き返るとリバランシングする
## Scaling policies * どのようにキャパシティが変わるか * desired capacityにあわせて * 個数で増減 * 割合で増減
スケジュールによるスケール
動的なスケーリングポリシー
- 需要によるイベントをスケールのトリガーにする
- メトリクスで需要を図る
CloudWatch
- CPUとかネットワークトラフィックとか
- アラーム = しきい値を指定した時間超えた
- 指定した時間 = evaluation period
- 一時的なCPUのスパイクでスケールさせたくない
- アラームがAuto Scalingに通知してスケールをキックできる
- 閾値超えからクールダウン終了までは別のアラームやスケールのイベントは起きない
めっちゃスパイクしたら間に合わなくね?
Step Scaling Policies
- 同じポリシーで段階的なステップを定義できる
- この段階的なステップでは追加のアラームやスケールが発生する
- コンソールでも定義できる
warmup period
Lifecycle Hooks
ユースケース
どう動く?
どうやる?
- 通知先を作る(SQSかSNS)
- IAM roleを作る(Auto Scaling to access the notification queue/topic)
- lifecycle hootとAutoScaling group, role ,通知先を連携
- フックで動くコードを書く
LifecycleActionToken
- アクションを続けたり破棄したりするのに必要
- 次のステップにわたしてこれ継続よろみたいな
アクションはどう書く?
SNSもいける
- インスタンスがInService, Terminatedになってから送られる
- Lifecycle hooksはその前の準備中に動く
スタンバイにできる
ググった単語
- descend
- arbitrary
- spectrum
- flip side
- grace period
- drain
- get rid of
- accordance
- sit on
- whatever
- boundaries
- fleet
- distribute
- reliability
- periodically
- superfluous
- counteract
- use a neat trick
- anticipate
- predicable
- disorient
- investigate
- abandon
- extract
- forensic