
alb
と の2 つのターゲット グループに登録されているサービスがありますwwwalb
。
ターゲットalb
グループは内部リクエスト用であり、wwwalb
ターゲット グループは外部リクエスト用です。
サービスをデプロイすると、サービスが正常に起動し、リクエストの受け入れを開始します。アクセス ログを見ると、との両方がalb
サービスwwwalb
をプローブしていることがわかります。サービスは 3 つのゾーンで実行されるため、ゾーンごとに 3 つのリクエスト、合計 6 つのリクエストが表示されます。
- - - [19/Jun/2022:20:45:28 +0200] "GET /api/system/status HTTP/1.1" 204 -
- - - [19/Jun/2022:20:45:28 +0200] "GET /api/system/status HTTP/1.1" 204 -
- - - [19/Jun/2022:20:45:28 +0200] "GET /api/system/status HTTP/1.1" 204 -
- - - [19/Jun/2022:20:45:30 +0200] "GET /api/system/status HTTP/1.1" 204 -
- - - [19/Jun/2022:20:45:30 +0200] "GET /api/system/status HTTP/1.1" 204 -
- - - [19/Jun/2022:20:45:30 +0200] "GET /api/system/status HTTP/1.1" 204 -
それにもかかわらず、ターゲット グループはサービスが不健全であると判断したため、最終的にサービスは停止されます。実際、サービスが健全であるとは考えたことがないようです。
ターゲット グループを確認するための API 呼び出しでは、次の結果が得られます。
{
"TargetHealthDescriptions": [
{
"Target": {
"Id": "10.1.143.94",
"Port": 8182,
"AvailabilityZone": "eu-north-1b"
},
"HealthCheckPort": "8182",
"TargetHealth": {
"State": "unhealthy",
"Reason": "Target.FailedHealthChecks",
"Description": "Health checks failed"
}
}
]
}
しばらくの間、ターゲット グループのメトリック、ロード バランサーの構成を調べてきましたが、この動作を説明できるセットアップに関する情報がまったく見つかりません。ヘルス チェックの設定も問題ないように見えます。
最近 を追加したばかりなwwwalb
ので、このサービスを 2 つのターゲット グループに含めることが原因であると考えられます。また、サービスを 2 つのターゲット グループに含めることは AWS によってサポートされ、説明されています。
この問題の本当の原因について AWS から詳細を入手する方法はありますか? AWS がサービスが失敗していると考える理由を調べる方法はありますか?
答え1
私は通常、不健全なしきい値を健全なしきい値よりも高い値に設定します。たとえば、10 秒間隔で 2 回の成功した通話は健全ですが、10 秒間隔で 6 回の失敗した通話は不健全です。
とはいえ、それは問題にはならず、設定は機能するはずです。ターゲットが登録されているとき、「初期」状態が発生します。その間、AWS はヘルスチェックを検証しようとしており、ヘルスチェックが成功した場合にのみ正常な状態に切り替える必要があります。
登録プロセスが完了し、ヘルスチェックが開始されるまでに数分かかる場合があります。
アプリケーションが正常に応答せず、その後長時間失敗して再び不調になっているのでしょうか? それとも、起動に時間がかかりすぎて「初期」状態から抜け出せないのでしょうか?