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
리소스를 사용합니다.
리전별 상태 점검을 만들려면 google_compute_region_health_check 리소스를 사용합니다.
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 ) 사양을 지원합니다. |
|
내부 패스 스루 네트워크 부하 분산기 | 인스턴스 그룹 및 지원되는 NEG |
이 부하 분산기의 백엔드 서비스에서 이름이 지정된 포트를 구독하지 않으므로 내부 패스 스루 네트워크 부하 분산기와 연결된 상태 점검에서 |
전역 외부 애플리케이션 부하 분산기 기존 애플리케이션 부하 분산기 리전 외부 애플리케이션 부하 분산기 리전 간 내부 애플리케이션 부하 분산기 리전 내부 애플리케이션 부하 분산기 전역 외부 프록시 네트워크 부하 분산기 기존 프록시 네트워크 부하 분산기 리전 외부 프록시 네트워크 부하 분산기 리전 간 내부 프록시 네트워크 부하 분산기 리전 내부 프록시 네트워크 부하 분산기 클라우드 서비스 메시 |
지원되는 NEG |
|
인스턴스 그룹 |
|
상태 점검을 만들 때 포트 사양을 생략하면 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 콘솔의 상태 점검 페이지에 상태 점검과 기존 상태 점검이 나열되어 create 수정할 수 있지만 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 호출 중 하나를 사용합니다.
대상 풀 기반 외부 패스 스루 네트워크 부하 분산기와 기존 상태 점검 연결
기존 상태 점검을 새 외부 패스 스루 네트워크 부하 분산기와 연결하려면 대상 풀을 사용하여 외부 패스 스루 네트워크 부하 분산기 설정을 참조하세요. 이 섹션에서는 기존 상태 점검을 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기와 연결하는 방법을 설명합니다.
이 섹션에서는 다음 작업을 이미 완료했다고 가정합니다.
콘솔
상태 점검을 기존의 대상 풀 기반 외부 패스 스루 네트워크 부하 분산기와 연결하려면 다음 단계를 따르세요.
- 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를 사용합니다.