share facebook facebook twitter menu hatena pocket slack

2012.04.18 WED

Auto ScalingでEC2を自動復旧(クラウドデザインパターン(CDP):Multi-Serverパターン)

鈴木 宏康

WRITTEN BY 鈴木 宏康

今回は、Cloud Design Pattern(CDP)の記事になります。
対象は「Multi-Serverパターン」です。

このパターンの利点の一つに下記があり、実際に試してみました。

ELBとAuto Scalingの設定により、ある一定数のサーバ(例えば、3台)を設定して、
常に3台で稼働させることを行える。

はじめに、Auto Scalingで起動するAMIを用意します。

このAMIは下記のように起動時にApacheが立ち上がり、/index.htmlでアクセスできるようにしておきます。

# yum -y install httpd
# chkconfig httpd on
# chkconfig --list httpd
httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
# /etc/init.d/httpd start
# cat /var/www/html/index.html

AS

上記により、起動すると同時にブラウザで、下記のようにアクセスできるようにしておきます。

この状態でAMIを作成します。

このAMIがAuto Scalingで利用(起動)されるAMIとなります。

Auto ScalingでEC2が起動した時に追加されるELBも作成しておきます。

今回は、EC2が別々のAZ(ap-northeast-1a/ap-northeast-1b)に分散するように配置するので、
ELBのAZも両方登録しておきます。

以上で、AWSリソースの準備が完了しましたので、次にAuto Scalingの設定をします。
(AWS PHP SDKで設定します。)

まず、Launch Configurationを下記のPHPスクリプトで設定します。

require_once("/opt/aws/php/latest/sdk.class.php");

$as = new AmazonAS(array(
"key" => "ACCESS_KEY",
"secret" => "SECRET_KEY"
));
$as->set_region(AmazonAS::REGION_APAC_NE1);
$response = $as->create_launch_configuration(
"as-test", // Launch Configration名
"ami-5c25945d", // 上記で作成したAMI
"t1.micro", // EC2のタイプ
array(
"SecurityGroups" => array(
"default" // 0.0.0.0/0からPort80へのアクセスが許可
)
)
);

var_dump($response->body);

そして、Auto Scaling Groupは下記のPHPスクリプトで設定します。

require_once("/opt/aws/php/latest/sdk.class.php");

$as = new AmazonAS(array(
"key" => "ACCESS_KEY",
"secret" => "SECRET_KEY"
));
$as->set_region(AmazonAS::REGION_APAC_NE1);
$response = $as->create_auto_scaling_group(
"as-test", // Auto Scaling Group名
"as-test", // Launch Configration名
2, // EC2の最小起動数
2, // EC2の最大起動数
array("ap-northeast-1a", "ap-northeast-1b"),
array(
"LoadBalancerNames" => "as-test",
"HealthCheckType" => "ELB", // 後述(ポイントです!)
"HealthCheckGracePeriod" => 60 // 後述(ポイントです!)
)
);

var_dump($response->body);

上記設定のポイントは2つです。

1つ目のポイントは、Auto Scalingで起動するEC2の最大値と最小値を同じ値(2)にしているところです。
こうすることで、あるEC2が機能しなくなると、そのEC2をターミネートして、上記のAMIから新しいEC2を作成し、
ELBにも追加するので、常に正常なEC2が2インスタンス稼働している状態にしてくれます。

2つ目のポイントはHealthCheckTypeをELBにしているところです。
(デフォルトはEC2です)

このHealthCheckTypeとは、EC2インスタンスが正常(healthy)か異常(unhealthy)かを判断する方法で、
EC2とELBの違いは下記となります。

▼ EC2(デフォルト)

EC2インスタンスのStateでチェックします。
runnningならhealthy、それ以外ならunhealthyとなります。

▼ ELB

ELBのヘルスチェックをそのまま使います。
ELBがEC2インスタンスをIn Serviceと判断している場合はhealthy、
Out of Serviceと判断している場合はunhealthyとなります。

今回は、Apacheが落ちた場合(EC2インスタンスはrunningの場合)でも、Auto Scalingで自動復旧して欲しいので、
HealthCheckTypeはELBとしました。

またELBを設定すると、HealthCheckGracePeriodも指定する必要があります。
これは、EC2インスタンスがAuto Scalingで起動した後に、ELBがヘルスチェックを
開始するまでの時間です。

EC2インスタンスが起動して、さらにApacheが起動するまでにELBのヘルスチェックが行われてしまうと、
unhealthyと判断され、すぐにターミネートされてしまいます。
HealthCheckGracePeriodはこのような問題を調整する値となり、今回は60秒にしています。

実際は、このAuto Scaling Groupを設定した時点で、下記のようにEC2インスタンスが起動されています。

さらに、ELBにも追加されています。

ELBのDNS名をブラウザでアクセスすると、EC2インスタンスに直接アクセスしたものと
同じ画面が表示され、正しく機能していることがわかります。

それでは、EC2インスタンスに障害が起きた場合の実験です。

一方のEC2インスタンスのApacheを停止してみます。

# /etc/init.d/httpd stop

これにより、ELBから切り離されます。

そして、ELBから切り離さたEC2インスタンスはunhealthyとみなされるので、
下記のようにAuto Scalingによりターミネートされます。

その後、EC2インスタンスが2つになるようにAuto Scalingが新しいインスタンスを起動します。

さらに、ELBにも追加されるので、元の2インスタンス体制に復旧したことになります。

上記の流れを図にすると、下記のようになります。

CDPの記事は長文化の傾向にあります。

こちらの記事はなかの人(suz-lab)監修のもと掲載しています。
元記事は、こちら

鈴木 宏康

鈴木 宏康

愛知県生まれ。東京工業大学大学院修士課程修了。在学時より、ベンチャー企業でインターネットに関する業務に携わり、現在はクラウド(主にAmazon Web Services)上での開発・運用を軸とした事業の、業務の中心として活躍。

cloudpack

cloudpackは、Amazon EC2やAmazon S3をはじめとするAWSの各種プロダクトを利用する際の、導入・設計から運用保守を含んだフルマネージドのサービスを提供し、バックアップや24時間365日の監視/障害対応、技術的な問い合わせに対するサポートなどを行っております。
AWS上のインフラ構築およびAWSを活用したシステム開発など、案件のご相談はcloudpack.jpよりご連絡ください。