상태 확인 개념

Google Cloud Platform(GCP)은 인스턴스 그룹과 네트워크 엔드포인트 그룹(NEG)과 같은 백엔드가 트래픽에 제대로 응답하는지 확인하는 상태 확인 메커니즘을 제공합니다. 이 문서에서는 GCP 및 부하 분산기와 관련된 상태 확인 개념에 대해 설명합니다.

개요

GCP는 구성 가능한 주기에 따라 백엔드에 연결하는 전역 및 리전의 상태 확인 시스템을 제공합니다. 각 연결 시도를 프로브라고 합니다. GCP는 각 프로브의 성공 또는 실패를 기록합니다.

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

GCP는 각 백엔드의 전반적인 상태를 사용하여 새 요청을 수신할 자격이 있는지를 결정합니다. 프로브 빈도와 상태 임계값을 구성할 수 있을 뿐만 아니라 성공적인 프로브를 정의하는 기준도 구성할 수 있습니다. 이 문서에서는 상태 확인이 작동하는 방식을 자세히 설명합니다.

GCP는 상태 확인을 위해 VPC 네트워크에 정의되지 않은 특수 경로를 사용합니다. 자세한 내용은 부하 분산기 반환 경로를 참조하세요.

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

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

상태 확인에는 상태 확인기존 상태 확인이라는 두 가지 카테고리가 있습니다. 각 카테고리는 서로 다른 프로토콜 집합과 상태 확인에 사용되는 포트 지정 수단을 지원합니다. 프로토콜과 포트는 GCP 상태 확인 시스템이 백엔드에 연결하는 방법을 결정합니다. 예를 들어 TCP 포트 80에서 HTTP 프로토콜을 사용하는 상태 확인을 만들거나, 인스턴스 그룹에 구성된 이름이 지정된 포트에 TCP 프로토콜을 사용하는 상태 확인을 만들 수 있습니다.

대부분의 GCP 부하 분산기에는 기존 상태 확인이 아닌 상태 확인이 필요하지만 네트워크 부하 분산에는 HTTP 프로토콜을 사용하는 기존 상태 확인이 필요합니다. 카테고리 및 프로토콜 선택과 포트 지정에 대한 구체적인 안내는 상태 확인 선택을 참조하세요.

기존 상태 확인을 상태 확인으로 변환할 수 없으며 그 반대도 마찬가지입니다.

상태 확인이라는 용어는 기존 상태 확인을 의미하지 않습니다. 이 문서에서는 기존 상태 확인을 명시적으로 기존 상태 확인이라고 합니다.

상태 확인 선택

상태 확인은 부하 분산기 유형 및 부하 분산기에서 사용하는 백엔드 유형(인스턴스 그룹 또는 네트워크 엔드포인트 그룹)과 호환되어야 합니다. 상태 확인을 만들 때는 다음 세 가지 요소를 지정해야 합니다.

  • 카테고리: 상태 확인 또는 이전 상태 확인. 부하 분산기와 호환되어야 합니다.
  • 프로토콜: GCP 시스템이 주기적으로 백엔드를 프로브하는 데 사용하는 프로토콜을 정의합니다.
  • 포트 사양: 상태 확인 프로토콜에 사용되는 포트를 정의합니다.

이 섹션의 끝에 있는 가이드에는 특정한 부하 분산기 유형과 백엔드 유형에 따라 상태 확인 카테고리, 프로토콜, 포트 사양의 올바른 조합이 요약되어 있습니다.

이 섹션에서 사용하는 인스턴스 그룹이라는 용어는 비관리형 인스턴스 그룹, 관리형 인스턴스 그룹 또는 관리형 리전 인스턴스 그룹을 의미합니다.

카테고리 및 프로토콜

부하 분산기 유형과 부하 분산기가 사용하는 백엔드 유형이 상태 확인 카테고리를 결정합니다. 네트워크 부하 분산에는 HTTP 프로토콜을 사용하는 기존 상태 확인이 필요합니다. 다른 모든 부하 분산기 유형에는 일반 상태 확인을 사용하세요.

상태 확인 카테고리에서 지원하는 프로토콜 목록에서 프로토콜을 선택해야 합니다. 부하 분산기와 동일한 프로토콜을 사용하는 것이 가장 좋습니다. 하지만 필수사항은 아니며 항상 가능하지도 않습니다. 예를 들어 네트워크 부하 분산기에는 기존 상태 확인이 필요하며, 네트워크 부하 분산은 일반적으로 TCP와 UDP를 지원하지만 네트워크 부하 분산기는 기존 상태 확인에 HTTP 프로토콜을 사용해야 합니다. 네트워크 부하 분산기의 경우 상태 확인 프로브에 응답할 수 있도록 VM에서 HTTP 서버를 실행해야 합니다.

다음 표에는 상태 확인 카테고리와 각 카테고리에서 지원되는 프로토콜이 나와있습니다.

상태 확인 카테고리 지원되는 프로토콜
상태 확인 • HTTP
• HTTPS
• HTTP/2
• SSL
• TCP
기존 상태 확인 • HTTP
• HTTPS(기존 HTTPS 상태 확인은 네트워크 부하 분산기에 지원되지 않으며 대부분의 다른 유형의 부하 분산기와 함께 사용할 수 없음)

카테고리 및 포트 사양

프로토콜 외에도 상태 확인을 위한 포트 사양을 선택해야 합니다. 상태 확인은 3가지 포트 사양 메서드를 제공하며, 기존 상태 확인은 하나의 메서드를 제공합니다. 각 부하 분산기 유형에 모든 포트 사양 메서드를 적용할 수 있는 것은 아닙니다. 부하 분산기 유형과 사용하는 백엔드 유형에 따라 사용 가능한 포트 사양 메서드가 결정됩니다.

상태 확인 카테고리 포트 사양 메서드와 의미
상태 확인 --port: TCP 포트 번호를 지정합니다.
--port-name: 인스턴스 그룹에 설정된 이름이 지정된 포트를 지정합니다.
--use-serving-port: 인스턴스 그룹에는 백엔드 서비스에서 사용하는 포트와 동일한 이름이 지정된 포트를 사용하고, 네트워크 엔드포인트 그룹에는 각 엔드포인트에 정의된 포트를 사용합니다.
기존 상태 확인 --port: TCP 포트 번호를 지정합니다.

여기와 아래에서 볼 수 있듯이 --use-serving-port 플래그는 gcloud beta compute health-checks create로 구현되지만, gcloud beta compute health-checks update로 구현되지는 않습니다.

부하 분산기 가이드

특정 부하 분산기에 대한 상태 확인의 올바른 카테고리와 프로토콜을 선택하려면 이 표를 사용하세요.

부하 분산기 백엔드 유형 상태 확인 카테고리 및 범위 포트 사양
내부 TCP/UDP 리전 내부 백엔드 서비스의 인스턴스 그룹 상태 확인(전역) 포트 번호(--port) 또는 이름이 지정된 포트(--port-name)
INTERNAL 부하 분산 스키마가 있는 백엔드 서비스에는 이름이 지정된 연결된 포트가 없으므로 --use-serving-port 플래그를 사용할 수 없습니다.
내부 HTTP(S) 네트워크 엔드포인트 그룹
(백엔드 서비스)
상태 확인(리전) 포트 번호(--port) 또는
--use-serving-port
백엔드 서비스의 인스턴스 그룹 상태 확인(리전) 포트 번호(--port), 이름이 지정된 포트(--port-name) 또는
--use-serving-port
네트워크 대상 풀을 사용하는 인스턴스 그룹 기존 상태 확인(전역)
HTTP 프로토콜 사용
기존 상태 확인은 포트 번호(--port)별 포트 사양만 지원
TCP 프록시
SSL 프록시
HTTP(S) 1
네트워크 엔드포인트 그룹
(백엔드 서비스)
상태 확인(전역) 포트 번호(--port) 또는
--use-serving-port
백엔드 서비스의 인스턴스 그룹 상태 확인(전역) 포트 번호(--port), 이름이 지정된 포트(--port-name) 또는
--use-serving-port

1다음과 같은 경우 HTTP(S) 부하 분산기와 연결된 백엔드 서비스에 기존 상태 확인을 사용할 수는 있지만 권장되지 않습니다.

  • 백엔드 서비스에서 사용하는 백엔드는 네트워크 엔드포인트 그룹이 아니라 인스턴스 그룹입니다.
  • 백엔드 VM은 HTTP 또는 HTTPS를 사용하여 프로브할 수 있습니다.

상태 확인의 작동 방식

프로브

상태 확인을 만들 때 또는 기존 상태 확인을 만들 때 다음 플래그를 지정하거나 기본값을 그대로 사용합니다. 이 플래그는 GCP 상태 확인 시스템이 인스턴스 그룹 또는 NEG 백엔드를 프로브하는 빈도를 제어합니다. GCP는 여러 시스템을 사용하여 프로브를 구현합니다.

상태 확인의 설정은 백엔드별로 구성할 수 없습니다. 상태 확인은 전체 백엔드 서비스와 연결되며, 기존 상태 확인은 특정 HTTP(S) 부하 분산기의 전체 대상 풀 또는 백엔드 서비스와 연결됩니다. 따라서 프로브의 매개변수는 특정 백엔드 서비스 또는 대상 풀에서 참조하는 모든 백엔드에 대해 동일합니다.

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

프로브 IP 범위

GCP 프로브 시스템의 소스 IP 주소는 부하 분산기의 유형에 따라 다릅니다. GCP 프로브 시스템에서 백엔드로 들어오는 트래픽을 허용하는 인그레스 허용 방화벽 규칙을 만들려면 다음 표를 사용합니다.

부하 분산기 프로브 IP 범위 방화벽 규칙 예시
내부
TCP 프록시
SSL 프록시
HTTP(S)
내부 HTTP(S)
35.191.0.0/16
130.211.0.0/22
네트워크 부하 분산기를 제외한 모든 부하 분산기의 방화벽 규칙
네트워크 35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
네트워크 부하 분산기의 방화벽 규칙

다중 프로브 및 빈도

GCP는 적절한 소스 IP 범위에서 여러 중복 시스템의 상태 확인 프로브를 보냅니다. 하나의 프로브 시스템이 모든 프로브를 담당하지 않습니다. 하나의 실패로 GCP가 백엔드 상태 확인을 추적하지 못하는 일이 발생하지 않도록 여러 시스템에서 동시에 여러 프로브를 실행합니다.

상태 확인을 위해 구성한 간격 및 시간 제한 설정은 각 프로브 시스템에 적용됩니다. 특정 백엔드에서 소프트웨어 액세스 로그와 tcpdump는 구성된 설정보다 더 자주 상태 확인 프로브를 표시합니다. 여러 프로브 시스템이 동시에 백엔드에 연결하면 단일 프로브 시스템의 구성보다 더 많은 상태 확인 프로브가 발생합니다.

이는 예상되는 동작이며, GCP가 상태 확인에 사용하는 프로브 시스템의 수는 구성할 수 없습니다. 그러나 다음과 같은 사항을 고려하여 여러 동시 프로브의 효과를 예측할 수 있습니다.

  • 백엔드 서비스당 프로브 빈도를 추정하려면 다음을 고려하세요.

    • 백엔드 서비스별 기본 빈도: 각 상태 확인에는 확인 빈도가 설정되며 이 값은 구성된 확인 간격에 반비례합니다.

      1(확인 간격)

      상태 확인을 백엔드 서비스와 연결할 때 백엔드 서비스의 백엔드에 각 프로브 시스템에서 사용하는 기본 빈도를 설정합니다.

    • 프로브 배율: 백엔드 서비스의 기본 빈도에 GCP가 사용하는 동시 프로브 시스템의 수를 곱합니다. 이 수는 경우에 따라 다르지만 일반적으로 5~10입니다.

  • 내부 TCP/UDP 부하 분산기의 다중 전달 규칙: 동일한 리전 내부 백엔드 서비스를 가리키는 여러 내부 전달 규칙을 각 규칙이 서로 다른 IP 주소를 갖도록 구성한 경우 GCP는 여러 프로브 시스템을 사용하여 각 IP 주소를 확인합니다. 백엔드 서비스당 프로브 빈도에 구성된 전달 규칙의 수를 곱합니다.

  • 네트워크 부하 분산기의 다중 전달 규칙: 동일한 대상 풀을 가리키는 여러 전달 규칙을 구성한 경우 GCP는 여러 프로브 시스템을 사용하여 각 IP 주소를 확인합니다. 대상 풀의 각 백엔드에서 확인되는 프로브 빈도에 구성된 전달 규칙의 수를 곱합니다.

  • HTTP(S) 부하 분산기의 여러 대상 프록시: HTTP(S) 부하 분산에 대해 동일한 URL 맵에 여러 대상 프록시를 구성한 경우 GCP는 여러 프로브 시스템을 사용하여 각 대상 프록시와 연결된 IP 주소를 확인합니다. 백엔드 서비스당 프로브 빈도에 구성된 대상 프록시 수를 곱합니다.

  • SSL 프록시 및 TCP 프록시 부하 분산기의 여러 대상 프록시: SSL 프록시 또는 TCP 프록시 부하 분산에 대해 동일한 백엔드 서비스에 대해 여러 대상 프록시를 구성한 경우 GCP는 여러 프록시 시스템을 사용하여 각 대상 프록시와 연결된 IP 주소를 확인합니다. 백엔드 서비스당 프로브 빈도에 구성된 대상 프록시 수를 곱합니다.

  • 백엔드 서비스의 합계: 여러 백엔드 서비스에서 하나의 백엔드(예: 인스턴스 그룹)를 사용하는 경우 이 백엔드 인스턴스는 각 백엔드 서비스 상태 확인의 빈도 합계만큼 자주 연결됩니다.

    네트워크 엔드포인트 그룹 백엔드(NEG)를 사용하면 상태 확인 프로브의 정확한 수를 알기가 더 어렵습니다. 예를 들면 동일한 엔드포인트가 여러 NEG에 있을 수 있는데, 이 경우 NEG의 엔드포인트 집합이 반드시 동일하지는 않으며 서로 다른 엔드포인트가 동일한 백엔드를 가리킬 수 있습니다.

상태 확인 패킷의 대상

GCP 상태 확인 프로브는 각 백엔드 인스턴스의 기본 네트워크 인터페이스에만 패킷을 전송합니다. 이러한 패킷의 대상 IP 주소는 부하 분산기의 유형에 따라 다릅니다.

  • 내부 TCP/UDP 부하 분산기와 네트워크 부하 분산기의 경우, 상태 확인 패킷의 대상은 부하 분산기의 전달 규칙의 IP 주소입니다. 여러 전달 규칙이 동일한 백엔드 서비스 또는 대상 풀을 가리키는 경우 GCP는 프로브를 각 전달 규칙의 IP 주소로 전송합니다. 그러면 이전 섹션에서 설명한 대로 프로브 수가 증가할 수 있습니다.
  • 인스턴스 그룹을 백엔드로 사용하는 HTTP(S), TCP 프록시, SSL 프록시, 내부 HTTP(S) 부하 분산기의 경우, 상태 확인 패킷의 대상은 각 백엔드 인스턴스의 기본 네트워크 인터페이스와 연결된 기본 내부 IP 주소입니다.
  • 네트워크 엔드포인트 그룹을 백엔드로 사용하는 HTTP(S), TCP 프록시, SSL 프록시, 내부 HTTP(S) 부하 분산기의 경우, 상태 확인 패킷의 대상은 엔드포인트의 IP 주소이며 이는 기본 또는 보조(별칭 IP) 주소입니다.

콘텐츠 기반 상태 확인

HTTP(S), HTTP/2, TCP 및 SSL 상태 확인은 선택적으로 콘텐츠 기반(요청/응답)으로 설정할 수 있습니다. 콘텐츠 기반 상태 확인에서 상태 확인 프로버는 요청 문자열을 백엔드로 보냅니다. 상태 확인은 프로브에 대한 특정한 응답을 예상하도록 구성됩니다.

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

HTTP, HTTPS 또는 HTTP/2 프로토콜을 사용하는 상태 확인 프로브의 응답은 GCP가 보낸 요청에 대해 HTTP 200 (OK) 응답을 수신하고 이 응답이 프로브 시간 초과 전에 전송된 경우에만 성공합니다.

요청은 구성 가능한 요청 경로 또는 지정되지 않은 경우 /로 전송됩니다. 콘텐츠 기반 확인을 사용하여 예상되는 응답 문자열을 제공하지 않는 한 모든 응답이 허용됩니다. HTTP, HTTPS, HTTP/2 상태 확인의 성공 기준을 제어하는 데 사용할 수 있는 플래그는 다음과 같습니다.

구성 플래그 목적
요청 경로
request-path
GCP가 상태 확인 프로브 요청을 보낼 URL 경로를 지정합니다.
생략하면 GCP가 프로브 요청을 루트 경로 /로 보냅니다. request-path 옵션은 쿼리 매개변수를 지원하지 않습니다.
응답
response
선택사항인 응답 플래그를 사용하면 콘텐츠 기반 상태 확인을 구성할 수 있습니다. 예상 응답 문자열은 ASCII(단일 바이트) 1,024자 이하여야 합니다. 이 값이 구성된 경우 GCP는 HTTP 200 (OK) 상태를 수신할 뿐만 아니라 응답의 처음 1,024 바이트 안에서 이 문자열을 예상합니다.

콘텐츠 기반 상태 확인은 선택사항입니다. 예상 응답 문자열을 지정했는지 여부에 관계없이 GCP는 확인 대상인 백엔드가 HTTP 200 (OK)으로 응답할 것을 예상합니다. 예상 응답을 제공하면 각 GCP 상태 확인 프로버는 백엔드가 제공한 응답을 검색하여 반환된 처음 1,024 바이트 안에서 예상 응답 문자열을 찾습니다. HTTP 200 (OK)이 수신되고 그리고 반환된 응답의 처음 1,024 바이트에서 예상 응답이 발견되면 콘텐츠 기반 HTTP 상태 확인이 성공한 것으로 간주됩니다.

SSL 및 TCP의 성공 기준

기본적으로 SSL 및 TCP 프로토콜을 사용하는 상태 확인 프로브의 응답은 GCP가 SSL 또는 TCP 핸드셰이크를 완료하여 프로브 시간 초과 전에 세션을 설정할 수 있는 경우에만 성공합니다.

선택사항으로, 핸드셰이크를 완료하는 것 외에도 각각 길이가 최대 ASCII(1바이트) 1,024자인 요청 문자열과 예상 응답 문자열을 제공할 수 있습니다. 예상 응답 문자열이 구성된 경우 GCP는 SSL 또는 TCP 핸드셰이크가 완료되고 그리고 반환된 응답 문자열이 예상 응답 문자열과 정확하게 일치하는 경우에만 프로브가 성공한 것으로 간주합니다. SSL 및 TCP 프로토콜을 사용하는 상태 확인에 다음과 같은 요청 및 응답 플래그의 조합을 이용할 수 있습니다.

구성 플래그 동작
요청과 응답이 모두 지정되지 않음
플래그가 모두 지정되지 않음: --request, --response
GCP는 프로브 시간 초과 이전에 TCP 또는 SSL 세션이 설정된 경우 프로브가 성공한 것으로 간주합니다.
요청과 응답이 모두 지정됨
두 플래그가 모두 지정됨: --request, --response
GCP가 구성된 요청 문자열을 전송하고 예상 응답 문자열을 기다립니다. 프로브 시간 초과 이전에 TCP 또는 SSL 세션이 설정되고 반환된 응답 문자열이 예상 응답 문자열과 정확하게 일치하는 경우 프로브가 성공합니다.
응답만 지정됨
다음 플래그만 지정됨: --response
GCP가 예상 응답 문자열을 기다립니다. 프로브 시간 초과 이전에 TCP 또는 SSL 세션이 설정되고 반환된 응답 문자열이 예상 응답 문자열과 정확하게 일치하는 경우 프로브가 성공합니다.
부하 분산된 백엔드가 핸드셰이크의 일부로 자동으로 응답 문자열을 전송하는 경우에만 --response를 단독으로 사용해야 합니다.
요청만 지정됨
다음 플래그만 지정됨: --request
GCP가 구성된 요청 문자열을 보냅니다. 프로브 시간 초과 전에 TCP 또는 SSL 세션이 설정된 경우 프로브가 성공합니다. 응답은 있어도 확인되지 않습니다.

상태

GCP는 다음과 같은 구성 플래그와 프로브가 성공했는지 여부를 사용하여 부하 분산되는 각 백엔드의 전반적인 상태를 결정합니다.

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

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

비정상 기준이 충족되면 GCP는 백엔드를 비정상으로 간주합니다. 비정상 백엔드는 새로운 연결을 받을 수 없지만 기존 연결이 즉시 종료되지는 않습니다. 대신 시간 초과가 발생하거나 트래픽이 삭제될 때까지 연결이 열려 있습니다. 구체적인 동작은 사용 중인 부하 분산기의 유형에 따라 다릅니다.

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

다음 단계

상태 확인 구성에 대한 자세한 내용은 상태 확인 만들기를 참조하세요.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...