マネージド インスタンス グループの作成

このページでは、マネージド インスタンス グループと呼ばれるマネージド インスタンスのグループを 1 つのゾーン内で作成する方法について説明します。マネージド インスタンス グループには単一のエンティティとして管理できる同一のインスタンスが含まれます。マネージド インスタンス グループは、インスタンスを実行可能な状態(RUNNING 状態)にしておくことで、アプリケーションの高可用性を維持します。マネージド インスタンス グループは、自動スケーリング、負荷分散、ローリング アップデート、自動修復などをサポートしています。

また、同じリージョン内の複数のゾーンのインスタンスが含まれるリージョン マネージド インスタンス グループを作成することもできます。インスタンス グループの詳細については、インスタンス グループの概要をご覧ください。

始める前に

制限事項

  • 1 つのマネージド インスタンス グループに含めることができる VM インスタンス数は最大で 1,000 個です。
  • マネージド インスタンス グループの更新時に、1 回のリクエストで指定できるインスタンス数は最大で 1,000 個です。

ステートレスなアプリケーションのマネージド インスタンス グループを使用する

マネージド インスタンス グループは、実行する基本 VM インスタンスの特定の状態に依存しないステートレスなアプリケーションをサポートすることを目的としています。これにより、自動スケーリングや自動修復などの機能が可能になります。そこでマネージド インスタンス グループは、自動的にインスタンスを削除および再作成できます。さらに、ユーザー操作、自動修復の一環、またはインフラストラクチャのメンテナンスによりインスタンスがマネージド インスタンス グループから削除された場合、インスタンスにライブ マイグレーションが設定されていなければ、新しいルート永続ディスクを使用して自動的にインスタンスが再作成されます。

マネージド インスタンス グループはステートレスです。保持されない特定のインスタンス プロパティ(IP アドレスやメモリ内データなど)に依存しないように、アプリケーションを設計または改良する必要があります。同様に、対応する VM インスタンスを削除した場合も、ブート永続ディスクのデフォルトの動作によってそれらのプロパティが削除されます。このため、マネージド インスタンス グループの永続データとしてブートディスクに依存しないようにしてください。

データを維持するためのおすすめの方法として、OS イメージを定期的にメンテナンスして最新の状態を維持すること、起動スクリプトを使用すること、Google Cloud Storage のような一元管理された別の場所にデータをバックアップすることが推奨されます。

インスタンス テンプレートには、コンテナ イメージカスタム イメージ、および関連する起動スクリプトを指定できます。これにより、インスタンスが再作成されたときに、必要なソフトウェア アプリケーションがインストールされ、必要なデータへのアクセス権が付与されます。インスタンス テンプレートの作成に関する推奨事項については、確定的なインスタンス テンプレートをご覧ください。

マネージド インスタンス グループに関連付けられたブートディスクを維持する必要がある場合、disks.autoDelete オプションを無効にすると、ブート永続ディスクの削除を防ぐことができます。ただし、このようにすると、マネージド インスタンス グループが新しいインスタンスを作成できなくなるため、この方法はおすすめしません。

マネージド インスタンス グループを作成する

マネージド インスタンス グループを作成するには、まずインスタンス テンプレートを作成して、オペレーティング システム イメージやコンテナ イメージ、またグループ内のすべてのインスタンスの設定を指定する必要があります。

テンプレートを作成したら、Google Cloud Platform Consolegcloud compute ツール、または API を使用してマネージド インスタンス グループを作成します。

Console

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

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

  2. [インスタンス グループを作成] をクリックします。
  3. マネージド インスタンス グループの名前を入力し、グループを配置するゾーンを選択します。
  4. [グループタイプ] で、[マネージド インスタンス グループ] を選択します。
  5. [インスタンス テンプレート] でインスタンス テンプレートを選択します。使用できるテンプレートがない場合は、インスタンス テンプレートを作成します。
  6. グループ内に作成するインスタンスの数を指定します。必要に応じて、自動スケーリングを有効にすると、インスタンスの CPU 使用率に基づいてグループのインスタンスを自動的に追加または削除できます。また、自動修復を有効にすると、インスタンス グループ内のインスタンスに対してヘルスチェックを実行できます。
  7. [作成] をクリックして、新しいグループを作成します。

gcloud

instance-groups managed create コマンドを次のように実行してインスタンス グループを作成します。

gcloud compute instance-groups managed create [NAME] \
    --base-instance-name [BASE_NAME] \
    --size [SIZE] \
    --template [INSTANCE_TEMPLATE] \
    --zone [ZONE]

それぞれ以下に置き換えられます。

  • [NAME]: このインスタンス グループの名前。
  • [BASE_NAME]: このインスタンス グループ内に作成されるインスタンスに使用する名前。これらのインスタンスは同一なので、インスタンス名の一部として各インスタンスにランダムな文字列が割り当てられます。このランダムな文字列の先頭にはベース名が追加されます。たとえば、ベース名が example の場合、インスタンスは example-yahs, example-qtyz といった名前になります。
  • [SIZE]: インスタンス グループのサイズ。
  • [INSTANCE_TEMPLATE]: このグループに使用するインスタンス テンプレートの名前。
  • [ZONE]: Compute Engine で使用できるゾーンのいずれか。

    たとえば、次のコマンドは example-group という名前のインスタンス グループを作成します。このグループのベース インスタンス名は test です。このグループには 3 つのインスタンスが含まれます。

    gcloud compute instance-groups managed create example-group
    --base-instance-name test
    --size 3
    --template an-instance-template

API

API で、instanceGroupManagers サービスに対する POST リクエストを作成します。リクエスト本文には、必要なグループ名、グループサイズ、グループ内のインスタンスのベース名、インスタンス テンプレートへの URL を記載します。

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

{
  "baseInstanceName": "[BASE_NAME]",
  "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/[INSTANCE_TEMPLATE]"
    }
  ],
  "name": "[NAME]",
  "targetSize": [SIZE]
}

それぞれ以下に置き換えられます。

  • [PROJECT_ID]: リクエストのプロジェクト ID。
  • [ZONE]: リクエストのゾーン。
  • [NAME]: このインスタンス グループの名前。
  • [BASE_NAME]: このインスタンス グループ内に作成されるインスタンスに使用する名前。これらのインスタンスは同一なので、インスタンス名の一部として各インスタンスにランダムな文字列が割り当てられます。このランダムな文字列の先頭にはベース名が追加されます。たとえば、ベース名が example の場合、インスタンスは example-yahs, example-qtyz といった名前になります。
  • [SIZE]: インスタンス グループのサイズ。
  • [INSTANCE_TEMPLATE]: このグループに使用するインスタンス テンプレート。

既存のグループとグループの説明を取得する

既存のマネージド インスタンス グループに関する情報を取得するには、Consolegcloud コマンドライン ツール、または API を使用します。グループの id を取得する場合は、gcloud または API を使用する必要があります。

Console

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

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

    既存のインスタンス グループがある場合は、このページにそれらのグループのリストが表示されます。このページには非マネージド インスタンス グループも表示されます。

  2. リストの [名前] 列で、情報を調べるインスタンス グループの名前をクリックします。ページが開き、インスタンス グループ プロパティと、グループに含まれるインスタンスのリストが表示されます。

gcloud

次のコマンドで、プロジェクト内のすべてのマネージド インスタンス グループをリストします。

gcloud compute instance-groups managed list

特定のグループの情報を取得するには、次のコマンドを実行します。

gcloud compute instance-groups managed describe [INSTANCE_GROUP] \
    --zone [ZONE]

API

ゾーン内のすべてのマネージド インスタンス グループを一覧表示するには、instanceGroupManagers サービスに対する GET リクエストを作成します。

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

特定のグループに関する情報を取得するには、instanceGroupManagers サービスに対する GET リクエストを作成し、そこに特定のマネージド インスタンス グループの名前を含めます。

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

リージョン(マルチゾーン)マネージド インスタンス グループの場合は、代わりに regionInstanceGroupManagers リソースの regionInstanceGroupManagers.list および regionInstanceGroupManagers.get を使用します。

マネージド インスタンス グループのインスタンス テンプレートを変更する

マネージド インスタンス グループのインスタンス テンプレートを変更しても、その変更を既存のインスタンスに反映する必要はありません。マネージド インスタンス グループでは、インスタンスの追加や再作成のリクエストが行われるときには新しいテンプレートが使用されますが、そのテンプレートによってグループ内の既存のインスタンスが自動的に更新されることはありません。したがって、どのインスタンスを更新するかは正確に制御できますが、インスタンス グループ内に別種のインスタンスが混在することになります。

新しいインスタンス テンプレートを作成した後、既存のインスタンス グループのインスタンス テンプレートを変更します。

Console

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

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

  2. リストの [名前] 列で、インスタンス テンプレートを変更するインスタンス グループの名前をクリックします。
  3. [グループを編集] をクリックして、このマネージド インスタンス グループを変更します。
  4. [インスタンス テンプレート] で、このグループに使用する新しいインスタンス テンプレートを選択します。
  5. [保存] をクリックして、新しいテンプレートを適用します。

gcloud

set-instance-template メソッドを使用してテンプレートを更新するには、新しいテンプレートを instance-groups managed set-instance-template サブコマンドに渡します。

gcloud compute instance-groups managed set-instance-template [INSTANCE_GROUP] \
    --template [INSTANCE_TEMPLATE] \
    --zone [ZONE]

API

instanceGroupManagers サービスへのリクエストを作成し、対象のマネージド インスタンス グループの名前を指定します。リクエスト本文に新しいインスタンス テンプレートの URL を指定します。

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

{
 "instanceTemplate": "global/instanceTemplates/[INSTANCE_TEMPLATE]
}

インスタンス テンプレートを変更した後、個々のインスタンスを再作成するか、ローリング アップデートでグループ内のインスタンスをすべて更新します。

マネージド インスタンス グループのサイズを自動的に変更する

マネージド インスタンス グループは、インスタンスがその負荷に応じて自動的に追加や削除されるように構成できます。増加するトラフィックをアプリケーションで簡単に処理でき、コンピューティング リソースがそれほど必要なくなったときに負担を減らすことができます。マネージド インスタンス グループのスケーリングを開始するには、インスタンス グループの自動スケーリングの記事をご覧ください。

マネージド インスタンス グループのサイズを手動で変更する

マネージド インスタンス グループで自動スケーリングが行われるように設定されていない場合、グループのサイズを手動で調整して、グループ内のインスタンス数を変更できます。サイズを大きくすると、マネージド インスタンス グループに現在のインスタンス テンプレートを使用して新しいインスタンスが追加されます。サイズを小さくすると、マネージド インスタンス グループからインスタンスが削除されます。DELETINGCREATINGRECREATINGcurrentAction のあるインスタンスがグループから削除された後で、スケジュールされたアクションのない実行中のインスタンスが削除されます。

グループが属するバックエンド サービス接続ドレインが有効になっていると、接続ドレインの期間が経過してから VM インスタンスが削除されるまでに 60 秒ほどかかる場合があります。

マネージド インスタンス グループのサイズを変更するには、Google Cloud Platform Consolegcloud compute ツール、または API を使用します。

Console

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

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

  2. リストの [名前] 列で、グループサイズを変更するインスタンス グループの名前をクリックします。
  3. [グループを編集] をクリックして、このマネージド インスタンス グループを変更します。
  4. [インスタンスの数] で、このマネージド インスタンス グループに含めるインスタンスの数を指定します。[自動スケーリング] が有効な場合は、グループのインスタンスが必要に応じて自動的に追加または削除されます。ただし、[インスタンスの最小数] および [インスタンスの最大数] の値を変更して、オートスケーラーで間接的にグループのサイズを調整することもできます。
  5. [保存] をクリックして、新しいテンプレートを適用します。

gcloud

コマンドを次のように使用します。

gcloud compute instance-groups managed resize [INSTANCE_GROUP ] \
    --size [NEW_SIZE] \
    --zone [ZONE]

API

instanceGroupManagers サービスへのリクエストを作成し、対象のマネージド インスタンス グループの名前を指定します。パラメータとして新しいインスタンスのサイズを指定します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]/resize?size=[NEW_SIZE]

マネージド インスタンス グループのサイズ変更リクエストを行うと、システムでプロビジョニングまたは削除が可能になり次第、そのインスタンスが開始または停止します。このプロセスにかかる時間は、グループ内のインスタンスの数によっては長くなる場合があります。 マネージド インスタンス グループのインスタンスのステータスを検証してください。

作成の再試行モードを無効にする

デフォルトでは、仮想マシン インスタンスの初回作成に失敗すると、マネージド インスタンス グループの各インスタンスが最終的に作成されるまで、インスタンスの作成が再試行され続けます。ただし、作成の自動再試行を望まない場合は、インスタンス グループのサイズを変更するときに、--nocreation-retries フラグを設定して作成の再試行モードを無効にできます。このモードでは、マネージド インスタンス グループですべてのインスタンスの作成が一度だけ試行されます。作成時にエラーが発生した場合は、マネージド インスタンス グループのこのインスタンスは作成されず、マネージド インスタンス グループの最終的なサイズが小さくなります。

このモードは、インスタンスの作成の最初の試行時にのみ適用されます。このモードが有効なときにインスタンスが正常に作成されると、そのインスタンスは通常のサイズ変更リクエストで作成された他のインスタンスと同じように動作します。特に、その後実行中のインスタンスが予期せず停止し、再作成が必要になった場合でも、このモードが再作成の動作に影響することはありません。

作成の再試行無効化モードは、インスタンスのグループが自動的に作成され、厳密な数のインスタンスが必要ではない状況で役立ちます。リクエストしたすべてのインスタンスが作成されるまで待ち続けるよりも、マネージド インスタンス グループのサイズをできるだけ早く確定し、グループ内のインスタンスの数を柔軟に変更できるようにした方が望ましいこともあります。インスタンスの作成は、割り当てエラーや関連のないその他の問題のために、一時的に遅れたり、いつまで経っても終わらなかったりする場合があるからです。

作成の再試行無効化モードでマネージド インスタンス グループのサイズを変更するには、gcloud compute ツールまたは API を使用します。

gcloud

gcloud コマンドライン ツールでは、--no-creation-retries フラグを指定して resize コマンドを実行します。

gcloud beta compute instance-groups managed resize [INSTANCE_GROUP] --size [NEW_SIZE] \
    --nocreation-retries \
    --zone [ZONE]

API

instanceGroupManagers サービスへのリクエストを作成し、対象のマネージド インスタンス グループの名前を指定します。リクエスト本文で新しいインスタンスのサイズと noCreationRetries フィールドを指定します。

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

{
 "targetSize": [SIZE]
 "noCreationRetries": true
}

listManagedInstances メソッドを使用すると、どのインスタンスをどのモードで作成中かを確認できます。作成の再試行無効化モードで作成しているインスタンスのステータスは CREATING_WITHOUT_RETRIES になります。

マネージド インスタンス グループのヘルスチェックと自動修復の設定

アプリケーションの可用性を高め、アプリケーションが応答していることを確認するには、マネージド インスタンス グループの自動修復ポリシーを構成します。自動修復ポリシーは、アプリケーション ベースのヘルスチェックを使用して、アプリケーションが期待どおりに応答していることを確認します。アプリケーションが応答していることを確認するほうが、単にインスタンスが RUNNING 状態であるかどうかを検証するよりも正確な結果を得られます。

自動修復によってアプリケーションが応答していないと判断されると、そのインスタンスはマネージド インスタンス グループにより自動的に再作成されます。プリエンプティブ インスタンスの場合は、必要なリソースが再び利用可能になってからインスタンスが再作成されます。

ヘルスチェック シグナルを使用することで、インスタンスが作成されていること、またそのアプリケーションが応答していることを確認できます。作成中のマネージド インスタンスの場合、その currentActionCREATING となります。自動修復ポリシーが適用されている場合、マネージド インスタンスが作成されて実行中になると、インスタンスの currentActionVERIFYING となり、ヘルスチェッカーがインスタンスのアプリケーションの調査を開始します。アプリケーションが、起動されるまでの時間内にこの初期ヘルスチェックにパスすると、インスタンスが検証され、その currentActionNONE に変わります。初めてマネージド インスタンス グループにヘルスチェックを適用する場合、検証が完了するまでに 15 分ほどかかることがあります。詳細については、マネージド インスタンス グループ内のインスタンスのステータスを検証するをご覧ください。

自動修復でインスタンスが再作成される場合、そのインスタンスの作成に使用された元のインスタンス テンプレート(マネージド インスタンス グループに適用されたデフォルトのインスタンス テンプレートとは限りません)が使用されます。インスタンスとそのディスクを削除して再作成すると、予防措置を講じていない限り、インスタンスのディスクに書き込まれたデータは失われます。Compute Engine の自動修復の動作と、接続されたディスクに自動修復が与える影響の詳細については、マネージド インスタンス グループと自動修復をご覧ください。マネージド インスタンス グループに設定できる自動修復ポリシーは、1 つだけです。

マネージド インスタンス グループでヘルスチェックを使用する例として、次の手順を実施し、ポート 80 でウェブサーバーのレスポンスを確認するヘルスチェックを作成します。その後、このヘルスチェックをマネージド インスタンス グループに適用して、そのグループのウェブサーバーが正しく機能していることを確認します。

Console

  1. 負荷分散のヘルスチェックよりも慎重に実施される、自動修復のヘルスチェックを作成します。

    たとえば、ポート 80 でのレスポンスを確認するヘルスチェックを作成します。このヘルスチェックでは、インスタンスが UNHEALTHY とマークされて再作成される前にいくつかの障害が許容されます。この例では、ヘルスチェックに 1 回成功すると、インスタンスは healthy とマークされます。連続して 3 回失敗すると、unhealthy とマークされます。

    1. GCP Console の [ヘルスチェックの作成] ページに移動します。

      [ヘルスチェックの作成] ページに移動

    2. ヘルスチェックに example-check などの名前を付けます。
    3. [プロトコル] で、選択されていない場合は [HTTP] を選択します。
    4. [ポート] に「80」と入力します。
    5. [チェック間隔] に「5」と入力します。
    6. [タイムアウト] に「5」と入力します。
    7. [正常しきい値] を設定して、ヘルスチェックが何回連続して正常完了したら、unhealthy とマークされていたインスタンスが healthy に変わるかを決定します。この例では「1」と入力します。
    8. [異常しきい値] を設定して、ヘルスチェックに何回連続して失敗したら、healthy とマークされていたインスタンスが unhealthy に変わるかを決定します。この例では「3」と入力します。
    9. [作成] をクリックしてヘルスチェックを作成します。
  2. ヘルスチェック プローブにアプリケーションへの接続を許可するファイアウォール ルールを作成します。

    ヘルスチェック プローブは 130.211.0.0/2235.191.0.0/16 の範囲のアドレスから送信されるため、ネットワーク ファイアウォール ルールがヘルスチェックの接続を許可するようにします。この例のマネージド インスタンス グループは default ネットワークを使用し、そのインスタンスはポート 80 をリッスンしています。デフォルト ネットワークでポート 80 がまだ開いていない場合は、ファイアウォール ルールを作成します。

    1. GCP Console の [ファイアウォール ルールの作成] ページに移動します。

      [ファイアウォール ルールの作成] ページに移動

    2. [名前] フィールドに、ファイアウォール ルールの名前(allow-health-check など)を入力します。
    3. [ネットワーク] で [default] ネットワークを選択します。
    4. [ソースフィルタ] で [IP ranges] を選択します。
    5. [ソース IP の範囲] に、「130.211.0.0/22」と「35.191.0.0/16」を入力します。
    6. [プロトコルとポート] で [指定したプロトコルとポート] をオンにして、「tcp:80」と入力します。
    7. [作成] をクリックします。
  3. リージョンまたはゾーンのマネージド インスタンス グループの自動修復ポリシーを構成して、ヘルスチェックを適用します。

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

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

    2. リストの [名前] 列で、ヘルスチェックを適用するインスタンス グループの名前をクリックします。
    3. [グループを編集] をクリックして、このマネージド インスタンス グループを変更します。
    4. [自動修復] で、前に作成したヘルスチェックを選択します。
    5. [初期遅延] 設定を変更または保持します。この設定は、起動プロセス中のインスタンスに対する自動修復を遅らせて、インスタンスが早期に再作成されることを防ぎます。初期遅延タイマーは、インスタンスの currentActionVERIFYING になると開始されます。
    6. [保存] をクリックして変更を適用します。

    自動修復でグループ内のインスタンスのモニタリングが開始されるまでに、数分かかることがあります。

gcloud

  1. 負荷分散のヘルスチェックよりも慎重に実施される、自動修復のヘルスチェックを作成します。

    たとえば、ポート 80 でのレスポンスを確認するヘルスチェックを作成します。このヘルスチェックでは、インスタンスが UNHEALTHY とマークされて再作成される前にいくつかの障害が許容されます。この例では、ヘルスチェックに 1 回成功すると、インスタンスは healthy とマークされます。連続して 3 回失敗すると、unhealthy とマークされます。

    gcloud compute health-checks create http example-check --port 80 \
        --check-interval 30s \
        --healthy-threshold 1 \
        --timeout 10s \
        --unhealthy-threshold 3
    
  2. ヘルスチェック プローブにアプリケーションへの接続を許可するファイアウォール ルールを作成します。

    ヘルスチェック プローブは 130.211.0.0/2235.191.0.0/16 の範囲のアドレスから送信されるため、ファイアウォール ルールがヘルスチェックの接続を許可するようにします。この例のマネージド インスタンス グループは default ネットワークを使用し、そのインスタンスはポート 80 をリッスンしています。デフォルト ネットワークでポート 80 がまだ開いていない場合は、ファイアウォール ルールを作成します。

    gcloud compute firewall-rules create allow-health-check \
        --allow tcp:80 \
        --source-ranges 130.211.0.0/22,35.191.0.0/16 \
        --network default
    
  3. リージョンまたはゾーンのマネージド インスタンス グループの自動修復ポリシーを構成して、ヘルスチェックを適用します。

    gcloud beta computeset-autohealing コマンドを使用して、ヘルスチェックをマネージド インスタンス グループに適用します。

    initial-delay の設定は、起動プロセス中のインスタンスに対する自動修復を遅らせて、インスタンスが早期に再作成されることを防ぎます。初期遅延タイマーは、インスタンスの currentActionVERIFYING になると開始されます。

    次に例を示します。

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

    自動修復でグループ内のインスタンスのモニタリングが開始されるまでに、15 分ほどかかることがあります。

API

  1. 負荷分散のヘルスチェックよりも慎重に実施される、自動修復のヘルスチェックを作成します。

    たとえば、ポート 80 でのレスポンスを確認するヘルスチェックを作成します。このヘルスチェックでは、インスタンスが UNHEALTHY とマークされて再作成される前にいくつかの障害が許容されます。この例では、ヘルスチェックに 1 回成功すると、インスタンスは healthy とマークされます。連続して 3 回失敗すると、unhealthy とマークされます。

    POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks
    
    {
     "name": "example-check",
     "type": "http",
     "port": 80,
     "checkIntervalSec": 30,
     "healthyThreshold": 1,
     "timeoutSec": 10,
     "unhealthyThreshold": 3
    }
    
  2. ヘルスチェック プローブにアプリケーションへの接続を許可するファイアウォール ルールを作成します。

    ヘルスチェック プローブは 130.211.0.0/2235.191.0.0/16 の範囲のアドレスから送信されるため、ファイアウォール ルールがヘルスチェックの接続を許可するようにします。この例のマネージド インスタンス グループは default ネットワークを使用し、そのインスタンスはポート 80 をリッスンしています。デフォルト ネットワークでポート 80 がまだ開いていない場合は、ファイアウォール ルールを作成します。

    POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    
    {
     "name": "allow-health-check",
     "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/default",
     "sourceRanges": [
      "130.211.0.0/22",
      "35.191.0.0/16"
     ],
     "allowed": [
      {
       "ports": [
        "80"
       ],
       "IPProtocol": "tcp"
      }
     ]
    }
    
  3. リージョンまたはゾーンのマネージド インスタンス グループの自動修復ポリシーを構成して、ヘルスチェックを適用します。

    自動修復ポリシーは、instanceGroupManager リソースまたは regionInstanceGroupManager リソースの一部です。

    insert メソッドまたは patch メソッドを使用して、自動修復ポリシーを設定できます。

    次の例では、instanceGroupManagers.patch メソッドを使用して自動修復ポリシーを設定します。

    PATCH https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]
    {
      "autoHealingPolicies": [
        {
          "healthCheck": "global/healthChecks/example-check",
          "initialDelaySec": 300
        }
      ],
    }
    

    initialDelaySec の設定は、起動プロセス中のインスタンスに対する自動修復を遅らせて、インスタンスが早期に再作成されることを防ぎます。初期遅延タイマーは、インスタンスの currentActionVERIFYING になると開始されます。

    自動修復でグループ内のインスタンスのモニタリングが開始されるまでに、数分かかることがあります。

    アプリケーション ベースの自動修復をオフにするには、自動修復ポリシーを空の値、autoHealingPolicies[] にします。マネージド インスタンス グループでは、RUNNING 状態でないインスタンスのみ再作成されます。

    instanceGroupManagers.autoHealingPolicies フィールドを読み取ることで、マネージド インスタンス グループの自動修復ポリシーを取得できます。次のいずれかのメソッドを使用して、マネージド インスタンス グループ リソースを取得できます。

    • instanceGroupManagers.get は、指定されたゾーンのマネージド インスタンス グループ リソースを返します。
    • instanceGroupManagers.list は、指定されたプロジェクトとゾーン内にある、すべてのゾーン マネージド インスタンス グループを返します。
    • regionInstanceGroupManagers.get は、指定されたリージョン マネージド インスタンス グループ リソースを返します。
    • regionInstanceGroupManagers.list は、指定されたプロジェクトとリージョン内にある、すべてのリージョン マネージド インスタンス グループを返します。

自動修復オペレーションの履歴を表示する

過去の自動修復イベントを表示するには、gcloud ツールまたは API を使用します。

gcloud

プロジェクト内の自動修復イベントのみを表示するには、filter を指定した gcloud compute operations list コマンドを使用します。

gcloud compute operations list --filter='operationType~compute.instances.repair.*'

特定の修復オペレーションの詳細を表示するには、describe コマンドを使用します。次に例を示します。

gcloud compute operations describe repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5 --zone us-east1-b

API

ゾーン マネージド インスタンス グループの場合、GET リクエストをゾーンの operations リソースに送信し、出力リストを compute.instances.repair.* イベントにスコープするフィルタを追加します。

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

リージョン マネージド インスタンス グループの場合、ゾーンではなくそのリージョンの operations リソースを使用します。

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/region/[REGION]/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

特定の修復オペレーションの詳細を表示するには、その特定のオペレーションに対する GET リクエストを送信します。

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

グループに含まれるインスタンスを識別する

グループ内のすべてのインスタンスのリストを表示するには、既存のグループとグループの説明を取得するをご覧ください。

特定のインスタンスが現在グループのメンバーであるかどうかを確認するには、Console または API を使用します。

Console

  1. [VM インスタンス] ページに移動します。

    [VM インスタンス] ページに移動

  2. インスタンスをクリックして、[VM インスタンスの詳細] にアクセスします。
  3. VM インスタンスがマネージド インスタンス グループのメンバーである場合、そのマネージド インスタンス グループの名前は「使用中」という見出しの下に表示されます。VM インスタンスがグループのメンバーでない場合、インスタンスの詳細ページに「使用中」の見出しは表示されません。

API

VM インスタンスのリファラーの表示をご覧ください。

また、インスタンスのメタデータで次の 2 つのメタデータキーを探し、インスタンスが過去または現在のマネージド インスタンス グループのメンバーであるかどうかを識別します。

  • instance-template は、インスタンスの作成に使用されたテンプレートを示します。
  • created-by は、インスタンスを作成したマネージド インスタンス グループを示します。

インスタンスを破棄する場合でも、手動で削除しない限り、インスタンスにはこれらのメタデータ エントリが含まれています。

たとえば、random-instance-biy という名前のインスタンスがあり、このインスタンスがマネージド インスタンス グループによって作成されたかどうかを確認するには、インスタンスを記述して、上のメタデータキーを探します。次に例を示します。

gcloud compute instances describe random-instance-biy --zone us-central1-f

gcloud は、次のようなレスポンスを返します。

canIpForward: false
cpuPlatform: Intel Ivy Bridge
creationTimestamp: '2016-08-24T14:11:38.012-07:00'
disks:
- autoDelete: true
  boot: true
  deviceName: persistent-disk-0
  index: 0
  interface: SCSI
  kind: compute#attachedDisk
...[snip]...
metadata:
  items:
  - key: instance-template
    value: projects/123456789012/global/instanceTemplates/example-it
  - key: created-by
    value: projects/123456789012/zones/us-central1-f/instanceGroupManagers/igm-metadata

グループから個々のインスタンスを削除する

マネージド インスタンス グループから個々のインスタンスを削除できます。インスタンスを削除すると、インスタンス グループに指定された targetSize が縮小され、削除されたインスタンスが属するすべてのターゲット プールからそのインスタンスが削除されます。

マネージド インスタンス グループからインスタンスを削除しても、指定したオートスケーラーは変更されません。マネージド インスタンス グループからインスタンスを削除すると、オートスケーラーがグループ内のその他のインスタンスでの負荷の増加を検出し、グループサイズを増やして元のレベルまで戻す場合があります。これを回避するには、インスタンスを削除する前にオートスケーラーを停止します。

グループが属するバックエンド サービス接続ドレインが有効になっていると、接続ドレインの期間が経過してから VM インスタンスが削除されるまでに 60 秒ほどかかる場合があります。

マネージド インスタンス グループからインスタンスを削除するには、Google Cloud Platform Consolegcloud compute ツール、または API を使用します。

Console

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

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

  2. リストの [名前] 列で、個々のインスタンスを削除するインスタンス グループの名前をクリックします。ページが開き、インスタンス グループ プロパティと、グループに含まれるインスタンスのリストが表示されます。
  3. インスタンスのリストで、削除するインスタンスを 1 つ以上選択します。
  4. [削除] をクリックします。選択したインスタンスが削除されます。

gcloud

gcloud でインスタンスを削除するには、instance-groups managed delete-instances サブコマンドを使用します。

gcloud compute instance-groups managed delete-instances [INSTANCE_GROUP] \
    --instances example-i3n2,example-z2x9 \
    --zone [ZONE]

API

instanceGroupManagers サービスへのリクエストを作成し、対象のマネージド インスタンス グループの名前を指定します。リクエスト本文で、除外する 1 つ以上のインスタンスの URL を指定します。

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

{
 "instances": [
  "zones/[ZONE]/instances/example-instance-i3n2",
  "zones/[ZONE]/instances/example-instance-l6n1"
 ]
}

マネージド インスタンス グループのインスタンスの削除のリクエストを行うと、システムで削除が可能になり次第、そのインスタンスが停止します。このプロセスにかかる時間は、グループから削除するインスタンスの数によっては長くなる場合があります。 マネージド インスタンス グループのインスタンスのステータスを検証してください。

グループからのインスタンスの除外

マネージド インスタンス グループからインスタンスを分離すると、グループ自体に影響を及ぼさずに、個々のインスタンスの問題を簡単にデバッグすることができます。グループからインスタンスを破棄すると、マネージド インスタンスに割り当てられたロードバランサからもインスタンスが削除されます。 特定の個別のインスタンスに手動で割り当てられたターゲット プールは削除されません。

インスタンスを破棄すると、インスタンス グループに指定された targetSize は縮小されますが、オートスケーラー設定の指定は何も変更されません。オートスケーラーのあるマネージド インスタンス グループでは、引き続きインスタンスが必要に応じて自動で追加または削除されます。

グループが属するバックエンド サービス接続ドレインが有効になっていると、接続ドレインの期間が経過してから VM インスタンスが削除されるまでに 60 秒ほどかかる場合があります。

マネージド インスタンス グループからインスタンスを除外するには、Google Cloud Platform Consolegcloud compute ツール、または API を使用します。

Console

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

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

  2. リストの [名前] 列で、インスタンスを削除するインスタンス グループの名前をクリックします。ページが開き、インスタンス グループ プロパティと、グループに含まれるインスタンスのリストが表示されます。
  3. インスタンスのリストで、グループから削除する 1 つ以上のインスタンスを選択します。
  4. [グループから削除] をクリックします。選択したインスタンスはグループから除外されますが、グループ外で引き続き実行されます。

gcloud

インスタンスを実際に削除せずにインスタンス グループからインスタンスを除外するには、abandon-instances サブコマンドを使用します。

gcloud compute instance-groups managed abandon-instances [INSTANCE_GROUP] \
    --instances example-i3n2,example-z2x9 \
    --zone [ZONE]

API

instanceGroupManagers サービスへのリクエストを作成し、対象のマネージド インスタンス グループの名前を指定します。リクエスト本文で、破棄する 1 つ以上のインスタンスの URL を指定します。

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

{
 "instances": [
  "zones/[ZONE]/instances/example-instance-i3n2",
  "zones/[ZONE]/instances/example-instance-l6n1"
 ]
}

マネージド インスタンス グループからインスタンスを破棄するリクエストを行うと、すぐにグループからそのインスタンスが削除されます。 マネージド インスタンス グループのインスタンスのステータスを検証してください。

グループ内にインスタンスを再作成する

インスタンスを再作成すると、指定したインスタンスが削除され、そのマネージド インスタンス グループに割り当てられているインスタンス テンプレートを使用して新しいインスタンスが作成されます。

この方法により、最新のインスタンス テンプレートを使用するよう、特定のインスタンスを更新できます。マネージド インスタンス グループ内のすべてのインスタンスを再作成する必要がある場合は、代わりにローリング アップデートを開始してください。

グループが属するバックエンド サービス接続ドレインが有効になっていると、接続ドレインの期間が経過してから VM インスタンスが削除されるまでに 60 秒ほどかかる場合があります。

マネージド インスタンス グループ内にインスタンスを再作成するには、gcloud compute ツールまたは API を使用します。

gcloud

instance-groups managed recreate-instances サブコマンドを使用します。

gcloud compute instance-groups managed recreate-instances [INSTANCE_GROUP] \
    --instances example-i3n2,example-z2x9 \
    --zone [ZONE]

API

instanceGroupManagers サービスへのリクエストを作成し、対象のマネージド インスタンス グループの名前を指定します。リクエスト本文で、再作成する 1 つ以上のインスタンスの URL を指定します。

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

{
 "instances": [
  "zones/[ZONE]/instances/example-instance-i3n2",
  "zones/[ZONE]/instances/example-instance-l6n1"
 ]
}

マネージド インスタンス グループの再作成のリクエストを行うと、システムでプロビジョニングが可能になり次第、新しいインスタンスが起動します。このプロセスにかかる時間は、再作成するインスタンスの数によっては長くなる場合があります。 マネージド インスタンス グループのインスタンスのステータスを検証してください。

マネージド インスタンス グループ内のインスタンスのステータスを検証する

マネージド インスタンス グループ内のインスタンスは、いくつかのコマンドやリクエストによって作成、削除、変更されます。これらのオペレーションでは、インスタンスの作成、削除、更新のアクションがグループでスケジュールされた時点で DONE が返されます。しかし、それらのアクションが完了するまでは、グループ内のインスタンスの作成、削除、更新が完了したわけではありません。これらのインスタンスのステータスは、gcloud compute ツールまたは API を使用して検証する必要があります。

gcloud

instance-groups managed list-instances コマンドを使用して、グループ内のインスタンスと、そのインスタンスに対する現在のアクションを一覧表示します。

gcloud compute instance-groups managed list-instances [INSTANCE_GROUP] \
    --zone [ZONE]

次に例を示します。

gcloud compute instance-groups managed list-instances example-group \
    --zone [ZONE]
NAME               STATUS  ACTION   LAST_ERROR
example-group-0gnk RUNNING NONE
example-group-15xy         CREATING Error QUOTA_EXCEEDED: Instance 'example-group-15xy' creation failed: Quota 'IN_USE_ADDRESSES' exceeded.  Limit: 23.0
example-group-18ep         CREATING Error QUOTA_EXCEEDED: Instance 'example-group-18ep' creation failed: Quota 'CPUS' exceeded.  Limit: 24.0, Error QUOTA_EXCEEDED: Instance 'example-group-18ep' creation failed: Quota 'IN_USE_ADDRESSES' exceeded.  Limit: 23.0
example-group-1u1y         CREATING

この例で、example-group には 4 つのインスタンスが含まれています。1 つは実行中のもの、2 つは作成を試みたもののアドレスと CPU の割り当てが不足するために作成が完了していないもの、もう 1 つはエラーが発生せずに作成中のものです。

プリエンプティブ インスタンスのグループでは、プリエンプティブ容量を使用できない場合、作成アクションは ZONE_RESOURCE_POOL_EXHAUSTED エラーで失敗します。過去のプリエンプション イベントを表示するには、インスタンスがプリエンプトされたかどうかの確認をご覧ください。

wait-until-stable

instance-groups managed wait-until-stable コマンドを使用すると、インスタンス グループを自動的にチェックして、グループ内のすべてのインスタンスが安定するまでスクリプトを待機させることができます。

gcloud compute instance-groups managed wait-until-stable example-group \
    --zone [ZONE]

API

instanceGroupManagers サービスへのリクエストを作成し、検証したいインスタンスが含まれているマネージド インスタンス グループの名前を指定します。

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

次に例を示します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-f/instanceGroupManagers/example-group/listManagedInstances

リクエストのレスポンスは次のようになります。

{
 "managedInstances": [
  {
   "instance": "https://content.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-f/instances/example-group-0gnk",
   "id": "16960422116594945029",
   "instanceStatus": "RUNNING",
   "currentAction": "NONE"
  },
  {
   "instance": "https://content.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-f/instances/example-group-15xy",
   "currentAction": "CREATING",
   "lastAttempt": {
    "errors": {
     "errors": [
      {
       "code": "QUOTA_EXCEEDED",
       "message": "Instance 'example-group-15xy' creation failed: Quota 'IN_USE_ADDRESSES' exceeded.  Limit: 23.0"
      }
     ]
    }
   }
  },
  {
   "instance": "https://content.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-f/instances/example-group-18ep",
   "currentAction": "CREATING",
   "lastAttempt": {
    "errors": {
     "errors": [
      {
       "code": "QUOTA_EXCEEDED",
       "message": "Instance 'example-group-18ep' creation failed: Quota 'CPUS' exceeded.  Limit: 24.0"
      },
      {
       "code": "QUOTA_EXCEEDED",
       "message": "Instance 'example-group-18ep' creation failed: Quota 'IN_USE_ADDRESSES' exceeded.  Limit: 23.0"
      }
     ]
    }
   }
  },
  {
   "instance": "https://content.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-f/instances/example-group-1u1y",
   "id": "7239700230861444556",
   "instanceStatus": "RUNNING",
   "currentAction": "CREATING"
  }
 ]
}

この例で、example-group には 4 つのインスタンスが含まれています。1 つは実行中のもの、2 つは作成を試みたもののアドレスと CPU の割り当てが不足するために作成が完了していないもの、もう 1 つはエラーが発生せずに作成中のものです。

プリエンプティブ インスタンスのグループでは、プリエンプティブ容量を使用できない場合、作成アクションは ZONE_RESOURCE_POOL_EXHAUSTED エラーで失敗します。過去のプリエンプション イベントを表示するには、インスタンスがプリエンプトされたかどうかの確認をご覧ください。

マネージド インスタンス グループを削除する

Google Cloud Platform Console または gcloud を使用してマネージド インスタンス グループを削除すると、グループ内のすべてのインスタンスと付随するオートスケーラーも削除されます。このマネージド インスタンス グループに保持する必要のあるインスタンスがある場合は、最初にそのインスタンスを破棄してグループから除外します。その後、マネージド インスタンス グループの delete を実行します。

API を使用してマネージド インスタンス グループを削除するには、あらかじめ別のリクエストを発行して、接続されたすべてのオートスケーラーを削除する必要があります。

マネージド インスタンス グループ全体とそのインスタンスを削除するには、Google Cloud Platform Consolegcloud compute ツール、または API を使用します。

Console

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

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

  2. 削除する 1 つ以上のグループをリストから選択します。
  3. [削除] をクリックして、マネージド インスタンス グループとグループ内のインスタンスをすべて削除します。

gcloud

instance-groups managed delete サブコマンドを使用します。

gcloud compute instance-groups managed delete [INSTANCE_GROUP] \
    --zone [ZONE]

API

instanceGroupManagers サービスへの DELETE リクエストを作成し、削除したいマネージド インスタンス グループの名前を指定します。

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

プリエンプティブ インスタンスのグループを作成する

マネージド インスタンス グループを使用すると、複数のプリエンプティブ インスタンスをすぐに作成できるため、マネージド インスタンス グループ内のインスタンスのコスト削減を実現できます。たとえば、プリエンプティブ インスタンスのグループを作成して、それを使用してバッチ処理タスクを実行し、タスクが完了したらそのグループを削除できます。

プリエンプティブ インスタンスのグループを作成するには、インスタンス テンプレートでプリエンプティブ オプションを設定し、そのテンプレートを使用してマネージド インスタンス グループを作成します。

Console

  1. GCP Console の [インスタンス テンプレート] ページに移動します。

    [インスタンス テンプレート] ページに移動

  2. [新しいインスタンス テンプレート] をクリックします。
  3. インスタンス テンプレートに必要なプロパティを入力します。
  4. [詳細設定を表示] をクリックして [可用性ポリシー] セクションを展開します。
  5. [プリエンプティブ] を [オン] にします。
  6. [作成] をクリックしてテンプレートを作成します。
  7. このテンプレートを使用して、マネージド インスタンス グループを作成します。

gcloud

gcloud compute で、instance-templates create コマンドを使用してインスタンス テンプレートを作成します。--preemptible フラグを含めます。

gcloud compute instance-templates create [INSTANCE_TEMPLATE] \
    --preemptible

インスタンス テンプレートを作成したら、それを使用してマネージド インスタンス グループを作成します。

API

instanceTemplates().insert メソッドを使用して新しいインスタンス テンプレートを作成します。schedulingpreemptible プロパティを含め、それを true に設定します。

{
"name": "[INSTANCE_TEMPLATE]",
"properties": {
  "machineType": "zones/[ZONE]/machineTypes/[MACHINE_TYPE]",
  "networkInterfaces": [
    {
      "network": "global/networks/default",
      "accessConfigs":
      [
        {
          "name": "external-IP",
          "type": "ONE_TO_ONE_NAT"
        }
      ]
    }
  ],
  "scheduling":
  {
    "preemptible": true
  },
  "disks":
  [
    {
      "type": "PERSISTENT",
      "boot": true,
      "mode": "READ_WRITE",
      "initializeParams":
      {
        "sourceImage": "projects/debian-cloud/global/images/family/debian-9"
      }
    }
  ]
  }
}

インスタンス テンプレートを作成したら、それを使用してマネージド インスタンス グループを作成します。

マネージド インスタンス グループをロードバランサに追加する

Google Cloud Platform の負荷分散では、マネージド インスタンス グループと非マネージド インスタンス グループの両方を使用してトラフィックが処理されます。使用するロードバランサのタイプに応じて、ターゲット プールまたはバックエンド サービスにインスタンス グループを追加できます。マネージド インスタンス グループと負荷分散の詳細については、インスタンス グループの概要をご覧ください。

マネージド インスタンス グループをバックエンド サービスに追加する

バックエンド サービスは、HTTP(S) ロードバランサ、内部ロードバランサ、または SSL ロードバランサの作成に必要です。バックエンド サービスには、マネージドまたは非マネージドのいずれかのインスタンス グループが 1 つ含まれている個別のバックエンドがそれぞれ含まれます。インスタンス グループ内のインスタンスがロードバランサからのトラフィックにレスポンスします。それにより、バックエンド サービスは使用できるインスタンス、処理可能なトラフィック数、現在処理しているトラフィック数を認識するようになります。また、バックエンド サービスはヘルスチェックをモニタリングし、異常なインスタンスにはトラフィックを送信しません。

インスタンス グループをバックエンド サービスに追加する手順については、バックエンド サービスへのインスタンス グループの追加をお読みください。

マネージド インスタンス グループをターゲット プールに追加する

ターゲット プールは、1 つ以上の仮想マシン インスタンスが含まれるオブジェクトです。ターゲット プールはネットワーク負荷分散で使用され、ネットワーク ロードバランサによって接続されているターゲット プールにユーザー リクエストが転送されます。このターゲット プールに含まれるインスタンスによってこれらのリクエストが処理され、レスポンスが返されます。インスタンス グループに対してインスタンスが追加または削除されると、その変更に合わせてターゲット プールが自動的に更新されるように、マネージド インスタンス グループをターゲット プールに追加できます。

マネージド インスタンス グループをターゲット プールに追加する前に、ターゲット プールを用意しておく必要があります。詳細については、ターゲット プールの追加に関するドキュメントをご覧ください。

既存のマネージド インスタンス グループをターゲット プールに追加する手順は次のとおりです。この操作を行うと、マネージド インスタンス グループに含まれるすべての VM インスタンスがターゲット プールに追加されます。

Console

  1. GCP Console の [ターゲット プール] ページに移動します。

    [ターゲット プール] ページに移動

  2. インスタンス グループを追加するターゲット プールをクリックします。
  3. [編集] ボタンをクリックします。
  4. [VM インスタンス] セクションまで下にスクロールして、[インスタンス グループを選択] をクリックします。
  5. プルダウン メニューからインスタンス グループを選択します。
  6. 変更を保存します。

gcloud

gcloud コマンドライン ツールでは、set-target-pools コマンドを使用します。

gcloud compute instance-groups managed set-target-pools [INSTANCE_GROUP] \
    --target-pools [TARGET_POOL,..] [--zone ZONE]

ここで

  • [INSTANCE_GROUP] はインスタンス グループの名前です。
  • [TARGET_POOL] は、このインスタンス グループの追加先である 1 つ以上のターゲット プールの名前です。
  • [ZONE] はインスタンス グループのゾーンです。

API

API では、次の URI に POST リクエストを送ります。

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

ここで

  • [PROJECT_ID] は、このリクエストのプロジェクト ID です。
  • [ZONE] はインスタンス グループのゾーンです。
  • [INSTANCE_GROUP] はインスタンス グループの名前です。

リクエストの本文には、このグループを追加するターゲット プールの URI のリストを含める必要があります。次に例を示します。

{
  "targetPools": [
    "regions/us-central1/targetPools/example-targetpool-1",
    "regions/us-central1/targetPools/example-targetpool-2"
  ]
}

マネージド インスタンス グループへの名前付きポートの割り当て

名前付きポートは、サービス名とそのサービスが実行されるポート番号を表すキー値のペアです。名前付きポートは、個別のインスタンスでトラフィックを特定のポートに転送するために負荷分散サービスで使用されます。たとえば、名前付きポートを http:80 に設定して http という名前のポートにトラフィックを送信するようにバックエンドを構成した場合、負荷分散によってインスタンス グループの一部である個別のインスタンスのポート 80 にトラフィックが転送されます。

名前付きポートは、負荷分散で使用されるシンプルなメタデータです。名前付きポートは Compute Engine のネットワークまたはファイアウォールのリソースを制御しません。

各サービス名に複数のポートを割り当てることができ、各ポートに複数のサービス名を割り当てることができます。ただし、特定のバックエンド サービスはトラフィックを一度に 1 つの名前付きポートにしか送信できないことに留意してください。

Console

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

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

  2. 名前付きポートを指定するインスタンス グループの名前をクリックします。インスタンス グループのプロパティが記載されたページが表示されます。
  3. [グループを編集] をクリックして、このマネージド インスタンス グループを変更します。
  4. [ポート名のマッピングを指定する] をクリックして、名前付きポートのオプションを展開します。
  5. [項目を追加] をクリックして、希望するポート名とその名前に関連付けるポート番号を入力します。必要に応じて、もう一度 [項目を追加] をクリックして、さらに項目を追加します。
  6. [保存] をクリックして、変更を保存し、マネージド インスタンス グループ内のインスタンスに名前付きポートを適用します。

gcloud

次の set-named-ports コマンドを使用して、1 つ以上の名前付きポートを設定します。

gcloud compute instance-groups managed set-named-ports [INSTANCE_GROUP] \
  --named-ports [PORT_NAME]:[PORT],[PORT_NAME]:[PORT]

次に例を示します。

gcloud compute instance-groups managed set-named-ports [INSTANCE_GROUP] \
  --named-ports name1:80,name2:8080

各サービス名に複数のポートを割り当てる、または各サービスに複数の名前を割り当てるには、各名前またはポートに 1 つ以上の項目を作成します。たとえば、name1 をポート 102080 に割り当てます。その後、name2name3 の両方をポート 80 に割り当てます。最後に、ポート 9000name4 に割り当てます。

gcloud compute instance-groups managed set-named-ports [INSTANCE_GROUP] \
  --named-ports name1:10,name1:20,name1:80,\
                name2:8080,name3:8080,\
                name4:9000

get-named-ports コマンドを使用して、マネージド インスタンス グループに対する名前付きポートの割り当てを確認します。

gcloud compute instance-groups managed get-named-ports [INSTANCE_GROUP]
NAME  PORT
name1 10
name1 20
name1 80
name2 8080
name3 8080
name4 9000

API

Instance Group Manager API では、setNamedPorts API メソッドを提供していませんが、その代わりに Instance Group API を使用してこのタスクを実行できます。

Instance Group API へのリクエストを作成し、インスタンス グループの名前を含めます。特定のインスタンス グループに関する情報を取得して、その情報からグループの現在の fingerprint 値を取得します。リクエスト本文に fingerprint と 1 つ以上の namedPorts 値のペアを含めます。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroups/[INSTANCE_GROUP]/setNamedPorts

{
 "fingerprint": "42WmSpB8rSM=",
 "namedPorts": [
  {
   "name": "[PORT_NAME]",
   "port": [PORT_NUMBER]
  },
  {
   "name": "[PORT_NAME]",
   "port": [PORT_NUMBER]
  }
 ]
}

次に例を示します。

POST https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-a/instanceGroups/example-group/setNamedPorts

{
 "fingerprint": "42WmSpB8rSM=",
 "namedPorts": [
  {
   "name": "name1",
   "port": 80
  },
  {
   "name": "name2",
   "port": 8080
  }
 ]
}

各サービス名に複数のポートを割り当てるには、そのサービス名の複数の項目を作成します。たとえば、ポート 102080name1 に割り当てることができます。さらに、ポート 8080name2 に割り当てます。

POST https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-a/instanceGroups/example-group/setNamedPorts

{
 "fingerprint": "42WmSpB8rSM=",
 "namedPorts": [
  {
   "name": "name1",
   "port": 10
  },
  {
   "name": "name1",
   "port": 20
  }
  {
   "name": "name1",
   "port": 80
  }
  {
   "name": "name2",
   "port": 8080
  }
  {
   "name": "name3",
   "port": 80
  }
  {
   "name": "name4",
   "port": 8080
  }
 ]
}

マネージド インスタンス グループにすでに割り当てられている名前付きポートのリストを表示するには、そのグループを指す GET リクエストを作成します。

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

instanceTemplate フィールドと versions フィールドを理解する

マネージド インスタンス グループを作成するときは、マネージド インスタンス グループが個々の VM インスタンスを作成するために使用するインスタンス テンプレートを指定します。デフォルトでは、Compute Engine で使用するインスタンス テンプレートは、2 つの個別の API プロパティ(トップレベルの instanceTemplate プロパティと versions プロパティ)で記述します。たとえば、次のマネージド インスタンス グループでは、instanceTemplate フィールドと versions フィールドの両方に値が指定されています。

{

 "name": "example-group",
 "zone": "zones/us-central1-a",
 "instanceTemplate": "global/instanceTemplates/example-it",
 "versions": [
  {
   "name": "v3",
   "instanceTemplate": "global/instanceTemplates/example-it",
   "targetSize": {
    "calculated": 3
   }
  }
 ]...
}

Compute Engine では、下位互換性のために、トップレベルの instanceTemplate フィールドと versions フィールドの両方の値が自動的に挿入されます。開発者の方には、versions フィールドを指定し、トップレベルの instanceTemplates フィールドは可能であれば省略することをおすすめします。ただし、アプリケーション コードで現在トップレベルの instanceTemplate フィールドが設定されている場合は、それが有効なリクエストになります。

Managed Instance Group Updater の詳細については、マネージド インスタンス グループの更新をご覧ください。

(詳細)マネージド インスタンス グループを使用したインスタンス テンプレートのカナリアテスト

マネージド インスタンス グループを作成し、VM を 2 つのグループに分けて、グループごとに異なるインスタンス テンプレートを使用させることができます。たとえば、20 個の VM インスタンスを持つマネージド インスタンス グループを作成し、10 個の VM は特定のオペレーティング イメージで実行するようにして、残りを異なるオペレーティング システム イメージで実行できます。この機能を使用すると、インスタンス テンプレートの 2 つの異なるバージョンを比較して 1 つに決めることができます。

API で、次の URL に POST リクエストを行います。

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

リクエストの本文では、トップレベルの instanceTemplates フィールドは省略しますが、2 つのインスタンス テンプレートを設定するために versions プロパティは含める必要があります。各 versions オブジェクトで、インスタンス テンプレートを指定します。versions オブジェクトのどちらか一方で targetSize も指定する必要があります(両方のオブジェクトで指定しないでください)。たとえば、次のリクエストでは、VM インスタンスの 50% で example-template インスタンス テンプレートが使用され、残りの VM インスタンスで small-machine-type テンプレートが使用されるインスタンス グループが作成されます。

{
  "baseInstanceName": "example-instances",
  "name": "example-group",
  "targetSize": 5,
  "versions":
  [
    {
      "instanceTemplate": "global/instanceTemplates/example-template",
      "targetSize":
      {
        "percent": 50
      }
    },
   {
     "instanceTemplate": "global/instanceTemplates/small-machine-type"
   }
  ]
}

マネージド インスタンス グループと IAM

マネージド インスタンス グループの一部として Compute Engine が実行するオペレーションはすべて、該当するプロジェクトの Google API サービス アカウントを使用して実行されます。このプロジェクトごとのサービス アカウントには、次のようなメールアドレスがあります。

[PROJECT_ID]@cloudservices.gserviceaccount.com

ここで

  • [PROJECT_ID] は、対応するプロジェクトの数値 ID です。

Google API サービス アカウントは、デフォルトの Compute Engine サービス アカウントとは異なります。

マネージド インスタンス グループが使用するサービス アカウントに十分な権限があり、インスタンス テンプレートをベースに仮想マシン インスタンスを作成できるかどうかを確認する必要があります。つまり、インスタンス グループでインスタンスを作成して管理するには、サービス アカウントに compute.instanceAdmin.v1(場合によっては serviceAccountUser)の役割が付与されている必要があります。serviceAccountUser の役割は、マネージド インスタンス グループ内に、サービス アカウントとして実行できるインスタンスを作成する場合のみ必要です。また、このアカウントは Deployment Manager を含むその他のプロセスでも使用されることに注意してください。

マネージド インスタンス グループを作成、またはインスタンス テンプレートを更新する際は、Compute Engine が Google API サービス アカウントに関して以下のことを検証します。

  • サービス アカウントとして実行できるインスタンスを作成する場合、インスタンス テンプレートに対する serviceAccountUser の役割が付与されているかどうか。
  • イメージ、ディスク、VPC ネットワーク、サブネットなど、インスタンス テンプレートから参照されているすべてのリソースへのアクセス権があるかどうか。

サービス アカウントの詳細については、サービス アカウントの概要をご覧ください。

マネージド インスタンス グループ内ですべてのインスタンスを更新する

マネージド インスタンス グループの更新をご覧ください。

トラブルシューティング

マネージド インスタンス グループでインスタンスの作成に繰り返し失敗します。どうなっているのでしょうか。

インスタンス グループでインスタンスを正常に作成または再作成できない原因として考えられる問題はいくつかあります。以下に、一般的な問題を一部紹介します。

  • マネージド インスタンス グループがインスタンスとブート永続ディスクの両方を作成または再作成しようとしていますが、永続ディスクはすでに存在します。デフォルトでは、新しいインスタンスが作成されると、新しいブート永続ディスクが作成されます。これらのディスクにはインスタンスの名前が付けられます。インスタンスの名前が my-awesome-instance の場合、ディスクにも my-awesome-instance という名前が付けられます。その名前で永続ディスクがすでに存在している場合、リクエストは失敗します。この問題を解決するには、既存の永続ディスクを削除します。

  • インスタンス テンプレートでブート永続ディスクの disks.autoDelete オプションが false に設定されていると、(たとえば自動修復によって)インスタンスが削除されても永続ディスクは削除されません。マネージド インスタンス グループが同じ名前でインスタンスを再作成しようとすると、その名前の永続ディスクがすでに存在する場合と同じ問題が発生します。既存の永続ディスクを削除して直接的な問題を解決します。インスタンスの削除時にブート永続ディスクも削除する場合は、インスタンス テンプレートの disks.autoDeletetrue に設定して更新します。

  • インスタンス テンプレートが無効である可能性があります。インスタンス テンプレートを最近更新した場合、マネージド インスタンス グループに無効なプロパティが存在することが原因でインスタンスの作成に失敗することがあります。無効なプロパティには次のようなものがあります。

    • ソースイメージなど、存在しないリソースを指定している。
    • リソース名にスペルミスがある。
    • ブート以外の追加の永続ディスクに読み取り / 書き込みモードで接続しようとしている。インスタンス グループには複数のインスタンスが含まれているため、グループ内のすべてのインスタンスで共有する追加のディスクの接続は、読み取り専用モードでのみ可能になります。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

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

Compute Engine ドキュメント