風邪が治らず、鼻がムズムズします、たいがーです。少しアレルギーな予感もするのですが、実際のところはどうなのかわかりません。

Wantedlyの閲覧数を見てみると、前々回のJavaScriptの回が少しばかり伸びているのですが、なぜなんでしょう…タイトルなのか、内容なのか、そのあたり気になります。どうやったら調べられるんですかね、せっかくだったらいろんな方に見ていただきたい、そんな27日目です。

今日は前回の続きを進めていきます。Cloud Automatorのマニュアル作成のための作業を進めていきます。Cloud WatchでElastic Load Barancing(以下:ELB)のレイテンシー(通信遅延)を監視し、レイテンシーが1秒を超える状態が5分以上続いたら、自動でスケールアップを行う仕組みのマニュアルを作成するための検証を行う準備を進めています。

前回はEC2インスタンスをELBと接続するところまでできました。今回は実際にスケールアップを行っていきたいと思います。と思ったのですが、EC2インスタンスが同一のアベイラビリティゾーンで起動されているものになっていたので、変更していきます。

ELBの設定と、EC2インスタンスのセキュリティグループの設定を行い、いざ！と思ったのですが、ELBの設定上で確認すると、両方のインスタンスがOutOfServiceになっていました…原因を探していきます。

Webサーバーを自動起動させる

セキュリティグループの設定はうまくできていたので、考えられる原因としてはWebサーバのほうだけでした。

そういえば…自動起動設定をした記憶がありませんでした。というわけで、設定していきます。

一度、webサーバを起動します。

$ sudo yum httpd start

自動起動設定を許可します。

$ sudo chkconfig httpd on

こうすることで、EC2のサーバを起動すると、webサーバが自動で起動するように変更できました。忘れずにwebサーバを再起動します。(忘れてやり直しました)

$ sudo yum httpd restart

確認すると、一つのインスタンスはきちんとInServiceになっていました。が、もう一つのほうはまだOutOfService。webサーバも設定変更できているし、セキュリティグループの設定もできている。謎だ…ということで、アクセスログから見てみれば？とアドバイスをいただきました。

アクセスログを確認するために、ルートユーザに切り替えます。

$ sudo su

続いて、アクセスログ等が入っているディレクトリに移動します。

# cd /var/log/httpd

さて、何が入っているか見てみます。すると、access__logとerror_logの二つが入っていました。access_logを表示してみます。

# tail -f access_log

これで、リアルタイムも含めてlogを表示することが出来ます。見てみると、ELBのヘルスチェックが確認できました。ステータスを確認すると、200…成功しているようです。もう一度ELBの設定画面を確認してみると、InServiceになっていました。時間差でうまく接続されたようです。

さて、検証を進めていきます。検証を行うために平均レイテンシーを100ミリ秒以下の時、アラートを出すように設定します。

データ不足が収まらない

検証を進めていこうとすると、ELBを監視するために設定をしていたCloudWatchがデータ不足だというエラーが発生していました。

原因は一度もELB上からページを表示していないことにありました。

ELBの説明のDNS名のところに書いてあるURLを表示してみます。すると、うまくアラートを出させることが出来ました。

そこからCloud AutomatorのジョブでEC2インスタンスのタイプを変更していきます。

次回はCloud Automatorの後処理設定を使って、それぞれのジョブをつなげていくところから始めていきたいと思います。

エラーメッセージを見る癖は少しずつついてきたのですが、ログを見るという癖はまだついていないので、少しずつつけていけたらなと思います。