今回は、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の記事は長文化の傾向にあります。