ヘルスチェックとスタンバイ起動

前回、スタンバイサーバに切り替えるためにEC2を自動起動するlambdaスクリプトを作成しました。
今回は本番稼働中のサーバに対してヘルスチェックを実行して、失敗した場合に自動でEC2上のサーバが切り替わるように設定します。

ヘルスチェックはAWSのRoute53を使用します。
Route53は、AWS外のサイトであってもヘルスチェックできますが、その場合月に$0.75かかります。更にHTTPSの場合追加で$2.00/月かかります。このサイトはhttp通信をhttpsにリダイレクトしていますが、httpでヘルスチェックOKになったので、ケチってhttpを使用していきます。

SNSのトピックを作成する

ヘルスチェック設定をする前に、異常発生時にlambda関数をトリガするためのトピックを作成します。サービスからSimple Notification Serviceを選択します。またリージョンをバージニア北部に変更します。Route53からのアラームはバージニア北部でしか受け取れないので注意しましょう。
新しいトピックの作成をクリックして、名前を入力します。

作成したら、作成したトピックをクリックしてサブスクリプションの作成をクリックします。
ここで、前回作成したlambda関数を選択します。

これでSNSのトピックができました。このSNSが発行されるとEC2が自動起動されるようになります。前回設定しなかったlambda関数のトリガにもこのトピックが作成されているはずです。

ヘルスチェックの設定

サービスからRoute53を選択して、Health Checkをクリックします。
モニタリング対象:エンドポイント
エンドポイントの指定:ドメイン名
として、自サイトのURLを入力します。パスにはできるだけ軽くて画像等も少ないページを指定した方が良いでしょう。結構正常判定がシビアなようです。最初に本サイトのトップページを指定したら、タイムアウトが頻発しました。投稿順に記事を並べるためレスポンスが遅かったようです。

アラームの設定で、先ほど作成したSNSトピックを指定します。

これで設定は完了です。しばらく待つとヘルスチェックのステータスが正常になります。

以上でコールドスタンバイサーバの構築は完了になります。

数年前に比べると、大分手間もコストも低くなったと思いますが、エンジニアで無い人には大分敷居が高いのではないでしょうか。
実はもっと簡単な選択肢がありそうです。torocca!にデータをバックアップしておき、同時にcloud frontを使用してコンテンツをAWS上にキャッシュしておく方法です。
100%の耐久性ではありませんが、障害発生してもcloud frontのキャッシュが効いているので普段読まれている記事はキャッシュから読むことができます。キャッシュに載っていない情報はサーバダウン時に見ることはできませんが、手軽に信頼性を向上できます。
その間にVPSサービス等の障害復旧を待ち、データが壊れていたらtorocca!から書き戻せば良いのです。
更新がキャッシュに反映されるまでタイムラグが出るデメリットもありますが、キャッシュによりサイトの応答速度が速くなるメリットもあります(むしろこちらが本来の目的)ので、検討に値する手段だと思います。

ということで次はcloud frontを使用して信頼性を高める方法を調査、紹介していきます。



シェアする

  • このエントリーをはてなブックマークに追加

フォローする