単一のバックエンドのHAProxyヘルスチェック
これに非常によく似た単一のバックエンドを持つHAProxy構成があります。
backend mybackend
option httpchk get /ping
http-check expect ! rstatus ^5
server mybackend-0 192.168.1.1:9041 weight 1
/pingエンドポイントは常に200を返します。
私の質問：単一のサーバーでヘルスチェックを実行する利点はありますか？私が理解しているように、ヘルスチェックは、複数のバックエンドサーバーがあり、それらの負荷を分散したい場合にのみ意味があります。
この点での助けはありがたいです。
ありがとう
「サーキットブレーカー」シナリオを可能にするために、単一のサーバーのヘルスチェックを行うことは理にかなっています。バックエンドがTCP接続を受け入れているが、応答を生成できないと想像してください。このhaproxyを介して接続しているクライアントアプリは、組み込みのタイムアウトが発生するまで待機して接続を閉じる必要があります。通常の場合50ミリ秒の応答時間を期待していて、要求タイムアウトが期限切れになるまで3秒待たなければならない場合、失敗する可能性が高くなります。
非常によく書かれたクライアントアプリはこの状況を検出し、独自の回路遮断を実行しますが、私の経験ではほとんどのアプリは検出しません。ヘルスチェックをHAProxyに追加すると、HAProxyが代わりに回線を切断できます。
そのため、バックエンドは応答を生成できず、ヘルスチェックが失敗します。その後、HAProxyは整形式の503を使用して着信要求に即座に応答し、クライアントアプリはそれを好きなように処理できます。
多くの場合、アプリケーションは、バックエンドが成功または失敗で迅速に応答することを前提として作成されています。 HAProxyにヘルスチェックを実行させると、アプリケーションが無応答を処理しないシナリオのいくつかが軽減されます。