(動画まとめ)AWS re:Invent 2015: All You Need To Know About Auto Scaling (CMP201)


AWS re:Invent 2015: All You Need To Know About Auto Scaling (CMP201)

ELB

Auto Scaling group

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をインストールする感じ
    • バランスはチームの文化とかツールに依存する

インスタンスをターミネイトする時

  • 猶予期間だけセッションがはけるのをまつ

どのインスタンスたターミネイトされるか

  • Termination Policies
    • 常にAZ間のバランスを保つ
    • その上でどうターミネイトするか

いつスケールされるか

Scaling Plans

  • いつローンチされていつターミネイトするか
  • desired capacityよりローンチ済みのインスタンスが少なければ増えるし、多ければ減る
    • default: ヘルスチェックがこけたインスタンスを潰して新しくローンチ
      • desired capacityは固定
    • Manual scaling:desired capacityをAPIとかコンソールとかで変える
    • Scheduled: スケジュールでやる
    • Dynamic scaling: CloudWatchメトリクスによるスケール

ELBとASGのインテグレーション

  • トラフィックの分散
  • アプリケーションのエンドポイントを1つに
  • Connection drainingで登録解除中のインスタンスにリクエストを送らない
  • ELBのメトリクスでスケール
  • 複数のELBとあわせ動作できる
  • インスタンスの登録と解除をターミネーションとあわせて自動で行う
  • Auto Scaling groupでELBヘルスチェックを使える
  • Scaling policyでELBメトリクスが使える

AutoScalingの利点

  • 需要にあわせて自動でキャパシティを設定
  • 信頼性

可用性と信頼性

  • 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

ユースケース

  • EIPのアサイ
  • DNSやらキューやらに登録
  • ターミネイトされる前にログをpull
  • ターミネイトされる前に問題の調査

どう動く?

参考

どうやる?

  • 通知先を作る(SQSかSNS
  • IAM roleを作る(Auto Scaling to access the notification queue/topic)
  • lifecycle hootとAutoScaling group, role ,通知先を連携
  • フックで動くコードを書く

LifecycleActionToken

  • アクションを続けたり破棄したりするのに必要
    • 次のステップにわたしてこれ継続よろみたいな

アクションはどう書く?

  • トークン、インスタンスID,その他パラメータの抽出
  • トークンはとっとく
  • なんかする
  • 終わったらCompleteLifecycleActionを送る
    • もっと時間が欲しければheartbeatを送る

SNSもいける

  • インスタンスがInService, Terminatedになってから送られる
    • Lifecycle hooksはその前の準備中に動く

スタンバイにできる

  • InServiceではない
  • Terminateもされない
  • InServiceに戻せる(API,CLI

ググった単語

  • 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