상태 점검 개요

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

달리 명시되지 않는 한 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 프로토콜을 사용할 수 있습니다.

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

상태 점검을 선택합니다.

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

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

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

부하 분산기 가이드

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

부하 분산기	백엔드 유형	상태 점검 카테고리 및 범위	포트 지정
전역 외부 애플리케이션 부하 분산기 기본 애플리케이션 부하 분산기 ¹ 전역 외부 프록시 네트워크 부하 분산기 기본 프록시 네트워크 부하 분산기	지원되는 NEG	상태 점검(전역)	커스텀 포트 번호(`--port`) 엔드포인트의 포트 번호(`--use-serving-port`)
	인스턴스 그룹	상태 점검(전역)	커스텀 포트 번호(`--port`) 백엔드 서비스의 이름이 지정된 포트(`--use-serving-port`)
리전 외부 애플리케이션 부하 분산기	지원되는 NEG	상태 점검(리전별)	커스텀 포트 번호(`--port`) 엔드포인트의 포트 번호(`--use-serving-port`)
리전 외부 애플리케이션 부하 분산기	인스턴스 그룹	상태 점검(리전별)	커스텀 포트 번호(`--port`) 백엔드 서비스의 이름이 지정된 포트(`--use-serving-port`)
리전 간 내부 애플리케이션 부하 분산기 리전 간 내부 프록시 네트워크 부하 분산기	지원되는 NEG	상태 점검(전역)	커스텀 포트 번호(`--port`) 엔드포인트의 포트 번호(`--use-serving-port`)
리전 간 내부 애플리케이션 부하 분산기 리전 간 내부 프록시 네트워크 부하 분산기	인스턴스 그룹	상태 점검(전역)	커스텀 포트 번호(`--port`) 백엔드 서비스의 이름이 지정된 포트(`--use-serving-port`)
리전 내부 애플리케이션 부하 분산기 리전 내부 프록시 네트워크 부하 분산기 리전 외부 프록시 네트워크 부하 분산기	지원되는 NEG	상태 점검(리전별)	커스텀 포트 번호(`--port`) 엔드포인트의 포트 번호(`--use-serving-port`)
	인스턴스 그룹	상태 점검(리전별)	커스텀 포트 번호(`--port`) 백엔드 서비스의 이름이 지정된 포트(`--use-serving-port`)
외부 패스 스루 네트워크 부하 분산기 ²	인스턴스 그룹	상태 점검(리전)	커스텀 포트 번호(`--port`)
외부 패스 스루 네트워크 부하 분산기 ²	대상 풀의 인스턴스	기존 상태 점검 (HTTP 프로토콜을 사용하는 전역)	기존 상태 점검은 포트 번호(`--port`) 사양만 지원합니다.
내부 패스 스루 네트워크 부하 분산기 ²	지원되는 NEG	상태 점검(전역 또는 리전)	커스텀 포트 번호(`--port`)
내부 패스 스루 네트워크 부하 분산기 ²	인스턴스 그룹	상태 점검(전역 또는 리전)	커스텀 포트 번호(`--port`)

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

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

부하 분산기 모드

기존 상태 점검 지원

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

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

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

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

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

아니요

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

추가 사용법 참고사항:

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

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

Traffic Director로 상태 점검

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

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

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

상태 점검 작동 방법

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

프로브

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

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

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

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

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

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

제품	프로브 소스 IP 범위	방화벽 규칙 예시
전역 외부 애플리케이션 부하 분산기 기본 애플리케이션 부하 분산기 리전별 외부 애플리케이션 부하 분산기 ^{1, 2} 리전 간 내부 애플리케이션 부하 분산기 ¹ 리전 내부 애플리케이션 부하 분산기 ^{1, 2} 내부 패스 스루 네트워크 부하 분산기 외부 프록시 네트워크 부하 분산기 리전 내부 프록시 네트워크 부하 분산기^{1, 2} 리전 간 내부 프록시 네트워크 부하 분산기 ¹ 리전 외부 프록시 네트워크 부하 분산기^{1, 2} Traffic Director(인터넷 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`	내부 패스 스루 네트워크 부하 분산기의 방화벽 규칙
인터넷 NEG 백엔드 및 하이브리드 NEG 백엔드가 있는 Traffic Director	Envoy 소프트웨어를 실행하는 VM의 IP 주소	방화벽 규칙 예시

¹ 하이브리드 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 주소

부하 분산기	대상 네트워크 인터페이스	대상 IP 주소
전역 외부 애플리케이션 부하 분산기 기본 애플리케이션 부하 분산기 리전 외부 애플리케이션 부하 분산기 리전 간 내부 애플리케이션 부하 분산기 내부 애플리케이션 부하 분산기 전역 외부 프록시 네트워크 부하 분산기 기본 프록시 네트워크 부하 분산기 리전 내부 프록시 네트워크 부하 분산기 리전 간 내부 프록시 네트워크 부하 분산기 Traffic Director	인스턴스 그룹 백엔드의 경우 기본 네트워크 인터페이스입니다(`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 주소로 프로브를 보냅니다. 그러면 프로브 수가 증가할 수 있습니다.

전역 외부 애플리케이션 부하 분산기
기본 애플리케이션 부하 분산기
리전 외부 애플리케이션 부하 분산기
리전 간 내부 애플리케이션 부하 분산기
내부 애플리케이션 부하 분산기
전역 외부 프록시 네트워크 부하 분산기
기본 프록시 네트워크 부하 분산기
리전 내부 프록시 네트워크 부하 분산기
리전 간 내부 프록시 네트워크 부하 분산기
Traffic Director

인스턴스 그룹 백엔드의 경우 기본 네트워크 인터페이스입니다(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) 상태 코드가 전달되어야 합니다. 또한 다음을 수행할 수 있습니다.

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를 지원하지 않습니다.

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

기존 상태 점검의 성공 기준

기존 상태 점검 프로브에서 받은 응답이 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 상태 점검 프로브가 백엔드 응답을 더 완전히 검증하도록 지시할 수 있습니다.

예상 응답 문자열을 지정하고 선택적으로 요청 경로를 정의하여 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. 소스 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를 중지합니다.

다음 단계

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