この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ども、大瀧です。
年明け一発目のAWSアップデートとして、Auto Scalingの新機能がリリースされました。ちょっと分かりにくい機能なのですが、上手く使えば今までのAuto Scalingの弱点を補うポテンシャルを持つ機能だったので、ご紹介したいと思います。
2013/01/09 Python版AWS CLIが本アップデートに対応したので、コマンドの実行例を追加しました。
Auto Scalingの既存EC2インスタンスの活用とは
AWS Auto Scalingは、EC2インスタンスの作成、破棄を自動で行うクラウドならではの管理機能です。ただ、従来のAuto Scalingでは以下の制限があり、初めて使う方にとっては敷居の高い印象がありました。
- Auto Scalingを利用するためには、インスタンス起動設定(Launch Configuration)を作成してからAuto Scalingグループを作成する2段階の操作が必要
- Auto ScalingのLaunch Configurationは、AMIイメージからセキュリティグループの選択までの起動設定を一から行わなければならない
- Auto Scalingで管理していない一般のEC2インスタンスは、Auto Scalingの管理下に入れることはできない
今回の機能追加は、上記制限を取り払い、既存のEC2インスタンスを利用してより簡単にAuto Scalingを使えるようにするものです。
- Auto Scalingグループの作成をLaunch Configurationなしで行えるようになった！
- Launch Configurationの設定を既存EC2インスタンスから流用できるようになった！
- 既存EC2インスタンスをAuto Scalingグループに追加できるようになった！
これらの新機能は、2013年1月9日現在、Java版/Python版 AWS CLIとAWS APIで利用することができます。Management Consoleでは利用できないことに注意してください。
では、それぞれ見ていきましょう。
1. Auto Scalingグループの作成
Auto Scalingグループの作成時に、既存EC2インスタンスの設定を流用してLaunch Configurationなしでできるようになりました。厳密に言うと、既存EC2インスタンスの設定を元にAuto Scalingグループと同名のLaunch Configurationが自動作成される形になります。
具体的には、as-create-auto-scaling-groupコマンドに--instance-idオプションで、流用するEC2インスタンスのインスタンスIDを指定します。このEC2インスタンスはRunning状態にする必要があるなど、いくつかの要件があります。詳細はドキュメントを参照してください。
Java版
$ as-create-auto-scaling-group asg1 --instance-id i-XXXXXXXX --region ap-northeast-1 ¥
--min-size 1 --max-size 1 --desired-capacity 1
OK-Created AutoScalingGroup
$Python版
$ aws autoscaling create-auto-scaling-group --auto-scaling-group-name asg1 ¥
--instance-id i-XXXXXXXX --region ap-northeast-1 ¥
--min-size 1 --max-size 1 --desired-capacity 1
$Management Consoleで見ると以下のような結果になります。ちゃんとできてますね。
ただ、グループに設定するVPCサブネットは既存EC2インスタンスに設定されている単一AZのVPCサブネット1つだけがセットされるため、Multi-AZ構成を組みたい場合はあとからグループの設定を変更する必要があります。
2. 起動設定(Launch Configuration)のEC2からの流用
続いて、Launch Configurationの作成時に、既存EC2インスタンスの設定を流用する機能です。最近Management ConsoleでLaunch Configurationの作成がサポートされ以前よりはかなりやりやすくなった作業ですが、インスタンスの起動設定を一つずつ行うのは、已然として面倒だと思います。そこで、既存EC2インスタンスから起動設定をコピーし、簡単にLaunch Configurationが作成できるのが、本機能になります。方法は1のグループ作成と同様、as-create-launch-configコマンドに--instance-idオプションで既存EC2インスタンスを指定します。
Java版
$ as-create-launch-config lc2 --instance-id i-XXXXXXXX --region ap-northeast-1
OK-Created launch config
$Python版
$ aws autoscaling create-launch-configuration --launch-configuration-name lc2 ¥
--instance-id i-XXXXXXXX --region ap-northeast-1
$Management Consoleで見てみると、できてますね！
ちなみに、as-create-launch-configコマンドに従来のオプションを指定することで、既存インスタンスの設定を上書きすることも可能です。
一点注意が必要なのは、このLaunch Configurationで設定されるAMI IDは、既存EC2インスタンスの元となるAMI IDになるところです。言い換えると、既存EC2インスタンスの持つディスクのデータは、Auto Scalingで作成されるインスタンスには反映されないことになります。勘違いしやすいところなので、気をつけましょう。
3. 既存EC2インスタンスのAuto Scalingグループへの追加
最後に、Auto Scalingの管理下ではないEC2インスタンスをAuto Scalingグループに追加する機能です。これは、新しく追加されたas-attach-instancesコマンドで実行します。
Java版
$ as-attach-instances --instances i-XXXXXXXX --auto-scaling-group asg1 --region ap-northeast-1
OK-Instance(s) will be attached
$Python版
$ aws autoscaling attach-instances --region ap-northeast-1 ¥
--instances i-XXXXXXXX --auto-scaling-group-name asg1
$割とあっさりできてしまうのですが、Management Consoleを見ると、ちゃんと追加されていることが分かります。
元々Auto Scalingグループにあるインスタンスと、後から追加したインスタンスはLaunch Configuration Nameの有無で確認できます。
ちなみに、グループからの取り外し機能は用意されていないようなので、戻せないことに注意しましょう。私は今回の検証で、上記1,2の元になるEC2インスタンスをグループに追加してしまい、いつこのインスタンスがTerminateされないか、結構ドキドキしていました *1。
また、追加する前にグループのMaxに余裕があることを確認してください。インスタンスを追加することでグループのインスタンス数がMax値を超えてしまう場合、以下のようにエラーになります。
$ as-attach-instances --instances i-XXXXXXXX --auto-scaling-group asg1 --region ap-northeast-1
as-attach-instances: Malformed input-AutoScalingGroup: asg1 has min-size:1, max-size: 1,
desired-size:1 .To attach 1 more instance(s), please update the
AutoScalingGroup sizes appropriately.
$必要に応じて、Maxを+1しましょう。Desired Capacityを+1しないのがコツです。Desired Capacityを増やしてしまうと、Auto Scaling配下のインスタンスが自動作成されてしまいます。
まとめ
というわけで、Auto Scalingの新機能3つをご紹介しました。いずれも、従来よりもより手軽にまた柔軟にAuto Scalingを活用できるものだと思っています。Auto Scalingを活かした、クラウドならではの運用に役立てていただければ幸いです。
脚注
- 実際は、Scaling Policyを設定していないので手動でStop/Terminateしない限り大丈夫なことにあとから気づきました。 ↩
13
