상태 확인 만들기

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

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

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

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

상태 확인에는 상태 확인기존 상태 확인이라는 두 가지 카테고리가 있습니다. 각 카테고리는 서로 다른 프로토콜 집합과 상태 확인에 사용되는 포트 지정 수단을 지원합니다.

Traffic Director 및 대부분의 부하 분산기는 이전 상태 확인이 아닌 상태 확인을 사용하지만 네트워크 부하 분산에 대해서는 이전 상태 확인을 사용해야 합니다. 상태 확인 개요 페이지에서 상태 확인 선택을 참조하여 적절한 카테고리, 프로토콜, 포트 지정 방법을 확인합니다.

상태 확인을 위해 선택한 프로토콜은 부하 분산기에서 사용하는 프로토콜과 일치할 필요가 없으며 경우에 따라서는 일치가 불가능합니다. 자세한 내용은 프로토콜 및 부하 분산기를 참조하세요.

'상태 확인'이라는 용어는 이전 상태 확인을 가리키지 않습니다. 이 문서에서 이전 상태 확인은 '이전 상태 확인'이라고 명시적으로 언급됩니다.

상태 확인 목록

Console

  1. Google Cloud Console의 상태 확인 페이지로 이동합니다.
    상태 확인 페이지로 이동
  2. 상태 확인을 클릭하여 세부정보를 봅니다.

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 호출을 사용합니다.

상태 확인의 현재 구성을 설명하려면 다음 API 호출을 사용합니다.

상태 확인 만들기

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

또한 Cloud Console의 부하 분산기 구성과 상관없이 상태 확인을 만들 수도 있습니다. 이는 상태 확인을 먼저 만들어야 하거나 여러 부하 분산기에 대해 상태 확인을 사용해야 하는 경우에 유용합니다. Cloud Console, gcloud 명령줄 도구 또는 REST API를 사용하여 상태 확인을 만들 수 있습니다.

Console

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

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은 상태 확인에 사용되는 프로토콜을 정의합니다. http, https, http2, ssl, tcp가 유효한 옵션입니다.
  • name은 상태 확인의 이름입니다. 특정 프로젝트 내: 각 전역 상태 확인에는 고유한 이름이 있어야 하며, 리전별 상태 확인은 해당 리전 내에서 고유한 이름을 가져야 합니다.
  • region: 내부 HTTP(S) 부하 분산기를 제외한 모든 부하 분산기는 전역 상태 확인(--global)을 사용합니다. 내부 HTTP(S) 부하 분산기는 리전이 백엔드 서비스의 리전과 일치해야 하는 리전별 상태 확인을 사용합니다.
  • description은 선택사항인 설명입니다.
  • check-interval은 하나의 상태 확인 프로브 시스템의 연결이 시작된 후부터 다음 프로브 시작까지 걸리는 시간입니다. 단위는 초입니다. 생략하면 Google Cloud에서는 5s(5초)를 값으로 사용합니다.
  • timeout은 Google Cloud가 프로브에 대한 응답을 대기하는 시간입니다. timeout 값은 check-interval 이하여야 합니다. 단위는 초입니다. 생략하면 Google Cloud에서는 5s(5초)를 값으로 사용합니다.
  • healthy-thresholdunhealthy-threshold는 VM 인스턴스가 정상 또는 비정상으로 간주되려면 성공하거나 실패해야 하는 연속 프로브의 수를 지정합니다. 둘 중 하나를 생략하면 Google Cloud에서는 기본 임곗값 2를 사용합니다.
  • port specification: 포트 지정 플래그 중 하나를 사용하여 포트 지정을 정의합니다.
  • ...additional flags는 포트와 protocol에 대한 옵션을 지정하기 위한 기타 플래그입니다. HTTP, HTTPS, HTTP/2 상태 확인을 위한 추가 플래그 또는 SSL 및 TCP 상태 확인을 위한 추가 플래그를 참조하세요.

API

상태 확인 수정

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

Console

  1. Google Cloud Console의 상태 확인 페이지로 이동합니다.
    상태 확인 페이지로 이동
  2. 상태 확인을 클릭하여 세부정보를 봅니다.
  3. 상태 확인을 수정해야 하는 경우 편집을 클릭하고 다음을 수행합니다.
    • 필요에 따라 매개변수를 변경합니다.
    • 저장을 클릭합니다.

gcloud

  1. 상태 확인의 이름과 범위를 나타냅니다. 자세한 내용은 상태 확인 나열을 참조하세요.

  2. 상태 확인 이름, 프로토콜, 범위를 제외하고 공통 플래그, 포트 지정 플래그, 선택적 플래그를 수정할 수 있습니다. 기존 상태 확인을 수정하려면 적합한 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

  1. 상태 확인의 이름과 범위를 나타냅니다. 자세한 내용은 상태 확인 나열을 참조하세요.

  2. 상태 확인 이름, 프로토콜, 범위를 제외하고 다음 API 호출을 통해 공통 플래그, 포트 지정 플래그, 선택적 플래그를 수정할 수 있습니다. patch API 호출을 사용하여 요청에 명시적으로 설정되지 않은 사전 구성된 설정을 유지합니다.

추가 플래그

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

포트 지정 플래그

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

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

제품 백엔드 유형 포트 지정 옵션
내부 TCP/UDP 부하 분산 인스턴스 그룹 --port: 1부터 65535까지의 TCP 포트를 번호로 지정합니다.
내부 TCP/UDP 부하 분산기의 백엔드 서비스에는 포트 지정이 없기 때문에 내부 TCP/UDP 부하 분산기와 연결된 상태 확인에는 --use-serving-port 플래그를 사용할 수 없습니다.
내부 HTTP(S) 부하 분산
TCP 프록시 부하 분산
SSL 프록시 부하 분산
외부 HTTP(S) 부하 분산
Traffic Director
영역별 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-headerNONE 또는 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-headerNONE 또는 PROXY_V1 중 하나여야 합니다. 생략하면 Google Cloud에서는 NONE을 사용합니다. PROXY_V1의 값은 헤더 PROXY UNKNOWN\r\n을 추가합니다.
  • request-string: TCP 또는 SSL 세션이 설정되면 최대 1,024개의 ASCII 문자로 구성된 문자열을 전송할 수 있습니다.
  • response-string: 예상 응답에 최대 1,024개의 ASCII 문자로 구성된 문자열을 제공할 수 있습니다.

--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 상태 서비스에 다음 서비스 및 상태를 등록할 수 있습니다.

  • 게재 상태가 SERVINGMyPackage.ServiceA
  • 게재 상태가 NOT_SERVINGMyPackage.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 상태 확인을 나열, 생성, 수정하는 방법을 설명합니다. 네트워크 부하 분산기는 기존 HTTP 상태 확인만 사용할 수 있으며 이전 HTTPS 상태 확인은 사용할 수 없습니다.

기존 상태 확인 목록

Console

  1. Google Cloud Console의 상태 확인 페이지로 이동합니다.
    상태 확인 페이지로 이동
  2. 세부정보를 보려면 기존 상태 확인을 클릭하세요.

gcloud

  1. 기존 HTTP 상태 확인을 나열하려면 compute http-health-checks list 명령어를 사용합니다.

    gcloud compute http-health-checks list
    

    기존 HTTPS 상태 확인을 나열하려면 compute https-health-checks list 명령어를 사용합니다.

    gcloud compute https-health-checks list
    
  2. 기존 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

  1. 기존 상태 확인을 나열하려면 다음 단계를 따르세요.

  2. 기존 상태 확인을 설명하려면 다음 안내를 따르세요.

이전 상태 확인 만들기

Console

Cloud Console의 상태 확인 페이지 목록을 나열하고 상태 확인과 기존 상태 확인을 모두 수정할 수 있지만 Cloud Console의 상태 확인 페이지에서는 새로운 기존 상태 확인을 만들 수 없습니다.

기존 상태 확인을 만들려면 Cloud Console의 네트워크 부하 분산기 페이지를 사용하거나 이 섹션의 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-thresholdunhealthy-threshold는 VM 인스턴스가 정상 또는 비정상으로 간주되려면 성공하거나 실패해야 하는 연속 프로브의 수를 지정합니다. 둘 중 하나를 생략하면 Google Cloud에서는 기본 임곗값 2를 사용합니다.
  • host는 호스트 HTTP 헤더 제공을 허용합니다. 생략하면 부하 분산기 전달 규칙의 IP 주소가 사용됩니다.
  • port에서는 포트 번호를 제공할 수 있습니다. 생략하면 Google Cloud에서는 80을 사용합니다.
  • request-path는 Google Cloud가 상태 확인 요청을 보낼 때 사용하는 URL 경로를 지정합니다. 생략하면 상태 확인 요청이 /로 전송됩니다.

API

기존 상태 확인 수정

Console

  1. Google Cloud Console의 상태 확인 페이지로 이동합니다.
    상태 확인 페이지로 이동
  2. 세부정보를 보려면 상태 확인을 클릭하세요.
  3. 수정 을 클릭하고 변경한 다음 저장을 클릭합니다.

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 호출은 패치 요청에 명시적으로 설정되지 않은 사전 구성된 설정을 유지합니다.

필수 방화벽 규칙

상태 확인 프로버 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를 사용하여 연결할 수는 없습니다.

상태 확인을 위한 방화벽 규칙

다음 예시에서는 다음 부하 분산기에 대한 인그레스 방화벽 규칙을 만듭니다.

  • 내부 TCP/UDP 부하 분산(상태 확인)
  • 내부 HTTP(S) 부하 분산(상태 확인)
  • TCP 프록시 부하 분산(상태 확인)
  • SSL 프록시 부하 분산(상태 확인)
  • HTTP(S) 부하 분산(상태 확인 기존 상태 확인)

이러한 부하 분산기에 대한 상태 확인(HTTP(S) 부하 분산에 사용되는 이전 상태 확인을 포함)을 위한 소스 IP 범위는 다음과 같습니다.

  • 35.191.0.0/16
  • 130.211.0.0/22

내부 HTTP(S) 부하 분산에 한해 소스 IP 범위는 프록시 전용 서브넷의 모든 IP 주소입니다.

네트워크 부하 분산 규칙을 만들려면 다음 섹션의 네트워크 부하 분산 규칙을 참조하세요.

Console

  1. Google Cloud Console의 방화벽 페이지로 이동합니다.
    방화벽 페이지로 이동
  2. 방화벽 규칙 만들기를 클릭합니다.
  3. 방화벽 규칙 만들기 페이지에서 다음 정보를 입력합니다.
    • 이름: 규칙의 이름을 입력합니다. 이 예시에서는 fw-allow-health-checks를 사용합니다.
    • 네트워크: VPC 네트워크를 선택합니다.
    • 우선순위: 우선순위의 번호를 입력합니다. 숫자가 낮을수록 우선순위가 높습니다. 방화벽 규칙이 인그레스 트래픽을 거부할 수 있는 다른 규칙보다 높은 우선 순위를 갖도록 해야 합니다.
    • 트래픽 방향: 인그레스를 선택합니다.
    • 일치 시 작업: 허용을 선택합니다.
    • 대상: 지정된 대상 태그를 선택한 다음 대상 태그 텍스트 상자에 태그를 입력합니다. 이 예시에서는 allow-health-checks를 사용합니다.
    • 소스 필터: IP 범위를 선택합니다.
    • 소스 IP 범위: 35.191.0.0/16,130.211.0.0/22
    • 허용되는 프로토콜 및 포트: tcp을 사용합니다. TCP는 모든 상태 확인 프로토콜의 기본 프로토콜입니다.
    • 만들기를 클릭합니다.
  4. 부하 분산되는 각 인스턴스에 네트워크 태그를 추가하여 새 인그레스 방화벽 규칙이 적용되게 합니다. 이 예시에서는 네트워크 태그로 allow-health-checks를 사용합니다.

gcloud

  1. 다음 gcloud 명령어를 사용하여 Google Cloud 상태 확인 시스템에서 allow-health-checks 태그가 있는 VPC 네트워크의 인스턴스로 수신되는 TCP 연결을 제공하는 fw-allow-health-checks라는 이름의 방화벽 규칙을 생성합니다. network-name을 VPC 네트워크 이름으로 바꿉니다.

    gcloud compute firewall-rules create fw-allow-health-checks \
        --network=network-name \
        --action=ALLOW \
        --direction=INGRESS \
        --source-ranges=35.191.0.0/16,130.211.0.0/22 \
        --target-tags=allow-health-checks \
        --rules=tcp
  2. 부하 분산되는 각 인스턴스에 네트워크 태그를 추가하여 새 인그레스 방화벽 규칙이 적용되게 합니다. 이 예시에서는 네트워크 태그로 allow-health-checks를 사용합니다.

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

네트워크 부하 분산 규칙

다음 예시에서는 이전 상태 확인이 필요한 네트워크 부하 분산에 대한 인그레스 방화벽 규칙을 만듭니다. 네트워크 부하 분산의 이전 상태 확인을 위한 소스 IP 범위는 다음과 같습니다.

  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22

Console

  1. Google Cloud Console의 방화벽 페이지로 이동합니다.
    방화벽 페이지로 이동
  2. 방화벽 규칙 만들기를 클릭합니다.
  3. 방화벽 규칙 만들기 페이지에서 다음 정보를 입력합니다.
    • 이름: 규칙의 이름을 입력합니다. 이 예시에서는 fw-allow-network-lb-health-checks를 사용합니다.
    • 네트워크: VPC 네트워크를 선택합니다.
    • 우선순위: 우선순위의 번호를 입력합니다. 숫자가 낮을수록 우선순위가 높습니다. 방화벽 규칙이 인그레스 트래픽을 거부할 수 있는 다른 규칙보다 높은 우선 순위를 갖도록 해야 합니다.
    • 트래픽 방향: 인그레스를 선택합니다.
    • 일치 시 작업: 허용을 선택합니다.
    • 대상: 지정된 대상 태그를 선택한 다음 대상 태그 텍스트 상자에 태그를 입력합니다. 이 예시에서는 allow-network-lb-health-checks를 사용합니다.
    • 소스 필터: IP 범위를 선택합니다.
    • 소스 IP 범위: 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22
    • 허용되는 프로토콜 및 포트: tcp을 사용합니다. TCP는 HTTP 및 HTTPS의 기본 프로토콜입니다.
    • 만들기를 클릭합니다.
  4. 부하 분산되는 각 인스턴스에 네트워크 태그를 추가하여 새 인그레스 방화벽 규칙이 적용되게 합니다. 이 예시에서는 네트워크 태그로 allow-network-lb-health-checks를 사용합니다.

gcloud

  1. 다음 gcloud 명령어를 사용하여 Google Cloud 상태 확인 시스템에서 allow-network-lb-health-checks 태그가 있는 VPC 네트워크의 인스턴스로 수신되는 TCP 연결을 제공하는 fw-allow-network-lb-health-checks라는 이름의 방화벽 규칙을 생성합니다. network-name을 VPC 네트워크 이름으로 바꿉니다.

    gcloud compute firewall-rules create fw-allow-network-lb-health-checks \
        --network=network-name \
        --action=ALLOW \
        --direction=INGRESS \
        --source-ranges=35.191.0.0/16,209.85.152.0/22,209.85.204.0/22 \
        --target-tags=allow-network-lb-health-checks \
        --rules=tcp
  2. 부하 분산되는 각 인스턴스에 네트워크 태그를 추가하여 새 인그레스 방화벽 규칙이 적용되게 합니다. 이 예시에서는 네트워크 태그로 allow-network-lb-health-checks를 사용합니다.

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

부하 분산기 및 Traffic Director로 상태 확인 연결

이 섹션에서는 특정 상태 확인 추천 항목과 상태 확인을 부하 분산기 또는 Traffic Director로 연결하기 전에 충족되어야 하는 요구사항에 대해 설명합니다.

프로토콜 일치

프로토콜이 부하 분산기의 백엔드 서비스 또는 대상 풀에서 사용하는 프로토콜과 일치하는 상태 확인(또는 이전 상태 확인)을 사용하는 것이 가장 좋습니다. 그러나 상태 확인 프로토콜과 부하 분산기 프로토콜이 반드시 동일할 필요는 없습니다. 예를 들면 다음과 같습니다.

  • 내부 TCP/UDP 부하 분산의 경우 백엔드 서비스의 프로토콜로만 TCP 또는 UDP를 사용할 수 있습니다. 내부 TCP/UDP 부하 분산기 뒤의 VM으로부터 HTTP 트래픽을 제공하는 경우 HTTP 프로토콜을 사용하여 상태 확인을 수행하는 것이 좋습니다.

  • 네트워크 부하 분산기는 기존 HTTP 상태 확인을 사용해야 합니다. 기존 HTTPS 상태 확인 또는 최신 상태 확인을 사용할 수 없습니다. 네트워크 부하 분산기를 사용하여 TCP 트래픽을 분산하는 경우 상태 확인 프로브에 응답할 수 있도록 부하 분산되는 VM에서 HTTP 서비스를 실행해야 합니다.

  • gRPC 프로토콜을 사용하는 백엔드 서비스의 경우 gRPC 또는 TCP 상태 확인만 사용합니다. HTTP(S) 또는 HTTP/2 상태 확인은 사용하지 마세요.

백엔드 서비스 상태 확인

이 섹션에서는 다음 유형의 부하 분산기에 대한 상태 확인을 백엔드 서비스와 연결하는 방법을 설명합니다.

  • 내부 TCP/UDP 부하 분산
  • 내부 HTTP(S) 부하 분산
  • TCP 프록시 부하 분산
  • SSL 프록시 부하 분산
  • HTTP(S) 부하 분산

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

상태 확인을 새로운 내부 TCP/UDP 부하 분산기, TCP 프록시 부하 분산기, SSL 프록시 부하 분산기 또는 외부 HTTP(S) 부하 분산기와 연결하려면 각 부하 분산기의 설정 가이드를 참조하세요.

Console

상태 확인을 기존 내부 TCP/UDP 부하 분산기, TCP 프록시 부하 분산기, SSL 프록시 부하 분산기 또는 외부 HTTP(S) 부하 분산기와 연결하려면 다음 안내를 따르세요.

  1. Google Cloud Console의 부하 분산 페이지로 이동합니다.
    부하 분산 페이지로 이동
  2. 부하 분산기를 클릭하여 세부정보를 봅니다.
  3. 수정 을 클릭한 다음 백엔드 구성을 클릭합니다.
  4. 상태 확인 메뉴에서 상태 확인을 선택합니다.
  5. 업데이트를 클릭합니다.

gcloud

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

  1. 백엔드 서비스의 이름과 범위를 지정합니다. 내부 TCP/UDP 부하 분산기, TCP 프록시 부하 분산기, SSL 프록시 부하 분산기에는 부하 분산기당 하나의 백엔드만 있습니다. 외부 HTTP(S) 부하 분산기와 내부 HTTP(S) 부하 분산기에는 단일 URL 맵과 연결된 하나 이상의 백엔드 서비스가 있습니다.

    • 내부 TCP/UDP 부하 분산기의 백엔드 서비스를 나열하려면 다음 명령어를 실행하여 region-list를 쿼리할 Google Cloud 리전의 쉼표로 구분된 목록으로 바꿉니다.

      gcloud compute backend-services list \
          --regions=region-list \
          --filter="loadBalancingScheme=INTERNAL"
      
    • TCP 프록시 부하 분산기의 백엔드 서비스를 나열하려면 다음 명령어를 실행합니다. TCP 프록시 부하 분산기의 백엔드 서비스는 네트워크 서비스 계층에 관계없이 항상 전역적입니다.

      gcloud compute backend-services list \
          --global \
          --filter="loadBalancingScheme=EXTERNAL" \
          --filter="protocol=TCP"
      
    • SSL 프록시 부하 분산기의 백엔드 서비스를 나열하려면 다음 명령어를 실행합니다. SSL 프록시 부하 분산기의 백엔드 서비스는 네트워크 서비스 계층에 관계없이 항상 전역적입니다.

      gcloud compute backend-services list \
          --global \
          --filter="loadBalancingScheme=EXTERNAL" \
          --filter="protocol=SSL"
      
    • 외부 HTTP(S) 부하 분산기의 백엔드 서비스를 지정하려면 먼저 URL 맵을 지정한 다음 맵을 설명합니다. 외부 HTTP(S) 부하 분산기의 URL 맵 및 백엔드 서비스는 네트워크 서비스 계층에 관계없이 항상 전역적입니다. url-map-name을 URL 맵의 이름으로 바꿉니다. 부하 분산기에서 사용하는 백엔드 서비스가 응답에 나열됩니다.

      gcloud compute url-maps list \
          --global
      
      gcloud compute url-maps describe url-map-name \
          --global
      
    • 내부 HTTP(S) 부하 분산기의 백엔드 서비스를 지정하려면 먼저 URL 맵을 지정한 다음 맵을 설명합니다. 내부 HTTP(S) 부하 분산기의 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
      
  2. 상태 확인을 식별합니다. 상태 확인 나열을 참조하세요.

  3. compute backend-services update 명령어를 사용하여 상태 확인을 백엔드 서비스와 연결합니다. 각 백엔드 서비스는 단일 상태 확인을 참조해야 합니다. 다음 명령어에서 backend-service-name을 백엔드 서비스의 이름으로 바꾸고 health-check-name을 상태 확인 이름으로 바꾸고, 필요하면 region을 백엔드 서비스나 상태 확인 또는 둘 다의 Google Cloud 리전으로 바꿉니다.

    • 내부 TCP/UDP 부하 분산기에 대해 상태 확인을 변경합니다. 내부 TCP/UDP 부하 분산기의 백엔드 서비스는 리전별 서비스입니다. 전역 또는 리전별 상태 확인을 참조할 수 있습니다. 다음 예시에서는 리전별 상태 확인 참조를 보여줍니다. 내부 TCP/UDP 부하 분산기로 전역 상태 확인을 사용하는 경우 --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
      
    • TCP 프록시 부하 분산기, SSL 프록시 부하 분산기 또는 외부 HTTP(S) 부하 분산기의 상태 확인을 변경하려면 백엔드 서비스 및 상태 확인이 이러한 부하 분산기에 전역적입니다. 외부 HTTP(S) 부하 분산기는 둘 이상의 백엔드 서비스를 참조하는 경우 둘 이상의 상태 확인을 참조할 수 있습니다.

      gcloud compute backend-services update backend-service-name \
          --global \
          --health-checks health-check-name \
          --global-health-checks
      
    • 내부 HTTP(S) 부하 분산기의 상태 확인을 변경하려면 백엔드 서비스와 상태 확인이 모두 리전 기준입니다. 내부 HTTP(S) 부하 분산기는 둘 이상의 백엔드 서비스를 참조하는 경우 둘 이상의 상태 확인을 참조할 수 있습니다.

      gcloud compute backend-services update backend-service-name \
          --region=region \
          --health-checks=health-check-name \
          --health-checks-region=region
      

API

  1. backendServices.list API 호출을 사용하여 백엔드 서비스를 나열할 수 있습니다.

  2. 상태 확인을 봅니다.

  3. 상태 확인을 백엔드 서비스와 연결하려면 다음 API 호출 중 하나를 사용합니다.

네트워크 부하 분산에 대한 이전 상태 확인

이 섹션에서는 네트워크 부하 분산을 위해 대상 풀에 이전 상태 확인을 연결하는 방법을 설명합니다. 이 섹션에서는 다음 작업을 이미 완료했다고 가정합니다.

이전 상태 확인을 새 네트워크 부하 분산기와 연결하려면 네트워크 부하 분산 설정을 참조하세요. 새 네트워크 부하 분산기를 만들 때는 이전 상태 확인을 대상 풀과 연결해야 합니다.

Console

상태 확인을 기존 네트워크 부하 분산기와 연결하려면 다음 단계를 따르세요.

  1. Google Cloud Console의 부하 분산 페이지로 이동합니다.
    부하 분산 페이지로 이동
  2. 네트워크 부하 분산기를 클릭하여 세부정보를 봅니다.
  3. 수정 을 클릭한 다음 백엔드 구성을 클릭합니다.
  4. 상태 확인 메뉴에서 기존 상태 확인을 선택합니다. 조건에 부합하는 이전 상태 확인만 표시됩니다.
  5. 업데이트를 클릭합니다.

gcloud

상태 확인을 기존 네트워크 부하 분산기와 연결하려면 다음 단계를 따르세요.

  1. 대상 풀을 식별합니다. 네트워크 부하 분산기에는 대상 풀이 하나 이상 있으며 보조 백업 풀이 있을 수 있습니다.

    gcloud compute target-pools list
    
  2. HTTP 프로토콜을 사용하여 이전 상태 확인을 식별합니다. 필요한 경우 이전 상태 확인을 봅니다.

  3. 기존 상태 확인을 대상 풀에 연결합니다. 다음 명령어에서 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

  1. targetPools.list API 호출을 사용하여 대상 풀을 나열할 수 있습니다.

  2. 이전 상태 확인을 보고 이전 HTTP 상태 확인을 식별합니다.

  3. 이전 HTTP 상태 확인을 대상 풀과 연결하려면 targetPools.addHealthCheck API 호출을 사용합니다.

상태 확인 상태 확인

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

Console

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

gcloud

  • 네트워크 부하 분산기를 제외한 모든 부하 분산기에 대해 백엔드 서비스의 이름과 범위를 지정합니다. 내부 TCP/UDP 부하 분산기와 내부 HTTP(S) 부하 분산기는 리전별 백엔드 서비스를 사용합니다. TCP 프록시 부하 분산기, SSL 프록시 부하 분산기, 외부 HTTP(S) 부하 분산기는 전역 백엔드 서비스를 사용합니다.

    compute backend-services get-health 명령어를 사용하여 필요한 경우 name을 백엔드 서비스 이름으로, region을 해당 리전으로 바꿉니다.

    • 전역 백엔드 서비스의 즉각적인 상태를 가져오려면 다음을 수행하세요.

      gcloud compute backend-services get-health name \
          --global \
          --format=get(name, healthStatus)
      
    • 리전별 백엔드 서비스의 즉각적인 상태를 가져오려면 다음 안내를 따르세요.

      gcloud compute backend-services get-health name \
          --region=region \
          --format=get(name, healthStatus)
      
  • 네트워크 부하 분산기에 부하 분산기 대상 풀의 이름과 리전을 지정한 다음 compute target-pools get-health 명령어를 사용하여 name을 대상 풀의 이름으로, region을 해당 리전으로 바꿉니다.

    gcloud compute target-pools get-health name \
            --region=region \
        --format=get(name, healthStatus)
    

API

  • 네트워크 부하 분산기를 제외한 모든 부하 분산기에 대해 백엔드 서비스의 이름과 범위를 지정합니다. 내부 TCP/UDP 부하 분산기와 내부 HTTP(S) 부하 분산기는 리전별 백엔드 서비스를 사용합니다. TCP 프록시 부하 분산기, SSL 프록시 부하 분산기, 외부 HTTP(S) 부하 분산기는 전역 백엔드 서비스를 사용합니다.

  • 네트워크 부하 분산기의 경우 targetPools.getHealth를 사용합니다.