Scale Out時のBackend-Connection-Errorsを回避する

スポンサーリンク

Auto Scalingは便利だ

AWSの便利な機能の1つがAuto Scaling。条件によってインスタンス(host)を増やしたり減らしたりできる優れもの。
仕事でも使っている…と思ったら、故障して止まったときに立ち上げ直すためにしか使っていなかった。いつも負荷がかかっているわけでもないので、増やしたり減らしたりするようにした。

Backend-Connection-Errors

インスタンスの台数を変化させるようにしたら、ELBがBackend-Connection-Errorsを検出するようになった。日によってはUnhealthy-Hostsのエラーも出ている。実害はないとはいえ、慣れっこになってしまうと、肝心なときの対応が遅れることになる。また、通知もうっとうしい。

LifeCycle hookでWaitを入れる

「ログを見ろ」の鉄則で、Auto Scalingのアクティビティ履歴とインスタンスのログ(Apache httpd)を見て、考える。どうやら、インスタンスが起動してELBの配下に入るタイミングがhttpdの起動より早いようだ。ということは、このタイミングを遅くすればよい。

Auto Scaling ライフサイクルフック – Auto Scalingは、インスタンスの起動時または終了時に割り込む仕掛けだ。

Auto Scaling のライフサイクルフックについて説明します。

ポイントは、「タイムアウト期間終了まで、インスタンスは一時停止されたまま。」CloudWatchイベントターゲットを定義してとか、ライフサイクルフック用の通知ターゲットを定義とかあるが、止めていればいいのでカスタムアクションは不要。タイムアウトの時間だけ設定すれば、その間、止まってくれる。

AWS ConsoleでAuto Scaling グループを見ると、一番右にライフサイクルフックというタブがある。このタブを選択すると、起動時や終了時のフックを定義することができる。

「ライフサイクルフックタイプ」として「インスタンスの作成」を選ぶと、インスタンスの起動後、ELBに参加する前のタイミングで割り込むことができる。「ハートビートのタイムアウト」で停止させる時間を設定し、「デフォルトの結果」として「CONTINUE」を選択すれば、OK。

起動完了を通知すべき

このやり方だとタイムアウトを待つので、どのくらい待てばよいのか試行錯誤が必要だ。また、インスタンスタイプが変われば、再調整が必要だろう。

本来であれば、インスタンスの起動script側でCONTINUEを通知すべきだ。負荷によってScale Outする場合、一刻も早く起動して、ELBに参加すべきだろう。

スポンサーリンク

シェアする

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

フォローする

この記事へのコメント

Loading Facebook Comments ...

No Trackbacks.