問題の概要
クラシックロードバランサー (CLB) インスタンスの TCP リスナーでヘルスチェックを有効化すると、バックエンドサーバーのサービスログに頻繁にネットワーク接続エラー（例： Connection reset by peer）が記録されます。パケットキャプチャの解析結果によると、これらのリクエストは CLB インスタンスから発信されています。また、CLB インスタンスは接続終了のためにバックエンドサーバーに対して RST パケットを送信しています。サービスログに記録されるエラーメッセージは、以下の例と類似しています。
原因
この現象は、CLB のヘルスチェック機構に起因します。TCP プロトコル自体は上位レイヤーのサービス状態を認識しないため、ヘルスチェックのコストおよびバックエンドサービスへの影響を最小限に抑えるため、CLB では TCP リスナーのヘルスチェックにおいて TCP SYN チェック（ハーフオープン接続検出）を実行します。これは、完全な TCP 3 ウェイハンドシェイクを完了させない方式です。CLB インスタンスはバックエンドから SYN+ACK を受信した直後に、サービスデータのやり取りを行わず、即座に RST パケットを送信して接続を終了します。その結果、Java 接続プールなどの上位レイヤーサービスは当該接続を異常と判断し、「Connection reset by peer」例外をスローします。データ交換の詳細なプロシージャは以下のとおりです：
-
CLB インスタンスがバックエンドサービスのポートに対して SYN パケットを送信します。
-
バックエンドサーバーがリクエストを受信した後、ポートの状態が正常である場合、標準的な TCP プロトコルに従って SYN および ACK パケットを返信します。
-
CLB インスタンスがバックエンドサービスのポートからの確認応答を受信した場合、当該ポートのリスナーは正常と判断し、ヘルスチェックを成功とマークします。
-
CLB インスタンスはその後、バックエンドサービスのポートに対して RST パケットを送信し、接続を終了します。これによりヘルスチェック操作が完了します。サービスデータは一切送信されません。
ソリューション
本障害を解消するには、以下のいずれかのソリューションをご利用ください。
-
ソリューション 1：リスナータイプの変更 CLB インスタンスのリスナーを TCP から HTTP または HTTPS に変更します。詳細については、「HTTP リスナーの追加」および「HTTPS リスナーの追加」をご参照ください。
-
ソリューション 2：ログのフィルター処理 サービス層で、CLB のヘルスチェックに使用される IP アドレス範囲から発生するエラーメッセージをログから除外するフィルターを設定します。
説明CLB のヘルスチェックに使用される IP アドレス範囲は 100.64.0.0/10 です。
適用対象
-
クラシックロードバランサー (CLB)