상태 확인 개요

Google Cloud는 백엔드가 트래픽에 응답하는지 확인하는 상태 확인을 제공합니다. 이 문서에서는 Google Cloud 부하 분산기 및 Traffic Director의 상태 확인 개념에 대해 설명합니다.

상태 확인은 구성 가능한 주기에 따라 백엔드에 연결됩니다. 각 연결 시도를 프로브라고 합니다. Google Cloud는 각 프로브의 성공 또는 실패를 기록합니다.

구성 가능한, 연속적으로 성공한 또는 실패한 프로브 수에 따라 각 백엔드의 전반적인 상태가 계산됩니다. 구성된 횟수만큼 성공적으로 응답한 백엔드는 정상으로 간주됩니다. 별도의 구성 가능한 횟수만큼 응답하지 않는 백엔드는 비정상입니다.

각 백엔드의 전반적인 상태는 새 요청 또는 연결을 수신할 자격이 있는지를 결정합니다. 성공적인 프로브를 정의하는 기준을 구성할 수 있습니다. 자세한 내용은 상태 확인 작동 방법 섹션을 참조하세요.

상태 확인은 Virtual Private Cloud(VPC) 네트워크에 정의되지 않은 특수 경로를 사용합니다. 자세한 내용은 부하 분산기 반환 경로를 참조하세요.

상태 확인 카테고리, 프로토콜, 포트

상태 확인에는 카테고리프로토콜이 있습니다. 상태 확인기존 상태 확인이라는 두 카테고리가 존재하며 지원되는 프로토콜은 다음과 같습니다.

프로토콜과 포트는 상태 확인 프로브가 수행되는 방법을 결정합니다. 예를 들어 상태 확인에서 TCP 포트 80의 HTTP 프로토콜을 사용하거나 인스턴스 그룹에 있는 이름이 지정된 포트의 TCP 프로토콜을 사용할 수 있습니다.

기존 상태 확인은 상태 확인으로 변환할 수 없고, 상태 확인을 기존 상태 확인으로 변환할 수도 없습니다.

상태 확인 선택

상태 확인이 부하 분산기 유형(또는 Traffic Director) 및 백엔드 유형과 호환되어야 합니다. 상태 확인을 선택할 때 고려해야 할 요소는 다음과 같습니다.

  • 카테고리:상태 확인 또는 기존 상태 확인
  • 프로토콜: Google Cloud가 백엔드를 프로브하는 데 사용하는 프로토콜
  • 포트 사양: Google Cloud에서 프로토콜에 사용하는 포트

부하 분산기 가이드에서는 각 부하 분산기 및 백엔드 유형에 유효한 상태 확인 선택을 설명합니다. 대략적인 요약은 상태 확인 기능 표를 참조하세요.

카테고리 및 프로토콜

부하 분산기와 동일한 프로토콜을 사용하는 것이 권장사항이지만 반드시 그래야 하는 것은 아니고, 항상 가능하지도 않습니다.

예를 들어 대상 풀 기반 네트워크 부하 분산기에는 기존 상태 확인이 필요하며 대상 풀 기반 네트워크 부하 분산기가 TCP 또는 UDP를 지원하더라도 기존 상태 확인은 HTTP 프로토콜을 사용해야 합니다. 대상 풀 기반 네트워크 부하 분산기의 경우 상태 확인 프로브에 응답할 수 있도록 가상 머신(VM) 인스턴스에서 HTTP 서버를 실행해야 합니다.

다른 거의 모든 부하 분산기 유형에는 프로토콜이 부하 분산기의 백엔드 서비스 프로토콜과 일치하는 경우에 기존 상태 확인이 아닌 일반 상태 확인을 사용해야 합니다.

카테고리 및 포트 사양

상태 확인에 사용할 포트를 지정해야 합니다. 상태 확인에는 2개의 포트 사양 메서드(--port--use-serving-port)가 있습니다. 기존 상태 확인에서는 하나의 메서드(--port)가 사용됩니다.

부하 분산기 가이드

다음 표에서는 각 부하 분산기 및 백엔드 유형에 대해 지원되는 카테고리, 범주, 포트 사양을 보여줍니다.

부하 분산기 백엔드 유형 상태 확인 카테고리 및 범위 포트 지정
전역 외부 HTTP(S) 부하 분산기

전역 외부 HTTP(S) 부하 분산기(기본) 1

외부 TCP 프록시 부하 분산기

외부 SSL 프록시 부하 분산기
지원되는 NEG 상태 확인(전역)
  • 커스텀 포트 번호(--port)
  • 엔드포인트의 포트 번호(--use-serving-port)
인스턴스 그룹 상태 확인(전역)
  • 커스텀 포트 번호(--port)
  • 백엔드 서비스의 이름이 지정된 포트(--use-serving-port)
리전 외부 HTTP(S) 부하 분산기 지원되는 NEG 상태 확인(리전별)
  • 커스텀 포트 번호(--port)
  • 엔드포인트의 포트 번호(--use-serving-port)
인스턴스 그룹 상태 확인(리전별)
  • 커스텀 포트 번호(--port)
  • 백엔드 서비스의 이름이 지정된 포트(--use-serving-port)
내부 HTTP(S) 부하 분산기
내부 리전 TCP 프록시 부하 분산기
지원되는 NEG 상태 확인(리전별)
  • 커스텀 포트 번호(--port)
  • 엔드포인트의 포트 번호(--use-serving-port)
인스턴스 그룹 상태 확인(리전별)
  • 커스텀 포트 번호(--port)
  • 백엔드 서비스의 이름이 지정된 포트(--use-serving-port)
네트워크 부하 분산기 2 인스턴스 그룹 상태 확인(리전)
  • 커스텀 포트 번호(--port)
대상 풀의
인스턴스
기존 상태 확인
(HTTP 프로토콜을 사용하는 전역)
기존 상태 확인은 포트 번호(--port) 사양만 지원합니다.
내부 TCP/UDP 부하 분산기 2 지원되는 NEG 상태 확인(전역 또는 리전)
  • 커스텀 포트 번호(--port)
인스턴스 그룹 상태 확인(전역 또는 리전)
  • 커스텀 포트 번호(--port)

1 외부 HTTP(S) 부하 분산기의 경우 기존 상태 확인이 권장되지 않지만 부하 분산기 모드에 따라 지원되는 경우도 있습니다.

부하 분산기 모드 기존 상태 확인 지원
전역 외부 HTTP(S) 부하 분산기 아니요
리전 외부 HTTP(S) 부하 분산기 아니요
외부 HTTP(S) 부하 분산기 예. 다음 두 조건을 모두 충족하는 경우:
  • 백엔드가 인스턴스 그룹입니다.
  • 백엔드 VM이 HTTP 또는 HTTPS 프로토콜을 사용하는 트래픽을 제공합니다.

2 내부 TCP/UDP 부하 분산기와 외부 TCP/UDP 네트워크 부하 분산기에 사용되는 백엔드 서비스는 이름이 지정된 어떤 포트도 구독하지 않으므로 --use-serving-port 플래그를 사용할 수 없습니다. 또한 내부 TCP/UDP 부하 분산기는 포트 정보가 없는 GCE_VM_IP 엔드포인트가 있는 영역 NEG만 지원합니다.

상태 확인 작동 방법

다음 섹션에서는 상태 확인의 작동 방법을 설명합니다.

프로브

상태 확인을 만들 때 또는 기존 상태 확인을 만들 때 다음 플래그를 지정하거나 기본값을 그대로 사용합니다. 사용자가 만드는 각 상태 확인 또는 기존 상태 확인은 여러 프로브로 구현됩니다. 이러한 플래그는 프로브가 인스턴스 그룹의 인스턴스 또는 영역 NEG의 엔드포인트를 평가하는 빈도를 제어합니다.

상태 확인의 설정은 백엔드별로 구성할 수 없습니다. 상태 확인은 전체 백엔드 서비스와 연결됩니다. 대상 풀 기반 네트워크 부하 분산의 경우 레거시 HTTP 상태 확인이 전체 대상 풀과 연결됩니다. 따라서 프로브의 매개변수는 특정 백엔드 서비스 또는 대상 풀에서 참조하는 모든 백엔드에 대해 동일합니다.

구성 플래그 목적 기본값
확인 간격
check-interval
확인 간격은 한 프로버에 의해 실행된 한 프로브의 시작부터 동일한 프로버에 의해 실행된 다음 프로브의 시작까지의 시간입니다. 단위는 초입니다. 5s(5초)
제한 시간
timeout
제한 시간은 Google Cloud가 프로브 응답을 기다리는 시간입니다. 이 값은 확인 간격보다 작거나 같아야 합니다. 단위는 초입니다. 5s(5초)

프로브 IP 범위 및 방화벽 규칙

상태 확인이 작동하기 위해서는 Google Cloud 프로버의 트래픽이 백엔드에 연결될 수 있도록 인그레스 allow 방화벽 규칙을 만들어야 합니다.

다음 표에는 허용할 소스 IP 범위가 나와 있습니다.

제품 프로브 소스 IP 범위 방화벽 규칙 예시
  • 전역 외부 HTTP(S) 부하 분산기
  • 전역 외부 HTTP(S) 부하 분산기(기본)
  • 리전 외부 HTTP(S) 부하 분산기
  • 내부 HTTP(S) 부하 분산
  • 내부 TCP/UDP 부하 분산
  • 외부 SSL 프록시 부하 분산
  • 외부 TCP 프록시 부하 분산
  • Traffic Director
  • 35.191.0.0/16
  • 130.211.0.0/22
네트워크 부하 분산기를 제외한 모든 제품의 방화벽 규칙
네트워크 부하 분산

백엔드로 들어오는 IPv4 트래픽:

  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22

백엔드로 들어오는 IPv6 트래픽:

  • 2600:1901:8001::/48

대상 풀 기반 네트워크 부하 분산기는 IPv4 트래픽만 지원하고 메타데이터 서버를 통해 상태 확인을 프록시할 수 있습니다. 이 경우 상태 확인 패킷 소스는 메타데이터 서버의 IP 주소 169.254.169.254와 일치합니다.

네트워크 부하 분산기에 대한 방화벽 규칙

방화벽 규칙의 중요성

Google Cloud에서는 프로버에서 백엔드로의 트래픽을 허용하기 위해 필요한 인그레스 allow 방화벽 규칙을 만들어야 합니다. 권장사항에 따라서는 상태 확인에 사용되는 것과 일치하는 프로토콜 및 포트로 이러한 규칙을 제한합니다. 소스 IP 범위에 대해서는 이전 섹션에 나열되어 설명된 프로브 IP 범위를 사용합니다.

상태 확인을 허용하는 인그레스 allow 방화벽 규칙이 없으면 암시적인 deny 규칙이 인바운드 트래픽을 차단합니다. 프로버가 백엔드에 연락할 수 없으면 부하 분산기가 백엔드를 비정상으로 간주합니다. 모든 백엔드가 비정상일 때의 동작은 부하 분산기 유형에 따라 달라집니다.

  • 모든 백엔드가 비정상이면 전역 외부 HTTP(S) 부하 분산기(기본)가 HTTP 502 응답을 반환합니다.

  • 모든 백엔드가 비정상이면 전역 외부 HTTP(S) 부하 분산기, 리전 외부 HTTP(S) 부하 분산기, 내부 HTTP(S) 부하 분산기가 HTTP 503 응답을 반환합니다.

  • 모든 백엔드가 비정상이면 외부 SSL 프록시 부하 분산기 및 외부 TCP 프록시 부하 분산기가 시간 초과됩니다.

  • 모든 백엔드가 비정상일 때 내부 리전 TCP 프록시 부하 분산기는 TCP RST 패킷을 전송하여 클라이언트 연결을 종료합니다.

  • 모든 백엔드가 비정상이고 장애 조치가 구성되지 않으면 내부 TCP/UDP 부하 분산기와 백엔드 서비스 기반 네트워크 부하 분산기는 최후의 수단으로 트래픽을 모든 백엔드 VM에 분산합니다. 이 동작에 대한 자세한 내용은 내부 TCP/UDP 부하 분산기의 트래픽 분산백엔드 서비스 기반 네트워크 부하 분산기의 트래픽 분산을 참조하세요.

  • 모든 백엔드가 비정상이면 대상 풀 기반 네트워크 부하 분산기가 최후의 수단으로 트래픽을 모든 백엔드 VM에 분산합니다.

프로브 IP 범위에 대한 보안 고려사항

상태 확인 및 필요한 방화벽 규칙을 계획할 때는 다음 정보를 고려하세요.

  • 프로브 IP 범위는 Google에 속합니다. Google Cloud는 VPC 네트워크 외부에 있지만 Google의 프로덕션 네트워크 내부에 있는 특수 경로를 사용하여 프로버로부터의 통신을 지원합니다.

  • Google은 프로브 IP 범위를 사용하여 외부 HTTP(S) 부하 분산기, 외부 SSL 프록시 부하 분산기, 외부 TCP 프록시 부하 분산기에 대한 상태 확인 프로브를 전송합니다. 패킷이 인터넷에서 수신되었고 패킷의 소스 IP 주소가 프로브 IP 범위 내에 있으면 Google이 해당 패킷을 삭제합니다. 여기에는 Compute Engine 인스턴스 또는 Google Kubernetes Engine(GKE) 노드의 외부 IP 주소가 포함됩니다.

  • 프로브 IP 범위는 Google Cloud 프로버에 사용되는 사용 가능한 IP 주소의 전체 집합입니다. tcpdump 또는 비슷한 도구를 사용할 경우에는 모든 프로브 IP 범위의 모든 IP 주소로부터 트래픽을 관찰할 수 없습니다. 모든 프로브 IP 범위를 소스로 허용하는 인그레스 방화벽 규칙을 만드는 것이 좋습니다. Google Cloud는 알림 없이 자동으로 새 프로버를 구현할 수 있습니다.

다중 프로브 및 빈도

Google Cloud는 프로버라고 부르는 다중 중복 시스템으로부터 상태 확인 프로브를 보냅니다. 프로버는 특정 소스 IP 범위를 사용합니다. Google Cloud는 상태 확인을 구현하기 위해 단일 프로버에만 의존하지 않습니다. 여러 프로버가 인스턴스 그룹 백엔드의 인스턴스 또는 영역 NEG 백엔드의 엔드포인트를 동시에 평가합니다. 프로버 하나가 실패하면 Google Cloud가 백엔드 상태를 계속 추적합니다.

상태 확인을 위해 구성하는 간격 및 제한 시간 설정이 각 프로버에 적용됩니다. 특정 백엔드에서 소프트웨어 액세스 로그와 tcpdump는 구성된 설정보다 더 자주 프로브를 표시합니다.

이것은 예상된 동작이며 Google Cloud가 상태 확인을 위해 사용하는 프로버 수를 사용자가 구성할 수 없습니다. 그러나 다음과 같은 사항을 고려하여 여러 동시 프로브의 효과를 예측할 수 있습니다.

  • 백엔드 서비스당 프로브 빈도를 추정하려면 다음을 고려하세요.

    • 백엔드 서비스별 기본 빈도: 각 상태 확인에는 확인 빈도가 설정되며 이 값은 구성된 확인 간격에 반비례합니다.

      1(확인 간격)

      상태 확인을 백엔드 서비스와 연결할 때 백엔드 서비스의 백엔드에 각 프로버에서 사용하는 기본 빈도를 설정합니다.

    • 프로브 배율. 백엔드 서비스의 기본 빈도에 Google Cloud가 사용하는 동시 프로버 수를 곱합니다. 이 수는 경우에 따라 다르지만 일반적으로 5~10입니다.

  • 내부 TCP/UDP 부하 분산기의 다중 전달 규칙. 동일한 리전별 내부 백엔드 서비스를 가리키는 여러 내부 전달 규칙(각각 다른 주소 포함)을 구성한 경우 Google Cloud는 여러 프로버를 사용하여 각 IP 주소를 확인합니다. 백엔드 서비스당 프로브 빈도에 구성된 전달 규칙의 수를 곱합니다.

  • 네트워크 부하 분산기의 여러 전달 규칙. 동일한 백엔드 서비스 또는 대상 풀을 가리키는 여러 전달 규칙을 구성한 경우 Google Cloud는 여러 프로버를 사용하여 각 IP 주소를 확인합니다. 백엔드 VM당 프로브 빈도에 구성된 전달 규칙의 수를 곱합니다.

  • 외부 HTTP(S) 부하 분산기에 대한 여러 대상 프록시. 동일한 URL 맵으로 트래픽을 전달하는 여러 대상 프록시가 있는 경우 Google Cloud는 여러 프로버를 사용해서 각 대상 프록시와 연결된 IP 주소를 확인합니다. 백엔드 서비스당 프로브 빈도에 구성된 대상 프록시 수를 곱합니다.

  • 외부 SSL 프록시 부하 분산기, 외부 TCP 프록시 부하 분산기, 내부 리전 TCP 프록시 부하 분산기에 대한 여러 대상 프록시. 동일한 백엔드 서비스로 트래픽을 전달하는 여러 대상 프록시를 구성한 경우 Google Cloud는 여러 프로버를 사용하여 각 대상 프록시와 연결된 IP 주소를 확인합니다. 백엔드 서비스당 프로브 빈도에 구성된 대상 프록시 수를 곱합니다.

  • 백엔드 서비스의 합계. 백엔드가 여러 백엔드 서비스에서 사용되는 경우 백엔드 인스턴스는 각 백엔드 서비스 상태 확인의 빈도 합계만큼 자주 연결됩니다.

    영역 NEG 백엔드를 사용하면 상태 확인 프로브의 정확한 수를 알기가 더 어렵습니다. 예를 들어 동일한 엔드포인트가 여러 영역 NEG에 있을 수 있습니다. 이러한 영역 NEG가 반드시 동일한 엔드포인트 집합을 포함하지는 않으며, 서로 다른 엔드포인트가 동일한 백엔드를 가리킬 수 있습니다.

프로브 패킷의 대상

다음 표에서는 부하 분산기 유형에 따라 상태 확인 프로버가 패킷을 전송하는 대상 IP 주소 및 네트워크 인터페이스를 보여줍니다.

네트워크 부하 분산기 및 내부 TCP/UDP 부하 분산기의 경우 애플리케이션은 부하 분산기의 IP 주소(또는 모든 IP 주소 0.0.0.0)에 결합되어야 합니다.

부하 분산기 대상 네트워크 인터페이스 대상 IP 주소
  • 전역 외부 HTTP(S) 부하 분산기
  • 전역 외부 HTTP(S) 부하 분산기(기본)
  • 리전 외부 HTTP(S) 부하 분산기
  • 내부 HTTP(S) 부하 분산기
  • 외부 SSL 프록시 부하 분산기
  • 외부 TCP 프록시 부하 분산기
  • 내부 리전 TCP 프록시 부하 분산기(미리보기)
  • Traffic Director
기본 네트워크 인터페이스(nic0)
  • 인스턴스 그룹 백엔드에 대해 각 인스턴스의 기본 네트워크 인터페이스(nic0)와 연결된 기본 내부 IP 주소입니다.
  • 영역 NEG 백엔드에 대한 엔드포인트의 IP 주소입니다. 기본 내부 IP 주소이거나 엔드포인트를 호스팅하는 인스턴스의 기본 네트워크 인터페이스 nic0에 해당하는 별칭 IP 범위 중 하나입니다.
네트워크 부하 분산기 기본 네트워크 인터페이스(nic0) 외부 전달 규칙의 IP 주소입니다.

여러 전달 규칙이 동일한 백엔드 서비스(대상 풀 기반 네트워크 부하 분산의 경우 동일한 대상 풀)를 가리키는 경우 Google Cloud는 각 전달 규칙의 IP 주소로 프로브를 보냅니다. 그러면 프로브 수가 증가할 수 있습니다.
내부 TCP/UDP 부하 분산기 내부 백엔드 서비스에 대해 지정된 네트워크에 있는 인스턴스의 네트워크 인터페이스입니다. 지정되지 않았으면 기본 네트워크 인터페이스(nic0)가 사용됩니다.

자세한 내용은 백엔드 서비스 및 네트워크 인터페이스를 참조하세요.
내부 전달 규칙의 IP 주소입니다.

여러 전달 규칙이 동일한 백엔드 서비스를 가리키는 경우 Google Cloud는 각 전달 규칙의 IP 주소로 프로브를 보냅니다. 그러면 프로브 수가 증가할 수 있습니다.

HTTP, HTTPS, HTTP/2의 성공 기준

상태 확인에 HTTP, HTTPS, HTTP/2 프로토콜이 사용되는 경우 각 프로브에는 프로브 제한 시간 전에 HTTP 200 (OK) 응답 코드가 전달되어야 합니다. 또한 다음을 수행할 수 있습니다.

  • HTTP 요청을 특정 요청 경로로 보내도록 Google Cloud 프로버를 구성할 수 있습니다. 요청 경로를 지정하지 않으면 /가 사용됩니다.

  • 예상 응답 문자열을 지정하여 콘텐츠 기반 상태 확인을 구성하는 경우 Google Cloud가 HTTP 응답 본문의 처음 1,024바이트 내에서 예상 문자열을 찾아야 합니다.

HTTP, HTTPS, HTTP/2 프로토콜을 사용하는 상태 확인에는 다음과 같은 요청 경로와 응답 문자열 플래그 조합을 사용할 수 있습니다.

구성 플래그 성공 기준
요청 경로
request-path
Google Cloud가 상태 확인 프로브 요청을 보내는 URL 경로를 지정합니다.
생략하면 Google Cloud가 루트 경로 /로 프로브 요청을 보냅니다.
응답
response
선택사항인 응답 플래그를 사용하면 콘텐츠 기반 상태 확인을 구성할 수 있습니다. 예상 응답 문자열은 ASCII(단일 바이트) 1,024자 이하여야 합니다. 구성된 경우 Google Cloud는 HTTP 200 (OK) 상태를 수신하는 것 외에도 응답의 처음 1,024바이트 내에 이 문자열이 있을 것으로 예상합니다.

SSL 및 TCP의 성공 기준

예상 응답 문자열을 지정하지 않는 한, SSL 및 TCP 프로토콜을 사용하는 상태 확인에 대한 프로브는 다음 기본 조건이 모두 true인 경우에 성공합니다.

  • 각 Google Cloud 프로버는 구성된 프로브 제한 시간 전에 SSL 또는 TCP 핸드셰이크를 성공적으로 완료할 수 있습니다.
  • TCP 상태 확인에서는 TCP 세션이 다음 중 하나를 통해 단계적으로 종료됩니다.
    • 백엔드 또는
    • 프로버에 대한 TCP 세션이 계속 설정된 동안 TCP RST(재설정) 패킷을 전송하는 Google Cloud 프로버

백엔드가 TCP 상태 확인의 TCP 세션을 닫기 위해 TCP RST (reset) 패킷을 보내는 경우 프로브가 실패한 것으로 간주될 수 있습니다. Google Cloud 프로버가 이미 단계적 TCP 종료를 시작한 경우에 이러한 상황이 발생합니다.

각 문자열 길이가 최대 1,024자(ASCII, 싱글 바이트)에 해당하는 요청 문자열 및 예상 응답 문자열을 제공할 경우 콘텐츠 기반 상태 확인을 만들 수 있습니다. 예상 응답 문자열이 구성된 경우 Google Cloud는 기본 조건이 충족되고 반환된 응답 문자열이 예상 응답 문자열과 정확히 일치하는 경우에만 프로브가 성공한 것으로 간주합니다.

SSL 및 TCP 프로토콜을 사용하는 상태 확인에 다음과 같은 요청 및 응답 플래그의 조합을 이용할 수 있습니다.

구성 플래그 성공 기준
요청 또는 응답이 지정되지 않음

플래그가 지정되지 않음: --request, --response
Google Cloud는 기본 조건이 충족된 경우에 프로브가 성공한 것으로 간주합니다.
요청 및 응답이 모두 지정됨

두 플래그가 모두 지정됨: --request, --response
Google Cloud가 구성된 요청 문자열을 보내고 예상 응답 문자열을 기다립니다. Google Cloud는 기본 조건이 충족되고 반환된 응답 문자열이 예상 응답 문자열과 정확하게 일치하는 경우 프로브가 성공한 것으로 간주합니다.
응답만 지정됨

플래그 지정됨: --response
Google Cloud가 예상 응답 문자열을 기다리고 기본 조건이 충족되고 반환된 응답 문자열이 예상 응답 문자열과 정확하게 일치하는 경우에 프로브가 성공한 것으로 간주합니다.

백엔드가 TCP 또는 SSL 핸드셰이크의 일부로 응답 문자열을 자동으로 보내는 경우에만 --response를 단독으로 사용해야 합니다.
요청만 지정됨

플래그 지정됨: --request
Google Cloud가 구성된 요청 문자열을 보내고 기본 조건이 충족될 때 프로브를 성공한 것으로 간주합니다. 응답은 있어도 확인되지 않습니다.

gRPC의 성공 기준

gRPC 상태 확인을 사용하는 경우 gRPC 서비스에서 상태가 OK이고 상태 필드가 SERVING 또는 NOT_SERVING으로 적절히 설정된 RPC 응답을 보내야 합니다.

다음에 유의하세요.

  • gRPC 상태 확인은 gRPC 애플리케이션 및 Traffic Director에서만 사용됩니다.
  • gRPC 상태 확인에서는 TLS를 지원하지 않습니다.

자세한 내용은 다음을 참조하세요.

상태

Google Cloud는 다음 구성 플래그를 사용하여 트래픽이 부하 분산되는 각 백엔드의 전체 상태를 확인합니다.

구성 플래그 목적 기본값
정상 기준
healthy-threshold
정상 기준은 백엔드에 대해 연속으로 성공한 프로브 결과의 수를 정상으로 간주하도록 지정합니다. 2 프로브의 기준점
비정상 기준
unhealthy-threshold
비정상 기준은 백엔드에 대해 연속으로 실패한 프로브 결과의 수를 비정상으로 간주하도록 지정합니다. 2 프로브의 기준점

이러한 정상 기준이 충족되면 Google Cloud가 백엔드를 정상으로 간주합니다. 정상 백엔드는 새로운 연결을 받을 수 있습니다.

비정상 기준이 충족되면 Google Cloud가 백엔드를 비정상으로 간주합니다. 비정상 백엔드는 새로운 연결을 받을 수 없지만 기존 연결이 즉시 종료되지는 않습니다. 대신 시간 초과가 발생하거나 트래픽이 삭제될 때까지 연결이 열려 있습니다. 구체적인 동작은 사용 중인 부하 분산기의 유형에 따라 다릅니다.

프로브가 실패한 원인에 따라 기존 연결이 응답을 반환하지 못할 수 있습니다. 비정상 백엔드는 정상 기준을 다시 충족할 수 있으면 정상 상태가 될 수 있습니다.

기타 참고사항

콘텐츠 기반 상태 확인

콘텐츠 기반 상태 확인은 성공 기준이 예상 응답 문자열에 대한 평가에 따라 달라지는 상태 확인입니다. 콘텐츠 기반 상태 확인을 사용하여 Google Cloud 상태 확인 프로브가 백엔드 응답을 더 완전히 검증하도록 지시할 수 있습니다.

  • 예상 응답 문자열을 지정하고 선택적으로 요청 경로를 정의하여 HTTP, HTTPS 또는 HTTP/2 콘텐츠 기반 상태 확인을 구성합니다. 자세한 내용은 HTTP, HTTPS, HTTP/2의 성공 기준을 참조하세요.

  • 예상 응답 문자열을 지정하고 선택적으로 요청 문자열을 정의하여 SSL 또는 TCP 콘텐츠 기반 상태 확인을 구성합니다. 자세한 내용은 SSL 및 TCP의 성공 기준을 참조하세요.

인증서 및 상태 확인

Google Cloud 상태 확인 프로버는 예를 들어 백엔드에 SSL, HTTPS, HTTP/2와 같은 인증서가 사용되어야 하는 프로토콜에 대해서도 인증서 검증을 수행하지 않습니다.

  • 자체 서명된 인증서 또는 인증 기관(CA)에서 서명된 인증서를 사용할 수 있습니다.
  • 만료되었거나 아직 유효하지 않은 인증서도 사용 가능합니다.
  • CN 또는 subjectAlternativeName 속성은 Host 헤더 또는 DNS PTR 레코드와 일치할 필요가 없습니다.

헤더

이전 상태 확인 말고 프로토콜을 사용하는 상태 확인의 경우 --proxy-header 플래그를 사용하여 프록시 헤더를 설정할 수 있습니다.

HTTP, HTTPS, HTTP/2 프로토콜을 사용하는 상태 확인과 기존 상태 확인에서는 --host 플래그를 사용하여 HTTP Host 헤더를 지정할 수 있습니다.

상태 확인 예시

다음 설정으로 상태 확인을 설정한다고 가정하세요.

  • 간격: 30초
  • 제한 시간: 5초
  • 프로토콜: HTTP
  • 비정상 기준: 2(기본값)
  • 정상 기준: 2(기본값)

이 설정을 사용하면 상태 확인이 다음과 같이 작동합니다.

  1. 여러 중복 시스템이 상태 확인 매개변수로 동시에 구성됩니다. 내부 및 제한 시간 설정이 각 시스템에 적용됩니다. 자세한 내용은 여러 프로브 및 빈도를 참조하세요.
  2. 각 상태 확인 프로버는 다음을 수행합니다.

    1. 소스 IP 주소에서 백엔드 인스턴스로의 HTTP 연결을 30초 간격으로 시작합니다.
    2. HTTP 200 (OK) 응답 코드(HTTP, HTTPS, HTTP/2 프로토콜의 성공 기준)를 최대 5초 동안 기다립니다.
  3. 상태 확인 프로브 시스템 중 하나 이상이 다음을 수행하면 백엔드가 비정상으로 간주됩니다.

    1. 2개의 연속된 프로브에 대해 HTTP 200 (OK) 응답 코드를 가져오지 않습니다. 예를 들어 연결이 거부되거나 연결 또는 소켓 제한 시간이 초과될 수 있습니다.
    2. 프로토콜 특정 성공 기준과 일치하지 않는 응답이 두 번 연속으로 수신됩니다.
  4. 상태 확인 프로브 시스템 중 하나 이상이 프로토콜 특정 성공 기준과 일치하는 응답을 두 번 연속으로 수신하면 백엔드가 정상으로 간주됩니다.

이 예시에서 각 프로버는 연결을 30초 마다 시작합니다. 제한 시간 기간에 관계없이(연결 제한 시간이 초과되었는지 여부에 관계없이) 30초 간격으로 프로버 연결이 시도됩니다. 즉, 제한 시간이 이 간격보다 작거나 같아야 하고, 제한 시간을 늘려도 간격은 절대로 늘어나지 않습니다.

이 예시에서 각 프로버의 시간 설정(초 단위)은 다음과 같이 표시됩니다.

  1. t=0: 프로브 A를 시작합니다.
  2. t=5: 프로브 A를 중지합니다.
  3. t=30: 프로브 B를 시작합니다.
  4. t=35: 프로브 B를 중지합니다.
  5. t=60: 프로브 C를 시작합니다.
  6. t=65: 프로브 C를 중지합니다.

다음 단계