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 に対する認証を行います。

このページのサンプルをどのように使うかに応じて、タブを選択してください。
コンソール

Google Cloud コンソールを使用して Google Cloud サービスと API にアクセスする場合、認証を設定する必要はありません。
gcloud
1. Install the Google Cloud CLI, then initialize it by running the following command:
  gcloud init
  Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
2. デフォルトのリージョンとゾーンを設定します。
REST

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

制限事項

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

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

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

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

ローリングアップデートの実行時に注意すべき点は以下のとおりです。

更新はインテントベースです。最初の更新リクエストを行うと、Compute Engine API はリクエストが有効であることを確認するために成功のレスポンスを返しますが、これは更新が成功したことを示すものではありません。更新が正常にデプロイされたかどうかを判断するには、グループのステータスを確認する必要があります。
Instance Group Updater API は宣言型 API です。この API は、明示的な関数呼び出しではなく、MIG の更新後に必要な構成を指定するためのリクエストを必要とします。
自動更新では、MIG で最大 2 つのインスタンステンプレートバージョンをサポートしています。つまり、グループに 2 つの異なるインスタンステンプレートバージョンを指定できます。これは、カナリアの更新を行う場合に便利です。

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

このタスクに必要な権限

このタスクを行うには、次の権限が必要です。

ゾーン MIG の場合、instanceGroupManagers.patch メソッドを呼び出すために必要なすべての権限
リージョン MIG の場合、regionInstanceGroupManagers.patch メソッドを呼び出すために必要なすべての権限

コンソール

Google Cloud コンソールの [インスタンスグループ] ページに移動します。

[インスタンスグループ] に移動
更新する MIG を選択します。
[VM を更新] をクリックします。
[新しいテンプレート] のプルダウンリストをクリックして、更新に使用する新しいテンプレートを選択します。ターゲットサイズは自動的に 100% に設定され、すべてのインスタンスが更新されます。
[構成の更新] で選択メニューを開き、[Update type] で [自動] を選択します。他のオプションはデフォルト値のままにします。
[VM を更新] をクリックして更新を開始します。

gcloud

rolling-action start-update コマンドを使用します。

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

以下を置き換えます。

INSTANCE_GROUP_NAME: MIG の名前
INSTANCE_TEMPLATE_NAME: 新しいインスタンステンプレート
ZONE: ゾーン MIG には、ゾーンを指定します
REGION: リージョン MIG には、リージョンを指定します

REST

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。

たとえば、リージョン MIG の場合、次のリクエストは、すべてのインスタンスを新しいインスタンステンプレートに自動的に更新するために必要な最小構成を示しています。

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 は次の条件が満たされるのを待ちます。

ヘルスチェックで HEALTHY が返されるまで、MIG の autohealingPolicies.initialDelaySec 値で指定された時間まで待機します。
次に、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% のインスタンスはそのままで、現在のインスタンステンプレートが使用されます。

このタスクに必要な権限

このタスクを行うには、次の権限が必要です。

ゾーン MIG の場合、instanceGroupManagers.patch メソッドを呼び出すために必要なすべての権限
リージョン MIG の場合、regionInstanceGroupManagers.patch メソッドを呼び出すために必要なすべての権限

コンソール

Google Cloud コンソールで、[インスタンスグループ] ページに移動します。
[インスタンスグループ] に移動
更新するマネージドインスタンスグループを選択します。
[VM を更新] をクリックします。
[2 つ目のテンプレートを追加] をクリックして、カナリア更新する新しいインスタンステンプレートを選択します。
[ターゲットサイズ] で、新しいインスタンステンプレートのカナリア更新に使用するインスタンスの数、または割合を入力します。
必要に応じて、他の更新オプションを構成できます。
[VM を更新] をクリックして更新を開始します。

gcloud

rolling-action start-update コマンドを使用します。現在のテンプレートと新しいテンプレートを両方指定し、各テンプレートを使用するインスタンス数を明示的に指定します。

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]

以下を置き換えます。

INSTANCE_GROUP_NAME: インスタンスグループ名。
CURRENT_INSTANCE_TEMPLATE_NAME: インスタンスグループが実行されているインスタンステンプレート。
NEW_TEMPLATE: カナリア更新に使用する新しいテンプレート。
SIZE: この更新を適用するインスタンスの数または割合。target-size プロパティは、--canary-version テンプレートに適用する必要があります。グループに 10 個以上のインスタンスが含まれている場合は、割合のみを設定できます。
ZONE: ゾーン MIG には、ゾーンを指定します。
REGION: リージョン MIG には、リージョンを指定します。

たとえば、次のコマンドは、example-template-B をグループ内のインスタンスの 10% にロールアウトするカナリア更新を実行します。

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%

REST

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。リクエストの本文には、現在のインスタンステンプレートと、カナリアに追加する新しいインスタンステンプレートの両方を含めます。次に例を示します。

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"
  }
 ]
}

以下を置き換えます。

NEW_TEMPLATE: カナリアに追加する新しいテンプレートの名前。
NUMBER|PERCENTAGE: この更新を行うカナリアのインスタンスの数または割合。グループに 10 個以上のインスタンスが含まれている場合は、割合のみを設定できます。それ以外の場合は、固定数を指定します。
CURRENT_INSTANCE_TEMPLATE_NAME: グループが実行されている現在のインスタンステンプレートの名前。

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

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

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

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

コンソール

Google Cloud コンソールで、[インスタンスグループ] ページに移動します。
[インスタンスグループ] に移動
更新するマネージドインスタンスグループを選択します。
[VM を更新] をクリックします。
[新しいテンプレート] で、カナリアテンプレートのターゲットサイズを 100% に更新して、テンプレートをすべてのインスタンスにロールフォワードするようにします。あるいは、プライマリテンプレートをカナリアテンプレートに置き換えて、2 つ目のテンプレートフィールドを削除することもできます。
[VM を更新] をクリックして更新を開始します。

gcloud

カナリア更新に commit する場合は、別の rolling-action start-update コマンドを発行して更新をロールフォワードしますが、version フラグのみを設定し、--canary-version フラグを省略します。

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

REST

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。リクエストの本文で、新しいインスタンステンプレートを version として指定し、古いインスタンステンプレートは、リクエスト本文に入れないようにします。すべてのインスタンスに更新をロールアウトするために、ターゲットサイズの指定は省略します。次に例を示します。

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 コンソールを使用して、現在更新中のインスタンス数とターゲット数を確認することもできます。

このタスクに必要な権限

このタスクを行うには、次の権限が必要です。

MIG に対する compute.instanceGroupManagers.get 権限

Console

グループの詳細ページに移動すると、グループのローリングアップデートをモニタリングできます。

Google Cloud コンソールで、[インスタンスグループ] ページに移動します。
[インスタンスグループ] に移動
モニタリングするマネージドインスタンスグループを選択します。グループの概要ページに、各インスタンスが使用するテンプレートが表示されます。
詳細を表示するには、[詳細] タブをクリックします。
[インスタンステンプレート] で、各インスタンステンプレートの現在のインスタンス数、インスタンスのターゲット数、更新パラメータを確認できます。

gcloud

describe コマンドを使用します。

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

gcloud compute instance-groups managed wait-until コマンドに --version-target-reached フラグを付けて使用すると、グループの status.versionTarget.isReached が true になるまで待機することもできます。

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

REST

リージョンまたはゾーンの MIG リソースに対して get メソッドを呼び出します。

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 フィールドの値をチェックして、マネージドインスタンスグループ内のすべてのインスタンスが実行中で正常な状態であることを確認します。

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 を使用して、マネージドインスタンスグループ内のインスタンスの詳細を表示します。詳細には、インスタンスのステータスと、グループがインスタンスで実行中の現在のアクションが含まれます。

このタスクに必要な権限

このタスクを行うには、次の権限が必要です。

グループに対する compute.instanceGroupManagers.get
グループに対する compute.instanceGroupManagers.list

gcloud

すべてのマネージドインスタンス

グループ内のすべてのインスタンスのステータスと現在のアクションを確認するには、list-instances コマンドを使用します。

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

ヘルスチェックを設定しない限り、HEALTH_STATE 列は空欄になります。

特定のマネージドインスタンス

グループ内の特定のインスタンスのステータスと現在のアクションを確認するには、describe-instance コマンドを使用します。

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

このコマンドは、インスタンスの詳細情報（現在のステータス、現在のアクション、ステートフル MIG の保持状態など）を返します。

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

REST

リージョンまたはゾーンの MIG リソースに対して listManagedInstances メソッドを呼び出します。たとえば、ゾーン MIG リソース内のインスタンスの詳細を表示するには、次のリクエストを行います。

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

この呼び出しでは、各インスタンスの instanceStatus と currentAction を含む MIG のインスタンスのリストが返されます。

{
 "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

たとえば、次の gcloud CLI コマンドを実行すると、可能な限り迅速に更新がロールバックされます。OLD_INSTANCE_TEMPLATE は、ロールバックするインスタンステンプレートの名前で置き換えます。

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]

REST

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。

リクエストの本文で、以前のインスタンステンプレートを version として指定します。

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
    }
  ]
}

インスタンス数が 10 個未満のリージョン MIG の場合、maxUnavailable には固定値を使用する必要があります。この値をグループ内のインスタンス数に設定します。

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

更新の停止

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

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

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

更新を先行型から追従型に変換した後、更新を完全に停止する方法は次のとおりです。

更新されたインスタンスの数を確認するリクエストを送ります。

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 つのインスタンスがすでに更新されています。

次に、新しい更新を実行するリクエストを作成しますが、すでに更新されているインスタンスの数をターゲットサイズとして渡します。
```
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 はできる限り迅速に更新を実行します。更新を完全に適用するか、暫定的に変更をテストするか判断できない場合は、次の方法で更新速度を制御できます。

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

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

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

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

最小アクション: このオプションは、中断を最小限に抑えるとともに、必要以上に大がかりなアクションを適用する場合に使用します。
- 中断を最小限に抑えるには、最小アクションを REFRESH に設定します。より大がかりなアクションを実行しなければ更新できない場合、Compute Engine は更新に必要なアクションを実行します。
- 必要以上に大がかりなアクションを適用するには、最小アクションに RESTART または REPLACE を設定します。たとえば、Compute Engine ではメタデータを変更するために VM を再起動する必要はありませんが、アプリケーションが VM の再起動時にのみインスタンスメタデータを読み取る場合は、メタデータの変更を取得するために、最小限のアクションを RESTART に設定します。
許容される最も大がかりなアクション: 許容可能なレベルを超える中断が必要な場合は、このオプションを使用して更新を防ぐことができます。このフラグで設定したアクションよりも大がかりなアクションを実行しなければ更新できない場合、更新リクエストは失敗します。たとえば、許容される最も大がかりなアクションとして RESTART を設定した場合、ブートディスクイメージを更新しようとしても失敗します。ブートディスクイメージの更新にはインスタンスの再作成が必要になり、これは再起動よりも大がかりなアクションになるためです。

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

値	説明	更新可能なインスタンスプロパティ
`REFRESH`	インスタンスを停止しません。	追加のディスク、インスタンスメタデータ、ラベル、タグ
`RESTART`	インスタンスを停止して再起動します。	追加のディスク、インスタンスメタデータ、ラベル、タグ、マシンタイプ
`REPLACE`	（デフォルト）置換メソッドオプションに従ってインスタンスを置き換えます。	インスタンステンプレートまたはインスタンスごとの構成ファイルに保存されているすべてのインスタンスプロパティ

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

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

デフォルトの最小アクションは 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 を使用して、再起動または置換を行います。

コンソール

Google Cloud コンソールで、[インスタンスグループ] ページに移動します。
[インスタンスグループ] に移動
再起動するか置換する VM があるマネージドインスタンスグループを選択します。
[VM を再起動 / 置換] をクリックします。
[操作] で、[再起動] または [置換] を選択します。
- [再起動] を選択した場合は、次のパラメータを切り替えます。
  - オフライン上限インスタンス
  - 最小待機時間
- [置換] を選択した場合は、次のようにします。
  1. インスタンスを置き換えるときにインスタンス名を保持するかどうかを選択します。
  2. 次のパラメータを切り替えます。
操作を開始するには、[VM を再起動] または [VM を置換] をクリックします。

gcloud

restart コマンドまたは replace コマンドを使用します。

次のコマンドは、MIG 内のすべてのインスタンスを 1 つずつ置換します。

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME

次のコマンドは、各インスタンスを 1 つずつ再起動します。

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME

更新に使用できるものと同じオプション（例: maxSurge と maxUnavailable）を指定して、コマンドをカスタマイズできます。

REST

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。

updatePolicy.minimalAction フィールドに、RESTART または REPLACE を指定します。versions.instanceTemplate フィールドに、現在のテンプレートを指定します。

アクションをトリガーするには、versions.name フィールドも更新する必要があります。たとえば、タイムスタンプを付加します。後で、MIG の VM を一覧取得し、各 VM の versions.name フィールドを調べて、置換または再起動された VM を確認できます。

たとえば、ゾーン MIG の場合、次のリクエストは、すべてのインスタンスを自動的に再起動するために必要な最小限の構成を示しています。

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

rolling-action コマンドを発行するときは、--replacement-method=recreate フラグを含めます。

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]

REST

リージョンまたはゾーンの MIG リソースに対して patch メソッドを呼び出します。リクエストの本文に、updatePolicy.replacementMethod フィールドを含めます。

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 イメージを更新する方法を確認する。

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

始める前に

コンソール

gcloud

REST

制限事項

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

このタスクに必要な権限

コンソール

gcloud

REST

更新のオプションの構成

タイプを更新する

最大サージ

オフライン上限

最小待機時間

最小アクション

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

置換メソッド

追加の更新例

カナリア更新

カナリア更新の開始

このタスクに必要な権限

コンソール

gcloud

REST

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

コンソール

gcloud

REST

更新のモニタリング

グループのステータス

このタスクに必要な権限

Console

gcloud

REST

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

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

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

このタスクに必要な権限

gcloud

REST

更新のロールバック

gcloud

REST

更新の停止

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

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

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

コンソール

gcloud

REST

追加の置換 / 再起動の例

インスタンス名の保持

gcloud

REST

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

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

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

次のステップ

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

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

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

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

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

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