Auto Scalingグループのヘルスチェックタイプ

AWS,EC2,ELB

Auto Scalingのヘルスチェックを理解する

ALB + EC2 のヘルスチェック落とし穴

  • 簡単そうに見えるAuto Scalingも色々と失敗があります。今回は、ヘルスチェックの落とし穴をご紹介します。
  • ALB + EC2 構成で設定すべきヘルスチェックは2種類あります。1つ目のヘルスチェックと言えば、ターゲットグループに設定するヘルスチェック(Ping path)ですね。ターゲットグループのヘルスチェックを設定すると、ロードバランサーは指定されたポート、プロトコル、および Ping pathを使用してターゲットのヘルスチェックを行います。
  • 今回もターゲットグループにヘルスチェックを設定して、すべてのインスタンスがHealthyとなっていました。Auto Scalingグループで、上記ALBが所属するターゲットグループを設定しているため、この状態で各インスタンスのヘルスチェックがHealthy→Unhealthyに変わったら、自動的に代替のEC2が起動すると考えていました。
  • しかし‼、なぜかすべてのインスタンスでヘルスチェックがUnhealthyに変わっても、代替のEC2が起動してこない…。
  • 実は、もう1つ設定すべきヘルスチェックがあります。ALBのヘルスチェックとは別に、Auto Scalingグループの設定でヘルスチェックタイプが設定できます。そして、デフォルトはEC2 になっているため、注意が必要です。

EC2/ELBのヘルスチェックタイプ

  • Auto Scalingグループは、インスタンスが正常ではない場合、該当のインスタンスをTerminate(削除)し、新しいインスタンスを起動します。ドキュメントには、下記の記載があります。
Auto Scaling インスタンスのヘルスステータスは、正常または異常のどちらかです。Auto Scaling グループ内のすべてのインスタンスは正常な状態で起動されます。インスタンスに異常があるという通知を Amazon EC2 Auto Scaling が受け取らない限り、インスタンスは正常であると見なされます。この通知は、Amazon EC2、Elastic Load Balancing、カスタムヘルスチェックのうち 1 つ以上のソースから送られる可能性があります。
 
  • ヘルスチェックタイプには、2つの種類があります。
    • EC2: インスタンスのステータスが running 以外である場合、またはシステムステータスが impaired である場合、Amazon EC2 Auto Scaling はインスタンスを異常と見なし、代わりのインスタンスを起動します。
    • ELB: Elastic Load Balancing がOutOfService とレポートしたときにインスタンスを異常とマークするようになります。
 
  • ターゲットグループのヘルスチェック(Ping path)だけでなく、Auto Scalingグループのヘルスチェックタイプも適切に設定する必要がありますね。

AWS,EC2,ELB

Posted by takaaki