상태 점검 개요

Google Cloud는 Google Cloud 부하 분산기 백엔드, Cloud Service Mesh 백엔드, 관리형 인스턴스 그룹을 위한 애플리케이션 기반 자동 복구에 대한 구성 가능한 상태 점검을 제공합니다. 이 문서에서는 주요 상태 점검 개념을 설명합니다.

달리 명시되지 않는 한 Google Cloud 상태 점검은 상태 점검 리소스에 지정된 매개변수에 따라 백엔드에 연결되는 전용 소프트웨어 태스크로 구현됩니다. 각 연결 시도를 프로브라고 합니다. Google Cloud는 각 프로브의 성공 또는 실패를 기록합니다.

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

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

전용 소프트웨어 태스크로 구현된 상태 점검은 Virtual Private Cloud(VPC) 네트워크에 정의되지 않은 특수 경로를 사용합니다. 자세한 내용은 상태 점검 경로를 참조하세요.

상태 점검 카테고리, 프로토콜, 포트

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

상태 확인
- 리전(gRPC, TCP, SSL, HTTP, HTTPS, HTTP/2)
- 전역(gRPC, TCP, SSL, HTTP, HTTPS, HTTP/2)
기존 상태 점검
- 기존 전역(HTTP)
- 기존 전역(HTTPS)

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

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

상태 점검을 선택합니다.

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

카테고리:상태 점검 또는 기존 상태 점검 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기에만 기존 상태 점검이 필요합니다. 다른 모든 제품에는 일반 상태 점검을 사용합니다.
프로토콜: Google Cloud가 백엔드를 프로브하는 데 사용하는 프로토콜 프로토콜이 부하 분산기의 백엔드 서비스 또는 대상 풀에서 사용하는 프로토콜과 일치하는 상태 점검(또는 이전 상태 점검)을 사용하는 것이 가장 좋습니다. 그러나 상태 점검 프로토콜과 부하 분산기 프로토콜이 반드시 동일할 필요는 없습니다.
포트 사양: Google Cloud에서 프로토콜에 사용하는 포트 상태 점검에 사용할 포트를 지정해야 합니다. 상태 점검에는 --port와 --use-serving-port의 두 가지 포트 사양 메서드가 있습니다. 기존 상태 점검의 경우 --port 메서드가 있습니다. 부하 분산기별 상태 점검 포트 요구사항에 관한 자세한 내용은 포트 사양 플래그를 참조하세요.

다음 섹션에서는 각 부하 분산기 및 백엔드 유형에 유효한 상태 점검 선택을 설명합니다.

부하 분산기 가이드

다음 표에는 각 부하 분산기 유형에 대해 지원되는 상태 점검 카테고리와 범위가 나와 있습니다.

부하 분산기	상태 점검 카테고리 및 범위
전역 외부 애플리케이션 부하 분산기 기본 애플리케이션 부하 분산기 ^* 전역 외부 프록시 네트워크 부하 분산기 기본 프록시 네트워크 부하 분산기 리전 간 내부 애플리케이션 부하 분산기 리전 간 내부 프록시 네트워크 부하 분산기	상태 점검(전역)
리전별 외부 애플리케이션 부하 분산기 리전별 내부 애플리케이션 부하 분산기 리전별 내부 프록시 네트워크 부하 분산기 리전별 외부 프록시 네트워크 부하 분산기	상태 점검(리전별)
외부 패스 스루 네트워크 부하 분산기	백엔드 서비스 기반 부하 분산기: 상태 점검(리전별) 대상 풀 기반 부하 분산기: 기존 상태 점검 (HTTP 프로토콜을 사용하는 전역)
내부 패스 스루 네트워크 부하 분산기	상태 점검(전역 또는 리전)

^* 외부 애플리케이션 부하 분산기의 경우 기존 상태 점검이 권장되지 않지만 부하 분산기 모드에 따라 지원되는 경우도 있습니다.

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

부하 분산기 모드

기존 상태 점검 지원

전역 외부 애플리케이션 부하 분산기

기본 애플리케이션 부하 분산기

예. 다음 두 조건을 모두 충족하는 경우:

백엔드가 인스턴스 그룹입니다.
백엔드 VM이 HTTP 또는 HTTPS 프로토콜을 사용하는 트래픽을 제공합니다.

리전 외부 애플리케이션 부하 분산기

아니요

추가 사용법 참고사항:

VM 인스턴스 그룹 백엔드의 경우 상태 점검은 시작된 VM 인스턴스에서만 수행됩니다. 중지된 VM 인스턴스는 상태 점검 패킷을 수신하지 않습니다.
내부 패스 스루 네트워크 부하 분산기의 경우 백엔드 서비스 프로토콜로 TCP 또는 UDP만 사용할 수 있습니다. 내부 패스 스루 네트워크 부하 분산기 뒤에 있는 VM의 HTTP 트래픽을 처리하는 경우 HTTP 프로토콜을 사용하여 상태 점검을 수행하는 것이 좋습니다.
대상 풀 기반 외부 패스 스루 네트워크 부하 분산기는 기존 HTTP 상태 점검을 사용해야 합니다. 기존 HTTPS 상태 점검 또는 기존 상태 점검이 아닌 상태 점검을 사용할 수 없습니다. 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기를 사용하여 TCP 트래픽을 분산하는 경우 상태 점검 프로브에 응답할 수 있도록 부하 분산되는 VM에서 HTTP 서비스를 실행해야 합니다.

다른 거의 모든 부하 분산기 유형에는 프로토콜이 부하 분산기의 백엔드 서비스 프로토콜과 일치하는 경우에 기존 상태 점검이 아닌 일반 상태 점검을 사용해야 합니다.
gRPC 프로토콜을 사용하는 백엔드 서비스의 경우 gRPC 또는 TCP 상태 점검만 사용하세요. HTTP(S) 또는 HTTP/2 상태 점검은 사용하지 마세요.
하이브리드 NEG 백엔드를 사용하는 특정 Envoy 기반 부하 분산기는 gRPC 상태 점검을 지원하지 않습니다. 자세한 내용은 하이브리드 NEG 개요를 참조하세요.

Cloud Service Mesh로 상태 점검

Cloud Service Mesh에서 상태 점검을 사용할 때는 다음과 같은 동작의 차이에 유의하세요.

Cloud Service Mesh를 사용하면 INTERNET_FQDN_PORT 및 NON_GCP_PRIVATE_IP_PORT 유형의 네트워크 엔드포인트에 대한 상태 점검 동작은 다른 유형의 네트워크 엔드포인트에 대한 상태 점검 동작과 다릅니다. Cloud Service Mesh는 전용 소프트웨어 태스크를 사용하는 대신 Envoy 프록시를 프로그래밍하여 인터넷 NEG(INTERNET_FQDN_PORT 엔드포인트) 및 하이브리드 NEG(NON_GCP_PRIVATE_IP_PORT 엔드포인트)에 대한 상태 점검을 수행합니다.

Envoy는 상태 점검을 위해 다음 프로토콜을 지원합니다.
- HTTP
- HTTPS
- HTTP/2
- TCP
Cloud Service Mesh가 서비스 디렉터리와 통합되고 서비스 디렉터리 서비스를 Cloud Service Mesh 백엔드 서비스에 바인딩하는 경우 백엔드 서비스에는 상태 점검을 설정할 수 없습니다.

상태 점검 작동 방법

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

프로브

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

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

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

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

상태 점검이 작동하기 위해서는 Google Cloud 프로버의 트래픽이 백엔드에 연결될 수 있도록 인그레스 allow 방화벽 규칙을 만들어야 합니다. 자세한 내용은 필수 방화벽 규칙 만들기를 참조하세요.

다음 표에는 각 부하 분산기에 허용할 소스 IP 범위가 나와 있습니다.

제품	상태 점검 프로브 소스 IP 범위
전역 외부 애플리케이션 부하 분산기 전역 외부 프록시 네트워크 부하 분산기	`35.191.0.0/16` `130.211.0.0/22` 백엔드로 들어오는 IPv6 트래픽: `2600:2d00:1:b029::/64` `2600:2d00:1:1::/64`
리전별 외부 애플리케이션 부하 분산기 ^{1, 2} 리전 간 내부 애플리케이션 부하 분산기 ¹ 리전별 내부 애플리케이션 부하 분산기 ^{1, 2} 리전별 외부 프록시 네트워크 부하 분산기^{1, 2} 리전별 내부 프록시 네트워크 부하 분산기^{1, 2} 리전 간 내부 프록시 네트워크 부하 분산기 ¹	`35.191.0.0/16` `130.211.0.0/22` 백엔드로 들어오는 IPv6 트래픽: `2600:2d00:1:b029::/64`
기존 프록시 네트워크 부하 분산기 기본 애플리케이션 부하 분산기 Cloud Service Mesh(인터넷 NEG 백엔드 및 하이브리드 NEG 백엔드 제외)	`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 트래픽: `35.191.0.0/16` `130.211.0.0/22` 백엔드로 들어오는 IPv6 트래픽: `2600:2d00:1:b029::/64`
Cloud Service Mesh(인터넷 NEG 백엔드 및 하이브리드 NEG 백엔드 포함)	Envoy 소프트웨어를 실행하는 VM의 IP 주소 샘플 구성은 Cloud Service Mesh 문서를 참조하세요.

¹ 하이브리드 NEG에는 Google의 상태 점검 프로브 범위를 허용 목록에 추가할 필요가 없습니다. 하지만 단일 백엔드 서비스에서 하이브리드 및 영역 NEG 조합을 사용하는 경우 영역별 NEG에 Google 상태 점검 프로브 범위를 허용 목록에 추가해야 합니다.

² 리전 인터넷 NEG의 경우 상태 점검은 선택사항입니다. 리전 인터넷 NEG를 사용하는 부하 분산기의 트래픽은 프록시 전용 서브넷에서 시작되며 수동 또는 자동 할당된 NAT IP 주소로 NAT 변환됩니다(Cloud NAT 사용). 이 트래픽에는 상태 점검 프로브와 부하 분산기에서 백엔드로의 사용자 요청이 포함됩니다. 자세한 내용은 리전 NEG: 이그레스 Cloud NAT 사용을 참조하세요.

³ 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기는 IPv4 트래픽만 지원하고 메타데이터 서버를 통해 상태 점검을 프록시할 수 있습니다. 이 경우 상태 점검 패킷 소스는 메타데이터 서버의 IP 주소 169.254.169.254와 일치합니다. 메타데이터 서버의 트래픽을 허용하도록 방화벽 규칙을 만들 필요가 없습니다. 메타데이터 서버의 패킷은 항상 허용됩니다.

방화벽 규칙의 중요성

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

상태 점검을 허용하는 인그레스 allow 방화벽 규칙이 없으면 암시적인 deny 규칙이 인바운드 트래픽을 차단합니다. 프로버가 백엔드에 연락할 수 없으면 부하 분산기가 백엔드를 비정상으로 간주합니다.

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

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

프로브 IP 범위는 Google에 속합니다. Google Cloud는 VPC 네트워크 외부에 있지만 Google의 프로덕션 네트워크 내부에 있는 특수 경로를 사용하여 프로버로부터의 통신을 지원합니다.
Google은 프로브 IP 범위를 사용하여 외부 애플리케이션 부하 분산기 및 외부 프록시 네트워크 부하 분산기에 대한 상태 점검 프로브를 전송합니다. 패킷이 인터넷에서 수신되었고 패킷의 소스 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가 상태 점검을 위해 사용하는 프로버 수를 사용자가 구성할 수 없습니다. 그러나 다음과 같은 사항을 고려하여 여러 동시 프로브의 효과를 예측할 수 있습니다.

백엔드 서비스당 프로브 빈도를 추정하려면 다음을 고려하세요.
- 백엔드 서비스별 기본 빈도: 각 상태 점검에는 확인 빈도가 설정되며 이 값은 구성된 확인 간격에 반비례합니다.
  
  ¹⁄_{(확인 간격)}
  
  상태 점검을 백엔드 서비스와 연결할 때 백엔드 서비스의 백엔드에 각 프로버에서 사용하는 기본 빈도를 설정합니다.
- 프로브 배율. 백엔드 서비스의 기본 빈도에 Google Cloud가 사용하는 동시 프로버 수를 곱합니다. 이 수는 경우에 따라 다르지만 일반적으로 5~10입니다.
내부 패스 스루 네트워크 부하 분산기의 여러 전달 규칙. 동일한 리전별 내부 백엔드 서비스를 가리키는 여러 내부 전달 규칙(각각 다른 주소 포함)을 구성한 경우 Google Cloud는 여러 프로버를 사용하여 각 IP 주소를 확인합니다. 백엔드 서비스당 프로브 빈도에 구성된 전달 규칙의 수를 곱합니다.
외부 패스 스루 네트워크 부하 분산기의 여러 전달 규칙. 동일한 백엔드 서비스 또는 대상 풀을 가리키는 여러 전달 규칙을 구성한 경우 Google Cloud는 여러 프로버를 사용하여 각 IP 주소를 확인합니다. 백엔드 VM당 프로브 빈도에 구성된 전달 규칙의 수를 곱합니다.
외부 애플리케이션 부하 분산기의 여러 대상 프록시. 동일한 URL 맵으로 트래픽을 전달하는 여러 대상 프록시가 있는 경우 Google Cloud는 여러 프로버를 사용해서 각 대상 프록시와 연결된 IP 주소를 확인합니다. 백엔드 서비스당 프로브 빈도에 구성된 대상 프록시 수를 곱합니다.
외부 프록시 네트워크 부하 분산기 및 리전 내부 프록시 네트워크 부하 분산기의 여러 대상 프록시. 동일한 백엔드 서비스로 트래픽을 전달하는 여러 대상 프록시를 구성한 경우 Google Cloud는 여러 프로버를 사용하여 각 대상 프록시와 연결된 IP 주소를 확인합니다. 백엔드 서비스당 프로브 빈도에 구성된 대상 프록시 수를 곱합니다.
백엔드 서비스의 합계. 백엔드가 여러 백엔드 서비스에서 사용되는 경우 백엔드 인스턴스는 각 백엔드 서비스 상태 점검의 빈도 합계만큼 자주 연결됩니다.

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

프로브 패킷의 대상

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

외부 패스 스루 네트워크 부하 분산기 및 내부 패스 스루 네트워크 부하 분산기의 경우 애플리케이션이 부하 분산기의 IP 주소(또는 모든 IP 주소 0.0.0.0)에 바인딩되어야 합니다.

부하 분산기	대상 네트워크 인터페이스	대상 IP 주소
전역 외부 애플리케이션 부하 분산기 전역 외부 프록시 네트워크 부하 분산기	인스턴스 그룹 백엔드의 경우 기본 네트워크 인터페이스입니다(`nic0`). `GCE_VM_IP_PORT` 엔드포인트가 있는 영역 NEG 백엔드의 경우 NEG와 연결된 VPC 네트워크의 네트워크 인터페이스입니다. `NON_GCP_PRIVATE_IP_PORT` 엔드포인트가 있는 영역 NEG 백엔드의 경우 엔드포인트가 NEG와 연결된 VPC 네트워크 및 NEG를 포함하는 리전의 경로로 도달할 수 있는 온프레미스 리소스 인터페이스를 제공해야 합니다.	인스턴스 그룹 백엔드에 대해 각 인스턴스의 기본 네트워크 인터페이스(`nic0`)와 연결된 기본 내부 IPv4 또는 IPv6 주소입니다. `GCE_VM_IP_PORT` 엔드포인트가 있는 영역 NEG 백엔드의 경우 엔드포인트의 IP 주소입니다. 네트워크 인터페이스의 기본 내부 IPv4 또는 IPv6 주소 또는 네트워크 인터페이스의 별칭 IP 범위의 내부 IPv4 또는 IPv6 주소입니다. `NON_GCP_PRIVATE_IP_PORT` 엔드포인트가 있는 영역 NEG 백엔드의 경우 엔드포인트의 IP 주소입니다.
기본 애플리케이션 부하 분산기 리전 외부 애플리케이션 부하 분산기 리전 간 내부 애플리케이션 부하 분산기 리전별 내부 애플리케이션 부하 분산기 기존 프록시 네트워크 부하 분산기 리전별 외부 프록시 네트워크 부하 분산기 리전 간 내부 프록시 네트워크 부하 분산기 ¹ 리전별 내부 프록시 네트워크 부하 분산기 Cloud Service Mesh	인스턴스 그룹 백엔드의 경우 기본 네트워크 인터페이스입니다(`nic0`). `GCE_VM_IP_PORT` 엔드포인트가 있는 영역 NEG 백엔드의 경우 NEG와 연결된 VPC 네트워크의 네트워크 인터페이스입니다. `NON_GCP_PRIVATE_IP_PORT` 엔드포인트가 있는 영역 NEG 백엔드의 경우 엔드포인트가 NEG와 연결된 VPC 네트워크 및 NEG를 포함하는 리전의 경로로 도달할 수 있는 온프레미스 리소스 인터페이스를 제공해야 합니다.	인스턴스 그룹 백엔드에 대해 각 인스턴스의 기본 네트워크 인터페이스(`nic0`)와 연결된 기본 내부 IPv4 주소입니다. `GCE_VM_IP_PORT` 엔드포인트가 있는 영역 NEG 백엔드의 경우 엔드포인트의 IP 주소입니다. 네트워크 인터페이스의 기본 내부 IPv4 주소 또는 네트워크 인터페이스의 별칭 IP 범위의 내부 IPv4 주소입니다. `NON_GCP_PRIVATE_IP_PORT` 엔드포인트가 있는 영역 NEG 백엔드의 경우 엔드포인트의 IP 주소입니다.
외부 패스 스루 네트워크 부하 분산기	기본 네트워크 인터페이스(`nic0`)	외부 전달 규칙의 IP 주소입니다. 여러 전달 규칙이 동일한 백엔드 서비스(대상 풀 기반 외부 패스 스루 네트워크 부하 분산의 경우 동일한 대상 풀)를 가리키는 경우 Google Cloud는 각 전달 규칙의 IP 주소로 프로브를 보냅니다. 그러면 프로브 수가 증가할 수 있습니다.
내부 패스 스루 네트워크 부하 분산기	인스턴스 그룹 백엔드와 `GCE_VM_IP` 엔드포인트가 있는 영역 NEG 백엔드의 경우 백엔드 서비스의 구성 방법에 따라 사용되는 네트워크 인터페이스가 달라집니다. 자세한 내용은 백엔드 서비스 및 네트워크 인터페이스입니다.	내부 전달 규칙의 IP 주소입니다. 여러 전달 규칙이 동일한 백엔드 서비스를 가리킬 경우 Google Cloud는 각 전달 규칙의 IP 주소로 프로브를 보냅니다. 그러면 프로브 수가 증가할 수 있습니다.

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

HTTP, HTTPS, HTTP/2 상태 확인에는 항상 상태 확인 시간 초과 전에 HTTP 200 (OK) 응답 코드가 수신되어야 합니다. 301 및 302와 같은 리디렉션 응답 코드를 비롯한 다른 모든 HTTP 응답 코드는 비정상으로 간주됩니다.

HTTP 200 (OK) 응답 코드를 요구하는 것 외에도 다음을 수행할 수 있습니다.

각 상태 점검 프로버를 구성하여 기본 요청 경로인 / 대신 특정 요청 경로로 HTTP 요청을 전송합니다.
HTTP 응답 본문에 예상 응답 문자열이 있는지 확인하도록 각 상태 확인 프로버를 구성합니다. 예상 응답 문자열은 HTTP 응답 본문의 처음 1,024바이트 내에 있는 단일 바이트 인쇄 가능한 ASCII 문자로만 구성되어야 합니다.

다음 표에는 HTTP, HTTPS, HTTP/2 상태 확인에 사용할 수 있는 유효한 요청 경로 및 응답 플래그 조합이 나와 있습니다.

구성 플래그	프로버 동작	성공 기준
`--request-path` 또는 `--response`가 지정되지 않음	프로버는 `/`를 요청 경로로 사용합니다.	HTTP `200 (OK)` 응답 코드만 해당합니다.
`--request-path` 및 `--response` 모두 지정됨	프로버는 구성된 요청 경로를 사용합니다.	HTTP `200 (OK)` 응답 코드 및 HTTP 응답 본문의 처음 1,024자(영문 기준)까지의 ASCII 문자는 예상 응답 문자열과 일치해야 합니다.
`--response`만 지정됨	프로버는 `/`를 요청 경로로 사용합니다.	HTTP `200 (OK)` 응답 코드 및 HTTP 응답 본문의 처음 1,024자(영문 기준)까지의 ASCII 문자는 예상 응답 문자열과 일치해야 합니다.
`--request-path`만 지정됨	프로버는 구성된 요청 경로를 사용합니다.	HTTP `200 (OK)` 응답 코드만 해당합니다.

SSL 및 TCP의 성공 기준

TCP 및 SSL 상태 확인에는 다음과 같은 기본 성공 기준이 있습니다.

TCP 상태 점검의 경우 상태 점검 프로버가 상태 점검 제한 시간 전에 백엔드에 대한 TCP 연결을 성공적으로 열어야 합니다.
SSL 상태 확인의 경우 상태 확인 프로버는 상태 확인 시간 초과 전에 백엔드에 대한 TCP 연결을 성공적으로 열고 TLS/SSL 핸드셰이크를 완료해야 합니다.
TCP 상태 점검의 경우 다음 방법 중 하나로 TCP 연결을 닫아야 합니다.
- 상태 확인 프로버가 FIN 또는 RST (재설정) 패킷 전송
- 백엔드에서 FIN 패킷을 전송합니다. 백엔드가 TCP RST 패킷을 전송하는 경우 상태 확인 프로버가 이미 FIN 패킷을 전송한 경우 프로브가 실패한 것으로 간주될 수 있습니다.

다음 표에는 TCP 및 SSL 상태 확인에 사용할 수 있는 유효한 요청 및 응답 플래그 조합이 나와 있습니다. 요청 및 응답 플래그는 모두 단일 바이트 인쇄 가능한 ASCII 문자로만 구성되어야 하며 각 문자열의 길이는 1,024자 이하여야 합니다.

구성 플래그	프로버 동작	성공 기준
`--request` 또는 `--response`가 지정되지 않음	프로버는 요청 문자열을 전송하지 않습니다.	기본 성공 기준만 해당됩니다.
`--request` 및 `--response` 모두 지정됨	프로버는 구성된 요청 문자열을 전송합니다.	기본 성공 기준과 프로버가 수신한 응답 문자열은 예상 응답 문자열과 정확하게 일치해야 합니다.
`--response`만 지정됨	프로버는 요청 문자열을 전송하지 않습니다.	기본 성공 기준과 프로버가 수신한 응답 문자열은 예상 응답 문자열과 정확하게 일치해야 합니다.
`--request`만 지정됨	프로버는 구성된 요청 문자열을 전송합니다.	기본 성공 기준만 적용됩니다(응답 문자열은 확인되지 않음).

gRPC의 성공 기준

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

다음에 유의하세요.

gRPC 상태 점검은 gRPC 애플리케이션 및 Cloud Service Mesh에서만 사용됩니다.
gRPC 상태 점검에서는 TLS를 지원하지 않습니다.

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

기존 상태 점검의 성공 기준

기존 상태 점검 프로브에서 받은 응답이 HTTP 200 OK이면 프로브는 성공한 것으로 간주됩니다. 리디렉션(301, 302)을 포함한 다른 모든 HTTP 응답 코드는 비정상으로 간주됩니다.

상태

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

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

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

비정상 기준이 충족되면 Google Cloud가 백엔드를 비정상으로 간주합니다. 비정상 백엔드는 새로운 연결을 받을 수 없지만 기존 연결이 즉시 종료되지는 않습니다. 대신 시간 초과가 발생하거나 트래픽이 삭제될 때까지 연결이 열려 있습니다.

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

모든 백엔드가 비정상일 때의 구체적인 동작은 사용 중인 부하 분산기의 유형에 따라 다릅니다.

부하 분산기	모든 백엔드가 비정상일 때 동작
기본 애플리케이션 부하 분산기	모든 백엔드가 비정상일 때 클라이언트에 HTTP `502` 상태 코드를 반환합니다.
전역 외부 애플리케이션 부하 분산기 리전 간 내부 애플리케이션 부하 분산기 리전별 외부 애플리케이션 부하 분산기 리전별 내부 애플리케이션 부하 분산기	모든 백엔드가 비정상일 때 클라이언트에 HTTP `503` 상태 코드를 반환합니다.
프록시 네트워크 부하 분산기	모든 백엔드가 비정상일 때 클라이언트 연결을 종료합니다.
내부 패스 스루 네트워크 부하 분산기 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기	모든 백엔드가 비정상적이고 장애 조치가 구성되지 않은 경우 최후의 수단으로 모든 백엔드 VM에 트래픽을 배포합니다. 이 동작에 대한 자세한 내용은 내부 패스 스루 네트워크 부하 분산기의 트래픽 분산 및 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기의 트래픽 분산을 참조하세요.
대상 풀 기반 외부 패스 스루 네트워크 부하 분산기	모든 백엔드가 비정상일 때 최후의 수단으로 트래픽을 모든 백엔드 VM에 배포합니다.

기타 참고사항

다음 섹션에는 Google Cloud에서 상태 점검을 사용하는 방법에 대한 추가 참고사항이 포함되어 있습니다.

인증서 및 상태 확인

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. 소스 IP 주소에서 백엔드 인스턴스로의 HTTP 연결을 30초 간격으로 시작합니다.
2. HTTP 200 (OK) 상태 코드(HTTP, HTTPS, HTTP/2 프로토콜의 성공 기준)를 최대 5초 동안 기다립니다.
상태 점검 프로브 시스템 중 하나 이상이 다음을 수행하면 백엔드가 비정상으로 간주됩니다.
1. 2개의 연속된 프로브에 대해 HTTP 200 (OK) 응답 코드를 가져오지 않습니다. 예를 들어 연결이 거부되거나 연결 또는 소켓 제한 시간이 초과될 수 있습니다.
2. 프로토콜 특정 성공 기준과 일치하지 않는 응답이 두 번 연속으로 수신됩니다.
상태 점검 프로브 시스템 중 하나 이상이 프로토콜 특정 성공 기준과 일치하는 응답을 두 번 연속으로 수신하면 백엔드가 정상으로 간주됩니다.

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

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

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

다음 단계

상태 점검을 만들고, 수정하고, 사용하려면 상태 점검 만들기를 참조하세요.
상태 점검 문제를 해결하려면 상태 점검 로깅을 사용 설정합니다.