이 페이지는 Cloud Translation API를 통해 번역되었습니다.

상태 점검 사용

Google Cloud는 백엔드 인스턴스가 트래픽에 제대로 응답하는지 확인하는 상태 점검 메커니즘을 제공합니다. 이 문서에서는 부하 분산기와 Cloud Service Mesh의 상태 점검을 만들고 사용하는 방법을 설명합니다.

이 페이지에서는 사용자가 다음에 익숙하다고 가정합니다.

상태 점검 만들기

Google Cloud를 사용하면 Google Cloud 콘솔에서 부하 분산기의 백엔드 구성을 완료할 때 상태 점검을 만들거나 선택할 수 있습니다.

또한 Google Cloud 콘솔의 부하 분산기 구성과 상관없이 상태 점검을 만들 수도 있습니다. 이는 상태 점검을 먼저 만들어야 하거나 여러 부하 분산기에 대해 상태 점검을 사용해야 하는 경우에 유용합니다. Google Cloud 콘솔, Google Cloud CLI 또는 REST API를 사용하여 상태 점검을 만들 수 있습니다.

콘솔

Google Cloud 콘솔의 상태 점검 페이지로 이동합니다.
상태 점검 페이지로 이동
상태 점검 만들기를 클릭합니다.
상태 점검 만들기 페이지에서 다음 정보를 입력합니다.
- 이름: 상태 점검에 이름을 입력합니다.
- 설명: 원하는 경우 설명을 제공합니다.
- 범위: 부하 분산기 유형에 따라 전역 또는 리전 범위를 선택합니다.
  - 리전을 선택한 경우 드롭다운에서 리전을 선택합니다.
- 프로토콜 : 상태 점검 프로토콜을 선택합니다.
- 포트: 포트 번호를 입력합니다. Google Cloud 콘솔에서 상태 점검을 만들 때 포트 번호를 사용하여 포트를 지정해야 합니다.
- 프록시 프로토콜: 선택적으로 상태 점검 프로브 시스템의 요청에 프록시 헤더를 추가 할 수 있습니다.
- 요청 경로 및 응답: HTTP, HTTPS, HTTP2 프로토콜에 대해 연결할 상태 점검 프로브 시스템의 URL 경로를 선택적으로 제공 할 수 있습니다. 자세한 내용은 HTTP, HTTPS, HTTP/2 상태 점검을 위한 추가 플래그를 참조하세요.
- 요청 및 응답: TCP 및 SSL 프로토콜에 대해 전송할 ASCII 텍스트 문자열과 예상 텍스트 응답 문자열을 지정할 수 있습니다. 자세한 내용은 SSL 및 TCP 상태 점검을 위한 추가 플래그를 참조하세요.
- 확인 간격: 한 프로브의 시작에서 다음 프로브의 시작까지의 시간을 정의합니다.
- 제한 시간: Google Cloud가 프로브에 대한 응답을 기다리는 시간을 정의합니다. 해당 값은 확인 간격보다 작거나 같아야 합니다.
- 정상 기준: VM 인스턴스가 정상으로 간주되도록 하기 위해 성공해야 하는 연속 프로브의 수를 정의합니다.
- 비정상 기준: VM 인스턴스가 비정상으로 간주되도록 하기 위해 실패해야 하는 연속 프로브의 수를 정의합니다.
만들기를 클릭합니다.

gcloud

전역 상태 점검을 만들려면 적절한 compute health-checks create 명령어를 사용합니다.

gcloud compute health-checks create PROTOCOL NAME \
    --global \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

리전별 상태 점검을 만들려면 적절한 compute health-checks create 명령어를 사용합니다.

gcloud compute health-checks create PROTOCOL NAME \
    --region=REGION \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

다음을 바꿉니다.

PROTOCOL은 상태 점검에 사용되는 프로토콜을 정의합니다. grpc, http, https, http2, ssl, tcp가 유효한 옵션입니다.
NAME은 상태 확인의 이름입니다. 특정 프로젝트 내: 각 전역 상태 점검에는 고유한 이름이 있어야 하며, 리전별 상태 점검은 해당 리전 내에서 고유한 이름을 가져야 합니다.
REGION: 상태 점검의 리전입니다. 리전별 부하 분산기의 경우 상태 점검 리전이 백엔드 서비스의 리전과 일치해야 합니다.
DESCRIPTION은 선택사항인 설명입니다.
CHECK_INTERVAL은 하나의 상태 점검 프로브 시스템의 연결이 시작된 후부터 다음 프로브 시작까지 걸리는 시간입니다. 단위는 초입니다. 생략하면 Google Cloud에서는 5s(5초)를 값으로 사용합니다.
TIMEOUT은 Google Cloud가 프로브에 대한 응답을 대기하는 시간입니다. TIMEOUT 값은 CHECK_INTERVAL 이하여야 합니다. 단위는 초입니다. 생략하면 Google Cloud에서는 5s(5초)를 값으로 사용합니다.
HEALTHY_THRESHOLD 및 UNHEALTHY_THRESHOLD는 VM 인스턴스가 정상 또는 비정상으로 간주되려면 성공하거나 실패해야 하는 연속 프로브의 수를 지정합니다. 둘 중 하나를 생략하면 Google Cloud에서는 기본 임곗값 2를 사용합니다.
PORT_SPECIFICATION: 포트 지정 플래그 중 하나를 사용하여 포트 지정을 정의합니다.
ADDITIONAL_FLAGS는 포트와 PROTOCOL에 대한 옵션을 지정하기 위한 기타 플래그입니다. HTTP, HTTPS, HTTP/2 상태 점검을 위한 추가 플래그, SSL 및 TCP 상태 점검을 위한 추가 플래그 또는 gRPC 상태 점검을 위한 추가 플래그를 참조하세요.

Terraform

전역 상태 점검을 만들려면 google_compute_health_check 리소스를 사용합니다.

resource "google_compute_health_check" "health_check_tcp_with_logging" {
  provider = google-beta

  name = "health-check-tcp"

  timeout_sec        = 1
  check_interval_sec = 1

  tcp_health_check {
    port = "22"
  }

  log_config {
    enable = true
  }
}

리전별 상태 점검을 만들려면 google_compute_region_health_check 리소스를 사용합니다.

resource "google_compute_region_health_check" "default" {
  name               = "tcp-health-check-region-west"
  timeout_sec        = 5
  check_interval_sec = 5
  tcp_health_check {
    port = "80"
  }
  region = "us-west1"
}

Terraform 구성을 적용하거나 삭제하는 방법은 기본 Terraform 명령어를 참조하세요.

API

전역 상태 점검을 만들려면 healthChecks.insert를 사용합니다.
리전별 상태 점검을 만들려면 regionHealthChecks.insert를 사용합니다.

상태 점검 수정

상태 점검을 수정하여 상태 점검을 기존 상태 점검(또는 반대로)으로 전환할 수 없습니다. 또한 상태 점검의 이름이나 범위(예: 전역에서 리전으로)를 변경할 수 없습니다.

콘솔

Google Cloud 콘솔의 상태 점검 페이지로 이동합니다.
상태 점검 페이지로 이동
상태 점검을 클릭하여 세부정보를 봅니다.
상태 점검을 수정해야 하는 경우 수정을 클릭하고 다음을 수행합니다.
- 필요에 따라 매개변수를 변경합니다.
- 저장을 클릭합니다.

gcloud

상태 점검의 이름과 범위를 나타냅니다. 자세한 내용은 상태 점검 나열을 참고하세요.
상태 점검 이름, 프로토콜, 범위를 제외하고 공통 플래그, 포트 지정 플래그, 기타 선택적 플래그를 수정할 수 있습니다. 기존의 상태 점검을 수정하려면 적합한 compute health-checks update 명령어를 사용합니다. 생략하는 플래그의 경우 사전 구성된 설정이 유지됩니다.
- 전역 상태 점검의 수정 예시: 다음 명령어는 확인 간격, 제한 시간, 요청 경로를 변경하여 hc-http-port-80라는 전역 HTTP 상태 점검을 수정합니다.
```
gcloud compute health-checks update http hc-http-port-80 \
    --global \
    --check-interval=20s \
    --timeout=15s \
    --request-path="/health"
```
- 리전별 상태 점검의 수정 예시: 다음 명령어는 포트 지정을 변경하여 hc-west1-tcp-ldap이라는 us-west1의 리전별 TCP 상태 점검을 수정합니다.
```
gcloud compute health-checks update tcp hc-west1-tcp-ldap \
    --region=us-west1 \
    --port=631
```

API

상태 점검의 이름과 범위를 나타냅니다. 자세한 내용은 상태 점검 나열을 참조하세요.
상태 점검 이름, 프로토콜, 범위를 제외하고 다음 API 호출을 통해 공통 플래그, 포트 지정 플래그, 기타 선택적 플래그를 수정할 수 있습니다. patch API 호출을 사용하여 요청에 명시적으로 설정되지 않은 사전 구성된 설정을 유지합니다.
- 전역 상태 점검을 수정하려면 healthChecks.update 또는 healthChecks.patch를 사용하세요.
- 리전별 상태 점검을 수정하려면 regionHealthChecks.update 또는 regionHealthChecks.patch를 사용합니다.

상태 확인 나열

콘솔

Google Cloud 콘솔의 상태 점검 페이지로 이동합니다.
상태 점검 페이지로 이동
상태 점검을 클릭하여 세부정보를 봅니다.

gcloud

상태 점검을 나열하려면 compute health-checks list 명령어를 사용합니다.

전역 상태 점검을 나열하려면 다음을 사용합니다.
```
gcloud compute health-checks list \
    --global
```
리전별 상태 점검을 나열하려면 다음을 사용합니다. REGION_LIST를 쿼리할 Google Cloud 리전의 쉼표로 구분된 목록으로 바꿉니다.
```
gcloud compute health-checks list \
    --regions=REGION_LIST
```

상태 점검의 이름과 범위를 알면 compute health-checks describe 명령어를 사용하여 현재 구성을 볼 수 있습니다.

전역 상태 점검을 설명하려면 NAME을 해당 이름으로 바꿉니다.
```
gcloud compute health-checks describe NAME \
    --global
```
리전별 상태 점검을 설명하려면 NAME을 해당 이름으로 바꾸고 REGION을 해당 리전으로 바꿉니다.
```
gcloud compute health-checks describe NAME \
    --region=REGION
```

API

상태 점검을 나열하려면 다음 API 호출을 사용합니다.

전역 상태 점검 나열: healthChecks.list
리전별 상태 확인 나열: regionHealthChecks.list

상태 점검의 현재 구성을 설명하려면 다음을 사용하세요.

전역 상태 확인 설명: healthChecks.get
리전별 상태 점검 설명: regionHealthChecks.get

추가 플래그

이 섹션에서는 상태 점검을 만들거나 수정할 때 사용할 수 있는 추가 플래그에 대해 설명합니다. 포트 지정과 같은 일부 플래그는 gcloud 또는 API를 사용하여 설정해야 합니다.

포트 지정 플래그

Google Cloud CLI 또는 API를 사용하여 상태 점검을 만드는 경우 상태 점검의 포트를 지정할 수 있는 두 가지 옵션이 있습니다. 다음 표는 유효한 부하 분산기 및 백엔드 조합에 대한 포트 지정 옵션을 보여줍니다. 인스턴스 그룹이라는 용어는 비관리형 인스턴스 그룹, 영역 관리형 인스턴스 그룹 또는 리전 관리형 인스턴스 그룹을 의미합니다.

각 상태 점검은 한 가지 유형의 포트 지정만 사용할 수 있습니다.

제품	백엔드 유형	포트 지정 옵션
외부 패스 스루 네트워크 부하 분산기	인스턴스 그룹 및 지원되는 NEG	`--port`: `1`에서 `65535`까지의 숫자로 TCP 포트를 지정합니다. 이 부하 분산기의 백엔드 서비스에서 이름이 지정된 포트를 구독하지 않으므로 내부 패스 스루 네트워크 부하 분산기와 연결된 상태 점검에서 `--use-serving-port` 플래그가 무시됩니다. 이는 부하 분산기에서 백엔드로 새 연결을 만드는 대신 패킷을 백엔드로 직접 전달하는 패스 스루 부하 분산기이기 때문입니다.
외부 패스 스루 네트워크 부하 분산기	대상 풀	기존 상태 점검은 포트 번호(`--port`) 사양을 지원합니다.
내부 패스 스루 네트워크 부하 분산기	인스턴스 그룹 및 지원되는 NEG	`--port`: `1`에서 `65535`까지의 숫자로 TCP 포트를 지정합니다. 이 부하 분산기의 백엔드 서비스에서 이름이 지정된 포트를 구독하지 않으므로 내부 패스 스루 네트워크 부하 분산기와 연결된 상태 점검에서 `--use-serving-port` 플래그가 무시됩니다. 이는 부하 분산기에서 백엔드로 새 연결을 만드는 대신 패킷을 백엔드로 직접 전달하는 패스 스루 부하 분산기이기 때문입니다.
전역 외부 애플리케이션 부하 분산기 기존 애플리케이션 부하 분산기 리전 외부 애플리케이션 부하 분산기 리전 간 내부 애플리케이션 부하 분산기 리전 내부 애플리케이션 부하 분산기 전역 외부 프록시 네트워크 부하 분산기 기존 프록시 네트워크 부하 분산기 리전 외부 프록시 네트워크 부하 분산기 리전 간 내부 프록시 네트워크 부하 분산기 리전 내부 프록시 네트워크 부하 분산기 클라우드 서비스 메시	지원되는 NEG	`--port`: `1`에서 `65535`까지의 숫자로 TCP 포트를 지정합니다. `--use-serving-port`: 네트워크 엔드포인트 그룹에 있는 각 엔드포인트의 포트를 사용합니다.
	인스턴스 그룹	`--port`: `1`에서 `65535`까지의 숫자로 TCP 포트를 지정합니다. `--use-serving-port`: 백엔드 서비스에서 구독하는 포트와 동일한 인스턴스 그룹 이름을 사용합니다.

상태 점검을 만들 때 포트 사양을 생략하면 Google Cloud가 다음 기본값을 사용합니다.

상태 점검의 프로토콜이 TCP 또는 HTTP이면 --port=80을 사용합니다.
상태 점검의 프로토콜이 SSL, HTTPS 또는 HTTP2이면 --port=443을 사용합니다.
상태 점검의 프로토콜이 GRPC이면 묵시적 기본값이 없으므로 포트 지정을 포함해야 합니다.

HTTP, HTTPS, HTTP/2 상태 점검을 위한 추가 플래그

공통 플래그 및 포트 지정 외에도 HTTP, HTTPS, HTTP/2 상태 점검에 다음 선택적 플래그를 사용할 수 있습니다. 이 예시에서는 기본 간격, 제한 시간, 상태 임곗값 기준으로 포트 80을 사용하여 hc-http-port-80이라는 이름의 HTTP 상태 점검을 만듭니다.

gcloud compute health-checks create HTTP_PROTOCOL hc-http-port-80 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --host=HOST \
    --proxy-header=PROXY_HEADER \
    --request-path=REQUEST_PATH \
    --response=RESPONSE

HTTP_PROTOCOL: http(TLS가 없는 HTTP/1.1), https(TLS가 있는 HTTP/1.1) 또는 http2(TLS가 있는 HTTP/2)일 수 있습니다.
COMMON_FLAGS: 공통 플래그를 정의합니다. 생성 절차를 참조하세요.
PORT_SPECIFICATION: 포트 지정 플래그 중 하나를 사용하여 포트 지정을 정의합니다.
HOST를 통해 Host HTTP 헤더를 제공할 수 있습니다. 생략하면 부하 분산기 전달 규칙의 IP 주소가 사용됩니다.
PROXY_HEADER는 NONE 또는 PROXY_V1 중 하나여야 합니다. 생략하면 Google Cloud에서는 NONE을 사용합니다. PROXY_V1의 값은 헤더 PROXY UNKNOWN\r\n을 추가합니다.
REQUEST_PATH는 Google Cloud가 상태 점검 요청을 보낼 때 사용하는 URL 경로를 지정합니다. 생략하면 상태 점검 요청이 /로 전송됩니다.
RESPONSE는 선택적 예상 응답을 정의합니다. 응답 문자열은 다음 규칙을 따라야 합니다.
- 응답 문자열은 ASCII 문자, 숫자, 공백으로 구성되어야 합니다.
- 응답 문자열의 최대 길이는 1,024자입니다.
- 와일드 카드 일치는 지원되지 않습니다.
- 콘텐츠 기반 검사는 도치를 지원하지 않습니다. 예를 들어 HAProxy에서 ! 같은 연산자는 지원되지 않습니다.

Google Cloud는 수신된 응답 본문의 첫 번째 1,024바이트의 아무 곳에서 예상되는 응답 문자열을 발견하고 HTTP 상태가 200(OK)인 경우 프로브는 성공한 것으로 간주됩니다.

--request-path 및 --response 플래그는 상태 점검 프로브의 성공 기준을 수정합니다.

SSL 및 TCP 상태 점검을 위한 추가 플래그

공통 플래그 및 포트 지정 외에도 다음 선택적 플래그를 SSL 및 TCP 상태 점검에 사용할 수 있습니다. 이 예시에서는 기본 간격, 제한 시간, 상태 임곗값 기준으로 포트 3268을 사용하여 hc-tcp-3268이라는 이름의 TCP 상태 점검을 만듭니다.

gcloud compute health-checks create tcp hc-tcp-3268 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --proxy-header=PROXY_HEADER \
    --request=REQUEST_STRING \
    --response=RESPONSE_STRING

프로토콜은 tcp(이 예시의 경우) 또는 ssl이 될 수 있습니다.
COMMON_FLAGS: 공통 플래그를 정의합니다. 생성 절차를 참조하세요.
PORT_SPECIFICATION: 포트 지정 플래그 중 하나를 사용하여 포트 지정을 정의합니다.
PROXY_HEADER는 NONE 또는 PROXY_V1 중 하나여야 합니다. 생략하면 Google Cloud에서는 NONE을 사용합니다. PROXY_V1의 값은 헤더 PROXY UNKNOWN\r\n을 추가합니다.
REQUEST_STRING: TCP 또는 SSL 세션이 설정되면 최대 1,024개의 ASCII 문자로 구성된 문자열을 전송할 수 있습니다.
RESPONSE_STRING: 예상 응답에 최대 1,024ASCII의 문자열을 제공할 수 있습니다.

--request 및 --response 플래그는 상태 점검 프로브의 성공 기준을 수정합니다. --response 플래그를 단독으로 사용하거나 --request 플래그와 함께 사용하는 경우 반환된 응답은 예상된 응답 문자열과 정확하게 일치해야 합니다.

gRPC 상태 점검을 위한 추가 플래그

백엔드 gRPC 서버는 gRPC 상태 점검 프로토콜에 설명된 대로 gRPC 상태 서비스를 구현해야 합니다. Google Cloud는 백엔드에서 상태 서비스의 Check 메서드를 호출하여 HealthCheckRequest 메시지를 백엔드로 전송합니다. gRPC 서비스 이름이 지정되지 않으면 요청의 서비스 매개변수는 빈 문자열로 설정됩니다.

gRPC 상태 점검은 gRPC 서비스의 상태를 확인할 수 있습니다. 백엔드 VM 또는 NEG에서 실행되는 특정 gRPC 서비스의 이름인 문자열(최대 1,024 ASCII 문자 길이)을 포함할 수 있습니다. 이렇게 하려면 gRPC 상태 점검에 다음 플래그(선택사항)를 사용합니다.

--grpc-service-name=GRPC_SERVICE_NAME

예를 들어 백엔드 서버가 백엔드의 gRPC 상태 서비스에 다음 서비스 및 상태를 등록할 수 있습니다.

제공 상태가 SERVING인 MyPackage.ServiceA
제공 상태가 NOT_SERVING인 MyPackage.ServiceB
제공 상태가 NOT_SERVING인 빈 서비스 이름

다음과 같이 MyPackage.ServiceA에 대해 상태 점검을 만드는 경우, 서비스 상태가 SERVING이기 때문에 상태 점검 프로브가 HEALTHY를 반환합니다.

gcloud beta compute health-checks create grpc MyGrpcHealthCheckServiceA \
    --grpc-service-name=MyPackage.ServiceA

MyPackage.ServiceB에 대해 상태 점검을 만드는 경우, 서비스 상태가 NOT_SERVING이기 때문에 상태 점검 프로브가 UNHEALTHY를 반환합니다.

gRPC 상태 서비스에 등록되지 않은 MyPackage.ServiceC에 대해 상태 점검을 만드는 경우, 상태 점검 프로브가 UNHEALTHY와 동일한 gRPC 상태 NOT_FOUND를 반환합니다.

빈 서비스 이름에 대해 상태 점검을 만드는 경우, 빈 서비스 이름이 NOT_SERVING 상태로 등록되었기 때문에 상태 점검 프로브가 UNHEALTHY 상태를 반환합니다.

이전 상태 확인

이 섹션에서는 기존 HTTP 및 HTTPS 상태 점검을 만들고, 수정하고, 나열하는 방법을 설명합니다. 기존 상태 점검은 상태 점검으로 변환할 수 없고, 상태 점검을 기존 상태 점검으로 변환할 수도 없습니다.

기존 상태 확인을 지원하는 부하 분산기 유형을 알아보려면 부하 분산기 가이드를 참고하세요.

기존 상태 점검 만들기

콘솔

Google Cloud 콘솔의 상태 점검 페이지에 상태 점검과 기존 상태 점검이 나열되어 모두 수정할 수 있지만 Google Cloud 콘솔의 상태 점검 페이지에서는 새로운 기존 상태 점검을 만들 수 없습니다.

대상 풀 기반 외부 패스 스루 네트워크 부하 분산기를 만드는 동안에만 Google Cloud 콘솔에서 기존 상태 점검을 만들 수 있습니다. 기존 상태 점검을 단독으로 만들려면 이 섹션의 gcloud 또는 API 안내를 사용합니다.

gcloud

기존 상태 점검을 만들려면 compute http-health-checks create 명령어를 사용합니다.

gcloud compute LEGACY_CHECK_TYPE create NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --host=HOST \
    --port=PORT \
    --request-path=REQUEST_PATH

다음을 바꿉니다.

LEGACY_CHECK_TYPE은 기존 HTTP 상태 점검의 경우 http-health-checks, 기존 HTTPS 상태 점검의 경우 https-health-checks입니다. 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기의 기존 상태 점검을 만드는 경우 http-health-checks를 사용해야 합니다.
NAME은 기존 상태 점검의 이름입니다. 프로젝트 내에서 각 기존 상태 점검에는 고유한 이름이 있어야 합니다.
DESCRIPTION은 선택사항인 설명입니다.
CHECK_INTERVAL은 한 프로브의 시작에서 다음 프로브의 시작까지의 시간을 정의합니다. 단위는 초입니다. 생략하면 Google Cloud에서는 5s(5초)를 값으로 사용합니다.
TIMEOUT은 Google Cloud가 프로브에 대한 응답을 대기하는 시간의 양입니다. TIMEOUT 값은 CHECK_INTERVAL 이하여야 합니다. 단위는 초입니다. 생략하면 Google Cloud에서는 5s(5초)를 값으로 사용합니다.
HEALTHY_THRESHOLD 및 UNHEALTHY_THRESHOLD는 VM 인스턴스가 정상 또는 비정상으로 간주되려면 성공하거나 실패해야 하는 연속 프로브의 수를 지정합니다. 둘 중 하나를 생략하면 Google Cloud에서는 기본 임곗값 2를 사용합니다.
HOST를 통해 호스트 HTTP 헤더를 제공할 수 있습니다. 생략하면 부하 분산기 전달 규칙의 IP 주소가 사용됩니다.
PORT를 통해 포트 번호를 제공할 수 있습니다. 생략하면 Google Cloud에서는 80을 사용합니다.
REQUEST_PATH는 Google Cloud가 상태 점검 요청을 보낼 때 사용하는 URL 경로를 지정합니다. 생략하면 상태 점검 요청이 /로 전송됩니다.

API

기존 HTTP 상태 점검을 만들려면 httpHealthChecks.insert API 호출을 사용합니다.
기존 HTTPS 상태 점검을 만들려면 httpsHealthChecks.insert를 사용합니다.

Terraform

기존 HTTP 상태 점검 리소스를 만들려면 google_compute_http_health_check 리소스를 사용합니다.
기존 HTTPS 상태 점검 리소스를 만들려면 google_compute_https_health_check 리소스를 사용하세요.

기존 상태 점검 수정

콘솔

Google Cloud 콘솔의 상태 점검 페이지로 이동합니다.
상태 점검 페이지로 이동
상태 점검을 클릭하여 세부정보를 봅니다.
수정 을 클릭하고 변경한 다음 저장을 클릭합니다.

gcloud

기존 HTTP 상태 점검을 수정하려면 compute http-health-checks update 명령어를 사용하여 NAME을 이름으로 바꿉니다. gcloud로 기존 상태 점검을 수정하면 생략한 플래그의 사전 구성된 설정이 유지됩니다. OTHER_OPTIONS는 기존 상태 점검 만들기에 설명된 옵션입니다.
```
gcloud compute http-health-checks update NAME \
  OTHER_OPTIONS
```
기존 HTTPS 상태 점검을 수정하려면 compute https-health-checks update 명령어를 사용하여 NAME을 이름으로 바꿉니다. gcloud로 기존 상태 점검을 수정하면 생략한 플래그의 사전 구성된 설정이 유지됩니다. OTHER_OPTIONS는 기존 상태 점검 만들기에 설명된 옵션입니다.
```
gcloud compute https-health-checks update NAME \
  OTHER_OPTIONS
```

API

기존 상태 점검의 이름과 유형을 제외하고 생성에 사용되는 플래그를 수정할 수 있습니다. patch API 호출은 패치 요청에 명시적으로 설정되지 않은 사전 구성된 설정을 유지합니다.

기존 HTTP 상태 점검을 수정하려면 httpHealthChecks.update 또는 httpHealthChecks.patch를 사용합니다.
기존 HTTPS 상태 점검을 수정하려면 httpsHealthChecks.update 또는 httpsHealthChecks.patch를 사용합니다.

이전 상태 확인 나열

콘솔

Google Cloud 콘솔의 상태 점검 페이지로 이동합니다.
상태 점검 페이지로 이동
세부정보를 보려면 기존 상태 점검을 클릭하세요.

gcloud

기존 HTTP 상태 점검을 나열하려면 compute http-health-checks list 명령어를 사용합니다.
```
gcloud compute http-health-checks list
```
기존 HTTPS 상태 점검을 나열하려면 compute https-health-checks list 명령어를 사용합니다.
```
gcloud compute https-health-checks list
```
기존 HTTP 상태 점검을 설명하려면 compute http-health-checks describe 명령어를 사용하여 NAME을 이름으로 바꿉니다.
```
gcloud compute http-health-checks describe NAME
```
기존 HTTPS 상태 점검을 설명하려면 compute https-health-checks describe 명령어를 사용하여 NAME을 이름으로 바꿉니다.
```
gcloud compute https-health-checks describe NAME
```

API

기존 상태 점검을 나열하려면 다음 단계를 따르세요.
- httpHealthChecks.list를 사용하여 기존 HTTP 상태 점검을 나열합니다.
- httpsHealthChecks.list를 사용하여 기존 HTTPS 상태 점검을 나열합니다.
기존 상태 점검을 설명하려면 다음 안내를 따르세요.
- httpHealthChecks.get을 사용하여 기존 HTTP 상태 점검을 설명합니다.
- httpsHealthChecks.get을 사용하여 기존 HTTPS 상태 점검을 설명합니다.

필수 방화벽 규칙 만들기

상태 점검 프로버 IP 범위에서 트래픽을 허용하려면 부하 분산되는 모든 VM에 적용되는 인그레스 방화벽 규칙을 만들어야 합니다. 다음 예에서는 특정 대상 태그로 식별된 VM 인스턴스에 적용할 수 있는 방화벽 규칙을 만듭니다.

이 예에서는 Google Cloud 상태 점검 시스템에서 VM 인스턴스로 보내는 모든 TCP 트래픽을 허용합니다. TCP 트래픽에는 SSL, HTTP, HTTPS, HTTP/2 트래픽이 포함됩니다. 원하는 경우 TCP 프로토콜로 포트를 지정할 수도 있습니다. 그러나 포트를 지정하면 방화벽 규칙이 특정 상태 점검에만 적용될 수 있습니다. 프로토콜 및 포트에 tcp:80을 사용하면 포트 80에서 TCP 트래픽이 허용되므로 Google Cloud는 포트 80에서 HTTP를 사용하여 VM에 연결할 수 있지만 포트 443에서 HTTPS를 사용하여 연결할 수는 없습니다.

콘솔

Google Cloud 콘솔에서 방화벽 정책 페이지로 이동합니다.
방화벽 정책으로 이동
방화벽 규칙 만들기를 클릭합니다.
방화벽 규칙 만들기 페이지에서 다음 정보를 입력합니다.
- 이름: 규칙의 이름을 입력합니다. 이 예시에서는 fw-allow-health-checks를 사용합니다.
- 네트워크: VPC 네트워크를 선택합니다.
- 우선순위: 우선순위의 번호를 입력합니다. 숫자가 낮을수록 우선순위가 높습니다. 방화벽 규칙이 인그레스 트래픽을 거부할 수 있는 다른 규칙보다 높은 우선 순위를 갖도록 해야 합니다.
- 트래픽 방향: 인그레스를 선택합니다.
- 일치 시 작업: 허용을 선택합니다.
- 대상: 지정된 대상 태그를 선택한 다음 대상 태그 필드에 태그를 입력합니다. 이 예시에서는 allow-health-checks를 사용합니다.
- 소스 필터: IP 범위를 선택합니다.
- 소스 IP 범위: 부하 분산기 유형, 트래픽 유형, 상태 점검 유형에 따라 소스 IP 범위를 입력합니다. 프로브 IP 범위 및 방화벽 규칙을 참고하세요.
- 허용되는 프로토콜 및 포트: tcp 및 상태 점검에 구성된 포트를 사용합니다. TCP는 모든 상태 점검 프로토콜의 기본 프로토콜입니다.
- 만들기를 클릭합니다.
부하 분산되는 각 인스턴스에 네트워크 태그를 추가하여 새 인그레스 방화벽 규칙이 적용되게 합니다. 이 예시에서는 네트워크 태그로 allow-health-checks를 사용합니다.

gcloud

다음 gcloud 명령어를 사용하여 Google Cloud 상태 점검 시스템에서 allow-health-checks 태그가 있는 VPC 네트워크의 인스턴스로 들어오는 TCP 연결을 허용하는 fw-allow-health-checks라는 방화벽 규칙을 만듭니다. 부하 분산기 유형에 따라 백엔드에 대한 IPv6 트래픽에 대해 서로 다른 프로브 IP 범위 및 방화벽 규칙 집합이 지원됩니다.

NETWORK_NAME을 VPC 네트워크의 이름으로 바꾸고 PORT를 부하 분산기에서 사용하는 포트로 바꿉니다.
```
gcloud compute firewall-rules create fw-allow-health-checks \
    --network=NETWORK_NAME \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=SOURCE_IP_RANGE \
    --target-tags=allow-health-checks \
    --rules=tcp:PORT
```
SOURCE_IP_RANGE 값은 부하 분산기 유형, 트래픽 유형, 상태 점검 유형에 따라 다릅니다. 프로브 IP 범위 및 방화벽 규칙을 참고하세요.
부하 분산되는 각 인스턴스에 네트워크 태그를 추가하여 새 인그레스 방화벽 규칙이 적용되게 합니다. 이 예시에서는 네트워크 태그로 allow-health-checks를 사용합니다.

자세한 내용은 gcloud 방화벽 규칙 문서 및 API 문서를 참조하세요.

부하 분산기와 상태 점검 연결

아직 상태 점검을 선택하지 않았다면 상태 점검 개요: 상태 점검 선택을 검토하세요.

상태 점검을 새 부하 분산기와 연결하려면 해당 부하 분산기의 설정 가이드를 참조하세요. 이 섹션에서는 상태 점검을 기존 부하 분산기의 백엔드 서비스와 연결하는 방법을 설명합니다.

이 섹션에서는 다음 작업을 이미 완료했다고 가정합니다.

부하 분산기를 만들었습니다.
상태 점검을 만들었습니다.
필요한 방화벽 규칙을 만들었습니다.

콘솔

상태 점검을 기존 부하 분산기와 연결하려면 다음 단계를 따르세요.

Google Cloud 콘솔의 부하 분산 페이지로 이동합니다.
부하 분산 페이지로 이동
부하 분산기를 클릭하여 세부정보를 봅니다.
수정 을 클릭한 다음 백엔드 구성을 클릭합니다.
상태 점검 메뉴에서 상태 점검을 선택합니다.
업데이트를 클릭합니다.

gcloud

상태 점검을 기존의 백엔드 서비스와 연결하려면 다음 단계를 따르세요.

백엔드 서비스의 이름과 범위를 식별합니다. 패스 스루 네트워크 부하 분산기 및 프록시 네트워크 부하 분산기에는 부하 분산기당 하나의 백엔드 서비스만 있습니다. 애플리케이션 부하 분산기에는 단일 URL 맵과 연결된 백엔드 서비스가 하나 이상 있습니다.
- 내부 패스 스루 네트워크 부하 분산기에 대한 백엔드 서비스를 나열하려면 다음 명령어를 실행합니다.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=INTERNAL"
```
- 외부 패스 스루 네트워크 부하 분산기에 대한 백엔드 서비스를 나열하려면 다음 명령어를 실행합니다.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=EXTERNAL"
```
- 전역 외부 프록시 네트워크 부하 분산기의 백엔드 서비스를 나열하려면 다음 명령어를 실행합니다.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- 기존 프록시 네트워크 부하 분산기에 대한 백엔드 서비스를 나열하려면 다음 명령어를 실행합니다.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL" \
    --filter="protocol=(SSL,TCP)"
```
- 리전 간 내부 프록시 네트워크 부하 분산기에 대한 백엔드 서비스를 나열하려면 다음 명령어를 실행합니다.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=INTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- 리전별 외부 프록시 네트워크 부하 분산기의 백엔드 서비스를 나열하려면 다음 명령어를 실행합니다.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=EXTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- 리전별 내부 프록시 네트워크 부하 분산기의 백엔드 서비스를 나열하려면 다음 명령어를 실행합니다.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=INTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"
```
- 전역 외부 애플리케이션 부하 분산기, 기존 애플리케이션 부하 분산기, 리전 간 내부 애플리케이션 부하 분산기의 백엔드 서비스를 식별하려면 먼저 URL 맵을 식별한 다음 맵을 설명합니다. 이러한 부하 분산기에 대한 URL 맵과 백엔드 서비스는 네트워크 서비스 등급에 관계없이 항상 전역적입니다. URL_MAP_NAME을 URL 맵의 이름으로 바꿉니다. 부하 분산기에서 사용하는 백엔드 서비스가 응답에 나열됩니다.
```
gcloud compute url-maps list \
    --global
```
```
gcloud compute url-maps describe URL_MAP_NAME \
    --global
```
- 리전 외부 애플리케이션 부하 분산기 또는 리전 내부 애플리케이션 부하 분산기의 백엔드 서비스를 식별하려면 먼저 URL 맵을 식별한 다음 맵을 설명합니다. 이러한 부하 분산기의 URL 맵과 백엔드 서비스는 모두 리전입니다. REGION_LIST를 쿼리할 Google Cloud 리전의 쉼표로 구분된 목록으로 바꿉니다. URL_MAP_NAME을 URL 맵 이름으로 바꾸고 REGION을 해당 리전으로 바꿉니다. 부하 분산기에서 사용하는 백엔드 서비스가 응답에 나열됩니다.
```
gcloud compute url-maps list \
    --regions=REGION_LIST
```
```
gcloud compute url-maps describe URL_MAP_NAME \
    --region=REGION
```
상태 점검을 식별합니다. 상태 점검 나열을 참조하세요.
compute backend-services update 명령어를 사용하여 상태 점검을 백엔드 서비스와 연결합니다. 각 백엔드 서비스는 단일 상태 점검을 참조해야 합니다. 다음 명령어에서 BACKEND_SERVICE_NAME을 백엔드 서비스의 이름으로 바꾸고, HEALTH_CHECK_NAME을 상태 점검 이름으로 바꾸고, 필요하면 REGION을 백엔드 서비스나 상태 점검 또는 둘 다의 Google Cloud 리전으로 바꿉니다.
- 내부 패스 스루 네트워크 부하 분산기의 상태 점검을 변경합니다. 내부 패스 스루 네트워크 부하 분산기의 백엔드 서비스는 리전 기준입니다. 전역 또는 리전별 상태 점검을 참조할 수 있습니다. 다음 예시는 리전별 상태 점검 참조를 보여줍니다. 내부 패스 스루 네트워크 부하 분산기에 전역 상태 점검을 사용하는 경우 --health-checks-region 대신 --global-health-checks를 사용합니다.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
- 백엔드 서비스 기반 외부 패스 스루 네트워크 부하 분산기의 상태 점검을 변경합니다. 외부 패스 스루 네트워크 부하 분산기의 백엔드 서비스는 리전 기준입니다. 리전별 상태 점검을 참조할 수 있습니다.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
- 전역 외부 프록시 네트워크 부하 분산기, 기본 프록시 네트워크 부하 분산기, 전역 외부 애플리케이션 부하 분산기, 기본 애플리케이션 부하 분산기 또는 리전 간 내부 애플리케이션 부하 분산기의 상태 점검을 변경하려면 다음 안내를 따르세요. 백엔드 서비스 및 상태 점검은 이러한 부하 분산기에 대해 전역적입니다. 애플리케이션 부하 분산기가 둘 이상의 백엔드 서비스를 참조하는 경우 둘 이상의 상태 점검을 참조할 수 있습니다.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --global \
    --health-checks HEALTH_CHECK_NAME \
    --global-health-checks
```
- 리전 외부 애플리케이션 부하 분산기, 리전 외부 프록시 네트워크 부하 분산기, 리전 내부 애플리케이션 부하 분산기 또는 리전 내부 프록시 네트워크 부하 분산기의 상태 점검을 변경하려면 다음과 같이 합니다. 백엔드 서비스와 상태 점검 모두 리전 기준입니다. 일부 부하 분산기는 둘 이상의 백엔드 서비스를 참조할 수 있는 경우 둘 이상의 상태 점검을 참조할 수 있습니다.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```

API

backendServices.list API 호출을 사용하여 백엔드 서비스를 나열할 수 있습니다.
상태 점검을 봅니다.
상태 점검을 백엔드 서비스와 연결하려면 다음 API 호출 중 하나를 사용합니다.
- backendServices.update
- backendServices.patch

대상 풀 기반 외부 패스 스루 네트워크 부하 분산기와 기존 상태 점검 연결

기존 상태 점검을 새 외부 패스 스루 네트워크 부하 분산기와 연결하려면 대상 풀을 사용하여 외부 패스 스루 네트워크 부하 분산기 설정을 참조하세요. 이 섹션에서는 기존 상태 점검을 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기와 연결하는 방법을 설명합니다.

이 섹션에서는 다음 작업을 이미 완료했다고 가정합니다.

대상 풀 기반 외부 패스 스루 네트워크 부하 분산기를 만들었습니다.
기존 상태 점검을 만들었습니다.
필요한 방화벽 규칙을 만들었습니다.

콘솔

상태 점검을 기존의 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기와 연결하려면 다음 단계를 따르세요.

Google Cloud 콘솔의 부하 분산 페이지로 이동합니다.
부하 분산 페이지로 이동
부하 분산기를 클릭하여 세부정보를 봅니다.
수정 을 클릭한 다음 백엔드 구성을 클릭합니다.
상태 점검 메뉴에서 기존 상태 점검을 선택합니다. 조건에 부합하는 기존 상태 점검만 표시됩니다.
업데이트를 클릭합니다.

gcloud

상태 점검을 기존의 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기와 연결하려면 다음 단계를 따르세요.

대상 풀을 식별합니다. 외부 패스 스루 네트워크 부하 분산기에는 대상 풀이 하나 이상 있으며 보조 백업 풀이 있을 수 있습니다.
```
gcloud compute target-pools list
```
HTTP 프로토콜을 사용하여 기존 상태 점검을 식별합니다. 필요한 경우 기존 상태 점검을 봅니다.
기존 상태 점검을 대상 풀에 연결합니다. 다음 명령어에서 TARGET_POOL_NAME을 대상 풀의 이름으로, REGION을 리전으로, LEGACY_CHECK_NAME을 기존 상태 점검의 이름으로 바꿉니다. 기존 상태 점검은 HTTP 프로토콜을 사용해야 합니다.
- 대상 풀에서 기존 HTTP 상태 점검을 제거하려면 다음 명령어를 사용합니다.
```
gcloud compute target-pools remove-health-checks TARGET_POOL_NAME \
    --region=REGION \
    --http-health-check LEGACY_CHECK_NAME
```
- 대상 풀에 기존 HTTP 상태 점검을 추가하려면 다음 명령어를 사용합니다.
```
gcloud compute target-pools add-health-checks TARGET_POOL_NAME \
    --region=REGION \
    --http-health-check LEGACY_CHECK_NAME
```

API

targetPools.list API 호출을 사용하여 대상 풀을 나열할 수 있습니다.
기존 상태 점검을 보고 기존 HTTP 상태 점검을 식별합니다.
기존 HTTP 상태 점검을 대상 풀과 연결하려면 targetPools.addHealthCheck API 호출을 사용합니다.

상태 점검 상태 확인

상태 점검을 백엔드 서비스 또는 대상 풀과 연결하면 부하 분산기의 백엔드에 대한 즉각적인 상태 점검 상태를 가져올 수 있습니다.

콘솔

부하 분산 요약 페이지로 이동합니다.
부하 분산 페이지로 이동
부하 분산기의 이름을 클릭합니다.
백엔드에서 정상 열을 검사합니다. 각 백엔드 인스턴스 그룹 또는 네트워크 엔드포인트 그룹의 상태가 보고됩니다.

gcloud

대상 풀 기반 외부 패스 스루 네트워크 부하 분산기를 제외한 모든 부하 분산기의 경우 백엔드 서비스의 이름과 범위(전역 또는 리전)를 식별합니다. 부하 분산기와 범위의 전체 목록은 백엔드 서비스를 참조하세요.

compute backend-services get-health 명령어를 사용하여 필요한 경우 NAME을 백엔드 서비스 이름으로, REGION을 해당 리전으로 바꿉니다.
- 전역 백엔드 서비스의 즉각적인 상태를 가져오려면 다음을 수행하세요.
```
gcloud compute backend-services get-health GLOBAL_BACKEND_SERVICE_NAME \
    --global
```
- 리전별 백엔드 서비스의 즉각적인 상태를 가져오려면 다음 안내를 따르세요.
```
gcloud compute backend-services get-health REGIONAL_BACKEND_SERVICE_NAME \
    --region=REGION
```
대상 풀 기반 외부 패스 스루 네트워크 부하 분산기의 경우 부하 분산기 대상 풀의 이름과 리전을 식별한 후 compute target-pools get-health 명령어를 사용하여 NAME을 대상 풀의 이름으로, REGION을 리전으로 바꿉니다.
```
gcloud compute target-pools get-health TARGET_POOL_NAME \
    --region=REGION
```

API

대상 풀 기반 외부 패스 스루 네트워크 부하 분산기를 제외한 모든 부하 분산기의 경우 백엔드 서비스의 이름과 범위(전역 또는 리전)를 식별합니다. 부하 분산기와 범위의 전체 목록은 백엔드 서비스를 참조하세요.
- 전역 백엔드 서비스의 즉각적인 상태를 가져오려면 backendServices.getHealth를 사용합니다.
- 리전별 백엔드 서비스의 즉각적인 상태 상태를 가져오려면 regionBackendServices.getHealth를 사용합니다.
대상 풀 기반 외부 패스 스루 네트워크 부하 분산기의 경우 targetPools.getHealth를 사용합니다.