Nginx + WordPress Auto Scaling篇

AWS運用自動化サービス「Cloud Automator」
この記事は1年以上前に書かれたものです。
内容が古い可能性がありますのでご注意ください。

こんにちは。CSチームの坂本です。

今回は、前回のNginx + WordPress ELB篇の構成にプラスして、日々の運用が少し楽になるようなカイゼンを、AWSのサービスを使っておこないたいと思います。

現状は、3台のWebサーバーがELBの配下で動いています。

通常の運用ですと、1台がダウンしてしまった場合は、手動でサーバーを立ち上げる必要がありますが、AWSのサービス「Auto Scaling」を利用すれば、Webサーバーがダウンしてしまったときに手動でサーバーを立ち上げる必要がなくなります。


目次

  1. はじめに
  2. 今回の構成
  3. Auto Scalingとは?
  4. AWS SDK for PHP 2
  5. Auto Scalingの設定
  6. 動作確認
  7. Auto Scalingの設定の消去方法
  8. まとめ

 

1. はじめに

今回利用するAWSのサービスは「Auto Scaling」というAWSのサービスです。このサービスを使うことで「自動」で「常に同じ構成を保って運用」をおこなうことが可能になります。

 

2. 今回の構成

前回までの構成に「Auto Scaling」が加わります。

 

3. Auto Scalingとは?

Auto Scaling」は、文字通り設定した内容によってEC2インスタンスを「自動でスケーリング」してくれるサービスです。

負荷によってサーバーを増減させる」というのが、このサービスのよく知られた利用方法ですが、実際は今回のように「Webサーバーを常に同じ構成で運用したい」という場合にも使えます。

このサービスを利用すると、「問題のあるインスタンスを自動で新しいインスタンスと交換」してくれるので、3台の内1台がダウンしてしまった場合でも手動で何もおこなうことなく同じ構成で運用が続けられます。

イメージを掴むために、どのように設定をおこなうのかを実際に確認してみたいと思います。

 

4. AWS SDK for PHP 2

Auto Scaling」は、GUIの管理画面「AWS Management Console」で操作できないサービスです。

そのため、「Auto Scaling Command Line Tool」や「SDK」で操作する必要があります。

今回はPHP用のSDKの新しい方のバージョンである、「AWS SDK for PHP 2」を利用して設定したいと思います。

まずは、「AWS SDK for PHP 2」のインストールからおこないます。

今回は、PEARを利用して「Amazon Linux」にインストールします。

インストールが完了したら、アクセスキー、シークレットキー、使用するリージョン、といった最低限必要な情報を以下のファイルを編集して「default_settings」の部分に設定しておきます。

/usr/share/pear/AWSSDKforPHP/Aws/Common/Resources/aws-config.php

これで、「AWS SDK for PHP 2」を利用するための最低限の設定が完了しました。

 

5. Auto Scalingの設定

次は、Auto Scalingの設定です。Auto Scalingの設定は「Auto Scalingの薄い説明書を作ってみた」にもあるように複雑ですが、今回の要件を満たすための設定はそんなに難しくありません。今回は、「起動条件(Launch Configration)」と「Auto Scalingグループ」だけ設定すればOKです。

はじめに、「起動条件(Launch Configration)」を設定するファイルを作成します。

起動条件は以下の表の内容を配列で設定しています。今回作成したコードを以下に載せましたので、配列以外の内容はそちらを参考にしてみてください。

内容 キー名 今回の値
起動条件名 LaunchConfigurationName wordpress_launch_configration
インスタンスの起動に利用するAMIの
ID
ImageId ami-xxxxxxxx
起動するインスタンスの
セキュリティグループ
SecurityGroups array(‘sg-xxxxxxxx’)
※配列で設定
使用するインスタンスタイプ InstanceType t1.micro

/home/ec2-user/create_launch_configration.php

 

次に「Auto Scalingグループ」を設定するファイルを作成します。「Auto Scalingグループ」では以下の表の内容を配列で設定しています。

内容 キー名 今回の値
Auto Scalingグループ名 AutoScalingGroupNam wordpress_auto_scaling_group
利用する起動条件名 LaunchConfigurationName wordpress_launch_configration
起動するインスタンスの最小数 MinSize 3
起動するインスタンスの最大数 MaxSize 3
利用するアベイラビティゾーン AvailabilityZones array(
‘ap-northeast-1a’,
‘ap-northeast-1b’,
‘ap-northeast-1c’
)
※配列で設定
利用するELB名
(このELBの配下で稼働させる)
LoadBalancerNames array(‘wordpress’)
※配列で設定
ELBのヘルスチェックを利用する場合
設定する※1
HealthCheckType ELB
インスタンス起動後にELBが
ヘルスチェックを開始するまでの秒数
HealthCheckGracePeriod 180

※1 デフォルトはEC2のStatusチェックです。ELBのヘルスチェックを利用すれば、前回と同じくPHP-FPMの終了でもインスタンスを交換してくれるので、今回はELBのヘルスチェックを利用しています。

/home/ec2-user/create_auto_scaling_group.php

この時、「起動インスタンスの最小数(MinSize)と最大数(MaxSize)を同じ」にすることで、常に同じ稼働台数を保つことができます。

 

6. 動作確認

では、実際に上記のファイルを順番に実行して3台のインスタンスが起動してくるかを確認してみましょう。

実行後、「Management Console」で確認します。

起動してきました。

※この設定は、いままで起動していたインスタンスに対して適用されるわけではありません。ですので、いままで使用していたインスタンスは終了しています。

Management Console」の「Load Balancers」の「Instances」タブでELBの配下で動作しているかも確認しましょう。3台が「In Service」になっています。

ブラウザで問題なくアクセスできているかも念のため確認しておきます。

今度は1台がダウンした場合を想定して、1台のインスタンスのPHP-FPMを終了させてみます。

Management Console」で確認します。PHP-FPMを終了させたインスタンスがターミネイトし、新しいインスタンスが起動してきたことを確認できました。

 

7. Auto Scalingの設定の消去方法

このまま運用を続けていく場合の手順は以上です。

ですが、今回のように検証で利用した場合は、Auto Scalingの設定をきちんと消去してください。

自動で起動させるために設定しているのであたりまえなのですが、ちゃんと設定を消去しておかないとインスタンスをターミネイトしてもまた起動してきてしまいます。ですので、Auto Scalingの設定を消去する方法についても触れておきたいと思います。

まず、「Auto Scalingグループ」の設定で「インスタンスの最小数(MinSize)と最大数(MaxSize)を0」に更新します。

次に、「Auto Scalingグループ」を削除し、最後に「起動条件(Launch Configration)」を削除します。この順番でおこなう必要がありますので注意しましょう。

 1. 「Auto Scalingグループ」の更新

/home/ec2-user/update_auto_scaling_group.php

 

 2. 「Auto Scalingグループ」の削除

/home/ec2-user/delete_auto_scaling_group.php

 

 3. 「起動条件(Launch Configration)」の削除

/home/ec2-user/delete_launch_configration.php

上のファイルから順番に実行します。

 

8. まとめ

これで「常に同じ構成で運用」ができるようになりました。

ここまで設定してあれば通常の運用ではほぼ問題のない設定ができていると思いますが、せっかくなので急なアクセス増加にも備えておきましょう。

次回は、負荷に応じてEC2インスタンスが増減するようにしたいと思います。

 

 

AWS運用自動化サービス「Cloud Automator」