애플리케이션 기반 상태 점검 및 자동 복구 설정

이 문서에서는 관리형 인스턴스 그룹(MIG)에서 VM을 자동 복구하도록 애플리케이션 기반 상태 점검을 설정하는 방법을 설명합니다. 또한 자동 복구 없이 상태 점검을 사용하고, 상태 점검을 삭제하고, 자동 복구 정책을 보고, 각 VM의 상태를 확인하는 방법을 설명합니다.

애플리케이션 기반 상태 점검을 구성하여 VM의 애플리케이션이 예상대로 응답하는지 확인할 수 있습니다. 구성한 상태 점검에서 VM의 애플리케이션이 응답하지 않는 것으로 확인되면 MIG는 VM을 비정상으로 표시하고 복구합니다. 애플리케이션 기반 상태 점검을 기반으로 VM을 복구하는 것을 자동 복구라고 합니다.

자동 복구를 트리거하지 않고 상태 점검을 사용할 수 있도록 MIG에서 복구를 사용 중지할 수도 있습니다.

MIG에서의 복구에 대한 자세한 내용은 고가용성을 위한 VM 복구 정보를 참조하세요.

시작하기 전에

아직 인증을 설정하지 않았다면 설정합니다. 인증은 Google Cloud 서비스 및 API에 액세스하기 위해 ID를 확인하는 프로세스입니다. 로컬 개발 환경에서 코드 또는 샘플을 실행하려면 다음과 같이 Compute Engine에 인증하면 됩니다.

Select the tab for how you plan to use the samples on this page:
Console

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
1. Install the Google Cloud CLI, then initialize it by running the following command:
  gcloud init
  Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
2. Set a default region and zone.

가격 책정

애플리케이션 기반 상태 점검을 설정할 때 VM의 상태가 변경될 때마다 Compute Engine은 기본적으로 Cloud Logging에 로그 항목을 작성합니다. Cloud Logging은 데이터 볼륨으로 로깅 가격이 책정되기 전의 월별 무료 할당량을 제공합니다. 비용이 부과되지 않도록 하려면 상태 변경 로그를 사용 중지할 수 있습니다.

애플리케이션 기반 상태 점검 및 자동 복구 설정

MIG에서 애플리케이션 기반 상태 점검 및 자동 복구를 설정하려면 다음을 수행해야 합니다.

아직 만들지 않았으면 상태 점검을 만듭니다.
상태 점검을 적용하기 위해 MIG에서 자동 복구 정책을 구성합니다.

상태 점검 만들기

MIG 최대 50개에 단일 상태 점검을 적용할 수 있습니다. 그룹이 50개를 초과하면 상태 점검을 여러 개 만듭니다.

다음 예시에서는 자동 복구용 상태 점검을 만드는 방법을 보여줍니다. MIG의 자동 복구를 위해 리전 또는 전역 상태 점검을 만들 수 있습니다. 이 예시에서는 포트 80에서 웹 서버 응답을 찾는 전역 상태 점검을 만듭니다. 상태 점검 프로브를 웹 서버에 연결하려면 방화벽 규칙을 구성합니다.

이 태스크에 필요한 권한

이 태스크를 수행하려면 다음과 같은 권한이 있어야 합니다.

상태 점검을 만드는 경우 프로젝트에 대한 compute.healthChecks.create 권한
사용하려는 상태 확인에 대한 compute.healthChecks.use 권한
방화벽을 만드는 경우 프로젝트에 대한 compute.firewalls.create 권한
방화벽을 만드는 경우 네트워크에 대한 compute.networks.updatePolicy 권한

이러한 권한은 사전 구성된 다음 역할에서 사용할 수 있습니다.

상태 확인 생성을 위한 compute.networkAdmin 역할
방화벽 규칙을 구성하여 상태 확인을 연결하기 위한 compute.securityAdmin 역할

콘솔

부하 분산 상태 확인보다 보수적인 자동 복구용 상태 확인을 만듭니다.

예를 들어 포트 80에서 응답을 찾고, VM을 UNHEALTHY로 표시해 VM이 다시 만들어지도록 하기 전에 일부 오류를 허용할 수 있는 상태 확인을 만듭니다. 이 예시에서는 상태 점검이 성공적으로 한 번 반환하면 VM이 정상으로 표시됩니다. 상태 점검이 3회 연속으로 실패하면 VM이 비정상으로 표시됩니다.
1. Google Cloud 콘솔에서 상태 점검 만들기 페이지로 이동합니다.
  
  상태 확인 만들기로 이동
2. 상태 확인에 이름을 지정합니다(예: example-check).
3. 범위를 선택합니다. 리전 또는 전역을 선택할 수 있습니다. 이 예시에서는 전역을 선택합니다.
4. 프로토콜에 HTTP가 선택되어 있는지 확인합니다.
5. 포트에 80을 입력합니다.
6. 상태 기준 섹션에 다음 값을 입력합니다.
  1. 확인 간격에 5를 입력합니다.
  2. 제한 시간에 5를 입력합니다.
  3. 정상 기준을 설정하여 비정상 VM이 정상으로 표시되려면 성공적인 상태 확인이 몇 번 연속 반환되어야 하는지 지정합니다. 이 예시에서는 1을 입력합니다.
  4. 비정상 기준을 설정하여 정상 VM이 비정상으로 표시되려면 실패한 상태 확인이 몇 번 연속 반환되어야 하는지 지정합니다. 이 예시에서는 3을 입력합니다.
7. 만들기를 클릭하여 상태 확인을 만듭니다.
방화벽 규칙을 만들어 상태 확인 프로브가 앱에 연결되도록 허용합니다.

주의: 방화벽 규칙에 의해 차단된 상태 확인 프로브는 앱에 연결될 수 없으므로 VM을 UNHEALTHY로 표시합니다. 이로 인해 정상일 수 있는 VM이 자동으로 다시 생성될 수 있습니다.

상태 점검 프로브가 130.211.0.0/22 및 35.191.0.0/16 범위의 주소에서 전송되므로 네트워크 방화벽 규칙에서 상태 점검 연결을 허용하도록 합니다. 이 예시에서는 MIG에서 default 네트워크를 사용하고 VM이 포트 80에서 리슨합니다. 기본 네트워크에서 포트 80이 아직 열려 있지 않으면 방화벽 규칙을 만듭니다.
1. Google Cloud 콘솔에서 방화벽 정책 페이지로 이동합니다.
  
  방화벽 정책으로 이동
2. 방화벽 규칙 만들기를 클릭합니다.
3. 방화벽 규칙의 이름을 입력합니다. 예를 들면 allow-health-check입니다.
4. 네트워크에서 default 네트워크를 선택합니다.
5. 타겟에서 All instances in the network를 선택합니다.
6. 소스 필터에서 IPv4 ranges를 선택합니다.
7. 소스 IPv4 범위에 130.211.0.0/22 및 35.191.0.0/16을 입력합니다.
8. 프로토콜 및 포트에서 지정된 프로토콜 및 포트를 선택하고 다음을 수행합니다.
  1. TCP를 선택합니다.
  2. 포트 필드에 80을 입력합니다.
9. 만들기를 클릭합니다.

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
```
참고: HTTP, HTTPS, TCP, SSL(TLS) 프로토콜을 지원하는 최신 상태 점검을 사용합니다. 기존 Compute Engine HTTP/HTTPS 상태 점검은 계속 작동합니다.
방화벽 규칙을 만들어 상태 확인 프로브가 앱에 연결되도록 허용합니다.
주의: 방화벽 규칙에 의해 차단된 상태 점검 프로브는 앱에 연결될 수 없으므로 VM을 UNHEALTHY로 표시합니다. 이로 인해 정상일 수 있는 VM이 자동으로 다시 생성될 수 있습니다.
상태 점검 프로브가 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
```

Terraform

google_compute_http_health_check 리소스를 사용하여 상태 점검을 만듭니다.

예를 들어 포트 80에서 응답을 찾고, VM을 UNHEALTHY로 표시해 VM이 다시 만들어지도록 하기 전에 일부 오류를 허용할 수 있는 상태 확인을 만듭니다. 이 예시에서는 VM이 성공적으로 한 번 반환하면 정상으로 표시되고, 3회 연속으로 반환이 실패하면 VM이 비정상으로 표시됩니다. 다음 요청은 전역 상태 점검을 만듭니다.
```
resource "google_compute_http_health_check" "default" {
  name                = "example-check"
  timeout_sec         = 10
  check_interval_sec  = 30
  healthy_threshold   = 1
  unhealthy_threshold = 3
  port                = 80
}
```
google_compute_firewall 리소스를 사용하여 방화벽을 만듭니다.
주의: 방화벽 규칙에 의해 차단된 상태 점검 프로브는 앱에 연결될 수 없으므로 VM을 UNHEALTHY로 표시합니다. 이로 인해 정상일 수 있는 VM이 자동으로 다시 생성될 수 있습니다.
상태 점검 프로브가 130.211.0.0/22 및 35.191.0.0/16 범위의 주소에서 전송되므로 방화벽 규칙에서 상태 점검 연결을 허용하도록 합니다. 이 예시에서는 MIG에서 default 네트워크를 사용하고 VM이 포트 80에서 리슨합니다. 기본 네트워크에서 포트 80이 아직 열려 있지 않으면 방화벽 규칙을 만듭니다.
```
resource "google_compute_firewall" "default" {
  name          = "allow-health-check"
  network       = "default"
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16"]
  allow {
    protocol = "tcp"
    ports    = [80]
  }
}
```

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

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
}
```
참고: HTTP, HTTPS, TCP, SSL(TLS) 프로토콜을 지원하는 최신 상태 점검을 사용합니다. 기존 Compute Engine HTTP/HTTPS 상태 점검은 계속 작동합니다.
방화벽 규칙을 만들어 상태 확인 프로브가 앱에 연결되도록 허용합니다.
주의: 방화벽 규칙에 의해 차단된 상태 점검 프로브는 앱에 연결될 수 없으므로 VM을 UNHEALTHY로 표시합니다. 이로 인해 정상일 수 있는 VM이 자동으로 다시 생성될 수 있습니다.
상태 점검 프로브가 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에서 복구를 사용 중지한 후 자동 복구 정책을 구성해야 합니다.

이 태스크에 필요한 권한

이 태스크를 수행하려면 다음과 같은 권한이 있어야 합니다.

MIG에 대한 compute.instanceGroupManagers.update 권한

이러한 권한은 사전 구성된 다음 역할에서 사용할 수 있습니다.

MIG에서 자동 복구 정책을 만들고 업데이트하기 위한 compute.instanceAdmin.v1 역할

콘솔

Google Cloud 콘솔에서 인스턴스 그룹 페이지로 이동합니다.

인스턴스 그룹으로 이동
목록의 이름 열에서 상태 점검을 적용할 MIG의 이름을 클릭합니다.
수정을 클릭하여 이 MIG를 수정합니다.
VM 인스턴스 수명 주기 섹션의 자동 복구에서 전역 또는 리전 상태 점검을 선택합니다.
초기 지연 설정을 변경하거나 유지합니다.

초기 지연은 새로운 VM이 시작 스크립트를 초기화하고 실행하는 데 걸리는 시간(초)입니다. VM의 초기 지연 기간 동안 MIG는 VM이 시작 프로세스에 있을 수 있으므로 실패한 상태 점검을 무시합니다. 이렇게 하면 MIG가 VM을 조기에 다시 만들 수 없습니다. 초기 지연 중에 상태 점검이 정상 응답을 받으면 시작 프로세스가 완료되고 VM이 준비된 것입니다. 초기 지연 타이머는 VM의 currentAction 필드가 VERIFYING으로 변경될 때 시작됩니다. 초기 지연 값은 0~3600초 사이여야 합니다. 콘솔에서 기본값은 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 플래그를 사용합니다.

Terraform

MIG에서 자동 복구 정책을 구성하려면 auto_healing_policies 블록을 사용합니다.

다음 샘플은 영역 MIG에서 자동 복구 정책을 구성합니다. 샘플에 사용된 리소스에 관한 자세한 내용은 google_compute_instance_group_manager를 참조하세요. 리전 MIG의 경우 google_compute_region_instance_group_manager 리소스를 사용합니다.

resource "google_compute_instance_group_manager" "default" {
  name               = "igm-with-hc"
  base_instance_name = "test"
  target_size        = 3
  zone               = "us-central1-f"
  version {
    instance_template = google_compute_instance_template.default.id
    name              = "primary"
  }
  auto_healing_policies {
    health_check      = google_compute_http_health_check.default.id
    initial_delay_sec = 30
  }
}

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

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 모니터링을 시작하는 데 10분 정도 걸릴 수 있습니다. 모니터링이 시작되면 Compute Engine은 자동 복구 구성에 따라 VM을 정상으로 표시하거나 다시 만듭니다. 예를 들어 초기 지연을 5분, 상태 확인 간격을 1분, 정상 기준을 1개로 구성하면 타임라인이 다음과 같게 됩니다.

자동 복구에서 그룹의 VM 모니터링을 시작하기까지 지연 시간 10분
+ 구성된 초기 지연 시간 5분
+ 확인 간격 1분 * 정상 기준(60초 * 1)
= VM이 정상으로 표시되거나 다시 생성되기 16분 전

자동 복구 정책을 구성하기 전에 MIG에서 복구를 사용 중지한 경우 VM 상태를 모니터링하여 상태 점검이 예상대로 작동하는지 확인한 다음 MIG를 VM 복구로 다시 설정합니다.

자동 복구 없이 상태 점검 사용

MIG에서 복구를 사용 중지하여 자동 복구 없이 MIG에 구성된 상태 점검을 사용할 수 있습니다. 이는 애플리케이션 상태 모니터링에만 상태 점검을 사용하거나 상태 점검을 기반으로 자체 복구 로직을 구현하려는 경우에 유용합니다.

비정상 VM을 복구하도록 MIG를 다시 설정하려면 실패 및 비정상 VM을 복구하도록 MIG 설정을 참조하세요.

상태 점검 삭제

다음과 같이 자동 복구 정책에서 구성된 상태 점검을 삭제할 수 있습니다.

콘솔

Google Cloud 콘솔에서 인스턴스 그룹 페이지로 이동합니다.

인스턴스 그룹으로 이동
1. 상태 점검을 삭제할 MIG의 이름을 클릭합니다.
2. 수정을 클릭하여 이 MIG를 수정합니다.
3. VM 인스턴스 수명 주기 섹션의 자동 복구에서 상태 점검 없음을 선택합니다.
4. 저장을 클릭하여 변경사항을 적용합니다.

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이 정상인지 확인
VM에서 현재 작업 확인
MIG가 안정적인지 확인

VM이 정상인지 확인

MIG에 애플리케이션 기반 상태 점검을 구성한 경우 각 관리형 인스턴스의 상태를 검토할 수 있습니다.

관리형 인스턴스 상태를 검사하여 다음을 수행합니다.

복구되지 않는 비정상적인 VM을 확인합니다. VM이 다음 상황에서 비정상으로 진단되더라도 즉시 복구되지 않을 수 있습니다.
- VM이 여전히 부팅 중이며 초기 지연이 지나지 않았습니다.
- 비정상 인스턴스의 상당 부분을 복구하는 중입니다. MIG는 그룹이 인스턴스의 하위 집합을 계속 실행하도록 추가 자동 복구를 지연시킵니다.
상태 확인 구성 오류를 감지합니다. 예를 들어 인스턴스가 상태를 TIMEOUT으로 보고하는 경우 잘못 구성된 방화벽 규칙 또는 유효하지 않은 애플리케이션 상태 확인 엔드포인트를 감지할 수 있습니다.
VM이 RUNNING 상태로 전환되는 시점과 VM이 HEALTHY 상태로 전환되는 시점 사이의 시간을 측정하여 구성할 초기 지연 값을 확인합니다. list-instances 메서드를 폴링하거나 instances.insert 작업과 첫 번째 정상 신호를 수신한 시간 사이의 시간을 관찰하여 이 간격을 측정할 수 있습니다.

콘솔, gcloud 명령줄 도구 또는 REST 사용하여 상태를 확인합니다.

이 태스크에 필요한 권한

이 태스크를 수행하려면 다음과 같은 권한이 있어야 합니다.

MIG에 대한 compute.instanceGroupManagers.get 권한

콘솔

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에서 모니터링을 시작하는 데 10분 정도 걸릴 수 있습니다.

새 VM은 상태 확인 시스템에 의해 확인될 때까지 UNHEALTHY 상태를 반환합니다.

VM의 복구 여부는 다음과 같이 상태에 따라 다릅니다.

VM의 상태가 UNHEALTHY 또는 TIMEOUT이고 초기화 기간이 지난 경우 MIG는 즉시 복구를 시도합니다.
VM의 상태가 UNKNOWN인 경우 MIG는 이를 즉시 복구하지 않습니다. 이는 상태 점검 신호를 일시적으로 사용할 수 없는 VM의 불필요한 복구를 방지하기 위한 것입니다.

자동 복구 시도는 다음과 같은 경우에 지연될 수 있습니다.

여러 번 연속적으로 복구한 후에도 VM이 비정상 상태로 남아 있습니다.
그룹의 VM 중 상당수가 비정상 상태입니다.

VM 상태 값에 대한 사용 사례, 문제 또는 의견에 대해 알고 싶습니다. Google팀(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초와 제한 시간 두 배 사이여야 합니다(너무 길지도, 너무 짧지도 않은 시간). 값이 너무 길면 실패한 인스턴스가 신속하게 포착되지 않습니다. 값이 너무 짧으면 매 초 전송되는 많은 수의 상태 확인 프로브로 인해 인스턴스와 네트워크의 사용량이 과도하게 많은 것으로 측정될 수 있습니다.

애플리케이션 기반 상태 점검 및 자동 복구 설정

시작하기 전에

Console

gcloud

Terraform

REST

가격 책정

애플리케이션 기반 상태 점검 및 자동 복구 설정

상태 점검 만들기

이 태스크에 필요한 권한

콘솔

gcloud

Terraform

REST

MIG의 자동 복구 정책 구성

이 태스크에 필요한 권한

콘솔

gcloud

Terraform

REST

자동 복구 없이 상태 점검 사용

상태 점검 삭제

콘솔

gcloud

REST

MIG의 자동 복구 정책 보기

콘솔

gcloud

REST

상태 파악

VM이 정상인지 확인

이 태스크에 필요한 권한

콘솔

gcloud

REST

상태

VM에서 현재 작업 확인

MIG가 안정적인지 확인

이전 자동 복구 작업 보기

gcloud

REST

유용한 자동 복구 상태 확인의 핵심 기능

다음 단계