CloudFormationでAutoScale管理すると便利＋α

巨大なJSONファイルをメンテするのが嫌で今までCloudFomationを避けていたのですが、
とある要件があり先日からがっつりCloudFormationを触り始めています。
実際使ってみて、特にAutoScaleを管理するのがだいぶ楽ちんだなーとおもったので
その辺りをメモがてら残してみます。

また、CloudFormationを使っている時に
「この場合、この操作をするとどういう動作になるんだろう？」
といった疑問もいくつかあったので
その検証結果なども書いてみようと思います。

前置きその１：CloudFomationとは

JSONに書かれたインフラ構成をどわーっと構築してくれる、といったAWSサービスです。
クラスメソッドさんのブログが入門編としては最適です。
CloudFormation入門 | Developers.io

設定の基本

この辺りを抑えておくだけで基本的な設定はできると思います*1

Parameters

入力項目を設定するカテゴリです。
デフォルト値を設定しておいて、実行する時に弄りたいパラメータなどを設定しておくと良いでしょう。

  ...
  "Parameters" : {
    "KeyName" : {
      "Description" : "Name of an existing EC2 KeyPair to enable SSH access to the web server",
      "Type" : "String"
    }
  },
  ...

Resources

AWSのリソース毎の設定です。
WebサーバのEC2インスタンス／DBサーバのEC2インスタンス／RDS／etc...など、
リソース毎にプロパティを設定出来ます。

  ...
  "Resources": {
    "WebServer" : {
      "Type" : "AWS::EC2::Instance",
      "Properties" : {
        "ImageId" : "ami-xxxxxxxxx",
        ...
      }
    },
    "DBServer" : {
       ...
    }
  ...
  },
  ...

Ref

他のアトリビュートを参照することが出来ます。
例えば、先ほどの例を使って
Parametersに入力された値を参照したいときには
以下のようになります。

    "WebServer" : {
      "Type" : "AWS::EC2::Instance",
      "Properties" : {
        ...
        "KeyName" : { "Ref" : "KeyName" },
        ...
      }
    },

前置きその２：AutoScaleについて

AutoScale便利なのですが、
初期設定でLaunchConfig設定したりGroup設定したりPolicy設定したりAlerm設定したり。。。
更新時にはLaunchConfigを新規に作り直してGroupの紐付けをする必要があったり。。。
まーとにかくめんどい！！！
AutoScaleの概要を知りたいのであれば、以下のスライドがまとまっていて良いです。
http://www.slideshare.net/serverworks/auto-scaling-17149997

前置きその３：UpdatePolicyについて

AutoScaleのローリングデプロイ*2を行うための設定です。
後述しますが、更新時の動作に大きな影響があるので覚えておきましょう。
http://aws.typepad.com/aws_japan/2013/02/three-new-features-for-aws-cloudformation.html

  "UpdatePolicy" : {
     "AutoScalingRollingUpdate" : {
        "MaxBatchSize" : "1",   // 一度に入れ替えを行うインスタンス数
        "MinInstancesInService" : "1", // 入れ替えを行っている最中、最低限残すインスタンス数
        "PauseTime" : "PT0S"  // 入れ替えと入れ替えの間のインターバル？0-3600の間で設定。
     }
  }

前置き終わり

というわけで、CloudFormationを使うと
AutoScaleの面倒なところをあまり意識せずに管理することが出来ます。
CloudFormationのテンプレートサンプルにAutoScaleのテンプレートがありますので
コピペして必要な部分だけ入れ替えればほぼそのまま流用可能です。
http://aws.amazon.com/jp/cloudformation/aws-cloudformation-templates/
https://s3.amazonaws.com/cloudformation-templates-us-east-1/AutoScalingMultiAZSample.template
https://s3.amazonaws.com/cloudformation-templates-us-east-1/VPC_AutoScaling_and_ElasticLoadBalancer.template

サンプルテンプレート

https://gist.github.com/toritori0318/6329255

入力画面。

size/image-id/instance-typeなどを入力できるようにしておいて、
UpdateStack時に変更できるようにしています。

FAQ

CloudFormation+AutoScaleで検証した結果をFAQ形式にしてみました。

Update StackでAutoScaleのsizeを変更するとどうなりますか？

問題なく反映されます。min-size/max-sizeだけでなくdesired-capacityも設定したほうが良いでしょう。

Update StackでAutoScaleのインスタンスタイプを変更するとどうなりますか？

UpdatePoricyの設定有無により動作が変わるようです。

UpdatePoricy なしの場合
- 問題なく反映されます。ただし即時反映はされないので手動でTerminateするなどしたほうが良いでしょう。
UpdatePoricy ありの場合
- 問題なく反映されます。即時、UpdatePoricyの設定に従った入れ替えが行われます。

Update StackでAutoScaleのAMI入れ替え行うとどうなりますか？

UpdatePoricyの設定有無により動作が変わるようです。

UpdatePoricy なしの場合
- 問題なく反映されます。ただし即時反映はされないので手動でTerminateするなどしたほうが良いでしょう。
UpdatePoricy ありの場合
- 問題なく反映されます。即時、UpdatePoricyの設定に従った入れ替えが行われます。

このように、基本的には想定通りの動作になります。
通常、AutoScaleでAMIの入れ替えやインスタンスタイプの変更を行うときには
LaunchConfig新規作成し、Groupを付け替え、古いLaunchConfigを削除、
といったことを手動で行わないといけませんが、その辺りも気を利かせて全て実行してくれます。