はじめに
今回発生していた事象にも記載の通り、利用しているALBで「HTTPCode_Target_5XX_Count」のメトリクスを検知していました。
今まではターゲットに原因があったので、今回もターゲットに原因があると思い込み調査をしていました。
「HTTPCode_Target_5XX_Count」で悩んでいる方のお役に立てれば幸いです。
ALBのメトリクス「HTTPCode_ELB_5XX_Count」、「HTTPCode_Target_5XX_Count」について
ALBの5XX_Countメトリクスは2種類あります。
以下に公式ドキュメントの内容を記載しますが、5XXエラーがロードバランサーから検知するのか、ターゲットから検知するのかの違いになります。[1]
| メトリクス名 | 内容 |
|---|---|
| HTTPCode_ELB_5XX_Count | ロードバランサーから送信される HTTP 5XX サーバーエラーコードの数。この数には、ターゲットによって生成される応答コードは含まれません。 |
| HTTPCode_Target_5XX_Count | ターゲットによって生成された HTTP 応答コードの数。これには、ロードバランサーによって生成される応答コードは含まれません。 |
今回発生していた事象
利用しているALBで「HTTPCode_Target_5XX_Count」のメトリクスを検知していたため、ターゲットに原因がないか調査を実施していました。
しかしながら、ターゲットから原因を特定することができず、継続して「HTTPCode_Target_5XX_Count」のメトリクスを検知していました。
結論
公式ドキュメントに以下記載があり、CloudTrailを確認したところドキュメント記載の内容と同じ状況でした。[2]
CloudTrail イベントで、問題の期間中に DeregisterTargets アクションを含む API コールを確認します。問題の期間中に DeregisterTargets を使用した API コールが発生した場合、このエラーは早期に登録解除されたターゲットが原因です。
この問題を解決するには、登録解除の遅延時間を長くして、長時間のオペレーションが失敗することなく完了できるようにします。
したがって、「DeregisterTargets」の値を変更することで「HTTPCode_Target_5XX_Count」のメトリクスは検知しなくなりました。
「DeregisterTargets」について
「DeregisterTargets」の内容は公式ドキュメントを確認していただければと思います。[3]
注意点としてはターゲットがAuto Scaling グループの場合、Health statusが「unused」にならないとインスタンスが置き換わらないです。
「DeregisterTargets」で設定した値を経過しないと、Health statusは「unused」にならないので、「DeregisterTargets」の値は適切な値に調整する必要があるかと思います。
参考記事
[1]：Application Load Balancer のメトリック
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html#load-balancer-metric-dimensions-alb
[2]：登録解除されたターゲットによって処理されたリクエストについて、登録解除の遅延期間が経過した
https://aws.amazon.com/jp/premiumsupport/knowledge-center/elb-alb-troubleshoot-502-errors/
[3]：登録解除の遅延
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-target-groups.html#deregistration-delay
まとめ
ルーティン化している調査でも詰まったときには、別の視点から調査する必要性を実感しました。
