상태 확인 개요

Google Cloud는 인스턴스 그룹 및 영역별 네트워크 엔드포인트 그룹(NEG)과 같은 백엔드가 트래픽에 올바르게 응답하는지 확인하는 상태 확인 메커니즘을 제공합니다. 이 문서에서는 Google Cloud 부하 분산기 및 Traffic Director와 관련된 상태 확인 개념에 대해 설명합니다.

Google Cloud는 구성 가능한 주기에 따라 백엔드에 연결하는 전역 및 리전별 상태 확인 시스템을 제공합니다. 각 연결 시도를 프로브라고 부르고, 각 상태 확인 시스템을 프로버라고 부릅니다. Google Cloud는 각 프로브의 성공 또는 실패를 기록합니다.

상태 확인은 부하 분산기 및 Traffic Director에서 작동합니다. Google Cloud는 연속으로 성공 또는 실패한 구성 가능 프로브 수를 기반으로 부하 분산기 또는 Traffic Director의 각 백엔드에 대한 전반적인 상태를 계산합니다. 구성된 횟수만큼 성공적으로 응답한 백엔드는 정상으로 간주됩니다. 별도의 횟수만큼 응답하지 않는 백엔드는 비정상입니다.

Google Cloud는 각 백엔드의 전반적인 상태를 사용하여 새 요청을 수신할 자격이 있는지를 결정합니다. 프로브 빈도와 상태 임곗값을 구성할 수 있을 뿐만 아니라 성공적인 프로브를 정의하는 기준도 구성할 수 있습니다. 자세한 내용은 상태 확인 작동 방법 섹션을 참조하세요.

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

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

Google Cloud는 카테고리프로토콜별로 상태 확인을 구성합니다.

두 카테고리는 상태 확인기존 상태 확인입니다. 각 카테고리는 서로 다른 프로토콜 집합과 상태 확인에 사용되는 포트 지정 수단을 지원합니다. 프로토콜과 포트는 Google Cloud 상태 확인 시스템이 백엔드에 연결하는 방법을 결정합니다. 예를 들어 TCP 포트 80에서 HTTP 프로토콜을 사용하는 상태 확인을 만들거나, 인스턴스 그룹에 구성된 이름이 지정된 포트에 TCP 프로토콜을 사용하는 상태 확인을 만들 수 있습니다.

Traffic Director 및 대부분의 Google Cloud 부하 분산기에는 이전 상태 확인이 아닌 상태 확인이 필요하지만 네트워크 부하 분산에 대해서는 HTTP 프로토콜을 사용하는 이전 상태 확인이 필요합니다. 카테고리, 프로토콜, 포트 선택에 대한 자세한 내용은 다음 섹션인 상태 확인 선택을 참조하세요.

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

상태 확인 선택

상태 확인은 Traffic Director 또는 부하 분산기 유형 및 제품에서 사용하는 백엔드 유형(인스턴스 그룹 또는 영역별 NEG)과 호환되어야 합니다. 상태 확인을 만들 때 지정해야 하는 세 가지 요소는 다음과 같습니다.

  • 카테고리: 상태 확인 또는 이전 상태 확인. 부하 분산기와 호환되어야 합니다.
  • 프로토콜: 백엔드를 주기적으로 프로브하기 위해 Google Cloud 시스템에 사용되는 프로토콜을 정의합니다.
  • 포트 사양: 상태 확인 프로토콜에 사용되는 포트를 정의합니다.

이 섹션의 끝에 있는 가이드에는 특정한 부하 분산기 유형과 백엔드 유형에 따라 상태 확인 카테고리, 프로토콜, 포트 사양의 올바른 조합이 요약되어 있습니다.

여러 부하 분산기에서 지원되는 상태 확인 유형에 대한 자세한 내용은 상태 확인을 참조하세요.

카테고리 및 프로토콜

부하 분산기 유형과 부하 분산기가 사용하는 백엔드 유형이 상태 확인 카테고리를 결정합니다. 네트워크 부하 분산에는 HTTP 프로토콜을 사용하는 기존 상태 확인이 필요합니다. 다른 모든 부하 분산기 유형은 일반 상태 확인을 사용합니다.

상태 확인 카테고리에서 지원하는 프로토콜 목록에서 프로토콜을 선택해야 합니다. 부하 분산기와 동일한 프로토콜을 사용하는 것이 권장사항이지만 반드시 그래야 하는 것은 아니고, 항상 가능하지도 않습니다. 예를 들어 네트워크 부하 분산기에는 기존 상태 확인이 필요하며, 네트워크 부하 분산은 일반적으로 TCP와 UDP를 지원하지만 네트워크 부하 분산기는 기존 상태 확인에 HTTP 프로토콜을 사용해야 합니다. 네트워크 부하 분산기의 경우 상태 확인 프로브에 응답할 수 있도록 가상 머신(VM) 인스턴스에서 HTTP 서버를 실행해야 합니다.

다음 표에는 상태 확인 카테고리와 각 카테고리에서 지원되는 프로토콜이 나와있습니다.

상태 확인 카테고리 지원되는 프로토콜
상태 확인 • gRPC
• HTTP
• HTTPS
• HTTP/2(TLS 포함)
• SSL
• TCP
기존 상태 확인 • HTTP
• HTTPS

기존 HTTPS 상태 확인은 네트워크 부하 분산기에 대해 지원되지 않으며 대부분의 다른 부하 분산기 유형과 함께 사용될 수 없습니다.

카테고리 및 포트 사양

프로토콜 외에도 상태 확인을 위한 포트 사양을 선택해야 합니다. 상태 확인은 3가지 포트 사양 메서드를 제공하며, 기존 상태 확인은 하나의 메서드를 제공합니다. 각 부하 분산기 유형에 모든 포트 사양 메서드를 적용할 수 있는 것은 아닙니다. 부하 분산기 유형과 부하 분산기에 사용되는 백엔드 유형에 따라 사용자가 사용 가능한 포트 사양 메서드가 결정됩니다.

상태 확인 카테고리 포트 사양 메서드와 의미
상태 확인 --port: TCP 포트 번호 지정
--use-serving-port:
• 인스턴스 그룹에 대해 백엔드 서비스가 구독하는 이름이 지정된 포트를 사용합니다.
• 영역별 NEG에 대해서는 각 엔드포인트에 정의된 포트를 사용합니다.
기존 상태 확인 --port: TCP 포트 번호 지정

부하 분산기 가이드

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

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

TCP 프록시 부하 분산

SSL 프록시 부하 분산
영역별 NEG 상태 확인(전역)
  • 커스텀 포트 번호(--port)
  • 엔드포인트의 포트 번호(--use-serving-port)
인스턴스 그룹 상태 확인(전역)
  • 커스텀 포트 번호(--port)
  • 백엔드 서비스의 이름이 지정된 포트(--use-serving-port)

1 내부 백엔드 서비스에 연결된 이름이 지정된 포트가 없기 때문에 --use-serving-port 플래그를 사용할 수 없습니다.
2 다음과 같은 경우 외부 HTTP(S) 부하 분산기와 연결된 백엔드 서비스에 기존 상태 확인을 사용할 수는 있지만 권장되지 않습니다.

  • 백엔드는 영역별 NEG가 아닌 인스턴스 그룹입니다.
  • 백엔드 VM은 HTTP 또는 HTTPS 프로토콜을 사용하는 트래픽을 제공합니다.

상태 확인 작동 방법

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

프로브

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

상태 확인의 설정은 백엔드별로 구성할 수 없습니다. 상태 확인은 전체 백엔드 서비스와 연결되며, 기존 상태 확인은 전체 대상 풀(네트워크 부하 분산) 또는 백엔드 서비스(특정 외부 HTTP(S) 부하 분산 구성)와 연결됩니다. 따라서 프로브의 매개변수는 특정 백엔드 서비스 또는 대상 풀에서 참조하는 모든 백엔드에 대해 동일합니다.

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

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

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

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

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

방화벽 규칙의 중요성

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

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

  • 모든 백엔드가 비정상일 때 외부 HTTP(S) 부하 분산기는 클라이언트에 대해 HTTP 502 응답을 반환합니다.

  • 모든 백엔드가 비정상일 때 내부 HTTP(S) 부하 분산기는 HTTP 503 응답을 반환합니다.

  • 모든 백엔드가 비정상일 때 SSL 프록시 부하 분산기 및 TCP 프록시 부하 분산기는 시간 초과가 발생합니다.

  • 네트워크 부하 분산기는 모든 백엔드가 비정상일 때 모든 백엔드 VM에 대한 트래픽 분산을 마지막 방법으로 시도합니다.

  • 장애 조치가 구성되지 않은 내부 TCP/UDP 부하 분산기는 백엔드가 모두 비정상일 때 마지막 방법으로 모든 백엔드 VM에 대해 트래픽을 분산합니다. 장애 조치를 사용 설정한 경우 이 동작을 중지할 수 있습니다.

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

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

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

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

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

다중 프로브 및 빈도

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

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

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

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

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

      1(확인 간격)

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

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

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

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

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

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

  • 백엔드 서비스의 합계: 여러 백엔드 서비스에서 하나의 백엔드(예: 인스턴스 그룹)를 사용하는 경우 이 백엔드 인스턴스는 각 백엔드 서비스 상태 확인의 빈도 합계만큼 자주 연결됩니다.

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

프로브 패킷의 대상

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

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

부하 분산기 대상 네트워크 인터페이스 대상 IP 주소
내부 TCP/UDP 부하 분산 내부 백엔드 서비스에 대해 지정된 네트워크에 있는 인스턴스의 네트워크 인터페이스입니다. 지정되지 않았으면 기본 네트워크 인터페이스(nic0)가 사용됩니다.

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

여러 전달 규칙이 동일한 백엔드 서비스를 가리키는 경우 Google Cloud는 각 전달 규칙의 IP 주소로 프로브를 보냅니다. 그러면 프로브 수가 증가할 수 있습니다.
네트워크 부하 분산 기본 네트워크 인터페이스(nic0) 외부 전달 규칙의 IP 주소입니다.

여러 전달 규칙이 동일한 대상 풀을 가리킬 경우 Google Cloud는 각 전달 규칙의 IP 주소로 프로브를 보냅니다. 그러면 프로브 수가 증가할 수 있습니다.
외부 HTTP(S) 부하 분산

내부 HTTP(S) 부하 분산

SSL 프록시 부하 분산

TCP 프록시 부하 분산

기본 네트워크 인터페이스(nic0)
  • 인스턴스 그룹 백엔드에 대해 각 인스턴스의 기본 네트워크 인터페이스(nic0)와 연결된 기본 내부 IP 주소입니다.
  • 영역별 NEG 백엔드에 대한 엔드포인트의 IP 주소입니다. 기본 내부 IP 주소 또는 별칭 IP 범위(엔드포인트를 호스팅하는 인스턴스의 기본 네트워크 인터페이스 nic0에 해당) 중 하나입니다.

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

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

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

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

  • 예상 응답 문자열을 구성하는 경우에는 각 Google Cloud 상태 확인 프로브가 백엔드에서 제공되는 실제 응답의 처음 1,024 바이트 내에서 예상 응답 문자열을 찾아야 합니다.

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

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

SSL 및 TCP의 성공 기준

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

  • 각 Google Cloud 프로버는 구성된 프로브 제한 시간 전에 SSL 또는 TCP 핸드셰이크를 성공적으로 완료할 수 있습니다.
  • TCP 상태 확인의 경우 TCP 세션이 백엔드 또는 Google Cloud 프로버에서 단계적으로 종료되거나, 프로버에 대한 TCP 세션이 계속 설정된 동안 백엔드가 TCP RST(reset) 패킷을 보냅니다.

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 문서를 참조하세요.

상태

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

구성 플래그 목적 기본값
정상 기준
healthy-threshold
정상 기준은 백엔드에 대해 연속으로 성공한 프로브 결과의 수를 정상으로 간주하도록 지정합니다. 생략할 경우 Google Cloud는 2 프로브 기준을 사용합니다.
비정상 기준
unhealthy-threshold
비정상 기준은 백엔드에 대해 연속으로 실패한 프로브 결과의 수를 비정상으로 간주하도록 지정합니다. 생략할 경우 Google Cloud는 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를 중지합니다.

다음 단계