HTTP 로드 밸런서 뒤에 2개의 인스턴스가 있는 인스턴스 그룹이 있습니다. 한 인스턴스는 작동되어 정상적으로 작동하고(http 200 반환), 다른 인스턴스는 충돌합니다(HTTP 요청 시간 초과). 내가 무엇을 잘못하고 있는지 잘 모르겠지만 문서에 따르면 실패한 인스턴스는 로드 밸런서에서 자동으로 제거되어야 합니다.
관련 문서는 다음과 같습니다.https://cloud.google.com/compute/docs/load-balancing/health-checks 관련 단락과 함께 :
상태 확인이 성공한 것으로 간주되려면 백엔드가 코드 200과 함께 유효한 HTTP 응답을 반환하고 timeoutSec 기간 내에 정상적으로 연결을 닫아야 합니다. 인스턴스가 상태 확인에 실패하면 알림이 전송되지 않고 그룹이나 풀에서 제거됩니다. 나중에 상태 확인을 통과하면 알림 없이 다시 그룹이나 풀로 반환됩니다.
현재 HTTP 로드 밸런서의 백엔드에 대한 Google Cloud 콘솔 페이지에 표시되는 내용은 다음과 같습니다.
내 사이트를 방문할 때(http://stage2.phantomjscloud.com) 내가 얻는 시간의 대략 절반
오류: 서버 오류 서버에 일시적인 오류가 발생하여 요청을 완료할 수 없습니다. 30초 후에 다시 시도해 주세요.
HTTP 로드 밸런서(및 상태 확인)는 실패한 인스턴스를 명확하게 감지하지만 이에 관계없이 트래픽은 계속 제공됩니다.
문제를 어떻게 해결할 수 있나요?
답변1
상태 확인 관리형 인스턴스 그룹 VS 상태 확인 부하 분산
관리형 인스턴스 그룹에서 사용하는 상태 확인은 부하 분산에서 사용하는 상태 확인과 동일하지만 동작에 약간의 차이가 있습니다. 로드 밸런싱 서비스에 적용하는 상태 확인은 로드 밸런서가 네트워크 트래픽을 전달할 위치를 결정하는 데 도움이 됩니다. 이러한 상태 확인으로 인해 Compute Engine이 인스턴스를 다시 생성하지는 않습니다. 관리형 인스턴스 그룹에 적용하는 상태 확인은 인스턴스가 UNHEALTHY 상태가 되면 인스턴스를 삭제하고 다시 생성하도록 관리형 인스턴스 그룹에 사전에 신호를 보냅니다.
대부분의 시나리오에서는 부하 분산 및 관리형 인스턴스 그룹 모니터링을 위해 별도의 상태 확인을 사용합니다. 로드 밸런싱을 위한 상태 확인은 인스턴스가 사용자 트래픽을 수신하는지 여부를 결정하므로 더욱 공격적일 수 있고 그래야 합니다. 고객이 귀하의 서비스에 의존할 수 있으므로 응답하지 않는 인스턴스를 신속하게 포착하여 필요한 경우 트래픽을 리디렉션할 수 있습니다. 반면, 인스턴스 그룹에 대한 상태 확인을 사용하면 Compute Engine이 실패한 인스턴스를 사전에 교체하므로 부하 분산기에 대한 상태 확인보다 더 보수적인 상태 확인을 만들 수 있습니다.
답변2
이런 종류의 버그를 한동안(6개월 정도) 본 적이 없어서 Google Cloud의 버그인 줄 알았고 수정되었습니다.