マネージド インスタンス グループの更新

このページでは、マネージド インスタンス グループを更新する方法について説明します。マネージド インスタンス グループの詳細については、インスタンス グループのドキュメントをご覧ください。

マネージド インスタンス グループには、インスタンス テンプレートを使用して制御される 1 つ以上の仮想マシン インスタンスが含まれます。マネージド インスタンス グループのインスタンスを更新するには、Managed Instance Group Updater 機能を使用してグループ全体に対する更新リクエストを実行します。

Managed Instance Group Updater を使用すると、ソフトウェアの新しいバージョンをマネージド インスタンス グループにデプロイでき、さらにデプロイの速度、サービス中断のレベル、更新のスコープを制御できます。Updater には主に 2 つの利点があります。

  • 仕様に従って更新のロールアウトが自動的に実行されます。初期リクエストの後に追加のユーザー入力を行う必要はありません。
  • 部分的ロールアウトを実行して、カナリアテストを行うことができます。

新しいソフトウェアを既存のマネージド インスタンス グループ内にデプロイできるようにすると、ソフトウェアの新しいバージョンがロールアウトされるたびにインスタンス グループを再設定する必要や、負荷分散、自動スケーリング、自動修復に再接続する必要がなくなります。Updater がない場合、新しいソフトウェア バージョンをデプロイするには、新しいソフトウェア バージョンで新しいマネージド インスタンス グループを作成して毎回追加の設定を行うか、インスタンスごとにユーザーが手動で再作成することを必須にします。どちらの方法でも、プロセス全体で手動での作業が数多く必要となります。

始める前に

基本のローリング更新の開始

ローリング更新は、すべてのインスタンスが更新されるまでインスタンス グループのすべてのインスタンスに段階的に適用される更新です。更新でオフラインにできるインスタンス数、インスタンスの更新間の待機時間、更新の影響範囲(全体または一部)など、ローリング更新のさまざまな設定を制御できます。

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

  • 更新はインテント ベースです。 初期の更新リクエストを実行すると、API はリクエストが有効であったことを確認する正常なレスポンスを返しますが、これは更新が成功したことを示すものではありません。更新が正常にデプロイされたことを確認するには、マネージド インスタンス グループのステータスを確認する必要があります。

  • Instance Group Updater API は宣言型 API です。API は明示的な関数呼び出しではなく、マネージド インスタンス グループの更新後に必要な構成を指定するためのリクエストを要求します。

  • Updater 機能は、マネージド インスタンス グループ内の 2 つのインスタンス テンプレート バージョンをサポートしています。マネージド インスタンス グループに 2 つの異なるインスタンス テンプレート バージョンを指定できます。これは、カナリア更新を行う場合に便利です。

グループのインスタンスの 100% に更新を適用する基本的なローリング更新を開始する手順は次のとおりです。

Console

  1. Cloud Platform Console で [インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. 更新するインスタンス グループを選択します。
  3. ページの上部で [ローリング更新] をクリックします。
  4. [テンプレート] でメニューをプルダウンし、更新に使用する新しいテンプレートを選択します。
  5. ターゲット サイズとして「100%」と入力し、すべてのインスタンスを更新します。
  6. 必要に応じて、設定オプションを切り替えることができます。たとえば、更新をプロアクティブ(グループがインスタンスの置換を能動的に実行する)と日和見(グループはインスタンスの置換を能動的には実行せず、インスタンスが他の手段で置き換えられた場合に更新を適用する)のどちらにするかなどです。また、最大サージオフライン上限オプション最小待機時間も指定できます。
  7. [更新] をクリックして更新を開始します。

gcloud

gcloud ツールで rolling-action start-update コマンドを実行します。

gcloud beta 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/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[MANAGED_INSTANCE_GROUP_NAME]

インスタンス グループがリージョン マネージド インスタンス グループの場合は、zones/[ZONE]regions/[REGION] に置き換えます。

リクエストのペイロードには次が含まれます。

  • グループの更新基準とするインスタンス テンプレート。
  • リクエストの更新ポリシーと他の更新オプション

以下の例は、API で更新を介する場合に必要な最小構成です。その他の設定を指定しないと、maxSurgemaxUnavailable プロパティは 1 に設定されます。この場合、Updater は特定の時間に 1 つのインスタンスを使用不能にし、更新中にインスタンス グループのターゲット サイズを超える 1 つのインスタンスを追加で作成します。このリクエストは、新しいインスタンス テンプレートにインスタンスの 100% を更新します。

次に例を示します。

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

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

更新のオプションの設定

複雑な更新の場合は、特定の更新リクエストに対して追加のオプションを設定できます。これらのオプションについて、以下で説明します。

最大サージ

maxSurge プロパティを設定すると、Updater で更新中に targetSize を超える数の新しいインスタンスを一時的に作成できます。たとえば、maxSurge を 5 に設定すると、マネージド インスタンス グループでは、新しいインスタンス テンプレートを使用して、ターゲット サイズを超える最大 5 つの新しいインスタンスが作成されます。maxSurge 値に高い値を設定すると更新速度は速くなりますが、追加のインスタンスの費用がかかります。この費用は Compute Engine の価格表に従って請求されます。maxSurge 値を設定しない場合、最大サージのデフォルト値である 1 が使用されます。

このオプションは、REPLACE 最小アクションで設定されている場合のみ認識され、RESTART アクション設定ではサポートされません。固定数を指定するか、マネージド インスタンス グループに 10 個以上のインスタンスがある場合は割合を指定できます。割合を設定すると、必要に応じてインスタンス数が切り上げられます。

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

オフライン上限

更新中の任意の時点に特定の数のインスタンスのみオフラインになるよう maxUnavailable を設定します。たとえば、maxUnavailable を 5 に設定すると、更新時に一度に 5 つのインスタンスのみオフラインになります。このパラメータを使用して、更新がサービスにとってどの程度大がかりなものであるか、および、更新がデプロイされるレートを制御します。

この数値には、他の理由でオフラインになっているインスタンスも含まれます。たとえば、インスタンス グループがサイズ増加の処理中である場合、作成中のインスタンスはオフラインになる場合があります。これらのインスタンスは maxUnavailable の数に加算されます。固定数を指定するか、マネージド インスタンス グループに 10 個以上のインスタンスが含まれる場合は割合を指定できます。割合を設定すると、Updater では必要に応じてインスタンス数が切り捨てられます。

指定しない場合、オフライン上限のデフォルト値である 1 が使用されます。

最小待機時間

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

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

ヘルスチェックを行うにあたり、Updater は次のように動作します。

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

initialDelaySec 内にヘルスチェックが HEALTHY を返さない場合、Updater は VM インスタンスを異常とみなし、更新を停止する可能性があります。VM インスタンスは、initialDelaySecminReadySeconds の期間検証を待機している間、マネージド インスタンス グループによって verifying ステータスになります。ただし、VM インスタンスの基本となるステータスは RUNNING のままです。

インスタンス グループのヘルスチェックがない場合、タイマーはインスタンスのステータスが RUNNING のときに起動します。minReadySeconds プロパティの最大値は 3,600 秒(1 時間)です。

最小アクション

最小アクション プロパティを設定して、Updater でグループ内のインスタンスを更新するために実行する必要のある最小アクションを制御します。たとえば、最小アクションとして REPLACE を設定すると、影響を受けるすべてのインスタンスが、必要かどうかに関係なく、削除されて新しいインスタンスに置き換えられます。

最小アクションを設定すると、Updater で最低限そのアクションが確実に実行されます。ただし、Updater によって、指定された最小アクションが更新の実行に不十分と判断された場合、より大がかりなアクションが実行される場合があります。たとえば、最小アクションとして RESTART を設定すると、更新を適用するためにインスタンスの再起動が実行されます。ただし、更新により大がかりなアクションが必要な場合は、そのアクションが実行されます。たとえば、インスタンスの OS の変更は、インスタンスを再起動しても実行できないため、Updater によりインスタンス グループ内のインスタンスが削除され、新しい VM インスタンスに置き換えられます。

適用可能なアクションは REPLACE または RESTART です。

  • RESTART: インスタンスを再起動します(stopstart リクエストを実行します)。更新リクエストで、変更を反映するためにインスタンスを置き換える必要がある場合(たとえば、イメージを変更するには、インスタンスを削除して置換する必要があります)、強制的に REPLACE が実行されます。

  • REPLACE: 既存のインスタンスを削除し、ターゲット テンプレートから新しいインスタンスを作成します。Updater によって、新しい内部 IP アドレスや外部 IP アドレスなど、すべての新しいインスタンス プロパティでインスタンスが作成されます。

次の図は、これらのオプションのインスタンスへの影響を示しています。

さまざまなアップデータ オプションによるリクエストへの影響を説明する図

追加の更新例

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

すべての仮想マシン インスタンスのローリング更新を実行するが、ターゲット サイズを超える新しいインスタンスは一度に 5 個まで作成する

gcloud beta 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]]

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

すべての仮想マシン インスタンスのローリング更新を実行するが、ターゲット サイズを超える新しいインスタンスは一度に 10% まで作成する

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

カナリア更新の開始

Instance Group Updater 機能を使用すると、カナリア更新を実行できます。この更新を行うと、更新を完全に commit する前に、インスタンスのサブセットをランダムに作成し、更新をテストすることができます。

カナリア更新は、インスタンス グループ内の特定の数のインスタンスに適用される更新です。カナリア更新を使用すると、大がかりになる可能性のある更新をすべてのインスタンスに実行するのではなく、インスタンスのサブセットで新しい機能または更新をテストすることができます。更新がうまくいかない場合、少数のインスタンスをロールバックするだけで済み、ユーザーに対する中断を最小限に抑えることができます。サーバーの観点では、カナリア更新は標準のローリング更新と同じですが、更新の必要のあるインスタンス数がインスタンス グループの合計サイズより小さい点が異なります。標準のローリング更新と同様に、カナリア更新は対象となるインスタンスに対して大きな影響を与えます。つまり、更新の際に、対象となるインスタンスは削除されて、新しい VM インスタンスに置き換えられます。

カナリア更新を開始するには:

  • 最大 2 つのインスタンス テンプレート バージョンを指定します。通常、カナリアに対しては新しいインスタンス テンプレートを、それ以外のインスタンスに対しては現在のインスタンス テンプレートを指定します。たとえば、new-instance-template に基づいてインスタンスの 20% が作成され、残りのインスタンスは引き続き old-instance-template で実行されるように指定します。同時に指定できるインスタンス テンプレートは 2 つまでです。

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

Console

  1. Cloud Platform Console で [インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. 更新するインスタンス グループを選択します。
  3. ページの上部で [ローリング更新] をクリックします。
  4. [テンプレートを追加] をクリックして、カナリア更新する新しいインスタンス テンプレートを選択します。
  5. [ターゲット サイズ] に、新しいインスタンス テンプレートをカナリア更新するために使用するインスタンスの割合または固定数を入力します。
  6. 必要に応じて、設定オプションを切り替えることができます。たとえば、更新をプロアクティブ(グループがインスタンスの置換を能動的に実行する)と日和見(グループはインスタンスの置換を能動的には実行せず、インスタンスが他の手段で作成された場合に更新を適用する)のどちらにするかなどです。また、最大サージオフライン上限オプション最小待機時間も指定できます。
  7. [更新] をクリックして更新を開始します。

gcloud

gcloud コマンドライン ツールで、現在のテンプレートと新しいテンプレートを両方指定し、各テンプレートを使用するインスタンス数を明示的に指定します。

gcloud beta 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] は、この更新を適用するインスタンスの数または割合です。target-size プロパティは、--canary-version テンプレートに適用する必要があります。インスタンス グループに 10 個以上のインスタンスが含まれている場合は、割合のみを設定できます。
  • このインスタンス グループの [ZONE] または [REGION]。インスタンス グループがゾーン インスタンス グループの場合は、ゾーンを指定します。リージョン インスタンス グループの場合は、リージョンを指定します。

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

gcloud beta 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/beta/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% に対する更新を commit するか、ロールバックするかを決めることができます。

Console

  1. Cloud Platform Console で [インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. 更新するインスタンス グループを選択します。
  3. ページの上部で [ローリング更新] をクリックします。
  4. [テンプレート] で、カナリア テンプレートのターゲット サイズを 100% に更新して、テンプレートをすべてのインスタンスにロール フォワードするようにします。また、プライマリ テンプレートをカナリア テンプレートに置き換え、ターゲット サイズを 100% に設定するという方法もあります。その後、2 番目のテンプレートのフィールドを完全に削除することができます。
  5. [更新] をクリックして更新を開始します。

gcloud

カナリア更新に commit する場合は、同じ更新リクエストを送りますが、version のみを設定し、--canary-version を省略して、更新をロール フォワードします。gcloud コマンドライン ツールを次のように使用します。

gcloud beta 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/beta/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. Cloud Platform Console で [インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. 更新するインスタンス グループを選択します。
  3. ページの上部で [ローリング更新] をクリックします。
  4. [テンプレート] で、インスタンス グループの更新に使用するテンプレートを選択し、テンプレートのターゲット サイズを選択します。
  5. [更新モード] で、日和見更新とプロアクティブ更新のいずれかを選択します。
  6. [更新] をクリックして更新を開始します。

gcloud

gcloud コマンドライン ツールを次のように使用します。

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

API

更新を開始するリクエスト ペイロードで、type プロパティを updatePolicy に含めます。

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

[NEW_TEMPLATE] は、カナリア更新に使用する新しいテンプレートの名前です。日和見更新が必要な場合は、PROACTIVEOPPORTUNISTIC に置き換えます。

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

restart または replace コマンドを使用すると、マネージド インスタンス グループの VM インスタンスにローリング再起動またはローリング置換を実行できます。start-update コマンドと同様に、再起動または置換の設定オプションを指定できます。ローリング再起動または置換では、インスタンス テンプレートなどのインスタンス グループの内容は変更されません。選択したメソッドを使用して、グループのインスタンスが更新されるだけです。

ローリング置換またはローリング再起動を実行する理由はさまざまです。たとえば、次の操作を行うために VM インスタンスの更新を随時実行します。

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

すべてのインスタンスが削除され、新しいインスタンスに置き換えられる置換を実行するには次の手順に従います。

Console

  1. Cloud Platform Console で [インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. 更新するインスタンス グループを選択します。
  3. ページの上部で、[ローリング再起動 / 置換] をクリックします。
  4. インスタンスを再起動するか置換するかを選択します。再起動するとインスタンスに対して stop メソッドと start メソッドが実行され、置換するとインスタンスの削除と作成が能動的に行われます。
  5. 必要に応じて、最大サージオフライン上限オプション最小待機時間などの設定オプションを切り替えることができます。
  6. [再起動] または [置換] ボタンをクリックして更新を開始します。

gcloud

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

このコマンドを実行すると、マネージド インスタンス グループ内のすべてのインスタンスが置換されます。置換は 1 回に 1 つずつ行われます。完全な置換が中断する場合には、ローリング再起動を指定できます。この場合、インスタンスは削除されず、インスタンスごとに再起動が実行されます。

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

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

API

API で、グループの PATCH リクエストを実行し、プロアクティブな updatePolicy を設定します。minimalAction は、各インスタンスが削除され新しいインスタンスに置換されるローリング置換または各インスタンスが停止して再起動されるローリング再起動を実行するかどうかに応じて RESTART または REPLACE になります。RESTARTREPLACE のどちらの場合も、常に versions.instanceTemplateversions.name プロパティ(v2 など)を指定してアクションを実行する必要があります。

ローリング置換は次のようになります。

PATCH https://www.googleapis.com/compute/beta/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/beta/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 beta compute instance-groups managed rolling-action restart [INSTANCE_GROUP_NAME] \
    --max-unavailable 2 [--zone [ZONE] | --region [REGION]]

すべての VM のローリング再起動を可能な限り迅速に実行する

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

すべての VM のローリング置換を可能な限り迅速に実行する

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

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

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

Instance Group Updater 機能によるリージョン マネージド インスタンス グループの更新は、ゾーン マネージド インスタンス グループでの更新と同じですが、以下のような例外があります。リージョン インスタンス グループの更新を開始すると、Updater はインスタンスの更新を各ゾーンに比例的かつ均等に実行します。どのゾーンのどのインスタンスを最初に実行するかを指定したり、1 つのゾーンのインスタンスのみを更新したりすることはできません。

リージョン マネージド インスタンスグループとゾーン マネージド インスタンス グループの更新の違い

リージョン マネージド インスタンス グループの更新を開始する前に、ゾーン マネージド インスタンス グループとはさまざまな点で動作が異なることを理解してください。

  • リージョン マネージド インスタンス グループのデフォルトの更新パラメータは、maxUnavailable=0 および maxSurge=3 に設定することです。これは、VM インスタンスが誤って削除されることがないようにし(maxUnavailable を 0 に設定)、一方でゾーンごとに 1 つの VM インスタンスを追加できるようにする(maxSurge を 3 に設定する)ことにより更新を続行できるようにするためです。

  • 更新を指定する際に固定数を使用している場合、その固定数は 0、または 3 以上でなければなりません。更新パラメータの値を 2 または 1 に設定することはできません。これは、リージョン マネージド インスタンス グループは 3 つのゾーンがあるリージョンに分散しているためです。たとえば、maxSurge を指定するには、0、または 3 以上の数値を使用する必要があります。これにより、Updater はゾーンごとに 1 つの追加インスタンスを作成できるようになります。

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

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

割合を指定できるのは、マネージド インスタンス グループの VM インスタンスが 10 以上ある場合のみです。割合の扱い方は、場合によってやや異なります。

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

  • maxSurgemaxUnavailable などの更新オプションで割合を指定すると、その割合はゾーンごとに独立して四捨五入され丸められます。ゾーン マネージド インスタンス グループの更新と同じルールがここでも適用されます。

ローリング更新をモニタリングする

ローリング更新を開始した後、更新が完了するまで時間がかかる場合があります。マネージド インスタンス グループの一部であるインスタンスの一覧を取得して更新の状態をモニタリングできます。Compute Engine API は、インスタンスの一覧とともにインスタンスのステータスを返します。

Console

特定のインスタンス グループの詳細ページに移動すると、グループのローリング更新をモニタリングできます。

  1. Cloud Platform Console で [インスタンス グループ] ページに移動します。

    [インスタンス グループ] ページに移動

  2. 更新するインスタンス グループを選択します。インスタンス グループの概要ページに、各インスタンスが使用するテンプレートが表示されます。
  3. 詳細を表示するには、[詳細] タブをクリックします。

[詳細] ページには、更新するインスタンスの現在の数とターゲット数がインスタンス テンプレートごとに表示されます。

gcloud

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

gcloud は、インスタンス グループ内のインスタンスの一覧と各インスタンスのステータスを含むレスポンスを返します。次に例を示します。

NAME               ZONE           STATUS   ACTION    INSTANCE_TEMPLATE  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 では、次の URI に POST リクエストを送ります。

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

インスタンス グループがリージョン マネージド インスタンス グループの場合は、zones/[ZONE]regions/[REGION] に置き換えます。

API は、グループのインスタンスの一覧と、それぞれのインスタンスのステータスおよび現在のアクションを返します。

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-j701",
   "id": "4251656203855893170",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  }
 ]
}

グループのステータスと保留中および現在のアクション

インスタンスの現在のステータスは、インスタンスの instanceStatus フィールドで示されます。インスタンスがなんらかの種類の変更を実行している場合、currentAction フィールドにもデータが入力され、更新のステータスを追跡するのに役立ちます。インスタンスが正常に更新されると、instanceStatus フィールドにインスタンスの現在の状態が反映されます。有効な instanceStatus フィールドのリストを参照するには、インスタンスのステータスの確認のドキュメントをご覧ください。

インスタンスがなんらかの種類の変更を実行している場合、currentAction フィールドには次のステータスのいずれかが入力されます。それ以外の場合、currentAction フィールドは空になります。

  • CREATING: インスタンスは作成中です。
  • CREATING_WITHOUT_RETRIES: インスタンスは再試行なしの条件で作成されています。インスタンスが 1 回目で作成できなかった場合、マネージド インスタンス グループはインスタンスの再置換を実行しません。
  • DELETING: インスタンスは削除中です。
  • RECREATING: インスタンスは削除され、置換中です。
  • RESTARTING: インスタンスは stop メソッドと start メソッドを使用して再起動中です。
  • REFRESHING: インスタンスは現在のターゲット プールから削除中で、現在のターゲット プールのリスト(このリストは既存のターゲット プールと同じ場合も異なる場合もあります)に再度追加されています。

マネージド インスタンス グループ レベルで、Compute Engine は、現在特定のアクションを待機しているインスタンス数を表す pendingActions という名前のフィールドに値を設定します。たとえば、pendingActions フィールドは、次のように pendingActions のカウントを返します。

CREATING: 3
DELETING: 3
RECREATING: 2
RESTARTING: 1

これは、削除保留中のインスタンスが 3 つ、置換されるインスタンスが 2 つ、再起動されるインスタンスが 1 つ、作成されるインスタンスが 3 つあることを示しています。

更新のロールバック

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

たとえば、次のコマンドを実行すると、可能な限り迅速に更新がロールバックされます。

gcloud beta 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/beta/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
    }
   ]
}

Instance Group Updater サービスはこれを通常の更新リクエストとして処理するため、このドキュメントで説明しているすべての更新オプションをリクエストで指定できます。

更新速度の管理

デフォルトでは、更新リクエストを送ると、サービスはできる限り迅速に更新を実行します。更新を完全に適用するか、変更を一時的にテストするかわからない場合は、次の方法を使用して更新の処理速度を落とすことができます。

  1. 完全な更新ではなく、カナリア更新を開始します。
  2. minReadySeconds に大きい値を設定します。この値を設定すると、サービスはここで指定した秒数待機してからインスタンスが正常に更新されたものとみなし、次のインスタンスに進みます。
  3. maxUnavailablemaxSurge に低い値を設定します。これにより、最小の数のインスタンスのみが一度に更新されます。

これらのパラメータの組み合わせを使用して、更新のレートを制御することもできます。

更新の停止

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

更新をプロアクティブから日和見に変更するには、次のコマンドを実行します。

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

更新をプロアクティブから日和見へ変換した後、更新を完全に停止する場合は、次の手順で停止できます。

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

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

    gcloud ツールは、インスタンス グループ内のインスタンスの一覧とその現在のステータスを含むレスポンスを返します。

    NAME               ZONE           STATUS   ACTION    INSTANCE_TEMPLATE  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 beta 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]]

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

マネージド インスタンス グループの instanceTemplate プロパティ間の関係

versions フィールドと最上位の instanceTemplate フィールドは機能が重複していて、どちらのフィールドを使用しても、マネージド インスタンス グループが新しいインスタンスの作成に使用するインスタンス テンプレートを指定できます。最上位の instanceTemplate フィールドと versions フィールドの違いは、新しい versions フィールドではユーザーが詳細な 2 つのテンプレート(カナリア)設定を指定できることです。

下位互換性を確保するために、マネージド インスタンス グループは引き続き最上位の instanceTemplate フィールドの設定をサポートしますが、versions フィールドのみの使用に切り替えることをおすすめします。機能的に、最上位の instanceTemplate フィールドのスーパーセットにあたるからです。両方のフィールドを同時に使用すると、曖昧さや混乱の原因となります。

update() メソッドや patch() メソッドを呼び出す際に instanceTemplate フィールドと versions フィールドの両方を指定した場合、次の 3 つの可能性が考えられます。

  • 両方のフィールドを同じ値に設定する。

    これは有効なリクエストです。この場合、曖昧さがなくなり、新しいインスタンス テンプレートがマネージド インスタンス グループに適用されます。

    たとえば、次のリクエストでは、最上位の instanceTemplate フィールドと versions フィールドに既存の現在のテンプレートとは異なる同じインスタンス テンプレートを指定しています。マネージド インスタンス グループは、新しいインスタンス テンプレートに更新されます。

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • 両方のフィールドの設定値は一致しないが、一方の値だけがマネージド インスタンス グループの現在のインスタンス テンプレートとは異なる。

    これは有効なリクエストです。現在の設定と異なるフィールドが、目的の値として取得されます。たとえば、get() メソッドを呼び出し、2 つのフィールドのいずれかを変更してから、その変更した 1 つのフィールドだけを使用して 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 フィールドの一方または両方を使用して、インスタンス テンプレートを 1 つだけ指定した場合、get() メソッドはそのレスポンスに両方のフィールドを返します。これにより、新しい versions フィールドでは下位互換性が確保されます。これらのフィールドのいずれかに単一のインスタンス テンプレートを指定する限り、get()instanceTemplate フィールドに同じ内容を返します。

versions フィールドに 2 つのインスタンス テンプレートが指定されている場合、get() メソッドは空の最上位の instanceTemplate フィールドを返します。カナリア更新中に最上位の instanceTemplate フィールドが使用されないように、そのフィールドにカナリアの 2 つのインスタンス テンプレート設定を明確に表現する方法はありません。

versions フィールドと setInstanceTemplate() メソッド

下位互換性を確保するために、setInstanceTemplate() メソッドはこれまでと同じように動作し、マネージド インスタンス グループが新しいインスタンスの作成に使用するテンプレートを変更できます。このメソッドを呼び出すと、versions フィールドは setInstanceTemplate() メソッドに指定されたインスタンス テンプレートでオーバーライドされます。

さらに、このメソッドは updatePolicyOPPORTUNISTIC に設定します。これにより、マネージド インスタンス グループは、versions フィールドに明示的に指定されていなかったインスタンス テンプレートを能動的にはデプロイしなくなります。

フィードバックと質問

皆様のご意見やご質問をお聞かせください。ディスカッション グループにお問い合わせください。

次のステップ

外出先でもリソースをモニタリング

Google Cloud Console アプリを入手して、プロジェクトの管理にお役立てください。

フィードバックを送信...

Compute Engine ドキュメント