관리형 인스턴스 그룹의 상태 확인 및 자동 복구 설정

관리형 인스턴스 그룹(MIG)은 사전에 가상 머신(VM) 인스턴스를 사용할 수 있도록, 즉 RUNNING 상태로 유지하여 애플리케이션의 고가용성을 보장합니다. 인스턴스에서 RUNNING을 중지하고 MIG에서 상태 변경을 시작하지 않은 경우(예: 자동 확장 처리 결정과 반대인 하드웨어 오류), MIG는 해당 인스턴스를 자동으로 다시 생성합니다. 하지만 인스턴스 상태를 사용하여 애플리케이션 상태를 결정하는 것은 충분하지 않을 수 있습니다. 예를 들어 인스턴스가 RUNNING인지 여부를 확인해도 정지, 과부하 또는 비정상 종료와 같은 애플리케이션 장애를 감지할 수 없습니다.

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

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

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

자동 복구 동작

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

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

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

자동 복구와 디스크

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

디스크 유형 autodelete 자동 복구 작업 중 동작
새로운 영구 디스크 true 인스턴스의 템플릿에 지정되어 있는 대로 디스크를 다시 만듭니다. 디스크와 인스턴스를 다시 만들면 디스크에 작성되었던 데이터가 모두 사라집니다.
새로운 영구 디스크 false 디스크가 보존되고 자동 복구 기능으로 인스턴스를 다시 만들 때 다시 연결됩니다.
기존 영구 디스크 true 이전 디스크가 삭제됩니다. Compute Engine이 삭제된 디스크를 인스턴스에 다시 연결할 수 없기 때문에 VM 인스턴스를 다시 만들지는 못합니다.
기존 영구 디스크 false 이전 디스크가 인스턴스의 템플릿에 지정되어 있는 대로 다시 연결됩니다. 디스크의 데이터도 보존됩니다. 하지만 읽기/쓰기 디스크의 경우에는 단일 영구 디스크를 읽기/쓰기 모드로 다수의 인스턴스에 연결할 수 없기 때문에 관리형 인스턴스 그룹에 포함될 수 있는 VM의 수는 1개로 제한됩니다.
새로운 로컬 SSD 해당 없음 인스턴스의 템플릿에 지정되어 있는 대로 디스크를 다시 만듭니다. 인스턴스를 다시 만들거나 삭제하면 로컬 SSD에 저장되어 있던 데이터는 모두 사라집니다.

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

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

  • 영구 디스크 스냅샷을 정기적으로 만드세요.

  • 데이터를 Cloud Storage 같은 다른 소스로 내보내세요.

인스턴스에 유지하려는 중요 설정이 있는 경우 Google에서는 인스턴스 템플릿에 커스텀 이미지를 사용하는 것을 권장합니다. 커스텀 이미지에는 필요한 모든 커스텀 설정이 포함되어 있습니다. 인스턴스 템플릿에 커스텀 이미지를 지정하면 관리형 인스턴스 그룹(MIG)에서 필요한 커스텀 설정이 포함된 커스텀 이미지를 사용하여 인스턴스를 다시 만듭니다.

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

관리형 인스턴스 그룹당 최대 하나의 자동 복구 정책을 설정할 수 있습니다.

최대 50개의 관리형 인스턴스 그룹에 단일 상태 확인을 적용할 수 있습니다. 그룹이 50개 이상인 경우 여러 상태 확인을 만듭니다.

상태 확인 설정 예시

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

Console

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

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

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

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

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

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

    1. GCP 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. 리전 또는 영역 관리형 인스턴스 그룹의 자동 복구 정책을 구성하여 상태 확인을 적용합니다.

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

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

    2. 목록의 이름 열에서 상태 확인을 적용할 인스턴스 그룹 이름을 클릭합니다.
    3. 그룹 편집을 클릭하여 이 관리형 인스턴스 그룹을 수정합니다.
    4. 자동 복구에서 전에 만든 상태 확인을 선택합니다.
    5. 초기 지연 설정을 변경하거나 유지합니다. 이 설정은 인스턴스 시작 도중에 자동 복구가 인스턴스를 너무 이르게 다시 만드는 것을 지연시킵니다. 초기 지연 타이머는 인스턴스의 currentActionVERIFYING일 때 시작됩니다.
    6. 저장을 클릭하여 변경사항을 적용합니다.

    자동 복구가 그룹의 인스턴스 모니터링을 시작하기까지 15분 정도 걸릴 수 있습니다.

gcloud

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

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

    예를 들어 포트 80에서 응답을 찾고, 인스턴스를 UNHEALTHY로 표시해 인스턴스가 다시 만들어지도록 하기 전에 일부 오류를 허용할 수 있는 상태 확인을 만듭니다. 이 예시에서는 인스턴스가 성공적으로 한 번 반환되면 정상으로 표시되고, 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 범위의 주소에서 전송되므로 방화벽 규칙에서 상태 확인 연결을 허용하도록 합니다. 이 예시에서는 관리형 인스턴스 그룹에 default 네트워크가 사용되고 인스턴스가 포트 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. 리전 또는 영역 관리형 인스턴스 그룹의 자동 복구 정책을 구성하여 상태 확인을 적용합니다.

    update 명령어를 사용하여 관리형 인스턴스 그룹에 상태 확인을 적용합니다.

    initial-delay 설정은 인스턴스 시작 도중에 자동 복구가 인스턴스를 너무 이르게 다시 만드는 것을 지연시킵니다. 초기 지연 타이머는 인스턴스의 currentActionVERIFYING일 때 시작됩니다.

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

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

    자동 복구가 그룹의 인스턴스 모니터링을 시작하기까지 15분 정도 걸릴 수 있습니다.

API

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

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

    예를 들어 포트 80에서 응답을 찾고, 인스턴스를 UNHEALTHY로 표시해 인스턴스가 다시 만들어지도록 하기 전에 일부 오류를 허용할 수 있는 상태 확인을 만듭니다. 이 예시에서는 인스턴스가 성공적으로 한 번 반환되면 정상으로 표시되고, 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 범위의 주소에서 전송되므로 방화벽 규칙에서 상태 확인 연결을 허용하도록 합니다. 이 예시에서는 관리형 인스턴스 그룹에 default 네트워크가 사용되고 인스턴스가 포트 80에서 수신 대기합니다. 기본 네트워크에서 포트 80이 아직 열려 있지 않으면 방화벽 규칙을 만듭니다.

    POST https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    
    {
     "name": "allow-health-check",
     "network": "https://compute.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. 리전 또는 영역 관리형 인스턴스 그룹의 자동 복구 정책을 구성하여 상태 확인을 적용합니다.

    자동 복구 정책은 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 설정은 인스턴스 시작 도중에 자동 복구가 인스턴스를 너무 이르게 다시 만드는 것을 지연시킵니다. 초기 지연 타이머는 인스턴스의 currentActionVERIFYING일 때 시작됩니다.

    자동 복구가 그룹의 인스턴스 모니터링을 시작하기까지 15분 정도 걸릴 수 있습니다.

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

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

상태 확인

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

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

인스턴스 상태

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

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

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

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

상태

다음과 같은 인스턴스 상태를 사용할 수 있습니다.

  • HEALTHY - 인스턴스에 연결할 수 있고, 애플리케이션 상태 확인 엔드포인트에 대한 연결을 설정할 수 있으며, 응답은 상태 확인에 정의된 요구 사항을 준수합니다.
  • DRAINING - 인스턴스가 소모되고 있습니다. 인스턴스에 대한 기존 연결은 완료되지만 새 연결은 거부됩니다.
  • UNHEALTHY - 인스턴스에 연결할 수 있지만 상태 확인에 정의된 요구 사항을 준수하지 않습니다.
  • TIMEOUT - 인스턴스에 연결할 수 없고, 애플리케이션 상태 확인 엔드포인트에 대한 연결을 설정할 수 없으며, VM 인스턴스의 서버가 지정된 제한 시간 내에 응답하지 않습니다. 예를 들어 방화벽 규칙이 잘못 구성되어 있거나 VM 인스턴스에 과부하된 서버 애플리케이션으로 인한 것일 수 있습니다.
  • UNKNOWN - 상태 확인 시스템이 인스턴스를 인식하지 못하거나 현재 인스턴스의 상태를 알 수 없습니다. MIG의 새 인스턴스에서 모니터링을 시작하는 데 15분 정도 걸릴 수 있습니다.

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

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

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

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

  • 여러 번 연속적으로 복구한 후에도 인스턴스가 비정상적으로 남아 있습니다.
  • 그룹에서 비정상적인 상태인 인스턴스의 상당 부분이 존재합니다.

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

Console

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

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

  2. 목록의 이름 열에서 알아보려는 인스턴스 그룹의 이름을 클릭합니다. 인스턴스 그룹 속성과 그룹에 포함된 인스턴스의 목록이 표시된 페이지가 열립니다.

  3. 인스턴스가 비정상 상태인 경우 Health issues(상태 문제) 열에서 해당 상태를 확인할 수 있습니다.

gcloud

list-instances 하위 명령어를 사용합니다.

$ gcloud beta 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 열은 각 인스턴스의 상태를 보여 줍니다.

API

리전 관리형 인스턴스 그룹의 경우 listManagedInstances 메서드에 대한 POST 요청을 만듭니다.

POST https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP]/listManagedInstances

영역 관리형 인스턴스 그룹의 경우 영역 관리형 인스턴스 그룹 listManagedInstances 메서드를 사용합니다.

POST https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]/listManagedInstances

요청은 각 관리형 인스턴스에 대한 instanceHealth 필드를 포함하여 다음과 같은 모습의 응답을 반환합니다.

{
 "managedInstances": [
  {
   "instance": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/example-group-5485",
   "instanceStatus": "RUNNING",
   "currentAction": "NONE",
   "lastAttempt": {
   },
   "id": "6159431761228150698",
   "instanceTemplate": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/instanceTemplates/example-template",
   "version": {
    "instanceTemplate": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/instanceTemplates/example-template"
   },
   "instanceHealth": [
    {
     "healthCheck": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/healthChecks/http-basic-check",
     "detailedHealthState": "HEALTHY"
    }
   ]
  },
  {
   "instance": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/example-group-sfdp",
   "instanceStatus": "STOPPING",
   "currentAction": "DELETING",
   "lastAttempt": {
   },
   "id": "6622324799312181783",
   "instanceHealth": [
    {
     "healthCheck": "https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/healthChecks/http-basic-check",
     "detailedHealthState": "TIMEOUT"
    }
   ]
  }
 ]
}

인스턴스에서 현재 작업 실행

관리형 인스턴스가 생성되는 과정에서 currentActionCREATING입니다. 자동 복구 정책이 그룹에 연결된 경우 관리형 인스턴스가 생성되어 실행되면 인스턴스의 currentActionVERIFYING으로 진행되며, 상태 확인기가 인스턴스의 애플리케이션을 조사하기 시작합니다. 애플리케이션이 애플리케이션 시작에 소요되는 시간 안에 이 초기 상태 확인을 통과하면 인스턴스가 확인되고 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 메서드에 POST 요청을 실행합니다. 영역 관리형 인스턴스 그룹의 경우 instanceGroupManagers.listManagedInstances 메서드를 사용합니다.

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

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

{
 "managedInstances": [
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.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: 인스턴스에서 실행 중인 작업이 없습니다.

그룹 상태

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

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

연결된 instanceGroupManagers 또는 regionInstanceGroupManagers 리소스의 status.isStable 필드 값을 확인하여 관리형 인스턴스 그룹이 실행 중이고 정상 상태인지 확인할 수 있습니다.

또한 gcloud 명령줄 도구 wait-until 명령어를 --stable 플래그와 함께 사용하여 그룹에 대해 status.isStabletrue로 설정될 때까지 기다릴 수 있습니다.

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --stable \
    [--zone [ZONE] | --region [REGION]]

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

리전 관리형 인스턴스 그룹의 경우 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

영역 관리형 인스턴스 그룹의 경우 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/us-east1-b/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

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

자동 복구에 사용되는 상태 확인은 인스턴스를 사전에 삭제하고 다시 만들지 않도록 보수적이어야 합니다. 자동 복구 상태 확인이 지나치게 공격적인 경우 자동 복구 기능은 사용량이 많은 인스턴스를 실패한 인스턴스로 오인하고 불필요하게 다시 시작하여 가용성을 저하시킬 수 있습니다.

  • unhealthy-threshold. 1보다 커야 합니다. 이 값을 3 이상으로 설정하는 것이 좋습니다. 이렇게 하면 네트워크 패킷 손실과 같이 드물게 발생하는 실패로부터 보호됩니다.
  • healthy-threshold. 대부분의 앱에서 값 2면 충분합니다.
  • timeout. 이 시간 값은 넉넉하게 설정합니다(예상되는 응답 시간의 5배 이상). 이렇게 하면 사용량이 많은 인스턴스 또는 느린 네트워크 연결과 같은 예상치 못한 지연으로부터 보호됩니다.
  • check-interval. 이 값은 1초와 제한 시간 두 배 사이여야 합니다(너무 길지도, 너무 짧지도 않은 시간). 값이 너무 길면 실패한 인스턴스가 신속하게 포착되지 않습니다. 값이 너무 짧으면 매 초 전송되는 많은 수의 상태 확인 프로브로 인해 인스턴스와 네트워크의 사용량이 과도하게 많은 것으로 측정될 수 있습니다.

다음 단계