MIG で VM 構成の更新を自動的に適用する

このドキュメントでは、マネージド インスタンス グループ（MIG）の仮想マシン（VM）インスタンスに構成の更新を自動的に適用する方法について説明します。

Compute Engine は、使用する構成コンポーネント（インスタンス テンプレート、オプションのすべてのインスタンス構成、オプションのステートフル構成）に基づいて MIG 内の VM を維持します。

コンポーネントを変更して MIG の VM 構成を更新すると、Compute Engine は更新された構成を、グループに追加された新しい VM に自動的に適用します。

更新された構成を既存の VM に適用するには、自動更新（先行型更新タイプとも呼ばれます）を設定します。MIG は、グループの VM のすべてまたは一部に構成の更新を自動的にロールアウトします。デプロイの速度、サービス中断のレベルを制御できます。また、カナリア更新を使用することで、MIG が新しい構成で更新するインスタンスの数を制御できます。新しい構成を指定した後は、追加の入力を指定する必要はありません。更新は自動で完了します。

また、新しい構成を MIG の新しいインスタンスまたは特定のインスタンスのみに適用する場合は、MIG で VM 構成の更新を選択的に適用するをご覧ください。判断するには、既存の VM に新しい構成を適用する方法をご覧ください。

始める前に

• ステートフル MIG を更新する場合は、MIG でのステートフル構成の適用、表示、削除をご覧ください。
• まだ設定していない場合は、認証を設定します。認証とは、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

  2. Set a default region and zone.

  REST

  このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。

  Install the Google Cloud CLI, then initialize it by running the following command:

  gcloud init

  詳細については、Google Cloud 認証ドキュメントの REST を使用して認証するをご覧ください。

制限事項

• ステートフル MIG があり、自動ローリング アップデートを使用する場合は、インスタンスを置換するときにインスタンス名を保持するか、置換メソッドを RECREATE に設定する必要があります。

基本的なローリング アップデートの開始

基本的なローリング アップデートとは、すべてのインスタンスが意図する最新の構成に更新されるまで、MIG のすべてのインスタンスに段階的に適用されるアップデートです。ローリング アップデートでは、最新の構成にあるインスタンスが自動的にスキップされます。

更新中にオフラインにすることが可能なインスタンス数、インスタンス間での更新待機時間、新しいテンプレートの影響範囲（全体または一部）など、ローリング アップデートのさまざまな設定を制御できます。

ローリング更新の実行時に注意すべき点は以下のとおりです。

• 更新はインテント ベースです。最初の更新リクエストを行うと、Compute Engine API はリクエストが有効であることを確認するために成功のレスポンスを返しますが、これは更新が成功したことを示すものではありません。更新が正常にデプロイされたかどうかを判断するには、グループのステータスを確認する必要があります。

• Instance Group Updater API は宣言型 API です。この API は、明示的な関数呼び出しではなく、MIG の更新後に必要な構成を指定するためのリクエストを必要とします。

• 自動更新では、MIG で最大 2 つのインスタンス テンプレート バージョンをサポートしています。つまり、グループに 2 つの異なるインスタンス テンプレート バージョンを指定できます。これは、カナリアの更新を行う場合に便利です。

グループ内のすべてのインスタンスに更新を適用する基本的なローリング アップデートを開始するには、次の操作を行います。

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

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
  "updatePolicy": {
    "type": "PROACTIVE"
   }
}

リクエストを送った後、更新をモニタリングして、更新が完了したことを確認できます。

詳細な構成を行う場合は、その他の更新オプションを含めます。特に指定しない場合、maxSurge オプションと maxUnavailable オプションはデフォルトで 1 に影響を受けるゾーンの数を掛けたものになります。つまり、影響を受ける各ゾーン内では 1 つのインスタンスだけがオフラインになり、MIG は更新中にゾーンごとに 1 つの追加インスタンスのみを作成します。

更新のオプションの構成

より複雑な更新の場合は、次のセクションで説明するように、追加のオプションを構成できます。

タイプの更新

マネージド インスタンス グループでは、次の 2 種類の更新がサポートされています。

• 自動更新（先行型）
• 選択（便宜）

更新を自動的に適用するには、先行型タイプに設定します。

また、自動更新が大がかりになる可能性がある場合は、便宜更新の実行を選択できます。MIG は、選択したインスタンスの更新を手動で開始した場合、または新しいインスタンスが作成された場合にのみ、便宜更新を適用します。ご自身や別のサービス（オートスケーラーなど）で MIG をサイズ変更すると、新しいインスタンスが作成されます。既存のインスタンスで、便宜更新を適用するためのリクエストが Compute Engine から積極的に開始されることはありません。

自動更新と部分的更新の詳細については、既存の VM に新しい構成を適用する方法をご覧ください。

最大サージ

maxSurge オプションを使用すると、自動更新中に MIG が targetSize を超えて作成できる新しいインスタンスの数を構成できます。たとえば、maxSurge を 5 に設定すると、MIG は新しいインスタンス テンプレートを使用して、ターゲット サイズを超える最大 5 つの新しいインスタンスを作成します。maxSurge の値が大きくなるほど更新速度は上がりますが、インスタンスの追加による費用がかかります。この費用は Compute Engine の料金表に従って課金されます。

固定数を指定するか、マネージド インスタンス グループに 10 個以上のインスタンスがある場合は割合を指定できます。割合を設定した場合、Updater は必要に応じてインスタンス数の値を切り上げます。

maxSurge の値を設定していない場合は、デフォルト値が使用されます。ゾーン MIG の場合、maxSurge のデフォルトは 1 です。リージョン MIG の場合、デフォルトはグループに関連付けられたゾーンの数です。デフォルトでは 3 です。

maxSurge は、追加のリソースをサポートするために十分な割り当てまたはリソースがある場合に限り機能します。

更新で VM の置き換えが不要な場合、このオプションは無視されます。最小アクション オプションを設定すると、更新中に VM を強制的に置き換えることができます。

オフライン上限

maxUnavailable オプションを使用すると、自動更新中に常時利用できないインスタンスの数を構成できます。たとえば、maxUnavailable を 5 に設定すると、更新の際、同時にオフラインになるのは、5 つのインスタンスだけです。このパラメータを使用して、更新がサービスに与える影響の度合いと、更新をデプロイする速度を制御します。

この数値には、他の理由でオフラインになっているインスタンスの数も含まれます。たとえば、グループがサイズ変更の処理中である場合、作成中のインスタンスがオフラインになることがあります。このようなインスタンスの数は、maxUnavailable にカウントされます。

固定数を指定するか、グループに 10 個以上のインスタンスがある場合は割合を指定できます。割合を設定した場合、Updater は必要に応じてインスタンス数の値を切り下げます。

更新中に使用できないマシンをなくしたい場合は、maxUnavailable 値を 0 に設定し、maxSurge の値を 0 より大きい値に設定します。この設定を行うと、Compute Engine は、古いマシンの代替マシンを新規に作成して実行した後にのみ、古いマシンを削除します。

maxUnavailable の値を設定していない場合は、デフォルト値が使用されます。ゾーン MIG の場合、デフォルトは 1 です。リージョン MIG の場合、デフォルトはグループに関連付けられたゾーンの数です。デフォルトでは 3 です。

最小待機時間

minReadySec オプションを使用して、新しいインスタンスまたは再起動されたインスタンスを更新済みとみなすまでの待機時間を指定します。このオプションを使用して、自動更新がデプロイされるレートを制御します。タイマーは、次の条件がどちらも満たされると起動します。

• インスタンスのステータスが RUNNING である。
• ヘルスチェックが有効の場合、ヘルスチェックのときに HEALTHY が返される。

ヘルスチェックを行うにあたり、Updater は次の条件が満たされるのを待ちます。

1. ヘルスチェックで HEALTHY が返されるまで、MIG の autohealingPolicies.initialDelaySec 値で指定された時間まで待機します。
2. 次に、minReadySec で指定された時間待機します。

ヘルスチェックが initialDelaySec 内に HEALTHY を返さなければ、Updater は VM インスタンスを異常とみなし、場合によっては更新を停止します。VM インスタンスが initialDelaySec と minReadySec で指定された時間、検証を待機している間は、インスタンスの currentAction は VERIFYING になります。ただし、基礎となる VM インスタンスのステータスは RUNNING のままです。

グループのヘルスチェックが行われない場合、タイマーはインスタンスのステータスが RUNNING のときに起動します。

minReadySec フィールドの最大値は 3,600 秒（1 時間）です。

次の図は、ターゲット サイズ、オフライン上限、最大サージ、最小待機時間オプションがインスタンスにどのように影響するかを示しています。ターゲット サイズの詳細については、カナリア更新をご覧ください。

最小アクション

最小アクション オプションは、中断を可能な限り最小限に抑えるため、または必要以上に大がかりなアクションを適用するために使用します。たとえば、Compute Engine ではメタデータを変更するために VM を再起動する必要はありませんが、アプリケーションが VM の再起動時にのみインスタンス メタデータを読み取る場合は、メタデータの変更を取得するために、最小限のアクションを設定して再起動します。

このフラグで設定したアクションよりも大がかりなアクションが更新で必要となる場合、Compute Engine は更新に必要なアクションを実行します。たとえば、最小アクションとして再起動を指定すると、Updater は更新を適用するためにインスタンスの再起動を試みます。ただし、OS を変更する場合（インスタンスの再起動では実行できません）、Updater はグループ内のインスタンスを新しい VM インスタンスに置き換えます。

有効なオプションを含む詳細については、ローリング アップデート中の中断の制御をご覧ください。

許容される最も大がかりなアクション

許容可能なレベルを超える中断が必要な場合は、許容される最も大がかりなアクション オプションを使用して更新を回避します。この設定が原因で更新を完了できない場合、更新は失敗し、VM は以前の構成を維持します。

詳細については、ローリング アップデート中の中断レベルの制御をご覧ください。

置換メソッド

デフォルトでは、MIG をプロアクティブに更新すると、グループが VM インスタンスを削除し、新しい名前の新しいインスタンスに置き換えます。VM インスタンスの名前を保持する必要がある場合は、replacementMethod オプションを使用します。

特定のインスタンス名の使用に依存するアプリケーションやシステムがある場合は、既存のインスタンス名を保持することが役立つ場合があります。たとえば、Memcached などの一部のアプリケーションは、検出サービスがないためインスタンス名に依存しています。その結果、インスタンス名が変更されると、アプリケーションはその特定の VM への接続を失います。

インスタンス名を保持するには、gcloud CLI または Compute Engine API を使用して MIG を更新するときに、置換メソッドを SUBSTITUTE ではなく RECREATE に設定します。Google Cloud コンソールから MIG を更新する場合は、[インスタンスを置き換えるときにインスタンス名を維持する] チェックボックスをオンにします。

指定できる replacementMethod 値は次のとおりです。

• SUBSTITUTE（デフォルト）。古い VM がシャットダウンされる前に新しい VM が作成されるため、VM インスタンスは更新中にすばやく置換されます。ただし、古いインスタンスでまだ名前が使用されているため、インスタンス名は保持されません。

• RECREATE。更新を通してインスタンス名が保持されます。Compute Engine は、古い VM がシャットダウンされるとインスタンス名を解放します。その後、Compute Engine は同じ名前を使用して新しいインスタンスを作成します。このモードを使用するには、maxSurge を 0 に設定する必要があります。

詳細については、インスタンス名の保持をご覧ください。

追加の更新例

ここでは、一般的な構成オプションを使用したコマンドラインの例を示します。

すべての VM インスタンスのローリング アップデートを実行するが、ターゲット サイズを超える新しいインスタンスの作成は一度に 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 beta 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]

すべての VM インスタンスのローリング アップデートを実行するが、ターゲット サイズを超える新しいインスタンスの作成は一度に 10% までとする

たとえば、1,000 個のインスタンスがあり、次のコマンドを実行した場合、Updater は最大 100 個のインスタンスを作成してから、前のインスタンス テンプレートを実行しているインスタンスの削除を開始します。

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

カナリア更新

カナリア更新とは、グループ内のインスタンスのサブセットに適用される更新です。カナリア更新を使用すると、大がかりになる可能性のある更新をすべてのインスタンスにロールアウトするのではなく、ランダムなインスタンスのサブセットで新しい機能または更新をテストできます。更新がうまくいかない場合、単にインスタンスのサブセットをロールバックするだけで済み、ユーザーに対する影響を最小限に抑えることができます。

カナリア更新は、更新が必要なインスタンス数がインスタンス グループの合計サイズより小さい点を除いては、標準のローリング アップデートと同じです。標準のローリング アップデートと同様に、追加のオプションを構成してサービス中断のレベルを制御できます。

カナリア更新の開始

カナリア更新を開始するには、最大 2 つのインスタンス テンプレート バージョンを指定します。通常、カナリアに対しては新しいインスタンス テンプレートを、残りのインスタンスに対しては現在のインスタンス テンプレートを指定します。たとえば、NEW_INSTANCE_TEMPLATE に基づいてインスタンスの 20% が作成され、残りのインスタンスは引き続き OLD_INSTANCE_TEMPLATE で実行されるように指定できます。同時に指定できるインスタンス テンプレートは 2 つまでです。 NEW_INSTANCE_TEMPLATE は、MIG と同じリージョンのリージョン インスタンス テンプレートか、グローバル インスタンス テンプレートのいずれかです。

カナリア バージョンにはターゲット サイズ（targetSize）を常に指定する必要があります。カナリア バージョンのターゲット サイズを省略すると、カナリア更新を開始できません。たとえば、カナリア処理にインスタンスの 10% を使用するように指定した場合、残り 90% のインスタンスはそのままで、現在のインスタンス テンプレートが使用されます。

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

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

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/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_INSTANCE_TEMPLATE_NAME"
  }
 ]
}

その他のオプションについては、更新のオプションの構成をご覧ください。

リクエストを送った後、更新をモニタリングして、更新が完了したことを確認できます。

カナリア更新のロール フォワード

カナリア更新の実行後、すべての MIG への更新を commit するかロールバックするかを決定できます。

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

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

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

更新のモニタリング

更新を開始した後に、新しい更新に対して影響を受けるすべてのインスタンスへのロールアウトを完了するには時間がかかることがあります。更新の進捗状況は、以下をチェックしてモニタリングできます。

• すべての VM が目的のテンプレート バージョンに達したかどうかを確認するには、グループのステータスを表示します。
• 特定の VM がターゲット テンプレート バージョンに達したかどうかを確認するには、インスタンスでの現在のアクションを確認します。
• ステートフル MIG の場合は、インスタンスごとの構成が適用されているかどうかを確認するもご覧ください。

グループのステータス

グループレベルでは、Compute Engine により、versionTarget.isReached フラグと isStable フラグを含む status という読み取り専用フィールドに値が設定されます。これらのフラグには、gcloud CLI または REST を使用してアクセスできます。Google Cloud コンソールを使用して、現在更新中のインスタンス数とターゲット数を確認することもできます。

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

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

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME/get

更新の公開が完了したかどうかの確認

MIG の status.versionTarget.isReached フィールドの値を確認して、更新のロールアウトが完了したかどうかを確認します。

• status.versionTarget.isReached が true である場合、すべての VM インスタンスがターゲット バージョンを使用して作成済みまたは作成中であることを示します。

• status.versionTarget.isReached が false である場合、少なくとも 1 つの VM が、まだターゲット バージョンを使用していないことを示します。カナリア更新の場合、false は、ターゲット バージョンを使用する VM の数がターゲット サイズと一致しないことを示します。

マネージド インスタンス グループが安定しているかどうかの確認

status.isStable が false である場合は、変更がアクティブか、保留中か、MIG 自体が変更されていることを示します。

status.isStable が true の場合は、次のことを意味します。

• なんらかの変更が行われているインスタンスが MIG 内に 1 つもなく、すべてのインスタンスの currentAction が NONE となっている。
• 変更が保留中になっているインスタンスが MIG 内に 1 つもない。
• MIG 自体も変更されていない。

MIG はさまざまな方法で変更可能なため、MIG の安定性はさまざまな要因で変化します。例:

• 新しいインスタンス テンプレートのロールアウトをリクエストした。
• MIG 内のインスタンスの作成、削除、サイズ変更、または更新をリクエストした。
• オートスケーラーによって MIG のサイズ変更をリクエストした。
• 自動修復ツールリソースが MIG 内の正常な状態でないインスタンスを少なくとも 1 つ置き換えた。
• リージョン MIG で、一部のインスタンスが再分散された。

すべてのアクションが終了すると、その MIG の status.isStable が true に再び設定されます。

インスタンスでの現在のアクション

Google Cloud CLI または REST を使用して、マネージド インスタンス グループ内のインスタンスの詳細を表示します。詳細には、インスタンスのステータスと、グループがインスタンスで実行中の現在のアクションが含まれます。

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

NAME               ZONE           STATUS   HEALTH_STATE  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

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

currentAction: NONE
id: '6789072894767812345'
instance: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/instances/example-mig-hz41
instanceStatus: RUNNING
name: example-mig-hz41
preservedStateFromConfig:
  metadata:
    example-key: example-value
preservedStateFromPolicy:
  disks:
    persistent-disk-0:
      autoDelete: NEVER
      mode: READ_WRITE
      source: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/disks/example-mig-hz41
version:
  instanceTemplate: https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME/listManagedInstances

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

有効な instanceStatus フィールド値の一覧については、VM インスタンスのライフサイクルをご覧ください。

インスタンスがなんらかの種類の変更を実行している場合、マネージド インスタンス グループは、インスタンスの currentAction フィールドを次のいずれかのアクションに設定して、変更の進捗状況を追跡できるようにします。それ以外の場合、currentAction フィールドは NONE に設定されます。

有効な currentAction の値は次のとおりです。

• ABANDONING。インスタンスを MIG から削除中です。
• CREATING。インスタンスは作成中です。
• CREATING_WITHOUT_RETRIES。インスタンスが再試行なしで作成されています。インスタンスが最初の試行で作成されない場合、MIG はインスタンスの置換を行いません。
• DELETING。インスタンスは削除中です。
• RECREATING。インスタンスは置換中です。
• REFRESHING。インスタンスは現在のターゲット プールから削除中で、現在のターゲット プールのリスト（このリストは既存のターゲット プールと同じ場合も異なる場合もあります）に再度追加中です。
• RESTARTING。インスタンスは stop メソッドと start メソッドを使用して再起動中です。
• RESUMING。インスタンスは一時停止後に再開処理中です。
• STARTING。インスタンスは停止後に起動中です。
• STOPPING。インスタンスは停止の準備中です。
• SUSPENDING。インスタンスは一時停止の準備中です。
• VERIFYING。インスタンスは作成済みで、検証中です。
• NONE。インスタンスに対して実行されているアクションはありません。

更新のロールバック

更新を前のバージョンにロールバックする明示的なコマンドはありませんが、更新をロールバックする場合（完全な commit 更新またはカナリア更新）は、新しい更新リクエストを行い、ロールバック基準とするインスタンス テンプレートを渡すことで実現できます。

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

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

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

Updater は、通常の更新リクエストと同じようにロールバック リクエストを処理するため、追加の更新オプションを指定できます。

更新の停止

更新を停止する明示的な方法やコマンドはありません。更新はプロアクティブから日和見に変更できます。グループがオートスケーラーなどの他のサービスでサイズ変更されていない場合、日和見へ変更することで、更新を実質的に停止できます。

gcloud CLI を使用して、更新を先行型から便宜型に変更するには、次のコマンドを実行します。

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 CLI は、グループ内のインスタンスと現在のステータスのリストを含むレスポンスを返します。

   NAME               ZONE           STATUS   HEALTH_STATE  ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
   vm-instances-9pk4  us-central1-f  RUNNING  HEALTHY       NONE      example-new-template
   vm-instances-j1h8  us-central1-f  RUNNING  HEALTHY       NONE      example-old-template
   vm-instances-ngod  us-central1-f  STAGING  UNKNOWN       CREATING  example-new-template
   

   この例では、2 つのインスタンスがすでに更新されています。

2. 次に、新しい更新を実行するリクエストを作成しますが、すでに更新されているインスタンスの数をターゲット サイズとして渡します。

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

   Updater では、この更新は完了として示されるため、他のインスタンスは更新されず、更新は実質的に停止されます。

ローリング アップデートの速度の制御

デフォルトでは、更新リクエストを送ると、Updater はできる限り迅速に更新を実行します。更新を完全に適用するか、暫定的に変更をテストするか判断できない場合は、次の方法で更新速度を制御できます。

1. 完全な更新ではなく、カナリア更新を開始します。
2. minReadySec に大きい値を設定します。この値を設定すると、Updater はここで指定した秒数待機してから、インスタンスが正常に更新されたものとみなして次のインスタンスに進みます。
3. ヘルスチェックを有効化します。これにより、Updater はアプリケーションが起動して正常のシグナルを報告するまで待機してから、インスタンスが正常に更新されたものとみなして次のインスタンスに進みます。
4. maxUnavailable と maxSurge に小さい値を設定します。これにより、最小数のインスタンスのみが一度に更新されます。
5. 自動更新を使用する代わりに、MIG 内のインスタンスを選択的に更新します。

これらの方法を組み合わせて使用することで、更新の速度を制御することもできます。

ローリング アップデート中の中断レベルの制御

更新の特性によっては、インスタンスのライフサイクル状態が損なわれる可能性があります。たとえば、インスタンスのブートディスクを変更するには、インスタンスを置き換える必要があります。ローリング アップデートでの中断レベルを制御するには、次のオプションを設定します。

• 最小アクション: このオプションは、中断を最小限に抑えるとともに、必要以上に大がかりなアクションを適用する場合に使用します。

  • 中断を最小限に抑えるには、最小アクションを REFRESH に設定します。より大がかりなアクションを実行しなければ更新できない場合、Compute Engine は更新に必要なアクションを実行します。
  • 必要以上に大がかりなアクションを適用するには、最小アクションに RESTART または REPLACE を設定します。たとえば、Compute Engine ではメタデータを変更するために VM を再起動する必要はありませんが、アプリケーションが VM の再起動時にのみインスタンス メタデータを読み取る場合は、メタデータの変更を取得するために、最小限のアクションを RESTART に設定します。

• 許容される最も大がかりなアクション: 許容可能なレベルを超える中断が必要な場合は、このオプションを使用して更新を防ぐことができます。このフラグで設定したアクションよりも大がかりなアクションを実行しなければ更新できない場合、更新リクエストは失敗します。たとえば、許容される最も大がかりなアクションとして RESTART を設定した場合、ブートディスク イメージを更新しようとしても失敗します。ブートディスク イメージの更新にはインスタンスの再作成が必要になり、これは再起動よりも大がかりなアクションになるためです。

どちらのオプションにも次の値を指定できます。

注: 許容される最も大がかりなアクションを、最小アクションよりも小さいアクションにすることはできません。

更新を自動的にロールアウトする場合、次のデフォルトが適用されます。

• デフォルトの最小アクションは REPLACE です。不必要な中断を防ぐには、最小アクションを中断の小さいものにします。
• デフォルトの許容される最も大がかりなアクションは REPLACE です。このような中断を許容できない場合は、許容される最も大がかりなアクションを可能な限り少なくします。

デフォルトの動作を変更するには、Compute Engine API を使用して（たとえば regionInstanceGroupManagers.patch メソッドを呼び出して）MIG リソースの updatePolicy.minimalAction フィールドと updatePolicy.mostDisruptiveAllowedAction フィールドを設定します。また、Google Cloud コンソールから MIG を更新する際に、特定の VM の更新を許可するアクションを選択することもできます。現在の設定を確認するには、MIG のプロパティの取得をご覧ください。

許容されるものよりも大がかりなアクションが必要な場合、更新は失敗します。その場合は、より大がかりなアクションを許容して更新を再試行するか、インスタンスを選択して更新します。Compute Engine はベスト エフォートの検証を行って、指定された中断制限でインスタンスを更新できるかどうかを確認します。ただし、システムで同時に変更が行われるため、更新の開始後に状況が変化する可能性があります。特定のインスタンスに対するオペレーションが失敗した場合は、インスタンス エラーを一覧表示してエラーを確認します。

ローリング置換または再起動の実行

ローリング再起動では、すべてのインスタンスが停止して再起動されます。一方、ローリング置換では、置換メソッド オプションに従ってインスタンスが置き換えられます。ローリング再起動およびローリング置換では、インスタンス テンプレートなどグループの内容は変更されません。

ローリング再起動またはローリング置換を実行する理由はさまざまです。たとえば、次のいずれかの理由で、VM インスタンスをいつでも再起動または交換できます。

• メモリリークを解消する。
• 新しいマシンから実行できるようにアプリケーションを再起動する。
• ベスト プラクティスとして定期的に置換を適用し、VM をテストする。
• VM のオペレーティング システム イメージの更新や、起動スクリプトを再実行してソフトウェアの更新を行う。

Google Cloud コンソール、Google Cloud CLI、または REST を使用して、再起動または置換を行います。

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME

PATCH https://compute.googleapis.com/compute/v1/projects/example-project/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME

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

追加の置換 / 再起動の例

すべての VM のローリング再起動を一度に 2 つずつ実行する

このコマンドは、グループ内のすべての VM を 一度に 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]

インスタンス名の保持

更新後も VM インスタンスの名前を保持する必要がある場合は、replacementMethod を RECREATE に設定します。また、maxUnavailable を 0 より大きく、maxSurge を 0 に設定する必要があります。置換せずに再作成すると、更新の完了に時間がかかりますが、更新されたインスタンスの名前は保持されます。

置換メソッドを指定しない場合、MIG の現在の updatePolicy.replacementMethod 値が使用されます。設定されていない場合、デフォルト値の substitute が使用され、VM インスタンスはランダムに生成された名前を持つ新しいインスタンスに置き換えられます。

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

PATCH /compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME
{
    "updatePolicy": {
        "type": "PROACTIVE",
        "maxUnavailable": { "fixed": 5 },
        "replacementMethod": "RECREATE"
    },
    "versions": [ {
        "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
    } ]
}

リクエストを送った後、更新をモニタリングして、更新が完了したことを確認できます。

リージョン マネージド インスタンス グループを更新する

リージョン MIG には、リージョン内の複数のゾーンに分散する VM インスタンスが含まれます。一方で、ゾーン MIG には 1 つのゾーンにしかインスタンスは含まれていません。リージョン マネージド インスタンス グループを使用すると、インスタンスを複数のゾーンに分散して、アプリの可用性を向上させることができます。また、1 つのゾーンで障害が発生する、インスタンスのグループ全体が応答しなくなるなどの極端なケースにも対応できます。

リージョン MIG の更新の実行は、ゾーン MIG の更新と同じですが、以下のようないくつかの例外があります。リージョン MIG の更新を開始すると、Updater はインスタンスの更新を各ゾーンに常に比例的かつ均等に実行します。どのゾーンのどのインスタンスを最初に実行するかを指定したり、1 つのゾーンのインスタンスだけを更新したりすることはできません。

リージョン MIG の更新とゾーン MIG の更新の違い

リージョン MIG のデフォルトの更新値は次のとおりです。

• maxUnavailable=NUMBER_OF_ZONES
• maxSurge=NUMBER_OF_ZONES

NUMBER_OF_ZONES は、リージョン MIG に関連付けられているゾーンの数です。デフォルトでは、リージョン MIG のゾーン数は 3 です。異なる番号を選択することもできます。

更新を指定するときに固定数を使用する場合、固定値は 0 か、リージョン MIG に関連付けられたゾーン数以上の数にする必要があります。たとえば、グループが 3 つのゾーンに分散している場合、Updater は 3 つのゾーンのそれぞれに追加のインスタンスを作成する必要があるため、maxSurge を 1 または 2 に設定することはできません。

更新リクエストで固定数または割合を使用する

更新リクエストで固定数を指定する場合、指定する数値はリージョン MIG のゾーン数で除算され、均等に分散されます。たとえば、maxSurge=10 を指定すると、Updater はリージョン内のゾーンの数で 10 を除算し、その値に基づいて新しいインスタンスを作成します。インスタンスの数がゾーン間で均等にならない場合、Updater は残りのインスタンスをランダムなゾーンに追加します。そのため、3 つのゾーンに 10 のインスタンスがある場合、2 つのゾーンでインスタンスが 3 つずつ作成され、1 つのゾーンでインスタンスが 4 つ作成されます。カナリア更新の maxUnavailable パラメータと targetSize パラメータに対しても同じロジックが適用されます。

割合を指定できるのは、MIG に 10 個以上の VM インスタンスが含まれる場合に限られます。割合の扱い方は、場合によってやや異なります。

• カナリア更新する VM インスタンスの割合を指定する場合、Updater はインスタンスをゾーン間で均等に分散しようとします。余りは各ゾーンで切り上げまたは切り捨てされますが、全体での差はグループあたり VM インスタンス 1 つを超えることはありません。たとえば MIG に 10 個のインスタンスがあり、ターゲット サイズの割合が 25% の場合、更新は 2～3 個の VM インスンタンスにロールアウトされます。

• maxSurge や maxUnavailable などの更新オプションで割合を指定すると、その割合はゾーンごとに独立して四捨五入され丸められます。

次のステップ

• MIG とマネージド インスタンスに関する情報の表示について確認する。
• インスタンス テンプレートの作成について確認する。
• イメージ ファミリーとローリング置換を使用して MIG 内のすべての VM で OS イメージを更新する方法を確認する。