こんにちは、TKです。
今回はAutoScalingでコンテンツ同期の方法を考えてみました。
コンテンツ同期が必要な理由
AutoScalingは閲覧数が不規則で普段は少ないインスタンス数、大量のアクセスが来た場合にスケールすることで対応することができるサービスです。
スケールする際にあらかじめ作成していたAMIを元にサーバを立てるため、コンテンツ情報が更新された場合はAMIを逐一更新する必要が出てきてしまいます。
そこでコンテンツを同期させ、AMIから立ち上がったサーバでもコンテンツを他所から持ってくることで対応します。
今回の方法のメリット
今回はS3にコンテンツをアップロードして、スケールしたインスタンスが自動的にS3にアップロードされたコンテンツをダウンロードすることで最新の情報にするという方法を取っています。
AutoScalingの元AMIを更新するスクリプトの実装方法も考えましたが、こちらは最新コンテンツ同期ができません。
rsyncなどの同期方法はスケールしたインスタンスに対して元サーバから送るための構築が必要になるため、採用しませんでした。
NFS用インスタンスを立ててコンテンツを置いておき、スケールしたインスタンスはNFSインスタンスにアクセスさせる方法は、NFSインスタンス分のコストがかかるためS3アップロード同期に軍配が上がりました。
EFSの東京リージョンへの実装が待たれます。
コンテンツ同期の設定
まずS3にコンテンツアップロード用のバケットを作成します。
次にスケールするインスタンスの設定を行います。
Webサーバを構築し、テストコンテンツを入れます。
行ったインスタンスにシェルを作ってcronに登録します。
シェルの内容は以下になります。
s3sync.sh
1 2 3 |
#!/bin/sh aws s3 sync s3://contents(コンテンツを置くバケット) /var/www/html/ service httpd restart |
s3sync2.sh
1 2 3 |
#!/bin/sh aws s3 sync s3://contents(コンテンツを置くバケット) /var/www/html/ service httpd reload |
シェルを作成した後cronに登録します。
1 2 3 |
crontab -e @reboot /root/script/s3.sync.sh */5 0 0 0 /root/script/s3.sync2.sh |
@rebootは再起動時に対象コマンドを行う設定です。
*/5 0 0 0 は5分ごとの同期設定ですがコンテンツ量に同期間隔を短くしすぎると場合によってはプロセスが終わらないうちに新たにプロセスが発生してしまうため、実行間隔は気をつけましょう。
設定後、インスタンスをAMI化してオートスケーリングの起動設定を作成します。
作成後現在のスケーリンググループの起動設定と交換します。
手順についてはこちらをご参照ください。
recipe.kc-cloud.jp/archives/1826
次に配信するコンテンツをテストするためのテスト環境インスタンスを作成します。
S3にアップロードする前にコンテンツが正しく配信できるか確認するためのサーバです。
先ほど作成したAMIから作成後、立てたサーバにログインしてcronに追記した内容をコメントアウトしておきます。
コメントアウトをしないとアップロードする前に内容が自動的に書き換わってしまい、コンテンツが上手くアップロードされないためです。。
コンテンツを作成したら以下のコマンドでS3にコンテンツをアップロードします。
1 |
aws s3 sync /var/www/html/ s3://s3-content-upload/content |
これで検証の準備ができました。
定期的にアップロードさせる場合はcronに上記コマンドを登録しておきましょう。
1 2 |
crontab -e */5 0 0 0 aws s3 sync /var/www/html/ s3://s3-content-upload/content |
それではAutoScalingの検証を行う前に更新前のコンテンツを確認します。
コンテンツを更新します。
それでは現在のインスタンスとAutoScalingを起動してスケーリングしたインスタンスを確認してみます。
コンテンツの同期が確認できました。
いかがでしたでしょうか。
AutoScalingの場合でも新しいコンテンツを維持する方法をご紹介いたしました。
複数台常設の場合にも対応できると思います。
ミドルウェアのアップデートを行った際にはAMIを更新して対応しましょう。
次回をお楽しみに!