Auto Scalingグループのヘルスチェックタイプ
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グループのヘルスチェックタイプも適切に設定する必要がありますね。