상태 확인 및 자동 복구 설정

관리형 인스턴스 그룹(MIG)은 사전에 가상 머신(VM) 인스턴스를 사용할 수 있도록, 즉 RUNNING 상태로 유지하여 애플리케이션의 고가용성을 보장합니다. 관리형 인스턴스가 실행을 중지했지만 MIG에서 상태 변경을 시작하지 않았으면 MIG는 자동으로 인스턴스를 다시 만듭니다. 반면에 MIG가 의도적으로 RUNNING에서 인스턴스를 중지하면(예: 자동 확장 처리가 인스턴스를 삭제하는 경우) 인스턴스를 다시 만들지 않습니다.

MIG에서 시작하지 않는 인스턴스 상태 변경사항은 다음과 같습니다.

하지만 인스턴스 상태를 사용하여 애플리케이션 상태를 결정하는 것은 충분하지 않을 수 있습니다. 예를 들어 인스턴스가 RUNNING인지 여부를 확인해도 정지, 과부하 또는 비정상 종료와 같은 애플리케이션 장애를 감지할 수 없습니다.

애플리케이션 가용성을 향상시키고 애플리케이션이 응답하는지 확인하려면 MIG에 자동 복구 정책을 구성하면 됩니다.

자동 복구 정책은 애플리케이션 기반 상태 확인을 사용하여 애플리케이션이 예상대로 응답하는지 확인합니다. 단순히 VM이 RUNNING 상태인지 확인하는 것보다 애플리케이션이 응답하는지 확인하는 것이 더욱 정확합니다.

자동 복구에서 애플리케이션이 응답하지 않는 것으로 확인되면 MIG는 VM을 자동으로 다시 만듭니다. 선점형 VM의 경우 필요한 리소스를 다시 사용할 수 있게 되면 그룹이 VM을 다시 만듭니다.

자동 복구 동작

자동 복구는 VM을 만드는 데 사용했던 원래 인스턴스 템플릿을 사용하여 비정상 VM을 다시 만듭니다. 이때 사용되는 템플릿은 MIG의 현재 인스턴스 템플릿이 아닐 수도 있습니다. 예를 들어 instance-template-a를 사용하여 VM을 만들었지만 MIG를 업데이트하여 OPPORTUNISTIC 모드에서 instance-template-b를 사용하더라도 자동 복구는 여전히 instance-template-a를 사용하여 VM을 다시 만듭니다. 이는 자동 복구로 VM을 다시 만드는 것이 사용자가 시작하는 작업이 아니므로 Compute Engine에서 VM에 새 템플릿을 사용해야 한다고 가정하지 않기 때문입니다. 새 템플릿을 적용하려면 MIG용 인스턴스 템플릿 변경을 참조하세요.

동시에 자동 복구된 VM의 수는 항상 MIG 크기보다 적습니다. 그래야만 자동 복구 정책이 워크로드에 적합하지 않거나, 방화벽 규칙이 잘못 구성되었거나, 네트워크 연결이나 인프라에 문제가 있어서 정상적인 VM이 비정상으로 잘못 식별되더라도 그룹에서 VM의 하위 집합을 계속 실행할 수 있기 때문입니다. 그러나 영역 MIG에 VM이 한 개만 있거나 리전 MIG에 영역당 VM이 한 개만 있는 경우 VM이 비정상 상태가 되면 자동 복구에서 VM을 다시 만듭니다.

VM 초기화 기간 동안에는 자동 복구에서 VM을 다시 만들지 않습니다. 자세한 내용은 autoHealingPolicies[].initialDelaySec 속성을 참조하세요. 이 설정은 VM을 시작하는 중에 점검하고 조기에 다시 만들지 않도록 자동 복구를 지연시킵니다. VM의 VERIFYINGcurrentAction이면 초기 지연 타이머가 시작됩니다.

관리형 인스턴스 그룹에 상태 확인을 처음 연결하면 모니터링을 시작할 때까지 30분 정도 걸릴 수 있습니다.

자동 복구와 디스크

템플릿을 기준으로 VM을 다시 만들 때는 디스크 유형에 따라 자동 복구 기능이 처리하는 방법도 다릅니다. 일부 디스크 구성에서는 VM을 다시 만들려고 할 때 자동 복구 기능이 작동하지 않을 수도 있습니다.

디스크 유형 autodelete 자동 복구 작업 중 동작
새로운 영구 디스크 true 인스턴스 템플릿에 지정되어 있는 대로 디스크를 다시 만듭니다. 디스크와 VM을 다시 만들면 디스크에 기록되었던 모든 데이터가 손실됩니다.
새로운 영구 디스크 false 디스크가 보존되어 자동 복구 기능으로 VM을 다시 만들 때 다시 연결됩니다.
기존 영구 디스크 true 이전 디스크가 삭제됩니다. Compute Engine이 삭제된 디스크를 VM에 다시 연결할 수 없으므로 VM을 다시 만들지 못합니다.
기존 영구 디스크 false 이전 디스크가 인스턴스의 템플릿에 지정되어 있는 대로 다시 연결됩니다. 디스크의 데이터도 보존됩니다. 하지만 기존 읽기/쓰기 디스크의 경우 단일 영구 디스크가 읽기/쓰기 모드에서 여러 VM에 연결될 수 없으므로 MIG에는 VM 한 개만 있을 수 있습니다.
새로운 로컬 SSD 해당 사항 없음 인스턴스 템플릿에 지정되어 있는 대로 디스크를 다시 만듭니다. VM을 다시 만들거나 삭제하면 로컬 SSD의 데이터가 손실됩니다.

자동 복구 시 VM을 만든 후 VM에 수동으로 연결한 디스크와 같이 인스턴스 템플릿에 지정되지 않은 디스크는 다시 연결되지 않습니다.

따라서 디스크에 작성된 중요 데이터를 보존하려면 다음과 같은 주의사항을 따라야 합니다.

VM에 보존하려는 중요한 설정이 있으면 인스턴스 템플릿에 커스텀 이미지를 사용하는 것이 좋습니다. 커스텀 이미지에는 필요한 모든 커스텀 설정이 포함되어 있습니다. 인스턴스 템플릿에 커스텀 이미지를 지정하면 MIG에서 필요한 커스텀 설정이 포함된 커스텀 이미지를 사용하여 VM을 다시 만듭니다.

상태 확인 및 자동 복구 정책 설정

자동 복구 정책을 MIG당 최대 한 개까지 설정할 수 있습니다.

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

상태 확인 설정 예시

다음 예시에서는 MIG에서 상태 확인을 사용하는 방법을 보여줍니다. 이 예시에서는 포트 80에서 웹 서버 응답을 찾는 상태 확인을 만듭니다. 상태 확인 프로브를 각 웹 서버에 연결하려면 방화벽 규칙을 구성합니다. 마지막으로, 그룹의 자동 복구 정책을 설정하여 MIG에 상태 확인을 적용합니다.

Console

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

    예를 들어 포트 80에서 응답을 찾고, VM을 UNHEALTHY로 표시해 VM이 다시 만들어지도록 하기 전에 일부 오류를 허용할 수 있는 상태 확인을 만듭니다. 이 예시에서는 VM이 성공적으로 한 번 반환하면 정상으로 표시되고, 3회 연속으로 반환이 실패하면 비정상으로 표시됩니다.

    1. Google Cloud Console에서 상태 확인 만들기 페이지로 이동합니다.

      상태 확인 만들기 페이지로 이동

    2. 상태 확인에 이름을 지정합니다(예: example-check).
    3. 프로토콜HTTP가 선택되어 있는지 확인합니다.
    4. 포트80을 입력합니다.
    5. 확인 간격5를 입력합니다.
    6. 제한 시간5를 입력합니다.
    7. 정상 기준을 설정하여 비정상 VM이 정상으로 표시되려면 성공적인 상태 확인이 몇 번 연속 반환되어야 하는지 지정합니다. 이 예시에서는 1을 입력합니다.
    8. 비정상 기준을 설정하여 정상 VM이 비정상으로 표시되려면 실패한 상태 확인이 몇 번 연속 반환되어야 하는지 지정합니다. 이 예시에서는 3을 입력합니다.
    9. 만들기를 클릭하여 상태 확인을 만듭니다.
  2. 방화벽 규칙을 만들어 상태 확인 프로브가 앱에 연결되도록 허용합니다.

    상태 확인 프로브130.211.0.0/2235.191.0.0/16 범위의 주소에서 전송되므로 네트워크 방화벽 규칙에서 상태 확인 연결을 허용하는지 확인합니다. 이 예시에서는 MIG에서 default 네트워크를 사용하고 VM이 포트 80에서 리슨합니다. 기본 네트워크에서 포트 80이 아직 열려 있지 않으면 방화벽 규칙을 만듭니다.

    1. Google Cloud Console에서 방화벽 규칙 만들기 페이지로 이동합니다.

      방화벽 규칙 만들기 페이지로 이동

    2. 이름에 방화벽 규칙의 이름(예: allow-health-check)을 입력합니다.
    3. 네트워크에서 default 네트워크를 선택합니다.
    4. 소스 필터에서 IP ranges를 선택합니다.
    5. 소스 IP 범위130.211.0.0/2235.191.0.0/16을 입력합니다.
    6. 프로토콜 및 포트에서 지정된 프로토콜 및 포트를 선택하고 tcp:80을 입력합니다.
    7. 만들기를 클릭합니다.
  3. 리전 또는 영역 MIG의 자동 복구 정책을 구성하여 상태 확인을 적용합니다.

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

      인스턴스 그룹 페이지로 이동

    2. 목록의 이름 열에서 상태 확인을 적용할 MIG의 이름을 클릭합니다.
    3. 그룹 수정을 클릭하여 이 MIG를 수정합니다.
    4. 자동 복구에서 이전에 만든 상태 확인을 선택합니다.
    5. 초기 지연 설정을 변경하거나 유지합니다. 이 설정은 VM 시작 중에 VM을 조기에 다시 만들지 않도록 자동 복구를 지연시킵니다. 초기 지연 타이머는 VM의 currentActionVERIFYING일 때 시작됩니다.
    6. 저장을 클릭하여 변경사항을 적용합니다.

gcloud

이 가이드의 명령줄 예시를 사용하려면 gcloud 명령줄 도구를 설치하거나 Cloud Shell을 사용합니다.

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

    예를 들어 포트 80에서 응답을 찾고, VM을 UNHEALTHY로 표시해 VM이 다시 만들어지도록 하기 전에 일부 오류를 허용할 수 있는 상태 확인을 만듭니다. 이 예시에서는 VM이 성공적으로 한 번 반환하면 정상으로 표시되고, 3회 연속으로 반환이 실패하면 비정상으로 표시됩니다.

    gcloud compute health-checks create http example-check --port 80 \
           --check-interval 30s \
           --healthy-threshold 1 \
           --timeout 10s \
           --unhealthy-threshold 3
  2. 방화벽 규칙을 만들어 상태 확인 프로브가 앱에 연결되도록 허용합니다.

    상태 확인 프로브130.211.0.0/2235.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
  3. 리전 또는 영역 MIG의 자동 복구 정책을 구성하여 상태 확인을 적용합니다.

    update 명령어를 사용하여 MIG에 상태 확인을 적용합니다.

    initial-delay 설정은 VM 시작 중에 VM을 조기에 다시 만들지 않도록 자동 복구를 지연시킵니다. 초기 지연 타이머는 VM의 currentActionVERIFYING일 때 시작됩니다.

    예를 들면 다음과 같습니다.

    gcloud compute instance-groups managed update my-mig \
            --health-check example-check \
            --initial-delay 300 \
            --zone us-east1-b

API

이 가이드의 API 예시를 사용하려면 API 액세스를 설정합니다.

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

    예를 들어 포트 80에서 응답을 찾고, VM을 UNHEALTHY로 표시해 VM이 다시 만들어지도록 하기 전에 일부 오류를 허용할 수 있는 상태 확인을 만듭니다. 이 예시에서는 VM이 성공적으로 한 번 반환하면 정상으로 표시되고, 3회 연속으로 반환이 실패하면 비정상으로 표시됩니다.

    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
    }
    
  2. 방화벽 규칙을 만들어 상태 확인 프로브가 앱에 연결되도록 허용합니다.

    상태 확인 프로브130.211.0.0/2235.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"
      }
     ]
    }
    
  3. 리전 또는 영역 MIG의 자동 복구 정책을 구성하여 상태 확인을 적용합니다.

    자동 복구 정책은 instanceGroupManager 리소스 또는 regionInstanceGroupManager 리소스의 일부입니다.

    insert 또는 patch 메서드를 사용하여 자동 복구 정책을 설정할 수 있습니다.

    다음 예시에서는 instanceGroupManagers.patch 메서드를 사용하여 자동 복구 정책을 설정합니다.

    PATCH https://compute.googleapis.com/compute/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]
    {
      "autoHealingPolicies": [
        {
          "healthCheck": "global/healthChecks/example-check",
          "initialDelaySec": 300
        }
      ],
    }
    

    initialDelaySec 설정은 VM 시작 중에 VM을 조기에 다시 만들지 않도록 자동 복구를 지연시킵니다. 초기 지연 타이머는 VM의 currentActionVERIFYING일 때 시작됩니다.

    애플리케이션 기반 자동 복구를 사용 중지하려면 자동 복구 정책을 빈 값인 autoHealingPolicies[]로 설정하세요. autoHealingPolicies[]를 통해 MIG는 RUNNING 상태에 있지 않은 VM만 다시 만듭니다.

    instanceGroupManagers.autoHealingPolicies 필드를 읽는 방식으로 MIG의 자동 복구 정책을 가져올 수 있습니다. 다음 메서드 중 하나를 사용하여 MIG 리소스를 가져올 수 있습니다.

그룹 만들기 또는 상태 확인 구성 업데이트가 완료되면 자동 복구에서 그룹의 인스턴스 모니터링을 시작하는 데 30분 정도 걸릴 수 있습니다. 모니터링이 시작되면 Compute Engine은 자동 복구 구성에 따라 인스턴스를 정상으로 표시하거나 다시 만듭니다. 예를 들어 초기 지연을 5분, 상태 확인 간격을 1분, 정상 기준을 1개로 구성하면 타임라인이 다음과 같게 됩니다.

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

상태 확인

각 VM의 현재 상태를 검사하거나 각 VM의 현재 작업을 확인하거나 그룹 상태를 확인하여 VM이 생성되고 애플리케이션이 응답하는지 확인할 수 있습니다.

VM이 정상인지 확인

MIG 자동 복구를 구성한 경우 각 관리형 인스턴스의 상태를 검토할 수 있습니다.

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

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

Console, gcloud 명령줄 도구 또는 API를 사용하여 상태를 봅니다.

Console

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

    인스턴스 그룹 페이지로 이동

  2. 목록의 이름 열에서 검토할 MIG의 이름을 클릭합니다. 인스턴스 그룹 속성과 그룹에 포함된 VM의 목록이 표시된 페이지가 열립니다.

  3. 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의 상태를 보여줍니다.

API

리전 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이고 초기화 기간이 지난 경우 자동 복구 서비스는 즉시 복구를 시도합니다.
  • VM의 상태가 UNKNOWN이면 즉시 복구되지 않습니다. 이는 상태 확인 신호를 일시적으로 사용할 수 없는 VM의 불필요한 복구를 방지하기 위한 것입니다.

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

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

VM 상태 값에 대한 사용 사례, 문제 또는 의견에 대해 알고 싶습니다. mig-discuss@google.com으로 저희 팀에 의견을 공유해 주세요.

VM에서 현재 작업 보기

VM이 생성되는 동안 인스턴스의 currentActionCREATING입니다. 자동 복구 정책이 그룹에 연결된 경우 VM이 생성되어 실행되면 인스턴스의 currentActionVERIFYING으로 진행되며, 상태 확인기가 VM의 애플리케이션을 프로브하기 시작합니다. 애플리케이션이 애플리케이션 시작에 소요되는 시간 안에 이 초기 상태 확인을 통과하면 VM이 확인되고 currentActionNONE으로 바뀝니다.

관리형 인스턴스 그룹에서 실행 중인 currentAction 및 각 인스턴스의 status를 보려면 gcloud 명령줄 도구 또는 API를 사용하면 됩니다.

gcloud

gcloud compute instance-groups managed list-instances instance-group-name \
[--filter="zone:(zone)" | --filter="region:(region)"]

gcloud는 인스턴스 그룹에 속한 인스턴스 목록뿐 아니라 각 인스턴스의 상태와 현재 작업을 반환합니다. 예를 들면 다음과 같습니다.

NAME               ZONE           STATUS    ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f            CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING  DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING   NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING   NONE      my-old-template

API

API에서 regionInstanceGroupManagers.listManagedInstances 메서드에 GET 요청을 실행합니다. 영역 관리형 인스턴스 그룹의 경우 instanceGroupManagers.listManagedInstances 메서드를 사용합니다.

GET https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/listManagedInstances

API는 각 인스턴스의 instanceStatuscurrentAction을 비롯한 그룹의 인스턴스 목록을 반환합니다.

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  }
 ]
}

관리형 인스턴스 그룹의 각 인스턴스의 경우 인스턴스의 상태는 instanceStatus 필드로 설명됩니다. 유효한 instanceStatus 필드 값 목록을 보려면 인스턴스 상태 확인을 참조하세요.

인스턴스를 변경 중인 경우 변경 과정을 쉽게 추적할 수 있도록 다음 작업 중 하나를 통해 currentAction 필드도 채워집니다. 그렇지 않으면 currentAction 필드는 NONE입니다.

가능한 currentAction 값은 다음과 같습니다.

  • ABANDONING: 인스턴스가 관리형 인스턴스 그룹에서 삭제되고 있습니다.
  • CREATING: 인스턴스가 생성되고 있습니다.
  • CREATING_WITHOUT_RETRIES: 인스턴스가 재시도없이 생성되고 있습니다. 인스턴스가 첫 번째 시도에서 생성되지 않은 경우에도 관리형 인스턴스 그룹이 해당 인스턴스를 다시 교체하지 않습니다.
  • DELETING: 인스턴스가 삭제되고 있습니다.
  • RECREATING: 인스턴스를 교체하는 중입니다.
  • REFRESHING: 인스턴스가 현재 대상 풀에서 삭제되고 현재 대상 풀 목록에 다시 추가되는 중입니다. 이 목록은 기존 대상 풀과 동일하거나 다를 수 있습니다.
  • RESTARTING: 인스턴스가 stopstart 메서드를 사용하여 다시 시작되고 있습니다.
  • VERIFYING: 인스턴스가 생성되었으며 확인되고 있습니다.
  • NONE: 인스턴스에서 수행 중인 작업이 없습니다.

MIG가 안정적인지 확인

그룹 수준에서 Compute Engine은 isStable 플래그가 포함된 status라는 읽기 전용 필드를 채웁니다.

그룹의 모든 VM이 실행 중이고 정상 상태이면(즉, 각 관리형 인스턴스의 currentActionNONE임) status.isStable==true입니다. MIG의 안정성은 자동 복구 정책 이외의 그룹 구성에 따라 달라집니다. 예를 들어 그룹이 자동 확장되는 경우와 그룹이 자동 확장 처리 작업으로 인해 현재 수평 축소 또는 수평 확장 중이고 isStable==false인 경우의 차이입니다.

status.isStable 필드 값을 확인하면 관리형 인스턴스 그룹이 실행 중이고 정상적인지 확인할 수 있습니다.

gcloud

인스턴스 그룹 describe 명령어를 사용합니다.

gcloud compute instance-groups managed describe instance-group-name \
    [--zone zone | --region region]

gcloud 도구는 status.isStable 필드를 비롯한 인스턴스 그룹에 대한 자세한 세부정보를 반환합니다.

그룹이 안정화될 때까지 스크립트를 일시중지하려면 wait-until 명령어와 함께 --stable 플래그를 사용합니다. 예를 들면 다음과 같습니다.

gcloud compute instance-groups managed wait-until instance-group-name \
    --stable \
    [--zone zone | --region region]
Waiting for group to become stable, current operations: deleting: 4
Waiting for group to become stable, current operations: deleting: 4
...
Group is stable

명령어는 그룹에 대해 status.isStabletrue로 설정된 후 반환됩니다.

API

영역 MIG의 경우 instanceGroupManagers.get 메서드에 GET 요청을 수행합니다.

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name/get

리전 관리형 인스턴스 그룹의 경우 zones/zoneregions/region으로 바꿉니다.

GET https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/get

API가 status.isStable 필드를 비롯한 인스턴스 그룹에 대한 세부정보를 반환합니다.

status.isStablefalse로 설정되면 변경사항이 활성 또는 대기 중 상태이거나 관리형 인스턴스 그룹 자체가 수정 중임을 나타냅니다.

status.isStabletrue로 설정되면 다음을 나타냅니다.

  • 관리형 인스턴스 그룹의 인스턴스 중 변경 중인 인스턴스가 없거나, 모든 인스턴스의 currentActionNONE입니다.
  • 관리형 인스턴스 그룹의 인스턴스에 대기 중인 변경사항이 없습니다.
  • 관리형 인스턴스 그룹 자체가 수정되지 않습니다.

관리형 인스턴스 그룹은 다양한 방법으로 변경할 수 있습니다. 예를 들면 다음과 같습니다.

  • 새 인스턴스 템플릿의 롤아웃을 요청합니다.
  • 그룹의 인스턴스를 생성, 삭제, 크기 조절 또는 업데이트하는 요청을 실행합니다.
  • 자동 확장 처리가 그룹의 크기 조절을 요청합니다.
  • 자동 복구 리소스가 관리형 인스턴스 그룹에 속한 1개 이상의 비정상 인스턴스를 교체합니다.
  • 리전 관리형 인스턴스 그룹에 속한 인스턴스 중 일부가 재배포됩니다.

모든 작업이 완료되면 이 관리형 인스턴스 그룹에 대한 status.isStable이 다시 true로 설정됩니다.

이전 자동 복구 작업 보기

gcloud 도구 또는 API를 사용하여 이전 자동 복구 이벤트를 볼 수 있습니다.

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

API

리전 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의 경우 zoneOoperations 리소스를 사용합니다.

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

다음 단계