이 문서에서는 관리형 인스턴스 그룹(MIG)에서 VM을 자동 복구하도록 애플리케이션 기반 상태 점검을 설정하는 방법을 설명합니다. 또한 자동 복구 없이 상태 점검을 사용하고, 상태 점검을 삭제하고, 자동 복구 정책을 보고, 각 VM의 상태를 확인하는 방법을 설명합니다.
애플리케이션 기반 상태 점검을 구성하여 VM의 애플리케이션이 예상대로 응답하는지 확인할 수 있습니다. 구성한 상태 점검에서 VM의 애플리케이션이 응답하지 않는 것으로 확인되면 MIG는 VM을 비정상으로 표시하고 복구합니다. 애플리케이션 기반 상태 점검을 기반으로 VM을 복구하는 것을 자동 복구라고 합니다.
자동 복구를 트리거하지 않고 상태 점검을 사용할 수 있도록 MIG에서 복구를 사용 중지할 수도 있습니다.
MIG의 복구에 대한 자세한 내용은 고가용성을 위한 VM 복구 정보를 참조하세요.
시작하기 전에
-
아직 인증을 설정하지 않았다면 설정합니다.
인증은 Google Cloud 서비스 및 API에 액세스하기 위해 ID를 확인하는 프로세스입니다.
로컬 개발 환경에서 코드 또는 샘플을 실행하려면 다음과 같이 Compute Engine에 인증하면 됩니다.
이 페이지의 샘플 사용 방법에 대한 탭을 선택하세요.
콘솔
Google Cloud 콘솔을 사용하여 Google Cloud 서비스 및 API에 액세스할 때는 인증을 설정할 필요가 없습니다.
gcloud
-
Google Cloud CLI를 설치한 후 다음 명령어를 실행하여 초기화합니다.
gcloud init
- 기본 리전 및 영역을 설정합니다.
REST
로컬 개발 환경에서 이 페이지의 REST API 샘플을 사용하려면 gcloud CLI에 제공한 사용자 인증 정보를 사용합니다.
-
가격 책정
애플리케이션 기반 상태 점검을 설정할 때 VM의 상태가 변경될 때마다 Compute Engine은 기본적으로 Cloud Logging에 로그 항목을 작성합니다. Cloud Logging은 데이터 볼륨으로 로깅 가격이 책정되기 전의 월별 무료 할당량을 제공합니다. 비용이 부과되지 않도록 하려면 상태 변경 로그를 사용 중지할 수 있습니다.
애플리케이션 기반 상태 점검 및 자동 복구 설정
MIG에서 애플리케이션 기반 상태 점검 및 자동 복구를 설정하려면 다음을 수행해야 합니다.
- 아직 만들지 않았으면 상태 점검을 만듭니다.
- 상태 점검을 적용하기 위해 MIG에서 자동 복구 정책을 구성합니다.
상태 점검 만들기
MIG 최대 50개에 단일 상태 점검을 적용할 수 있습니다. 그룹이 50개를 초과하면 상태 점검을 여러 개 만듭니다.
다음 예시에서는 자동 복구용 상태 점검을 만드는 방법을 보여줍니다. MIG의 자동 복구를 위해 리전 또는 전역 상태 점검을 만들 수 있습니다. 이 예시에서는 포트 80에서 웹 서버 응답을 찾는 전역 상태 점검을 만듭니다. 상태 점검 프로브를 웹 서버에 연결하려면 방화벽 규칙을 구성합니다.
콘솔
부하 분산 상태 확인보다 보수적인 자동 복구용 상태 확인을 만듭니다.
예를 들어 포트
80에서 응답을 찾고, VM을UNHEALTHY로 표시해 VM이 다시 만들어지도록 하기 전에 일부 오류를 허용할 수 있는 상태 확인을 만듭니다. 이 예시에서는 상태 점검이 성공적으로 한 번 반환하면 VM이 정상으로 표시됩니다. 상태 점검이3회 연속으로 실패하면 VM이 비정상으로 표시됩니다.Google Cloud 콘솔에서 상태 점검 만들기 페이지로 이동합니다.
상태 확인에 이름을 지정합니다(예:
example-check).범위를 선택합니다. 리전 또는 전역을 선택할 수 있습니다. 이 예시에서는 전역을 선택합니다.
프로토콜에 HTTP가 선택되어 있는지 확인합니다.
포트에
80을 입력합니다.상태 기준 섹션에서 다음 값을 제공합니다.
- 확인 간격에
5를 입력합니다. - 제한 시간에
5를 입력합니다. - 정상 기준을 설정하여 비정상 VM이 정상으로 표시되려면 성공적인 상태 확인이 몇 번 연속 반환되어야 하는지 지정합니다. 이 예시에서는
1을 입력합니다. - 비정상 기준을 설정하여 정상 VM이 비정상으로 표시되려면 실패한 상태 확인이 몇 번 연속 반환되어야 하는지 지정합니다. 이 예시에서는
3을 입력합니다.
- 확인 간격에
만들기를 클릭하여 상태 확인을 만듭니다.
방화벽 규칙을 만들어 상태 확인 프로브가 앱에 연결되도록 허용합니다.
상태 확인 프로브가
130.211.0.0/22및35.191.0.0/16범위의 주소에서 전송되므로 네트워크 방화벽 규칙에서 상태 확인 연결을 허용하도록 합니다. 이 예시에서는 MIG에서default네트워크를 사용하고 VM이 포트80에서 리슨합니다. 기본 네트워크에서 포트80이 아직 열려 있지 않으면 방화벽 규칙을 만듭니다.Google Cloud 콘솔에서 방화벽 정책 페이지로 이동합니다.
방화벽 규칙 만들기를 클릭합니다.
방화벽 규칙의 이름을 입력합니다. 예를 들면
allow-health-check입니다.네트워크에서
default네트워크를 선택합니다.타겟에서
All instances in the network를 선택합니다.소스 필터에서
IPv4 ranges를 선택합니다.소스 IPv4 범위에
130.211.0.0/22및35.191.0.0/16을 입력합니다.프로토콜 및 포트에서 지정된 프로토콜 및 포트를 선택하고 다음을 수행합니다.
- TCP를 선택합니다.
- 포트 필드에
80을 입력합니다.
만들기를 클릭합니다.
gcloud
부하 분산 상태 확인보다 보수적인 자동 복구용 상태 확인을 만듭니다.
예를 들어 포트
80에서 응답을 찾고, VM을UNHEALTHY로 표시해 VM이 다시 만들어지도록 하기 전에 일부 오류를 허용할 수 있는 상태 확인을 만듭니다. 이 예시에서는 VM이 성공적으로 한 번 반환하면 정상으로 표시되고,3회 연속으로 반환이 실패하면 VM이 비정상으로 표시됩니다. 다음 명령어는 전역 상태 확인을 만듭니다.gcloud compute health-checks create http example-check --port 80 \ --check-interval 30s \ --healthy-threshold 1 \ --timeout 10s \ --unhealthy-threshold 3 \ --global
방화벽 규칙을 만들어 상태 확인 프로브가 앱에 연결되도록 허용합니다.
상태 확인 프로브가
130.211.0.0/22및35.191.0.0/16범위의 주소에서 전송되므로 방화벽 규칙에서 상태 확인 연결을 허용하도록 합니다. 이 예시에서는 MIG에서default네트워크를 사용하고 VM이 포트80에서 리슨합니다. 기본 네트워크에서 포트80이 아직 열려 있지 않으면 방화벽 규칙을 만듭니다.gcloud compute firewall-rules create allow-health-check \ --allow tcp:80 \ --source-ranges 130.211.0.0/22,35.191.0.0/16 \ --network default
REST
부하 분산 상태 확인보다 보수적인 자동 복구용 상태 확인을 만듭니다.
예를 들어 포트
80에서 응답을 찾고, VM을UNHEALTHY로 표시해 VM이 다시 만들어지도록 하기 전에 일부 오류를 허용할 수 있는 상태 확인을 만듭니다. 이 예시에서는 VM이 성공적으로 한 번 반환하면 정상으로 표시되고,3회 연속으로 반환이 실패하면 VM이 비정상으로 표시됩니다. 다음 요청은 전역 상태 확인을 만듭니다.POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks { "name": "example-check", "type": "http", "port": 80, "checkIntervalSec": 30, "healthyThreshold": 1, "timeoutSec": 10, "unhealthyThreshold": 3 }방화벽 규칙을 만들어 상태 확인 프로브가 앱에 연결되도록 허용합니다.
상태 확인 프로브가
130.211.0.0/22및35.191.0.0/16범위의 주소에서 전송되므로 방화벽 규칙에서 상태 확인 연결을 허용하도록 합니다. 이 예시에서는 MIG에서default네트워크를 사용하고 VM이 포트80에서 리슨합니다. 기본 네트워크에서 포트80이 아직 열려 있지 않으면 방화벽 규칙을 만듭니다.POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls { "name": "allow-health-check", "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default", "sourceRanges": [ "130.211.0.0/22", "35.191.0.0/16" ], "allowed": [ { "ports": [ "80" ], "IPProtocol": "tcp" } ] }여기서
PROJECT_ID를 프로젝트 ID로 바꿉니다.
MIG에서 자동 복구 정책 구성
MIG에서는 자동 복구 정책을 하나만 설정하여 상태 점검을 적용할 수 있습니다.
MIG의 자동 복구를 위해 리전 또는 전역 상태 점검을 사용할 수 있습니다. 리전 상태 점검은 리전 간 종속 항목을 줄이고 데이터 상주를 달성하는 데 도움이 됩니다. 전역 상태 확인은 여러 리전의 MIG에 동일한 상태 확인을 사용하려는 경우에 편리합니다.
자동 복구 정책을 구성하기 전에 다음을 수행하세요.
- 아직 상태 점검이 없으면 하나 만듭니다.
- 새 상태 점검을 설정하는 동안 자동 복구의 거짓 트리거를 방지하려면 먼저 MIG에서 복구를 사용 중지한 후 자동 복구 정책을 구성해야 합니다.
콘솔
Google Cloud 콘솔에서 인스턴스 그룹 페이지로 이동합니다.
목록의 이름 열에서 상태 점검을 적용할 MIG의 이름을 클릭합니다.
수정을 클릭하여 이 MIG를 수정합니다.
VM 인스턴스 수명 주기 섹션의 자동 복구에서 전역 또는 리전 상태 점검을 선택합니다.
초기 지연 설정을 변경하거나 유지합니다.
초기 지연은 새로운 VM이 시작 스크립트를 초기화하고 실행하는 데 걸리는 시간(초)입니다. VM의 초기 지연 기간 동안 MIG는 VM이 시작 프로세스에 있을 수 있으므로 실패한 상태 점검을 무시합니다. 이렇게 하면 MIG가 VM을 조기에 다시 만들 수 없습니다. 초기 지연 중에 상태 점검이 정상 응답을 받으면 시작 프로세스가 완료되고 VM이 준비된 것입니다. 초기 지연 타이머는 VM의
currentAction필드가VERIFYING으로 변경될 때 시작됩니다. 초기 지연 값은 0~3,600초여야 합니다. 콘솔에서 기본값은 300입니다.저장을 클릭하여 변경사항을 적용합니다.
gcloud
기존 MIG에서 자동 복구 정책을 구성하려면 update 명령어를 사용합니다.
예를 들어 다음 명령어를 사용하여 기존 영역 MIG에서 자동 복구 정책을 구성합니다.
gcloud compute instance-groups managed update MIG_NAME \
--health-check HEALTH_CHECK_URL \
--initial-delay INITIAL_DELAY \
--zone ZONE
MIG를 만들 때 자동 복구 정책을 구성하려면 create 명령어를 사용합니다.
예를 들어 영역 MIG를 만들 때 다음 명령어를 사용하여 자동 복구 정책을 구성합니다.
gcloud compute instance-groups managed create MIG_NAME \
--size SIZE \
--template INSTANCE_TEMPLATE_URL \
--health-check HEALTH_CHECK_URL \
--initial-delay INITIAL_DELAY \
--zone ZONE
다음을 바꿉니다.
MIG_NAME: 자동 복구를 설정할 MIG의 이름입니다.SIZE: 그룹의 VM 수입니다.INSTANCE_TEMPLATE_URL: 그룹에서 VM을 만드는 데 사용할 인스턴스 템플릿의 부분 URL입니다. 예를 들면 다음과 같습니다.- 리전 인스턴스 템플릿:
projects/example-project/regions/us-central1/instanceTemplates/example-template - 전역 인스턴스 템플릿:
projects/example-project/global/instanceTemplates/example-template
- 리전 인스턴스 템플릿:
HEALTH_CHECK_URL: 자동 복구를 설정할 상태 점검의 부분 URL입니다. 리전 상태 점검을 사용하려면 리전 상태 점검의 부분 URL을 제공해야 합니다. 예를 들면 다음과 같습니다.- 리전 상태 점검:
projects/example-project/regions/us-central1/healthChecks/example-health-check - 전역 상태 점검:
projects/example-project/global/healthChecks/example-health-check
- 리전 상태 점검:
INITIAL_DELAY: 새로운 VM이 시작 스크립트를 초기화하고 실행하는 데 걸리는 시간(초)입니다. VM의 초기 지연 기간 동안 MIG는 VM이 시작 프로세스에 있을 수 있으므로 실패한 상태 점검을 무시합니다. 이렇게 하면 MIG가 VM을 조기에 다시 만들 수 없습니다. 초기 지연 중에 상태 점검이 정상 응답을 받으면 시작 프로세스가 완료되고 VM이 준비된 것입니다. 초기 지연 타이머는 VM의currentAction필드가VERIFYING으로 변경될 때 시작됩니다. 초기 지연 값은0~3600초여야 합니다. 기본값은0입니다.ZONE: MIG가 있는 영역입니다. 리전 MIG의 경우--region플래그를 사용합니다.
REST
기존 MIG에서 자동 복구 정책을 구성하려면 다음과 같이 patch 메서드를 사용합니다.
- 영역 MIG의 경우
instanceGroupManager.patch메서드를 사용합니다. - 리전 MIG의 경우
regionInstanceGroupManager.patch메서드를 사용합니다.
예를 들어 기존 영역 MIG에서 자동 복구를 설정하려면 다음 호출을 수행합니다.
PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME
{
"autoHealingPolicies": [
{
"healthCheck": "HEALTH_CHECK_URL",
"initialDelaySec": INITIAL_DELAY
}
]
}
MIG를 만들 때 자동 복구 정책을 구성하려면 다음과 같이 insert 메서드를 사용합니다.
- 영역 MIG의 경우
instanceGroupManager.insert메서드를 사용합니다. - 리전 MIG의 경우
regionInstanceGroupManager.insert메서드를 사용합니다.
예를 들어 영역 MIG를 만들 때 자동 복구 정책을 구성하려면 다음 호출을 수행합니다.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers
{
"name": "MIG_NAME",
"targetSize": SIZE,
"instanceTemplate": "INSTANCE_TEMPLATE_URL"
"autoHealingPolicies": [
{
"healthCheck": "HEALTH_CHECK_URL",
"initialDelaySec": INITIAL_DELAY
}
],
}
다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.MIG_NAME: 자동 복구를 설정할 MIG의 이름입니다.SIZE: 그룹의 VM 수입니다.INSTANCE_TEMPLATE_URL: 그룹에서 VM을 만드는 데 사용할 인스턴스 템플릿의 부분 URL입니다. 예를 들면 다음과 같습니다.- 리전 인스턴스 템플릿:
projects/example-project/regions/us-central1/instanceTemplates/example-template - 전역 인스턴스 템플릿:
projects/example-project/global/instanceTemplates/example-template
- 리전 인스턴스 템플릿:
HEALTH_CHECK_URL: 자동 복구를 설정할 상태 점검의 부분 URL입니다. 예를 들면 다음과 같습니다.- 리전 상태 점검:
projects/example-project/regions/us-central1/healthChecks/example-health-check - 전역 상태 점검:
projects/example-project/global/healthChecks/example-health-check
- 리전 상태 점검:
INITIAL_DELAY: 새로운 VM이 시작 스크립트를 초기화하고 실행하는 데 걸리는 시간(초)입니다. VM의 초기 지연 기간 동안 MIG는 VM이 시작 프로세스에 있을 수 있으므로 실패한 상태 점검을 무시합니다. 이렇게 하면 MIG가 VM을 조기에 다시 만들 수 없습니다. 초기 지연 중에 상태 점검이 정상 응답을 받으면 시작 프로세스가 완료되고 VM이 준비된 것입니다. 초기 지연 타이머는 VM의currentAction필드가VERIFYING으로 변경될 때 시작됩니다. 초기 지연 값은0~3600초여야 합니다. 기본값은0입니다.ZONE: MIG가 있는 영역입니다. 리전 MIG의 경우 URL에regions/REGION을 사용합니다.
자동 복구 설정이 완료된 후 자동 복구가 그룹의 VM 모니터링을 시작하는 데 30분 정도 걸릴 수 있습니다. 모니터링이 시작되면 Compute Engine은 자동 복구 구성에 따라 VM을 정상으로 표시하거나 다시 만듭니다. 예를 들어 초기 지연을 5분, 상태 확인 간격을 1분, 정상 기준을 1개로 구성하면 타임라인이 다음과 같게 됩니다.
- 자동 복구에서 그룹의 VM 모니터링을 시작하기까지 지연 시간 30분
- + 구성된 초기 지연 시간 5분
- + 확인 간격 1분 * 정상 기준(60초 * 1)
- = VM이 정상으로 표시되거나 다시 생성되기 36분 전
자동 복구 정책을 구성하기 전에 MIG에서 복구를 사용 중지한 경우 VM 상태를 모니터링하여 상태 점검이 예상대로 작동하는지 확인한 다음 MIG를 VM 복구로 다시 설정합니다.
자동 복구 없이 상태 점검 사용
MIG에서 복구를 사용 중지하여 자동 복구 없이 MIG에 구성된 상태 점검을 사용할 수 있습니다. 이는 애플리케이션 상태 모니터링에만 상태 점검을 사용하거나 상태 점검을 기반으로 자체 복구 로직을 구현하려는 경우에 유용합니다.
MIG를 비정상 VM 복구로 다시 설정하려면 실패 및 비정상 VM을 복구하도록 MIG 설정을 참조하세요.
상태 점검 삭제
다음과 같이 자동 복구 정책에서 구성된 상태 점검을 삭제할 수 있습니다.
콘솔
Google Cloud 콘솔에서 인스턴스 그룹 페이지로 이동합니다.
- 상태 점검을 삭제할 MIG의 이름을 클릭합니다.
- 수정을 클릭하여 이 MIG를 수정합니다.
- VM 인스턴스 수명 주기 섹션의 자동 복구에서 상태 점검 없음을 선택합니다.
- 저장을 클릭하여 변경사항을 적용합니다.
gcloud
자동 복구 정책에서 상태 점검 구성을 삭제하려면 update 명령어에서 다음과 같이 --clear-autohealing 플래그를 사용합니다.
gcloud compute instance-groups managed update MIG_NAME \
--clear-autohealing
MIG_NAME을 MIG의 이름으로 바꿉니다.
REST
자동 복구 정책에서 상태 점검 구성을 삭제하려면 자동 복구 정책을 빈 값으로 설정합니다.
- 영역 MIG의 경우
instanceGroupManagers.patch메서드를 사용합니다. - 리전 MIG의 경우
regionInstanceGroupManagers.patch메서드를 사용합니다.
예를 들어 영역 MIG에서 상태 점검을 제거하려면 다음 요청을 수행합니다.
PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME
{
"autoHealingPolicies": [
{}
]
}
다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.MIG_NAME: 자동 복구를 설정할 MIG의 이름입니다.ZONE: MIG가 있는 영역입니다. 리전 MIG의 경우regions/REGION을 사용합니다.
MIG에서 자동 복구 정책 보기
MIG의 자동 복구 정책은 다음과 같이 볼 수 있습니다.
콘솔
Google Cloud 콘솔에서 인스턴스 그룹 페이지로 이동합니다.
자동 복구 정책을 보려는 MIG의 이름을 클릭합니다.
세부정보 탭으로 이동합니다.
VM 인스턴스 수명 주기 섹션의 자동 복구 필드에는 상태 점검과 자동 복구 정책에서 구성된 초기 지연이 표시됩니다.
gcloud
MIG에서 자동 복구 정책을 보려면 다음 명령어를 사용합니다.
gcloud compute instance-groups managed describe MIG_NAME \
--format="(autoHealingPolicies)"
MIG_NAME을 MIG의 이름으로 바꿉니다.
다음은 샘플 출력입니다.
autoHealingPolicies: healthCheck: https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check initialDelaySec: 300
REST
MIG에서 자동 복구 정책을 보려면 다음과 같이 REST 메서드를 사용합니다.
- 영역 MIG의 경우
instanceGroupManagers.get메서드를 사용합니다. - 리전 MIG의 경우
regionInstanceGroupManagers.get메서드를 사용합니다.
예를 들어 영역 MIG에서 자동 복구 정책을 보려면 다음 요청을 수행합니다.
GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME
응답 본문에서 autoHealingPolicies[] 객체를 확인합니다.
다음은 샘플 응답입니다.
{
...
"autoHealingPolicies": [
{
"healthCheck": "https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check",
"initialDelaySec": 300
}
],
...
}
다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.MIG_NAME: 자동 복구를 설정할 MIG의 이름입니다.ZONE: MIG가 있는 영역입니다. 리전 MIG의 경우regions/REGION을 사용합니다.
상태 파악
MIG에서 애플리케이션 기반 상태 점검을 설정한 후에는 다음 방법을 사용하여 VM이 실행 중이고 애플리케이션이 응답하는지 확인할 수 있습니다.
VM이 정상인지 확인
MIG에 애플리케이션 기반 상태 점검을 구성한 경우 각 관리형 인스턴스의 상태를 검토할 수 있습니다.
관리형 인스턴스 상태를 검사하여 다음을 수행합니다.
- 복구되지 않는 비정상적인 VM을 확인합니다. VM이 다음 상황에서 비정상으로 진단되더라도 즉시 복구되지 않을 수 있습니다.
- VM이 여전히 부팅 중이며 초기 지연이 지나지 않았습니다.
- 비정상 인스턴스의 상당 부분이 복구되는 중입니다. MIG는 그룹이 인스턴스의 하위 집합을 계속 실행하도록 추가 자동 복구를 지연시킵니다.
- 상태 확인 구성 오류를 감지합니다. 예를 들어 인스턴스가 상태를
TIMEOUT으로 보고하는 경우 잘못 구성된 방화벽 규칙 또는 유효하지 않은 애플리케이션 상태 확인 엔드포인트를 감지할 수 있습니다. - VM이
RUNNING상태로 전환되는 시점과 VM이HEALTHY상태로 전환되는 시점 사이의 시간을 측정하여 구성할 초기 지연 값을 확인합니다.list-instances메서드를 폴링하거나instances.insert작업과 첫 번째 정상 신호를 수신한 시간 사이의 시간을 관찰하여 이 간격을 측정할 수 있습니다.
콘솔, gcloud 명령줄 도구 또는 REST 사용하여 상태를 확인합니다.
콘솔
Google Cloud Console에서 인스턴스 그룹 페이지로 이동합니다.
목록의 이름 열에서 검토할 MIG의 이름을 클릭합니다. 인스턴스 그룹 속성과 그룹에 포함된 VM의 목록이 표시된 페이지가 열립니다.
VM이 비정상 상태이면 상태 확인 상태 열에서 상태를 확인할 수 있습니다.
gcloud
list-instances 하위 명령어를 사용합니다.
gcloud compute instance-groups managed list-instances instance-group
NAME ZONE STATUS HEALTH_STATE ACTION INSTANCE_TEMPLATE VERSION_NAME LAST_ERROR
igm-with-hc-fvz6 europe-west1 RUNNING HEALTHY NONE my-template
igm-with-hc-gtz3 europe-west1 RUNNING HEALTHY NONE my-template
HEALTH_STATE 열은 각 VM의 상태를 보여줍니다.
REST
리전 MIG의 경우 listManagedInstances 메서드에 대한 POST 요청을 작성합니다.
POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group/listManagedInstances
영역 MIG의 경우 영역 MIG listManagedInstances 메서드를 사용합니다.
POST https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group/listManagedInstances
요청은 각 관리형 인스턴스에 대한 instanceHealth 필드를 포함하여 다음과 비슷한 응답을 반환합니다.
{
"managedInstances": [
{
"instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-5485",
"instanceStatus": "RUNNING",
"currentAction": "NONE",
"lastAttempt": {
},
"id": "6159431761228150698",
"instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template",
"version": {
"instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template"
},
"instanceHealth": [
{
"healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
"detailedHealthState": "HEALTHY"
}
]
},
{
"instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-sfdp",
"instanceStatus": "STOPPING",
"currentAction": "DELETING",
"lastAttempt": {
},
"id": "6622324799312181783",
"instanceHealth": [
{
"healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
"detailedHealthState": "TIMEOUT"
}
]
}
]
}
상태
다음과 같은 VM 상태를 사용할 수 있습니다.
HEALTHY: VM에 연결할 수 있고, 애플리케이션 상태 확인 엔드포인트에 대한 연결을 설정할 수 있으며, 응답은 상태 확인에 정의된 요구 사항을 준수합니다.DRAINING: VM이 드레이닝되고 있습니다. VM에 대한 기존 연결은 완료되지만 새 연결은 거부됩니다.UNHEALTHY: VM에 연결할 수 있지만 상태 확인에서 정의된 요구 사항을 준수하지 않습니다.TIMEOUT: VM에 연결할 수 없거나, 애플리케이션 상태 확인 엔드포인트에 대한 연결을 설정할 수 없거나, VM의 서버가 지정된 제한 시간 내에 응답하지 않습니다. 예를 들어 방화벽 규칙이 잘못 구성되어 있거나 VM의 서버 애플리케이션 과부하로 인한 것일 수 있습니다.UNKNOWN: 상태 점검 시스템이 VM을 인식하지 못하거나 현재 VM의 상태를 알 수 없습니다. MIG의 새 VM에서 모니터링을 시작하는 데 30분 정도 걸릴 수 있습니다.
새 VM은 상태 확인 시스템에 의해 확인될 때까지 UNHEALTHY 상태를 반환합니다.
VM의 복구 여부는 다음과 같이 상태에 따라 다릅니다.
- VM의 상태가
UNHEALTHY또는TIMEOUT이고 초기화 기간이 지난 경우 MIG는 즉시 복구를 시도합니다. - VM의 상태가
UNKNOWN이면 MIG가 즉시 복구하지 않습니다. 이는 상태 점검 신호를 일시적으로 사용할 수 없는 VM의 불필요한 복구를 방지하기 위한 것입니다.
자동 복구 시도는 다음과 같은 경우에 지연될 수 있습니다.
- 여러 번 연속적으로 복구한 후에도 VM이 비정상 상태로 남아 있습니다.
- 그룹의 VM 중 상당수가 비정상 상태입니다.
VM 상태 값에 대한 사용 사례, 문제 또는 의견에 대해 알고 싶습니다. mig-discuss@google.com으로 저희 팀에 의견을 공유해 주세요.
VM에서 현재 작업 확인
MIG가 VM 인스턴스를 만드는 중일 때 MIG는 인스턴스의 읽기 전용 currentAction 필드를 CREATING으로 설정합니다. 자동 복구 정책이 그룹에 연결된 경우, VM을 만들고 실행하면 MIG가 인스턴스의 현재 작업을 VERIFYING으로 설정하고 상태 점검기가 VM 애플리케이션 프로브를 시작합니다. 애플리케이션을 시작하는 데 걸리는 시간 내에 애플리케이션에서 이 초기 상태 확인에 성공하면 VM이 확인되고 MIG가 VM의 currentAction 필드를 NONE으로 설정합니다.
VM에서 현재 작업을 확인하려면 VM에서 현재 작업 보기를 참조하세요.
MIG가 안정적인지 확인
그룹 수준에서 Compute Engine은 isStable 플래그가 포함된 status라는 읽기 전용 필드를 채웁니다.
그룹의 모든 VM이 실행되고 있고 정상 상태이면(즉, 각 관리형 인스턴스의 currentAction 필드가 NONE으로 설정됨), MIG가 status.isStable 필드를 true로 설정합니다. MIG의 안정성은 자동 복구 정책 이외의 그룹 구성에 따라 달라집니다. 예를 들어 그룹이 자동 확장되며 수평 축소 또는 수평 확장이 진행 중인 경우 자동 확장 처리 작업으로 인해 MIG가 status.isStable 필드를 false로 설정합니다.
MIG의 status.isStable 필드 값을 확인하려면 MIG가 안정적인지 확인을 참조하세요.
이전 자동 복구 작업 보기
gcloud CLI 또는 REST를 사용하여 이전 자동 복구 이벤트를 볼 수 있습니다.
gcloud
gcloud compute operations list 명령어를 필터와 함께 사용하면 프로젝트의 자동 복구 이벤트만 볼 수 있습니다.
gcloud compute operations list --filter='operationType~compute.instances.repair.*'
특정 복구 작업에 대한 자세한 내용을 알아보려면 describe 명령어를 사용합니다. 예를 들면 다음과 같습니다.
gcloud compute operations describe repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5 --zone us-east1-b
REST
리전 MIG의 경우 regionOperations 리소스에 GET 요청을 제출하고 출력 목록을 compute.instances.repair.* 이벤트로 범위를 지정하는 필터를 포함합니다.
GET https://compute.googleapis.com/compute/v1/projects/project-id/region/region/operations?filter=operationType+%3D+%22compute.instances.repair.*%22
영역 MIG의 경우 zoneOperations 리소스를 사용합니다.
GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations?filter=operationType+%3D+%22compute.instances.repair.*%22
특정 복구 작업에 대한 자세한 내용을 보려면 특정 작업에 대한 GET 요청을 제출하세요. 예를 들면 다음과 같습니다.
GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5
유용한 자동 복구 상태 확인의 핵심 기능
자동 복구에 사용되는 상태 확인은 인스턴스를 사전에 삭제하고 다시 만들지 않도록 보수적이어야 합니다. 자동 복구 상태 확인이 지나치게 공격적인 경우 자동 복구 기능은 사용량이 많은 인스턴스를 실패한 인스턴스로 오인하고 불필요하게 다시 시작하여 가용성을 저하시킬 수 있습니다.
unhealthy-threshold:1보다 커야 합니다. 이 값을3이상으로 설정하는 것이 좋습니다. 이렇게 하면 네트워크 패킷 손실과 같이 드물게 발생하는 실패로부터 보호됩니다.healthy-threshold: 대부분의 앱에서 값이2면 충분합니다.timeout: 이 시간 값은 넉넉하게 설정합니다(예상되는 응답 시간의 5배 이상). 이렇게 하면 사용량이 많은 인스턴스 또는 느린 네트워크 연결과 같은 예상치 못한 지연으로부터 보호됩니다.check-interval: 이 값은 1초와 제한 시간 두 배 사이여야 합니다(너무 길지도, 너무 짧지도 않은 시간). 값이 너무 길면 실패한 인스턴스가 신속하게 포착되지 않습니다. 값이 너무 짧으면 매 초 전송되는 많은 수의 상태 확인 프로브로 인해 인스턴스와 네트워크의 사용량이 과도하게 많은 것으로 측정될 수 있습니다.