관리형 인스턴스 그룹에 업데이트 롤아웃

관리형 인스턴스 그룹에는 인스턴스 템플릿을 사용하여 제어되는 가상 머신 인스턴스가 하나 이상 들어 있습니다. 관리형 인스턴스 그룹의 인스턴스를 업데이트하려면 관리형 인스턴스 그룹 업데이터 기능을 사용하여 그룹에 대한 전체 업데이트 요청을 할 수 있습니다.

인스턴스 그룹에 대한 자세한 내용은 인스턴스 그룹 개요를 참조하세요.

관리형 인스턴스 그룹 업데이터를 사용하면 배포 속도, 서비스의 중단 수준, 업데이트 범위를 제어하면서 관리형 인스턴스 그룹에 새 버전의 소프트웨어를 쉽게 배포할 수 있습니다. 업데이터의 주요 이점은 다음 2가지입니다.

  • 초기 요청 후 추가 사용자 입력 없이 사양에 맞게 업데이트가 자동으로 롤아웃됩니다.
  • 카나리아 테스트를 허용하는 부분 롤아웃을 수행할 수 있습니다.

새 소프트웨어를 기존 관리형 인스턴스 그룹 내에 배포할 수 있도록 허용하면 인스턴스 그룹을 재구성하거나, 부하 분산을 다시 연결하거나, 새 버전의 소프트웨어를 롤아웃할 때마다 자동 확장이나 자동 복구를 할 필요가 없습니다. 업데이터를 사용하지 않는 경우, 매번 추가 설정을 필요로 하는 새 소프트웨어 버전으로 새 관리형 인스턴스 그룹을 만들거나, 사용자가 시작하는 수동 인스턴스별 재생성을 통해 새 소프트웨어 버전을 배포해야 합니다. 이 두 가지 방법 모두 프로세스 전반에 걸쳐 상당한 수작업이 필요합니다.

시작하기 전에

기본 순차적 업데이트 시작하기

순차적 업데이트란 모든 인스턴스가 업데이트될 때까지 인스턴스 그룹의 모든 인스턴스에 단계적으로 적용되는 업데이트입니다. 업데이트 중 오프라인으로 설정할 수 있는 인스턴스 수, 인스턴스 업데이트 간격, 업데이트의 적용 범위(인스턴스 전체 또는 일부) 등의 다양한 측면을 제어할 수 있습니다.

순차적 업데이트를 수행할 때 다음 사항에 유의해야 합니다.

  • 업데이트는 인텐트를 기반으로 합니다. 처음 업데이트를 요청하면 API는 요청의 유효성을 확인하기 위해 성공 응답을 반환하지만, 이것이 업데이트 성공을 나타내지는 않습니다. 업데이트가 성공적으로 배포되었는지 확인하려면 관리형 인스턴스 그룹의 상태를 확인해야 합니다.

  • 인스턴스 그룹 업데이터 API는 선언적 API입니다. 이 API에는 명시적 함수 호출이 아니라 관리형 인스턴스 그룹에서 원하는 사후 업데이트 구성을 지정하라는 요청이 필요합니다.

  • 업데이터 기능은 관리형 인스턴스 그룹에 있는 최대 두 개의 인스턴스 템플릿을 지원합니다. 즉, 관리형 인스턴스 그룹에 대해 2개의 인스턴스 템플릿 버전을 지정할 수 있으므로 카나리아 업데이트를 수행하는 데 유용합니다.

업데이트가 그룹에 있는 인스턴스 모두에 100% 적용되는 기본 순차적 업데이트를 시작하려면 아래 안내를 따르세요.

Console

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

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

  2. 업데이트할 인스턴스 그룹을 선택합니다.
  3. 페이지 상단에서 순차적 업데이트를 클릭합니다.
  4. 템플릿 아래의 드롭다운 메뉴를 풀다운하고 업데이트할 새 템플릿을 선택합니다.
  5. 대상 크기로 100%를 입력하여 모든 인스턴스를 업데이트합니다.
  6. 필요에 따라 업데이트가 사전형(그룹이 적극적으로 인스턴스를 바꿈)인지 아니면 상황별(그룹이 적극적으로 인스턴스를 바꾸지 않지만 다른 수단으로 인스턴스가 바뀔 때 업데이트를 적용함)인지와 같은 구성 옵션을 전환할 수 있습니다. 최대 초과 개수, 최대 사용 불가능 옵션, 최소 대기 시간을 제공해도 됩니다.
  7. 업데이트를 클릭하여 업데이트를 시작합니다.

gcloud

gcloud 도구를 사용하여 rolling-action start-update 명령어를 실행합니다.

gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP] \
    --version template=[INSTANCE_TEMPLATE] [--zone [ZONE] | --region [REGION]]

각 항목의 의미는 다음과 같습니다.

  • [INSTANCE_GROUP]은 업데이트할 인스턴스 그룹의 이름입니다.
  • [INSTANCE_TEMPLATE]은 인스턴스 그룹을 업데이트할 새 인스턴스 템플릿입니다.
  • 이 인스턴스 그룹의 [ZONE] 또는 [REGION]입니다. 인스턴스 그룹이 영역별 인스턴스 그룹인 경우 영역을 제공하고, 리전별인 경우 리전을 제공합니다.

API

API에서 다음 URL에 PATCH를 요청합니다.

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[MANAGED_INSTANCE_GROUP_NAME]

인스턴스 그룹이 리전 관리형 인스턴스 그룹인 경우 zones/[ZONE]regions/[REGION]으로 바꿉니다.

요청 페이로드에는 다음이 포함됩니다.

다음은 API에서 업데이트를 시작하는 데 필요한 최소 구성의 예시입니다.

별도로 지정하지 않은 경우 maxSurgemaxUnavailable 속성의 기본값은 1에 영향을 받는 영역 수를 곱한 값으로 지정됩니다. 즉, 업데이터는 영향을 받는 영역별로 1개의 인스턴스만 사용 불가능하게 만들고, 업데이트 도중 영역별로 1개의 추가 인스턴스만 만든다는 의미입니다.

이 요청 예시에서는 전체 인스턴스를 새 인스턴스 템플릿으로 업데이트합니다.

{
  "instanceTemplate": "global/instanceTemplates/example-template",
  "updatePolicy": {
    "type": "proactive"
   }
 }

요청한 후에는 업데이트를 모니터링하여 업데이트가 언제 완료되었는지 알 수 있습니다.

업데이트 옵션 구성하기

보다 복잡한 업데이트의 경우 특정 업데이트 요청에 대한 추가 옵션을 구성할 수 있습니다. 해당 옵션은 아래에 설명되어 있습니다.

최대 초과 개수

업데이트 중 업데이터가 임시로 새 인스턴스를 targetSize 이상으로 만들 수 있게 maxSurge 속성을 설정합니다. 예를 들어 maxSurge를 5로 설정하면 관리형 인스턴스 그룹이 새 인스턴스 템플릿을 사용하여 새 인스턴스를 대상 크기보다 최대 5개 더 많이 만듭니다. maxSurge 값을 높게 설정하면 추가되는 인스턴스 덕분에 업데이트 속도가 향상됩니다. 이때 추가 인스턴스는 Compute Engine 가격표에 따라 비용이 청구됩니다.

maxSurge 값을 설정하지 않으면 기본값이 사용됩니다. 영역 관리형 인스턴스 그룹에서 maxSurge의 기본값은 1입니다. 리전 관리형 인스턴스 그룹의 경우에는 기본값이 [NUMBER_OF_ZONES]이며, 여기서 [NUMBER_OF_ZONES]는 리전 관리형 인스턴스 그룹에 연결된 영역 수입니다.

이 옵션은 REPLACE 최소 작업으로 구성되었을 때만 인식되지만 RESTART 작업 설정에는 지원되지 않습니다. 고정된 숫자를 지정할 수 있습니다. 또는 관리형 인스턴스 그룹에 인스턴스가 10개 이상 있는 경우 백분율을 지정할 수 있습니다. 백분율을 설정하면 업데이터는 필요에 따라 인스턴스 수를 반올림합니다.

maxSurge는 추가 리소스를 지원하기에 충분한 할당량 또는 리소스가 있는 경우에만 작동합니다.

최대 사용 불가

업데이트 중 항상 특정 수의 인스턴스만 사용할 수 없도록 maxUnavailable 구성을 설정합니다. 예를 들어, maxUnavailable을 5로 설정하면 업데이트를 위해 한 번에 5개의 인스턴스만 오프라인으로 설정됩니다. 이 매개변수를 사용하여 업데이트로 인해 서비스가 얼마나 중단되는지 제어하고 업데이트가 배포되는 속도를 조정합니다.

이 숫자에는 다른 이유로 사용할 수 없는 인스턴스도 포함됩니다. 예를 들어 인스턴스 그룹의 크기 확장이 진행 중인 경우 생성 중인 인스턴스는 사용하지 못할 수 있지만, 이러한 인스턴스도 maxUnavailable 수에 포함됩니다. 고정된 숫자를 지정할 수 있습니다. 또는 관리형 인스턴스 그룹에 인스턴스가 10개 이상 있는 경우 백분율을 지정할 수 있습니다. 백분율을 설정하면 업데이터는 필요에 따라 인스턴스 수를 내림합니다.

영역 관리형 인스턴스 그룹에서 maxUnavailable의 기본값은 1입니다. 리전 관리형 인스턴스 그룹에서는 기본값이 [NUMBER_OF_ZONES]이며, 리전 관리형 인스턴스 그룹에 선택된 영역 수의 기본값은 3입니다.

최소 대기 시간

새로 생성되거나 다시 시작된 인스턴스를 업데이트된 것으로 간주하기 전에 대기할 시간을 지정하려면 minReadySeconds를 설정합니다. 이 기능을 사용하여 업데이트가 배포되는 속도를 제어합니다. 다음 두 조건이 모두 충족되면 타이머가 시작됩니다.

  • 인스턴스의 상태가 RUNNING입니다.
  • 상태 확인이 사용 설정된 경우 상태 확인이 HEALTHY를 반환합니다.

상태 확인에서 정상을 반환하면 업데이터가 다음을 수행합니다.

  1. 상태 확인에서 HEALTHY를 반환할 때 autohealingPolicies.initialDelaySec에서 지정된 시간 동안 대기합니다.
  2. 그런 다음 minReadySeconds에서 지정된 시간 동안 대기합니다.

상태 확인에서 initialDelaySec 내에 HEALTHY를 반환하지 않으면 업데이터가 VM 인스턴스를 비정상으로 선언하고 업데이트를 중지할 수 있습니다. initialDelaySecminReadySeconds 기간 중 VM 인스턴스가 확인을 기다리는 동안 인스턴스의 currentActionVERIFYING 상태가 됩니다. 하지만 기본 VM 인스턴스 상태는 RUNNING으로 유지됩니다.

인스턴스 그룹에 대한 상태 확인이 없으면 인스턴스의 상태가 RUNNING일 때 타이머가 시작됩니다. minReadySeconds 속성의 최댓값은 3600초(1시간)입니다.

최소 작업

업데이터가 그룹의 인스턴스를 업데이트하기 위해 수행해야 하는 최소 작업을 제어하려면 최소 작업 속성을 설정합니다. 예를 들어 REPLACE를 최소 작업으로 설정하면 영향을 받는 모든 인스턴스가 삭제되고 필요 여부에 관계없이 새 인스턴스로 바뀝니다.

최소 작업을 설정하면 업데이터가 최소한 해당 작업을 수행합니다. 그러나 업데이터에서 지정된 최소 작업이 업데이트를 수행하기에 충분하지 않다고 판단하면 더 많은 중단이 요구되는 작업을 수행할 수 있습니다. 예를 들어 RESTART를 최소 작업으로 설정하면 업데이터가 업데이트를 적용하기 위해 인스턴스 다시 시작을 시도합니다. 중단을 더 많이 유발하는 작업이 업데이트에 필요한 경우 업데이터가 해당 작업을 수행합니다. 예를 들어 인스턴스를 다시 시작하여 인스턴스의 OS를 변경할 수 없으므로 업데이터가 인스턴스 그룹의 인스턴스를 새 VM 인스턴스로 바꿉니다.

적용 가능한 작업은 REPLACE 또는 RESTART입니다.

  • RESTART: 인스턴스를 다시 시작합니다(stopstart 요청 수행). 이미지를 변경하려면 인스턴스가 삭제되고 바뀌어야 하는 경우와 같이 업데이트 요청에서 변경사항 적용을 위해 인스턴스가 바뀌어야 하는 경우 요청에서 REPLACE를 수행해야 합니다.

  • REPLACE: 기존 인스턴스를 삭제하고 대상 템플릿에서 새 인스턴스를 만듭니다. 업데이터가 새로운 내부 및 외부 IP 주소와 같은 모든 새 인스턴스 속성을 사용하여 완전히 새로운 인스턴스를 만듭니다.

다음 다이어그램에서는 이러한 옵션이 어떻게 인스턴스에 영향을 주는지 보여줍니다.

서로 다른 여러 업데이터 옵션이 요청에 어떻게 영향을 미치는지 설명하는 다이어그램

추가 업데이트 예

다음은 일반적인 구성 옵션을 사용하는 몇 가지 명령줄의 예입니다.

모든 가상 머신 인스턴스의 순차적 업데이트를 수행하지만 대상 크기보다 최대 5개 더 많은 새 인스턴스를 한 번에 생성

gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[NEW_TEMPLATE] --max-surge 5 [--zone [ZONE] | --region [REGION]]

새 인스턴스를 사용 가능으로 표시하기 전 최대 3개의 사용 불가능 머신과 최소 3분의 대기 시간을 사용하여 순차적 업데이트 수행

gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[NEW_TEMPLATE] --min-ready 3m \
    --max-unavailable 3 [--zone [ZONE] | --region [REGION]]

예를 들어 1,000개의 인스턴스가 있는 경우 이 명령어를 실행하면 업데이터는 이전 인스턴스 템플릿을 실행하는 인스턴스 삭제를 시작하기 전에 최대 100개의 새 인스턴스를 만듭니다.

모든 가상 머신 인스턴스의 순차적 업데이트를 수행하지만 대상 크기보다 최대 10% 더 많은 새 인스턴스를 한 번에 생성

gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[NEW_TEMPLATE] --max-surge 10% [--zone [ZONE] | --region [REGION]]

카나리아 업데이트 시작하기

인스턴스 그룹 업데이터 기능을 사용하면 카나리아 업데이트를 수행할 수 있으므로 업데이트에 완전히 커밋하기 전에 임의의 인스턴스 하위 집합에서 업데이트를 테스트할 수 있습니다.

카나리아 업데이트는 인스턴스 그룹의 일부 인스턴스에 적용되는 업데이트입니다. 카나리아 업데이트를 사용하면 중단을 유발할 수 있는 업데이트를 모든 인스턴스에 롤아웃하는 대신 인스턴스의 하위 집합에서 새 기능이나 업그레이드를 테스트할 수 있습니다. 업데이트가 잘 진행되지 않을 경우 소수의 인스턴스만 롤백하면 사용자의 작업 중단을 최소화할 수 있습니다. 서버의 관점에서 카나리아 업데이트는 표준 순차적 업데이트와 동일하지만 업데이트해야 하는 인스턴스 수가 인스턴스 그룹의 전체 크기보다 작습니다. 표준 순차적 업데이트와 마찬가지로 카나리아 업데이트는 영향을 받는 인스턴스의 중단을 유발합니다. 즉, 영향을 받는 인스턴스가 삭제되고 업데이트 중에 새 VM 인스턴스로 바뀝니다.

카나리아 업데이트를 시작하는 방법은 다음과 같습니다.

  • 최대 2개의 인스턴스 템플릿 버전(대개 카나리아 테스트를 수행할 새 인스턴스 템플릿과 나머지 인스턴스를 위한 현재 인스턴스 템플릿)을 지정합니다. 예를 들어 20%의 인스턴스는 new-instance-template을 기반으로 생성되고, 나머지 인스턴스는 old-instance-template에서 계속 실행되도록 지정할 수 있습니다. 한 번에 3개 이상의 인스턴스 템플릿을 지정할 수 없습니다.

  • 항상 카나리아 버전의 대상 크기(targetSize)를 지정해야 합니다. 카나리아 버전의 대상 크기를 생략하면 카나리아 업데이트를 시작할 수 없습니다. 예를 들어 10%의 인스턴스를 카나리아 업데이트에 사용하도록 지정하면 나머지 90%는 변경되지 않고 현재 인스턴스 템플릿을 사용합니다.

Console

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

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

  2. 업데이트할 인스턴스 그룹을 선택합니다.
  3. 페이지 상단에서 순차적 업데이트를 클릭합니다.
  4. 템플릿 추가를 클릭하고 카나리아 테스트를 수행할 새 인스턴스 템플릿을 선택합니다.
  5. 대상 크기 아래에서 새 인스턴스 템플릿에 대해 카나리아 테스트를 수행하는 데 사용할 인스턴스의 백분율이나 고정된 숫자를 입력합니다.
  6. 필요에 따라 업데이트가 사전형(그룹이 적극적으로 인스턴스를 바꿈)인지 아니면 상황별(그룹이 적극적으로 인스턴스를 바꾸지 않지만 다른 수단으로 인스턴스가 만들어질 때 업데이트를 적용함)인지와 같은 구성 옵션을 전환할 수 있습니다. 최대 초과 개수, 최대 사용 불가능 옵션, 최소 대기 시간을 제공해도 됩니다.
  7. 업데이트를 클릭하여 업데이트를 시작합니다.

gcloud

gcloud 명령줄 도구로 현재 템플릿과 새 템플릿을 제공하여 각 템플릿을 사용해야 하는 인스턴스 수를 명시합니다.

gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[CURRENT_TEMPLATE] \
    --canary-version template=[NEW_TEMPLATE],target-size=[SIZE] \
    [--zone [ZONE] | --region [REGION]]

각 항목의 의미는 다음과 같습니다.

  • [CURRENT_TEMPLATE]은 인스턴스 그룹이 실행 중인 현재 템플릿입니다.
  • [NEW_TEMPLATE]은 카나리아 테스트를 수행할 새 템플릿입니다.
  • [SIZE]는 이 업데이트를 적용할 인스턴스의 수 또는 백분율입니다. --canary-version 템플릿에 target-size 속성을 적용해야 합니다. 인스턴스 그룹에 인스턴스가 10개 이상 있는 경우에만 백분율을 설정할 수 있습니다.
  • 이 인스턴스 그룹의 [ZONE] 또는 [REGION]입니다. 인스턴스 그룹이 영역별 인스턴스 그룹인 경우 영역을 제공하고, 리전별인 경우 리전을 제공합니다.

예를 들어 다음 명령어는 인스턴스 그룹의 인스턴스 중 10%에 my-template-b를 롤아웃하는 카나리아 업데이트를 수행합니다.

gcloud compute instance-groups managed rolling-action start-update my-ig1 \
        --version template=my-template-A --canary-version template=my-template-B,target-size=10%

API

API에서 다음 URI에 PATCH를 요청합니다.

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

요청 페이로드에는 현재 인스턴스 템플릿과 카나리아 테스트를 수행할 새 인스턴스 템플릿이 모두 포함되어야 합니다. 예를 들면 다음과 같습니다.

{
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/[NEW_TEMPLATE]",
   "targetSize": {
    "[percent|fixed]": [NUMBER|PERCENTAGE] # Use `fixed` for a specific number of instances
   }
  },
  {
   "instanceTemplate": "global/instanceTemplates/[CURRENT_TEMPLATE]"
  }
 ]
}

각 항목의 의미는 다음과 같습니다.

  • [NEW_TEMPLATE]은 카나리아 테스트를 수행할 새 템플릿의 이름입니다.
  • [NUMBER|PERCENTAGE]는 이 업데이트에 대해 카나리아 테스트를 수행할 인스턴스의 고정된 숫자나 백분율입니다. 인스턴스 그룹에 인스턴스가 10개 이상 있는 경우에만 백분율을 설정할 수 있습니다. 그렇지 않으면 고정된 숫자를 대신 제공합니다.
  • [CURRENT_TEMPLATE]은 인스턴스 그룹이 실행 중인 현재 템플릿의 이름입니다.

카나리아 업데이트 롤포워드하기

카나리아 업데이트를 실행한 후 업데이트를 인스턴스 그룹의 100%로 커밋할지 아니면 롤백할지 결정할 수 있습니다.

Console

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

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

  2. 업데이트할 인스턴스 그룹을 선택합니다.
  3. 페이지 상단에서 순차적 업데이트를 클릭합니다.
  4. 템플릿 아래에서 카나리아 템플릿의 대상 크기를 100%로 업데이트하여 템플릿을 모든 인스턴스로 롤포워드합니다. 또는 기본 템플릿을 카나리아 템플릿으로 바꾸고 대상 크기를 100%로 설정해도 됩니다. 그런 다음 두 번째 템플릿 필드를 완전히 삭제할 수 있습니다.
  5. 업데이트를 클릭하여 업데이트를 시작합니다.

gcloud

카나리아 업데이트에 커밋하려면 동일한 업데이트를 만든 후 version만 설정하고 --canary-version은 생략하여 업데이트를 롤포워드합니다. gcloud 명령줄 도구를 사용합니다.

gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[NEW_TEMPLATE] [--zone [ZONE] | --region [REGION]]

API

API에서 다음 URI에 PATCH를 요청합니다.

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

요청 본문에서 새 인스턴스 템플릿을 version으로 지정하고 요청 본문에서 이전 인스턴스 템플릿을 생략합니다. 업데이트를 인스턴스의 100%로 롤아웃하려면 대상 크기 사양을 생략합니다. 예를 들어 요청 본문은 다음과 같습니다.

{
"versions": [
   {
   "instanceTemplate": "global/instanceTemplates/[NEW_TEMPLATE]" # New instance template
   }
 ]
}

[NEW_TEMPLATE]을 롤포워드할 새 인스턴스 템플릿으로 바꿉니다.

상황별 또는 사전형 업데이트 시작하기

기본적으로 gcloud 명령줄 도구를 사용하여 수행한 업데이트는 사전형이고, API에서 시작된 업데이트는 상황별입니다.

사전형 업데이트의 경우 Compute Engine은 필요에 따라 요청된 업데이트를 인스턴스에 적용하기 위해 작업을 적극적으로 예약합니다. 대부분의 경우 이는 사전에 인스턴스를 삭제하고 재작성하는 것을 의미합니다.

사전형 업데이트가 중단을 너무 많이 유발할 가능성이 있는 경우 상황별 업데이트를 수행하도록 선택할 수 있습니다. 상황별 업데이트는 선택된 인스턴스에서 업데이트를 수동으로 시작할 때 또는 관리형 인스턴스 그룹이 새 인스턴스를 만들 때만 적용됩니다. 관리형 인스턴스 그룹은 자동 확장 처리 등의 다른 서비스에 의해 관리형 인스턴스 그룹의 크기가 조정되거나 사용자가 수동으로 관리형 인스턴스 그룹의 크기를 조정하는 경우에 새 인스턴스를 만듭니다. Compute Engine은 상황별 업데이트 적용 요청을 적극적으로 시작하지 않습니다.

일부 시나리오에서는 가능하면 시스템을 안정적으로 유지하려고 하는 상황별 업데이트가 유용할 수 있습니다. 예를 들어, 긴급하지 않고 필요에 따라 적용할 수 있는 중요하지 않은 업데이트와 자동 확장 중인 관리형 인스턴스 그룹이 있는 경우 Compute Engine에서 업데이트 적용을 위해 기존 인스턴스를 적극적으로 삭제하지 않도록 상황별 업데이트를 수행합니다.

업데이트가 상황별인지 아니면 사전형인지 선택하려면 gcloud 명령줄 도구나 API를 사용하여 유형 속성을 OPPORTUNISTIC 또는 PROACTIVE로 설정합니다.

Console

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

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

  2. 업데이트할 인스턴스 그룹을 선택합니다.
  3. 페이지 상단에서 순차적 업데이트를 클릭합니다.
  4. 템플릿 아래에서 인스턴스 그룹을 업데이트할 템플릿을 선택하고 템플릿의 대상 크기를 선택합니다.
  5. 업데이트 모드 아래에서 상황별 업데이트나 사전형 업데이트를 선택합니다.
  6. 업데이트를 클릭하여 업데이트를 시작합니다.

gcloud

gcloud 명령줄 도구를 사용합니다.

gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[INSTANCE_TEMPLATE] \
    --type [opportunistic|proactive] [--zone [ZONE] | --region [REGION]]

API

업데이트를 시작하려는 요청 페이로드에서 updatePolicytype 속성을 포함합니다.

{
"updatePolicy": {
  "type": "PROACTIVE" # Performs a proactive update
},
"versions": [{
  "instanceTemplate": "global/instanceTemplates/[NEW_TEMPLATE]",
  }]
}

여기에서 [NEW_TEMPLATE]은 카나리아 테스트를 수행할 새 템플릿의 이름입니다. 상황별 업데이트를 원하는 경우 PROACTIVEOPPORTUNISTIC으로 바꿉니다.

선택한 인스턴스 업데이트

상황별 업데이트를 시작할 때는 상황이 발생하면 Compute Engine에서 업데이트를 롤아웃할 때까지 기다려야 합니다. 그러나 보다 효과적인 롤아웃 제어가 필요한 경우 관리형 인스턴스 그룹의 특정 인스턴스에서 즉시 해당 업데이트를 수동으로 시작할 수 있습니다.

수동으로 업데이트를 시작하면 다음을 수행할 수 있습니다.

  • 업데이트할 인스턴스를 선택합니다.
  • 업데이트를 완료하는 데 필요한 중단을 최소화하여 업데이트를 적용합니다. 예를 들어 메타데이터만 업데이트할 경우 업데이트를 완료하기 위해 인스턴스를 다시 시작할 필요가 없습니다. 업데이트를 수동으로 시작할 때는 최소 필요한 작업만 자동으로 수행됩니다.
  • 이러한 작업이 업데이트를 적용하는 데 필요하지 않은 경우에도 인스턴스를 다시 시작하거나 다시 생성해야 합니다. 예를 들어 게스트 소프트웨어가 VM 부팅 시 새 메타데이터를 적용해야 하므로 메타데이터만 업데이트하는 경우에도 VM을 다시 시작해야 할 수 있습니다.
  • 예상보다 더 많은 중단이 필요한 업데이트는 피합니다.
  • maxSurgemaxUnavailable 제약조건을 통해 롤아웃을 제한하지 않고 선택된 모든 인스턴스의 업데이트를 즉시 수행합니다.

최소한의 작업과 중단 요구가 가장 많은 작업

업데이트의 특성에 따라 인스턴스의 상태가 중단될 수 있습니다. 예를 들어 인스턴스의 머신 유형을 변경하려면 VM을 다시 시작해야 하지만 부팅 이미지를 변경할 때는 인스턴스를 삭제하고 바꿔야 합니다.

minimal-actionmost-disruptive-allowed-action 플래그를 사용하면 중단 수준을 제어할 수 있습니다.

  • minimal-action을 사용하면 필요 이상으로 더 많이 중단을 유발할 수 있습니다.
  • most-disruptive-allowed-action은 감당할 수 있는 수준보다 더 많이 중단을 유발하는 업데이트를 피할 수 있습니다.

선택한 인스턴스를 업데이트할 때 이 플래그는 모두 다음 작업을 허용합니다.

작업설명업데이트할 인스턴스 속성
NONE인스턴스를 전혀 중단하지 않습니다.없음
REFRESH인스턴스를 중지하지 않습니다.보조 디스크, 인스턴스 메타데이터, 라벨
RESTART인스턴스를 중지한 후 다시 시작합니다.머신 유형
REPLACE인스턴스를 삭제하고 다시 만듭니다.인스턴스 템플릿에 저장된 모든 인스턴스 속성

기본적으로 minimal-actionNONE입니다. 업데이트에 이 플래그로 설정한 것보다 더 많이 중단을 유발하는 작업이 필요한 경우 Compute Engine이 업데이트를 실행하는 데 필요한 작업을 수행합니다.

most-disruptive-allowed-action의 기본값은 REPLACE입니다. 업데이트에 이 플래그로 설정한 것보다 더 많이 중단을 유발하는 작업이 필요한 경우 업데이트 요청이 실패합니다. 예를 들어 '다시 시작'을 중단 요구가 가장 많은 작업으로 설정하면 부팅 디스크 이미지 업데이트 시도는 실패하게 됩니다. 이는 해당 업데이트가 다시 시작하는 것보다 더 많이 중단을 유발하는 인스턴스 재생성이 필요하기 때문입니다.

gcloud 도구 또는 API로 선택한 인스턴스를 업데이트할 수 있습니다.

gcloud

상황별 업데이트를 시작한 후, update-instances 서브커맨드를 사용하여 특정 인스턴스에 업데이트를 적용할 수 있습니다.

gcloud beta compute instance-groups managed update-instances [INSTANCE_GROUP] \
    --instances [INSTANCE_NAMES] \
    --most-disruptive-allowed-action [DISRUPTION_LEVEL] \
    --minimal-action [DISRUPTION_LEVEL]

각 항목의 의미는 다음과 같습니다.

  • [INSTANCE_GROUP]은 대기 중인 업데이트가 있는 인스턴스 그룹의 이름입니다.
  • [INSTANCE_NAMES]는 즉시 업데이트할 인스턴스 목록입니다.
  • [DISRUPTION_LEVEL]은 최소 또는 최대 중단 수준(NONE, REFRESH, RESTART, REPLACE)입니다.
    • minimal-action의 기본값은 NONE입니다.
    • most-disruptive-allowed-action의 기본값은 REPLACE입니다.

지정된 인스턴스가 모두 업데이트될 때까지 기다려야 하는 경우 그룹의 상태를 확인하고 그룹이 안정될 때까지 기다리세요.

API

상황별 업데이트를 시작한 후에는 베타 regionInstanceGroupManagers.applyUpdatesToInstances 메서드에 대해 POST 요청을 생성합니다. 영역 관리형 인스턴스 그룹의 경우 영역 instanceGroupManagers.applyUpdatesToInstances 메서드를 사용합니다.

POST https://www.googleapis.com/compute/beta/projects/[PROJECT]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/applyUpdatesToInstances
{
  "instances": "zones/[ZONE]/instances/[INSTANCE_NAME]","zones/[ZONE]/instances/[INSTANCE_NAME]"
  "minimalAction": [DISRUPTION_LEVEL],
  "mostDisruptiveAllowedAction": [DISRUPTION_LEVEL]
}

각 항목의 의미는 다음과 같습니다.

  • [INSTANCE_GROUP_NAME]은 대기 중인 업데이트가 있는 인스턴스 그룹의 이름입니다.
  • [ZONE]은 즉시 업데이트할 인스턴스의 영역입니다.
  • [INSTANCE_NAME]은 즉시 업데이트할 인스턴스의 이름입니다.
  • [DISRUPTION_LEVEL]은 최소 또는 최대 중단 수준(NONE, REFRESH, RESTART, REPLACE)입니다.
    • minimalAction의 기본값은 NONE입니다.
    • mostDisruptiveAllowedAction의 기본값은 REPLACE입니다.

다른 관리형 인스턴스 그룹 메서드와 마찬가지로 applyUpdatesToInstances는 인텐트 기반이므로 작업 응답을 반환합니다. 작업이 DONE이면 listManagedInstances에는 REFRESHING, RESTARTING 또는 RECREATING로 변경된 currentAction 필드의 인스턴스 목록이 포함됩니다. 예를 들어 그룹 내 동시 변경사항으로 인해 작업 필드가 실패하면 lastAttempt.errors 필드에 오류가 기록됩니다.

지정된 인스턴스가 모두 업데이트될 때까지 기다려야 하는 경우 그룹의 상태를 확인하고 그룹이 안정될 때까지 기다리세요.

순차적 교체 또는 재시작 수행하기

restart 또는 replace 명령어를 사용하여 관리형 인스턴스 그룹에서 VM 인스턴스의 지속적 재시작 또는 지속적 교체를 수행할 수도 있습니다. start-update 명령어와 비슷하게 재시작 또는 교체를 위한 구성 옵션을 지정할 수 있습니다. 지속적 재시작 또는 교체는 인스턴스 템플릿을 비롯하여 인스턴스 그룹에서 아무것도 변경하지 않습니다. 사용자가 선택하는 방법을 사용하여 그룹의 인스턴스를 새로 고치기만 합니다.

지속적 교체나 지속적 재시작을 원하는 이유는 많습니다. 예를 들어, 가끔 VM 인스턴스를 새로 고치려고 할 수 있습니다.

  • 메모리 누수 문제를 해결합니다.
  • 새로운 머신에서 실행될 수 있게 애플리케이션을 다시 시작합니다.
  • 정기적 교체를 VM 테스트의 권장사항으로 정합니다.
  • VM의 운영체제 이미지를 업데이트하거나 시작 스크립트를 다시 실행하여 소프트웨어를 업데이트합니다.

모든 인스턴스가 삭제되고 새 인스턴스로 바뀌는 교체를 수행하는 방법은 다음과 같습니다.

Console

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

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

  2. 업데이트할 인스턴스 그룹을 선택합니다.
  3. 페이지 상단에서 지속적 재시작/교체를 클릭합니다.
  4. 인스턴스를 재시작할지 아니면 교체할지 선택합니다. 재시작하면 인스턴스에서 stopstart 메서드가 실행되고, 교체하면 인스턴스가 삭제되고 생성됩니다.
  5. 필요에 따라 최대 초과 개수, 최대 사용 불가능 옵션, 최소 대기 시간과 같은 구성 옵션을 전환할 수 있습니다.
  6. 재시작 또는 교체 버튼을 클릭하여 업데이트를 시작합니다.

gcloud

gcloud compute instance-groups managed rolling-action replace [INSTANCE_GROUP]

이 명령어는 관리형 인스턴스 그룹의 모든 인스턴스를 한 번에 하나씩 교체합니다. 전체 교체가 중단을 너무 많이 유발하는 경우 인스턴스를 삭제하지 않고 각 인스턴스를 재시작하기만 하는 지속적 재시작을 지정할 수 있습니다.

gcloud compute instance-groups managed rolling-action restart [INSTANCE_GROUP]

업데이트에 사용 가능한 동일한 옵션으로 각 명령어를 더 자세히 맞춤설정할 수 있습니다(예: maxSurge, maxUnavailable, min-ready).

API

API에서 그룹에 대해 PATCH를 요청하고 사전형 updatePolicy를 설정합니다. 여기에서 minimalAction은 각 인스턴스가 삭제되고 새 인스턴스로 바뀌는 지속적 교체와 각 인스턴스가 중지되었다가 재시작되는 지속적 재시작 중 무엇을 수행할지에 따라 RESTART 또는 REPLACE입니다. RESTARTREPLACE 모두 항상 작업 트리거를 위해 versions.instanceTemplateversions.name 속성(예: v2)을 제공해야 합니다.

지속적 교체는 다음과 같습니다.

PATCH https://www.googleapis.com/compute/v1/projects/myproject/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

{
 "updatePolicy": {
  "minimalAction": "REPLACE",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/example-template",
   "name": "v2"
  }
 ]
}

지속적 재시작의 경우:

PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

{
 "updatePolicy": {
  "minimalAction": "RESTART",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/example-template",
   "name": "v2"
  }
 ]
}

추가 교체/재시작 예

한 번에 2개씩 모든 가상 머신의 지속적 재시작 수행

이 명령어는 인스턴스 그룹의 모든 가상 머신을 한 번에 2개씩 재시작합니다. 새 인스턴스 템플릿이 지정되어 있지 않습니다.

gcloud compute instance-groups managed rolling-action restart [INSTANCE_GROUP_NAME] \
    --max-unavailable 2 [--zone [ZONE] | --region [REGION]]

가능한 한 빨리 모든 VM 지속적 재시작

gcloud compute instance-groups managed rolling-action restart [INSTANCE_GROUP_NAME] \
    --max-unavailable 100% [--zone [ZONE] | --region [REGION]]

가능한 한 빨리 모든 VM 지속적 교체

gcloud compute instance-groups managed rolling-action replace [INSTANCE_GROUP_NAME]  \
    --max-unavailable 100% [--zone [ZONE] | --region [REGION]]

리전 관리형 인스턴스 그룹 업데이트하기

한 영역의 인스턴스만 들어 있는 영역별 관리형 인스턴스 그룹과 반대로, 리전 관리형 인스턴스 그룹에는 한 리전 내의 여러 영역에 분포된 가상 머신 인스턴스가 들어 있습니다. 리전 관리형 인스턴스 그룹을 사용하면 여러 영역에 인스턴스를 배포하여 애플리케이션의 가용성을 높일 수 있으며 한 영역에서 오류가 발생하거나 전체 인스턴스 그룹이 응답하지 않는 극단적인 경우를 지원할 수 있습니다.

인스턴스 그룹 업데이터 기능을 사용하여 리전 관리형 인스턴스 그룹을 업데이트하는 것은 아래 설명된 몇 가지 예외를 제외하고는 영역 관리형 인스턴스 그룹에 대해 업데이트를 수행하는 것과 동일합니다. 리전 인스턴스 그룹에 대한 업데이트를 시작하면 업데이터가 항상 각 영역에 균등하게 비례적으로 인스턴스를 업데이트합니다. 어느 영역의 어느 인스턴스를 먼저 업데이트할지 선택하거나 한 영역의 인스턴스만 업데이트할 수 없습니다.

리전 관리형 인스턴스 그룹 업데이트와 영역 관리형 인스턴스 그룹 업데이트의 차이

리전 관리형 인스턴스 그룹의 업데이트를 시작하기 전에 영역별 관리형 인스턴스 그룹과 다르게 동작하는 항목이 많다는 점을 알고 있어야 합니다.

  • 리전 관리형 인스턴스 그룹의 기본 업데이트 매개변수는 maxUnavailable=[NUMBER_OF_ZONES]maxSurge=[NUMBER_OF_ZONES]이며, 여기서 [NUMBER_OF_ZONES]는 지역별 관리형 인스턴스 그룹에 선택된 영역 수입니다(기본값: 3).

  • 업데이트를 지정할 때 고정된 숫자를 사용하는 경우 고정된 숫자는 0이거나 리전 관리형 인스턴스 그룹과 연결된 영역 수보다 크거나 같아야 합니다. 예를 들어 인스턴스 그룹이 3개 영역에 분산된 경우 업데이터가 3개의 각 영역에 추가 인스턴스를 만들어야 하므로 maxSurge1이나 2로 설정할 수 없습니다.

업데이트 요청에 고정된 숫자 또는 백분율 사용하기

업데이트 요청에 고정된 숫자를 지정하면 해당 숫자는 리전 관리형 인스턴스 그룹의 영역 수로 나뉘고 균등하게 배포됩니다. 예를 들어 maxSurge=10을 지정하면 리전의 영역 수에 10개의 인스턴스를 나누고 해당 숫자를 기반으로 새 인스턴스를 만듭니다. 인스턴스의 수가 영역에서 균등하게 분할되지 않으면 업데이터가 추가 인스턴스를 임의 영역에 추가합니다. 예를 들어 3개 영역에 10개의 인스턴스를 나누는 경우 두 영역이 3개의 인스턴스를 받고 한 영역은 4개의 인스턴스를 받습니다. 동일한 로직이 카나리아 업데이트의 maxUnavailabletargetSize 매개변수에 적용됩니다.

인스턴스 그룹에 인스턴스가 10개 이상 있는 경우에만 백분율을 지정할 수 있습니다. 백분율은 상황에 따라 약간 다르게 처리됩니다.

  • 카나리아 업데이트에 대한 VM 인스턴스의 백분율을 지정하면 업데이터가 인스턴스를 여러 영역에 균등하게 배포하려고 시도합니다. 나머지는 각 영역에서 올림 또는 내림되지만 전체 차이는 그룹당 VM 인스턴스 1개를 넘지 않습니다. 예를 들어 인스턴스가 10개이고 대상 크기(백분율)가 25%인 관리형 인스턴스 그룹의 경우 2~3개의 VM 인스턴스로 업데이트가 롤아웃됩니다.

  • maxSurgemaxUnavailable과 같은 업데이트 옵션에 대해 백분율을 지정하는 경우 백분율이 영역마다 독립적으로 반올림됩니다. 영역 관리형 인스턴스 그룹 업데이트에 적용되는 동일한 규칙이 여기에도 적용됩니다.

업데이트 모니터링하기

순차적 업데이트를 시작한 후에는 업데이트가 완료되는 데 약간의 시간이 걸릴 수 있습니다. 관리형 인스턴스 그룹의 status를 검사하거나 관리형 인스턴스 그룹의 각 인스턴스에서 currentAction을 확인하여 업데이트 과정을 모니터링할 수 있습니다.

그룹 상태

그룹 수준에서 Compute Engine은 versionTarget.isReached 플래그와 isStable 플래그가 포함된 status라는 읽기 전용 필드를 채웁니다. gcloud 도구 또는 API를 사용하여 이러한 플래그에 액세스할 수 있습니다.

인스턴스 그룹에 대한 업데이트가 롤아웃을 완료했는지 확인하려면 status.versionTarget.isReached==true를 확인하세요. 그룹의 모든 인스턴스가 실행 중이고 정상 상태인지 확인(즉, 각 관리형 인스턴스의 currentActionNONE임)하려면 status.isStable==true를 확인하세요. 관리형 인스턴스 그룹의 안정성은 업데이터 이외의 그룹 구성에 따라 달라집니다. 예를 들어 그룹이 자동 확장되는 경우와 그룹이 자동 확장 처리 작업으로 인해 확장 중이고 isStable==false인 경우의 차이입니다.

Console에서도 업데이트 중인 현재 및 대상 인스턴스 수를 확인할 수 있습니다.

Console

특정 인스턴스 그룹의 세부정보 페이지로 이동하여 그룹의 순차적 업데이트를 모니터링할 수 있습니다.

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

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

  2. 모니터링할 인스턴스 그룹을 선택합니다. 인스턴스 그룹의 개요 페이지에 각 인스턴스가 사용 중인 템플릿이 표시됩니다.
  3. 세부정보를 보려면 세부정보 탭을 클릭합니다.

세부정보 페이지에 인스턴스 템플릿별로 업데이트 중인 인스턴스의 현재 및 목표 수와 업데이트 매개변수가 표시됩니다.

gcloud

gcloud compute instance-groups managed describe [INSTANCE_GROUP_NAME] \
    [--zone [ZONE] | --region [REGION]]

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

API

API에서 다음 URI에 대해 POST 요청을 실행합니다.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/get

인스턴스 그룹이 리전 관리형 인스턴스 그룹인 경우 zones/[ZONE]regions/[REGION]으로 바꿉니다.

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

status.versionTarget.isReached

그룹의 모든 VM 인스턴스가 대상 버전에서 생성되었거나 생성 중이면 업데이트 롤아웃이 완료된 것으로 간주됩니다. 전체 롤아웃의 경우 모든 인스턴스가 새 인스턴스 템플릿을 사용하도록 구성됩니다. 부분 롤아웃인 경우 인스턴스는 인스턴스 템플릿별로 분리된 특정 대상에 따라 구성됩니다.

instanceGroupManagers(또는 regionInstanceGroupManagers) 리소스의 status.versionTarget.isReached 필드 값을 확인하여 업데이트 롤아웃의 완료 여부를 확인할 수 있습니다.

모든 VM 인스턴스가 대상 버전(versions[])에서 생성되었거나 생성 중이면 status.versionTarget.isReachedtrue로 설정됩니다.

하나 이상의 VM이 아직 대상 버전(versions[])을 사용하지 않은 경우 status.versionTarget.isReachedfalse로 설정됩니다. 카나리아 업데이트의 경우 대상 버전(versions[].instanceTemplates)을 사용하는 VM 수가 대상 크기(versions[].targetSize)와 일치하지 않으면 status.versionTarget.isReachedfalse로 설정됩니다.

gcloud beta compute instance-groups managed wait-until 명령어를 --version-target-reached 플래그와 함께 사용하여 그룹의 status.versionTarget.isReachedtrue로 설정될 때까지 기다릴 수도 있습니다.

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

status.isStable

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

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

status.isStabletrue로 설정되면 다음을 의미합니다.

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

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

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

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

gcloud beta compute instance-groups managed wait-until 명령어를 --stable 플래그와 함께 사용하여 그룹의 status.isStabletrue로 설정될 때까지 기다릴 수도 있습니다.

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

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

gcloud 명령줄 도구 또는 API를 사용하여 실행되는 currentAction과 관리형 인스턴스 그룹의 각 인스턴스 status를 볼 수 있습니다.

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           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://www.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: 인스턴스에서 실행 중인 작업이 없습니다.

인스턴스가 성공적으로 업데이트되면 instanceStatus 필드에 인스턴스의 현재 상태가 반영됩니다.

업데이트 롤백

이전 버전으로 업데이트를 롤백하기 위한 명시적인 명령어는 없지만 새 업데이트를 요청하고 롤백 대상 인스턴스 템플릿을 전달하여 완전히 커밋된 업데이트나 카나리아 업데이트를 롤백할 수 있습니다.

예를 들어 다음 명령어는 최대한 빨리 업데이트를 롤백합니다.

gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
    --version template=[OLD_INSTANCE_TEMPLATE] --max-unavailable 100% [--zone [ZONE] | --region [REGION]]

[OLD_INSTANCE_TEMPLATE]을 롤백 대상으로 사용할 기존 인스턴스 템플릿의 이름으로 바꿉니다.

API에서 다음 URI에 PATCH를 요청합니다.

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

인스턴스 그룹이 리전 관리형 인스턴스 그룹인 경우 zones/[ZONE]regions/[REGION]으로 바꿉니다.

요청 본문에서 이전 인스턴스 템플릿을 version으로 지정합니다.

{ "updatePolicy":
  {
    "maxUnavailable":
    {
      "percent": 100
    }
  },
 "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/[OLD_TEMPLATE]" # Old instance template
    }
   ]
}

리전 관리형 인스턴스 그룹에 10개 미만의 인스턴스가 있으면 maxUnavailable에 고정 값을 사용하고 이 값을 그룹에 속한 인스턴스 수로 설정해야 합니다.

{ "updatePolicy":
  {
    "maxUnavailable":
    {
      "fixed": [NUMBER_OF_INSTANCES_IN_GROUP]
    }
  },
 "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/[OLD_TEMPLATE]" # Old instance template
    }
   ]
}

인스턴스 그룹 업데이터 서비스는 이를 일반 업데이트 요청으로 처리하므로 이 문서에서 설명하는 모든 업데이트 옵션을 요청에 지정할 수 있습니다.

업데이트 속도 제어하기

기본적으로 업데이트 요청을 실행하면 서비스가 최대한 빨리 업데이트를 수행합니다. 업데이트를 완전히 적용할지 아니면 변경사항을 시험 삼아 테스트할지 잘 모르겠으면 다음 방법을 사용하여 업데이트 속도를 제어할 수 있습니다.

  1. 전체 업데이트가 아닌 카나리아 업데이트를 시작합니다.
  2. minReadySeconds 값을 크게 설정합니다. 이 값을 설정하면 인스턴스가 성공적으로 업데이트되었다고 간주하고 다음 인스턴스로 진행하기에 앞서 서비스가 해당 시간(초) 동안 대기합니다.
  3. 상태 확인을 사용 설정하면 인스턴스가 성공적으로 업데이트되었다고 간주하고 다음 인스턴스로 진행하기에 앞서 서비스가 애플리케이션이 시작되고 상태 신호를 보고할 때까지 대기합니다.
  4. maxUnavailablemaxSurge 값을 낮게 설정합니다. 그러면 한 번에 최소한의 인스턴스만 업데이트됩니다.
  5. 수동으로 특정 인스턴스에서 업데이트를 시작하여 해당 인스턴스를 즉시 업데이트할 수 있습니다.

매개변수를 조합해서 사용하여 업데이트 속도를 제어할 수도 있습니다.

업데이트 중지하기

업데이트를 중지하는 명시적 메서드나 명령어는 없습니다. 사전형에서 상황별로 업데이트를 변경할 수 있으며 자동 확장 처리 등의 다른 서비스에서 관리형 인스턴스 그룹의 크기를 조정하지 않는 경우 상황별로 변경하면 업데이트가 효과적으로 '중지'됩니다.

사전형에서 상황별로 변경하려면 다음 명령어를 실행하세요.

gcloud compute instance-groups managed rolling-action stop-proactive-update [INSTANCE_GROUP_NAME] \
    [--zone [ZONE] | --region [REGION]]

사전형에서 상황별로 변경한 후 업데이트를 완전히 중지하기로 결정한 경우 다음 단계에 따라 업데이트를 중지할 수 있습니다.

  1. 업데이트된 인스턴스 수를 확인하도록 요청합니다.

    gcloud compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] \
        [--zone [ZONE] | --region [REGION]]

    gcloud 도구는 인스턴스 그룹의 인스턴스 목록과 현재 상태가 포함된 응답을 반환합니다.

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

    이 예에서는 2개의 인스턴스가 이미 업데이트되었습니다.

  2. 다음으로 새 '업데이트'를 요청하지만 대상 크기로 이미 업데이트된 인스턴스 수를 전달합니다.

    gcloud compute instance-groups managed rolling-action start-update [INSTANCE_GROUP_NAME] \
        --version template=my-old-template \
        --canary-version template=my-new-template,target-size=2 \
        [--zone [ZONE] | --region [REGION]]

    업데이터 서비스에 이 업데이트는 '완료'로 나타나므로 다른 인스턴스는 업데이트되지 않고 업데이트를 효과적으로 중지합니다.

관리형 인스턴스 그룹의 version 및 instanceTemplate 속성 간의 관계

versions 필드를 사용하여 관리형 인스턴스 그룹의 인스턴스 템플릿을 구성하는 것이 좋습니다.

기존 instanceTemplate 필드와 versions 필드는 모두 관리형 인스턴스 그룹이 새 인스턴스를 생성하는 데 사용할 인스턴스 템플릿을 지정하므로 기능이 중복됩니다. 그러나 versions 필드만 사용하면 2개의 고급 템플릿 (카나리아) 구성을 지정할 수 있습니다.

이전 버전과의 호환성을 위해 versions 필드만 사용하도록 전환하는 것도 좋지만 관리형 인스턴스 그룹은 최상위 instanceTemplate 필드 설정도 계속 지원합니다. 두 필드를 동시에 사용하면 모호해지고 혼란스러워집니다.

update() 또는 patch() 메서드 호출 시 instanceTemplate 필드와 versions 필드를 모두 지정하면 다음과 같은 3가지 상황이 발생할 수 있습니다.

  • 두 필드 모두 동일한 값으로 설정합니다.

    유효한 요청입니다. 이 경우 모호해지지 않으며 새 인스턴스 템플릿이 관리형 인스턴스 그룹에 적용됩니다.

    예를 들어 다음 요청에서 최상위 instanceTemplateversions 필드는 기존 현재 템플릿과 다른 동일한 인스턴스 템플릿을 지정합니다. 관리형 인스턴스 그룹이 새 인스턴스 템플릿으로 업데이트됩니다.

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • 일치하지 않는 두 필드를 모두 설정하지만 하나의 값만 관리형 인스턴스 그룹의 현재 인스턴스 템플릿과 다릅니다.

    유효한 요청입니다. 현재 설정과 다른 필드가 의도한 값으로 사용됩니다. 예를 들어 get() 메서드를 호출하고 두 필드 중 하나를 변경한 다음 하나의 변경된 필드만 사용하여 update()를 호출합니다.

    {
     "instanceTemplate": "global/instanceTemplates/current-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • 두 필드를 모두 설정하지만 두 필드가 일치하지 않고 값이 다르며 두 값 모두 관리형 인스턴스 그룹의 현재 인스턴스 템플릿과 다릅니다.

    이 설정은 유효하지 않으며 명확한 의도가 없으므로 오류를 반환합니다.

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/a-different-new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    

versions 필드, instanceTemplate 필드, get() 메서드

최상위 instanceTemplate 필드나 versions 필드 또는 둘 다를 통해 하나의 인스턴스 템플릿만 지정하는 경우 get() 메서드가 응답으로 두 필드를 모두 반환합니다. 이렇게 하면 새 versions 필드가 이전 버전과 호환됩니다. 이 두 필드 중 하나에 단일 인스턴스 템플릿을 지정하면 get()instanceTemplate 필드에서 반환하는 내용에 변화가 없습니다.

versions 필드에 2개의 인스턴스 템플릿이 지정된 경우 get() 메서드가 빈 최상위 instanceTemplate 필드를 반환합니다. 카나리아 업데이트 중에 필드가 사용되지 않도록 최상위 instanceTemplate 필드에 두 인스턴스 템플릿 구성을 명확하게 표현할 수 있는 방법은 없습니다.

versions 필드 및 setInstanceTemplate() 메서드

이전 버전과의 호환성을 위해 setInstanceTemplate() 메서드는 이전과 동일하게 동작하므로 관리형 인스턴스 그룹이 새 인스턴스를 만드는 데 사용하는 템플릿을 변경할 수 있습니다. 이 메서드를 호출하면 versions 필드가 setInstanceTemplate() 메서드로 지정된 인스턴스 템플릿으로 재정의됩니다.

또한 이 메서드는 updatePolicyOPPORTUNISTIC으로 설정합니다. 그러면 관리형 인스턴스 그룹에서 versions 필드에 명시적으로 지정되지 않은 인스턴스 템플릿을 적극적으로 배포하는 것을 방지할 수 있습니다.

다음 단계

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

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

Compute Engine 문서