リージョン マネージド インスタンス グループを使用したインスタンスの配分

このページでは、単一のリージョン内に分散したインスタンスを含むマネージド インスタンス グループを作成する方法について説明します。

単一のゾーンに属しているゾーンのマネージド インスタンス グループとは異なり、リージョン マネージド インスタンス グループではインスタンス単一のリージョン内の複数のゾーンに分散されるため、アプリケーションの可用性が向上します。たとえば、デフォルトで、リージョン us-east1 のリージョン マネージド インスタンス グループが、そのリージョン内の us-east1-bus-east1-cus-east1-d という 3 つのゾーンでインスタンスを均等に配分するとします。

リージョンに 4 つ以上のゾーンが含まれる場合、リージョン マネージド インスタンス グループは 3 つのゾーンを選択して、そこにインスタンスを作成します。また、インスタンスを作成するゾーンを選択したり、ゾーンが 3 つ未満のリージョンでインスタンスを作成したりすることもできます。たとえば、GPU でワークロードを高速化する場合は、GPU をサポートするゾーンを選択します。

ゾーン マネージド インスタンス グループと同様、リージョン マネージド インスタンス グループでは、自動スケーリング、内部負荷分散、外部負荷分散がサポートされます。

始める前に

制限事項

  • 1 つのリージョン マネージド インスタンス グループには最大で 2,000 個のインスタンスを組み込むことができます。
  • マネージド インスタンス グループの更新時に、1 回のリクエストで指定できるインスタンス数は最大で 1,000 個です。
  • リージョン マネージド インスタンス グループには、maxRate 分散オプションを使用するロードバランサを使用できません。

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

リージョン マネージド インスタンス グループは、アプリケーションの負荷を複数のゾーンに分散でき、アプリケーションが単一のゾーンに制限されることも、異なるゾーンで複数のインスタンス グループを管理する必要もないため、通常のゾーン マネージド インスタンス グループよりもおすすめします。このレプリケーション機能は、ゾーン障害の発生や、単一ゾーンでインスタンス グループ全体の誤動作が起こる予期しない事態からトラフィックを保護します。このような事態が起きた場合でも、アプリケーションは同じリージョンの別のゾーンで実行しているインスタンスからトラフィックの処理を続行できます。

ゾーン障害が発生した場合、またはゾーン内のインスタンス グループのレスポンスが停止した場合でも、リージョン マネージド インスタンス グループは次のように VM のサポートを続行します。

  • このリージョン マネージド インスタンス グループに含まれるインスタンスのうち、他のゾーンに存在するものは、トラフィックの処理を続行します。自動スケーリングが設定されている場合を除き、新しいインスタンスの追加やインスタンスの再配分は行われません。

  • 障害が発生したゾーンが回復すると、インスタンス グループはそのゾーンからのトラフィック処理を再開します。

強固でスケーラブルなアプリケーションを設計する必要がある場合は、リージョン マネージド インスタンス グループを使用してください。

プロアクティブなインスタンスの再配布

デフォルトでは、ゾーンレベルで障害が発生した場合のアプリケーションの可用性を維持するため、リージョン マネージド インスタンス グループはリージョン内のソーン間で VM インスタンスを均等に配布しようとします。

グループの VM インスタンスに delete または abandon を実行すると、ゾーン間の配布が不均等になるため、グループはインスタンスをプロアクティブに再配布し、均等な配布状態を維持します。

ゾーン間での均等な配布を維持するため、グループは複数の VM を持つインスタンスを削除し、VM 数の少ない新しいインスタンスをゾーンに追加します。削除されるインスタンスは自動的に選択されます。

プロアクティブな再配布の例

たとえば、リージョン マネージド インスタンス グループで、ゾーン us-central1-aus-central1-bus-central1-c にそれぞれ 4 つのインスタンスがあり、us-central1-c から 3 つの VM インスタンスを削除したとします。この場合、ゾーン間でインスタンスが均等に存在するように再調整が行われます。この例では、ゾーン us-central1-aus-central1-b から 1 つのインスタンスが削除され、ゾーン us-central1-c に 2 つのインスタンスが追加されます。これにより、各ゾーンのインスタンス数がすべて 3 つになります。削除されるインスタンスを選択することはできません。

インスタンスの自動再配布を防ぐには、リージョン マネージド インスタンス グループを作成または更新するときに、プロアクティブなインスタンスの再配布を無効にします

この設定は、次のような場合に便利です。

  • 実行中の他の VM インスタンスに影響を与えずに、VM を削除または放棄する。たとえば、ジョブの完了時に、他のワーカーに影響を及ぼさずにバッチワーカー VM を削除できます。
  • ステートフル アプリケーションが実行されている VM がプロアクティブな再配布により自動的に削除されないようにする。
プロアクティブな再配布を無効にした後に発生する不均等な配布状態

プロアクティな再配布を無効にしても、マネージド インスタンス グループはサイズ変更オペレーションの実行時に調整を行います。サイズ変更オペレーションがグループの調整機会となります。たとえば、スケールダウンでは大きいゾーンからインスタンスが削除され、スケールアップでは小さいゾーンにインスタンスが追加されます。ただし、プロアクティブなインスタンスの再配布を無効にした場合、バランス調整のためにインスタンスの追加や削除が事前に行われることはありません。

正しいマネージド インスタンス グループサイズをプロビジョニングする

ゾーンでの障害や、インスタンスのグループ全体での応答停止など、特殊な状況に備えるために、Compute Engine ではマネージド インスタンス グループをオーバープロビジョニングしておくことを強くおすすめします。アプリケーションのニーズに応じて、グループをオーバープロビジョニングし、ゾーンやインスタンスのグループが応答しなくなった場合にシステム全体に障害が発生することを防止します。

Google は、ユーザーがアプリケーションを使用できる状態を保つという点を優先して、オーバープロビジョニングに関する推奨事項を作成しています。これらの推奨事項には、アプリケーションで日常的に必要な VM インスタンスよりも多くの VM インスタンスのプロビジョニングや支払いが含まれます。アプリケーションのニーズとコストに関する制限に基づき、オーバープロビジョニングに関して最適な判断を行う必要があります。

3 つ以上のゾーンでリージョン マネージド インスタンス グループをプロビジョニングする

少なくとも 3 つのゾーンを含むリージョンでリージョン マネージド インスタンス グループを作成する場合、インスタンス グループを少なくとも 50% オーバープロビジョニングすることをおすすめします。デフォルトで、リージョン マネージド インスタンス グループによって、3 つのゾーンにインスタンスが作成されます。3 つのゾーンに VM インスタンスを置くことで、処理能力の少なくとも 2/3 を確保することができ、1 つのゾーンで障害が発生しても、リージョン内の残りの 2 つのゾーンでは、トラフィックの処理を中断なく続行できます。150% までオーバープロビジョニングすると、能力の 1/3 が失われても、残りのゾーンでトラフィックに 100% 対応できます。

たとえば、3 つのゾーン全体でマネージド インスタンス グループに 20 の仮想マシン インスタンスが必要な場合、インスタンス数の少なくとも 50% をさらに追加することをおすすめします。この場合、20 のインスタンスの 50% にあたる 10 のインスタンスが追加して、インスタンス グループ内のインスタンス数を 30 にします。サイズが 30 のリージョン マネージド インスタンス グループを作成すると、ゾーン間で可能な限り均等になるようにグループ内のインスタンスが配布されます。

ゾーン インスタンス数
example-zone-1 10
example-zone-2 10
example-zone-3 10

あるゾーンで障害が発生したとしても、トラフィックを処理するインスタンスは 20 残っています。

2 つのゾーンでリージョン マネージド インスタンス グループをプロビジョニングする

3 つではなく、2 つのゾーンでインスタンスをプロビジョニングする場合、インスタンスの数を 2 倍にすることをおすすめします。たとえば、サービス用に 20 の VM インスタンスを 2 つのゾーンに配分する必要がある場合、40 のインスタンスを持つリージョン マネージド インスタンス グループを構成して、各ゾーンに 20 のインスタンスが含まれるようにする必要があります。1 つのゾーンで障害が発生しても、20 のインスタンスでトラフィックが引き続き処理されます。

ゾーン インスタンス数
example-zone-1 20
example-zone-2 20

グループ内のインスタンス数が 2 つのゾーン間で均等にならない場合、Compute Engine はインスタンスを可能な限り均等に分割し、残りのインスタンスをいずれかのゾーンにランダムに追加します。

1 つのゾーンでリージョン マネージド インスタンス グループをプロビジョニングする

1 つのゾーンのみを使用して、リージョン マネージド インスタンス グループを作成することもできます。これは、ゾーン マネージド インスタンス グループの作成に似ています。

単一のゾーン リージョン マネージド インスタンス グループを作成することはおすすめしません。これは、可用性が最小限の構成であるからです。ゾーンまたはリージョンに障害が発生すると、マネージド インスタンス グループ全体が使用できなくなり、ユーザーに混乱が生じる可能性があります。

グループのゾーンを選択する

リージョン マネージド インスタンス グループのデフォルト構成では、3 つのゾーン全体にわたって可能な限り均等にインスタンスが配分されます。さまざまな理由で、アプリケーション用に特定のゾーンを選択することが必要になる場合があります。たとえば、インスタンス用の GPU が必要な場合、GPU をサポートしているゾーンのみを選択する可能性があります。特定のゾーンでのみ使用できる永続ディスクを使用している場合や、リージョン内の 3 つのランダムなゾーンではなく、いくつかのゾーンでのみ、VM インスタンスで開始する場合などです。

ゾーンの数を選択したり、インスタンス グループが実行される特定のゾーンを選択したりする必要がある場合、最初にグループを作成する時点で選択する必要があります。作成中に特定のゾーンを選択すると、後でそのゾーンを変更または更新することはできなくなります。

  • 1 つのリージョン内で 4 つ以上のゾーンを選択するには、個々のゾーンを明示的に指定する必要があります。たとえば、リージョン内の 4 つすべてのゾーンを選択するには、リクエストで 4 つのゾーンのすべてを明示的に指定する必要があります。これを行わなければ、Compute Engine のデフォルトによって 3 つのゾーンが選択されます。

  • 特定リージョン内の 2 つ以下のゾーンを選択するには、個々のゾーンを明示的に指定する必要があります。リージョンに含まれているゾーンが 2 つしかない場合でも、リクエストではゾーンを明示的に指定する必要があります。

特定のゾーンを選択するか、単にリージョンを選択し、Compute Engine がそのリージョン内のすべてのゾーンでインスタンスを作成できるようにするかに関係なく、新しい VM インスタンスはデフォルトですべてのゾーンにわたって均等に配分されます。ベスト プラクティスとして、指定された数のゾーンでアプリケーションをサポートするのに十分な VM インスタンスがプロビジョニングされていることを確認します。

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

gcloud コマンドライン ツール、Console、または API でリージョン マネージド インスタンス グループを作成します。

各ゾーンにインスタンス グループのインスタンスをサポートに十分な容量がない場合、Compute Engine は可能な限り多くのインスタンスを作成し、追加の割り当て量が利用可能になったら、引き続き残りのインスタンスの作成を試行します。

リージョン マネージド インスタンス グループを作成する場合、永続ディスクなど、特定のリソースはゾーンリソースであることに注意してください。インスタンス テンプレートでゾーンリソースを指定している場合、追加の永続ディスクと同様、このディスクはすべてのゾーンに存在し、このリージョン マネージド インスタンス グループで作成されたインスタンスが接続できるようにする必要があります。

デフォルトでは、リクエストに個々のゾーンを明示的に指定しないと、Compute Engine は 3 つのゾーンを自動的に選択し、そのゾーン内にインスタンスを作成します。3 つを超える、または 3 つ未満のゾーンにインスタンスを作成する必要がある場合、あるいは、使用するゾーンを選択する必要がある場合、リクエストでゾーンのリストを指定します。詳しくは、グループのゾーンを選択するをご覧ください。

デフォルトでは、プロアクティブなインスタンスの再配布は有効になっています。各ゾーンのインスタンス数を手動で管理する必要がある場合は、プロアクティブなインスタンスの再配布を無効にできます。この場合、自動スケーリングは構成できません。プロアクティブなインスタンスの再配布をご覧ください。

Console

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

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

  2. [インスタンス グループを作成] をクリックして、新しいインスタンス グループを作成します。
  3. [ロケーション] で [マルチゾーン] を選択します。
  4. 目的のリージョンを選択します。
  5. 特定のゾーンを選択する場合、[ゾーンを設定] をクリックして、使用するゾーンを選択して構成します。
  6. プロアクティブなインスタンスの再配布を無効にするには:
    1. 自動スケーリング モードオフになっていることを確認します。
    2. [インスタンスの再配布] を [オフ] に設定します。
  7. インスタンス グループ用のインスタンス テンプレートを選択するか、新しいインスタンス テンプレートを作成します。
  8. そのグループのインスタンス数を指定します。ゾーンに障害が発生した場合に備えて、アプリケーションのサポートに十分なインスタンスをプロビジョニングしてください。
  9. マネージド インスタンス グループの残りの作成手順を続行します。

gcloud

すべてのマネージド インスタンス グループに、インスタンス テンプレートが必要です。ない場合は、インスタンス テンプレートを作成してください。たとえば、次のコマンドを使用して、デフォルト プロパティを含む基本的なインスタンス テンプレートを作成します。

gcloud compute instance-templates create example-template

次に、--region フラグを指定して instance-groups managed create サブコマンドを使用します。たとえば、このコマンドによって、us-east1 リージョン内の 3 つのゾーンにリージョン マネージド インスタンス グループが作成されます。

gcloud compute instance-groups managed create example-rmig \
    --template example-template --base-instance-name example-instances \
    --size 30 --region us-east1

グループで使用する特定のゾーンを選択する必要がある場合は、--zones フラグを指定します。

gcloud compute instance-groups managed create example-rmig \
    --template example-template --base-instance-name example-instances \
    --size 30 --zones us-east1-b,us-east1-c

プロアクティブなインスタンスの再配布を無効にするには、--instance-redistribution-type フラグを NONE に設定します。この機能はベータ版のため、gcloud beta ツールを使用する必要があります。自動スケーリングが有効になっていると、プロアクティブなインスタンスの再配布を無効にできません。

gcloud beta compute instance-groups managed create example-rmig \
    --template example-template --base-instance-name example-instances \
    --size 30 --instance-redistribution-type NONE

注: プロアクティブなインスタンスの再配布を無効にするには、gcloud beta コンポーネントを使用します。プロアクティブなインスタンスの再配布を無効にする機能は、現在ベータ版として提供されています。

API

すべてのマネージド インスタンス グループに、インスタンス テンプレートが必要です。ない場合は、インスタンス テンプレートを作成してください。

API で、regionInstanceGroupManagers.insert メソッドへの POST リクエストを作成します。リクエスト本文には、必要なグループ名、グループサイズ、グループ内のインスタンスのベース名、インスタンス テンプレートへの URL を記載します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers

{
  "baseInstanceName": "[BASE_INSTANCE_NAME]",
  "instanceTemplate": "global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
  "name": "[INSTANCE_GROUP_NAME]",
  "targetSize": "[TARGET_SIZE]",
  "distributionPolicy": {
     "zones": [
       {"zone": "zones/[ZONE]"},
       {"zone": "zones/[ZONE]"}
      ]
   }
}

ここで

  • [PROJECT_ID] は、このリクエストのプロジェクト ID です。
  • [REGION] はインスタンス グループのリージョンです。
  • [BASE_INSTANCE_NAME] は、インスタンス グループの構成部分として作成された、各インスタンスのインスタンス名です。たとえば、ベース インスタンス名が example-instance の場合、example-instance-[RANDOM_STRING] のような名前のインスタンスが作成されます。ここで、[RANDOM_STRING] はサーバーによって生成されます。
  • [INSTANCE_TEMPLATE_NAME] は使用するインスタンス テンプレートです。
  • [TARGET_SIZE] はインスタンス グループ内のインスタンスのターゲット数です。

特定のゾーンを選択する場合や、3 つ未満あるいは 3 つを超えるゾーンを含むリージョンでインスタンスを作成する場合、リクエストに distributionPolicy プロパティを含めて、ゾーンのリストを指定します。インスタンスを作成するゾーンの名前に [ZONE] を置き換えます。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers

{
  "baseInstanceName": "[BASE_INSTANCE_NAME]",
  "instanceTemplate": "global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
  "name": "[INSTANCE_GROUP_NAME]",
  "targetSize": "[TARGET_SIZE]",
  "distributionPolicy": {
     "zones": [
       {"zone": "zones/[ZONE]"},
       {"zone": "zones/[ZONE]"}
      ]
   }
}

たとえば以下のようにすると、us-east1-b ゾーンと us-east1-c ゾーンにわたり、10 個のインスタンスが分配された、example-rmig という名前のインスタンス グループが作成されます。

POST https://www.googleapis.com/compute/v1/projects/myproject/regions/us-east1/instanceGroupManagers
{

  "baseInstanceName": "example-instance",
  "instanceTemplate": "global/instanceTemplates/example-instance",
  "name": "example-rmig",
  "targetSize": 10,
  "distributionPolicy": {
      "zones": [
        {"zone": "zones/us-east1-b"},
        {"zone": "zones/us-east1-c"}
      ]
   }
}

プロアクティブなインスタンスの再配布を無効にするには、リクエストに updatePolicy プロパティを追加し、instanceRedistributionTypeNONE に設定します。この機能はベータ版のため、Beta API を使用する必要があります。自動スケーリングが有効になっていると、プロアクティブなインスタンスの再配布を無効にできません。

POST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers

{
  "baseInstanceName": "[BASE_INSTANCE_NAME]",
  "instanceTemplate": "global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
  "name": "[INSTANCE_GROUP_NAME]",
  "targetSize": "[TARGET_SIZE]",
  "updatePolicy": {
     "instanceRedistributionType": "NONE"
   },
}

リージョン マネージド インスタンス グループのインスタンスを一覧表示する

リージョン マネージド インスタンス グループのインスタンスの一覧を取得するには、GCP Console を使用するか、gcloud コマンドライン ツールの instance-groups managed list-instances コマンドを使用するか、regionInstanceGroupManagers.listManagedInstances メソッドに対してリクエストを実行します。

Console

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

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

  2. インスタンスを表示するリージョン マネージド インスタンス グループの名前をクリックします。

インスタンス グループ詳細ページに、インスタンス グループのインスタンスの一覧が読み込まれます。

gcloud

instance-groups managed list-instances コマンドを実行します。

gcloud compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] --region [REGION]

ここで

  • [INSTANCE_GROUP_NAME] はインスタンス グループの名前です。
  • [REGION] はインスタンス グループのリージョンです。

たとえば、以下のコマンドでは、リージョン us-east1example-rmig という名前のインスタンス グループの一部であるインスタンスを一覧表示します。

gcloud compute instance-groups managed list-instances example-rmig --region us-east1

API

API では、regionInstanceGroupManagers.listManagedInstances メソッドに対する空の GET リクエストを作成します。

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

例:

GET https://www.googleapis.com/compute/v1/projects/myproject/regions/us-east1/instanceGroupManagers/example-rmig

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

Instance Group Updater 機能を使用して、リージョン マネージド インスタンス グループを更新できます。Updater を使用すると、インスタンスのサブセットまたはグループ内のすべてのインスタンスを新しいインスタンス テンプレートに更新できます。また、Updater を使用してカナリア更新を実行し、更新の速度を制御することもできます。

関連して、gcloudset-instance-template コマンドまたは API の setInstanceTemplate メソッドを使用して、既存のインスタンスを更新せずにインスタンス グループのインスタンス テンプレートを変更することもできます。インスタンス テンプレートを変更しても、既存のインスタンスが新しいインスタンス テンプレートに応じて自動的に更新されるわけではないことに注意してください。変更を適用するには、個々のインスタンスを再作成するか、Instance Group Updater を実行する必要があります。ただし、グループに対する新しい VM インスタンスは新しいインスタンス テンプレートを使用します。

プロアクティブなインスタンスの再配布の無効化と有効化

プロアクティブなインスタンスの再配布はリージョン内のゾーン間でインスタンス数を均等にする機能です。この構成は、ゾーンレベルで障害が発生した場合にアプリケーションの可用性を可能な限り維持することを目的としています。

リージョン マネージド インスタンス グループでは、プロアクティブなインスタンスの再配布がデフォルトで有効になっていますが、自動スケーリングを行わないマネージド インスタンス グループではこの機能を無効にすることができます。プロアクティブなインスタンスの再配布を無効にすると、ゾーン間でインスタンスの再配布は事前に行われません。この設定は、次のような場合に便利です。

  • 実行中の他の VM インスタンスに影響を与えずに、VM を手動で削除または放棄する。
  • ジョブの完了時に、他のワーカーに影響を及ぼさずにバッチワーカー インスタンスを自動的に削除する。
  • ステートフル アプリケーションが実行されているインスタンスがプロアクティブな再配布により自動的に削除されないようにする。

グループの VM インスタンスを削除または放棄して、ゾーン間でインスタンス数が不均等になった場合は、プロアクティブな再配布を有効にする前に、グループ内の調整を手動で行う必要があります。グループの調整を手動で行うには、グループのサイズを変更するか、インスタンス数の多いゾーンからインスタンスを削除します。

プロアクティブなインスタンスの再配布が無効になっているマネージド インスタンス グループのサイズを変更すると、グループ内の調整が自動的に行われます。サイズ変更オペレーションがグループの調整機会となります。グループのサイズを大きくする場合、VM 数が最も少ないゾーンにインスタンスが追加されます。グループのサイズを小さく場合は、インスタンス数が最も多いゾーンからインスタンスが削除されます。

グループのサイズを手動で変更して均等な配布を実現

プロアクティブなインスタンスの再配布が無効なインスタンス グループを作成するには、コンソール、gcloud ツールまたは API を使用します。既存のグループでプロアクティブなインスタンスの再配布を無効または有効にする場合も同様です。

プロアクティブなインスタンスの再配布が無効なグループを作成する

Console

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

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

  2. [インスタンス グループを作成] をクリックして、新しいインスタンス グループを作成します。
  3. [ロケーション] で [マルチゾーン] を選択します。
  4. 目的のリージョンを選択します。
  5. 特定のゾーンを選択する場合、[ゾーンを設定] をクリックして、使用するゾーンを選択して構成します。
  6. To disable proactive instance redistribution:
    1. 自動スケーリング モードオフになっていることを確認します。
    2. [インスタンスの再配布] を [オフ] に設定します。
  7. インスタンス グループ用のインスタンス テンプレートを選択するか、新しいインスタンス テンプレートを作成します。
  8. そのグループのインスタンス数を指定します。ゾーンに障害が発生した場合に備えて、アプリケーションのサポートに十分なインスタンスをプロビジョニングしてください。
  9. マネージド インスタンス グループの残りの作成手順を続行します。

gcloud

プロアクティブなインスタンスの再配布を行わない新しいリージョン マネージド インスタンス グループを作成するには、gcloud beta compute instance-groups managed create コマンドを使用して --instance-redistribution-type フラグを NONE に設定します。

gcloud beta compute instance-groups managed create [INSTANCE_GROUP_NAME] \
    --template [TEMPLATE] \
    --size [SIZE] \
    --zones [ZONES] \
    --instance-redistribution-type NONE

ここで

  • [INSTANCE_GROUP_NAME] はインスタンス グループの名前です。
  • [TEMPLATE] は、グループに使用するインスタンス テンプレートの名前です。
  • [SIZE] は、インスタンス グループのターゲット サイズです。
  • [ZONES] は、1 つのリージョン内で VM インスタンスのデプロイが必要なゾーンのリストです。

例:

gcloud beta compute instance-groups managed create example-rmig \
    --template example-template \
    --size 30 \
    --zones us-east1-b,us-east1-c \
    --instance-redistribution-type NONE

API

プロアクティブなインスタンスの再配布と自動スケーリングを行わないリージョン マネージド インスタンス グループを作成するには、regionInstanceGroupManagers.insert メソッドを呼び出す POST リクエストを送信します。リクエストの本文に updatePolicy プロパティを含め、instanceRedistributionType フィールドを NONE に設定します。

POST
https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]
{
    "name": "[INSTANCE_GROUP_NAME]",
    "baseInstanceName": "[BASE_INSTANCE_NAME]",
    "instanceTemplate": "global/instanceTemplates/[TEMPLATE]",
    "targetSize": "[TARGET_SIZE]",
    "distributionPolicy": {
        "zones": [
            {"zone": "zones/[ZONE]"},
            {"zone": "zones/[ZONE]"}
        ]
    },
    "updatePolicy": {
        "instanceRedistributionType": "NONE"
    }
}

ここで

  • [PROJECT_ID] は、このリクエストのプロジェクト ID です。
  • [REGION] はインスタンス グループのリージョンです。
  • [INSTANCE_GROUP_NAME] はインスタンス グループの名前です。
  • [BASE_INSTANCE_NAME] は、インスタンス名のプレフィックスです。インスタンス名のサフィックスは自動的に生成されます。
  • [TEMPLATE] は、グループに使用するインスタンス テンプレートの名前です。
  • [TARGET_SIZE] は、インスタンス グループのターゲット サイズです。
  • [ZONE] は、1 つのリージョン内で VM インスタンスのデプロイが必要なゾーンの名前です。

プロアクティブなインスタンスの再配布を無効にする

プロアクティブなインスタンスの再配布を無効にする前に、自動スケーリングを無効にする必要があります。

Console

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

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

  2. 更新するインスタンス グループを選択するには、[グループの編集] をクリックします。
  3. 自動スケーリング モードオフになっていることを確認します。
  4. [インスタンスの再配布] を [オン] に設定し、自動再配布を無効にします。
  5. [保存] をクリックします。

gcloud

自動スケーリングを行わないリージョン マネージド グループでプロアクティブなインスタンスの再配布を無効にするには、compute instance-groups managed update コマンドを使用して --instance-redistribution-type フラグを NONE に設定します。

 gcloud beta compute instance-groups managed update [INSTANCE_GROUP_NAME]
    --instance-redistribution-type NONE \
    --region [REGION]

ここで

  • [INSTANCE_GROUP_NAME] はインスタンス グループの名前です。
  • [REGION] はインスタンス グループのリージョンです。

注: プロアクティブなインスタンスの再配布を無効にするには、gcloud beta コンポーネントを使用します。現在、インスタンスの再配布を無効にする機能はベータ版として提供されています。

API

API で、regionInstanceGroupManagers.patch メソッドへの PATCH リクエストを作成します。リクエストの本文に updatePolicy プロパティを含め、instanceRedistributionType フィールドを NONE に設定します。

PATCH
https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP]

{
    "updatePolicy": {
         "instanceRedistributionType": "NONE"
    }
}

ここで

  • [PROJECT_ID] は、このリクエストのプロジェクト ID です。
  • [REGION] はインスタンス グループのリージョンです。
  • [INSTANCE_GROUP] は、自動スケーリングを行わないマネージド インスタンス グループの名前です。

注: プロアクティブなインスタンスの再配布を無効にするには、ベータ版の API を使用します。現在、インスタンスの再配布を無効にする機能はベータ版として提供されています。

プロアクティブなインスタンスの再配布を有効にする

プロアクティブなインスタンスの再配布を有効にするには、プロアクティブなインスタンスの再配布を無効にすると類似するコマンドを使用しますが、インスタンスの配布タイプを PROACTIVE に設定します。

インスタンスを手動で削除または放棄し、リージョン間でインスタンス数の不均等が発生した場合、プロアクティブなインスタンスの再配布を有効にする前に、グループの調整を手動で行う必要があります。2 つのゾーン間での VM インスタンス数の違いは 1 VM 以下にする必要があります。

ゾーン間のインスタンス数を手動で均等にするには、配布状態が均等になるまで、インスタンス数が多いゾーンから VM を削除するか、インスタンス数の少ないゾーンがいっぱいになるまでグループのサイズを変更します。

リージョン マネージド インスタンス グループでは、ゾーン間のインスタンス数が不均等になってもプロアクティブなインスタンスの再配布を有効にできません(2 つのゾーン間の VM インスタンス数の違いが 2 つ以上のため)。これは、不均等を調整するために、インスタンス数の多いゾーンから VM が自動的に削除されないようにするためです。

リージョン マネージド インスタンス グループを自動スケーリングする

Compute Engine はマネージド インスタンス グループの自動スケーリング機能を備えています。この機能では、負荷の増減に基づき、インスタンス グループが自動的にインスタンスの追加と削除を実行します。リージョン マネージド インスタンス グループに対しても、自動スケーリングを有効にすることができます。

リージョン マネージド インスタンス グループで自動スケーリングを有効にした場合、この機能は次のように動作します。

  • 自動スケーリングのポリシーは、個別のゾーンではなく、グループ全体に適用されます。たとえば、CPU 使用率 66% を目標としてオートスケーラーを設定すると、オートスケーラーはグループ内のすべてのインスタンスを追跡して、すべてのゾーンのすべてのインスタンスの平均 CPU 使用率が 66% に保持されるようにします。

  • 自動スケーリングでは、利用可能なゾーンにインスタンスが可能な限り均等に配分されます。一般にオートスケーラーはサイズの小さいゾーンを大きくし、大きいゾーンから負荷が振り分けられるようにしてゾーンのサイズのバランスを保ちます。1 つのゾーンを優先するカスタムのロードバランサは、予期しない動作の発生原因になる可能性があるため、このようなロードバランサの構成はおすすめできません。

  • 1 つのゾーン、または 1 つのゾーン内のインスタンス グループに障害が発生した場合は、処理能力の 1/3 が失われることになりますが、2/3 は他のゾーンで確保されています。あるゾーンが停止したときに、残っているサーバーへの負荷の集中を回避するため、自動スケーリング対象のマネージド インスタンス グループをオーバープロビジョニングするように、自動スケーリング ポリシーを設定することをおすすめします。

オートスケーラーがゾーンに追加できるインスタンスは、グループに指定されている上限数の 1/3 までに制限されています。たとえば、自動スケーリングに構成された maxNumReplicas が 15 であれば、オートスケーラーでインスタンス グループのゾーンごとに追加できるインスタンス数は 1/3 × 15 = 5 になります。1 つのゾーンに障害が発生した場合、オートスケーラーが設定できる数は、残り 2 つのゾーンであわせて maxNumReplicas の 2/3 までになります。

オートスケーラー構成をプロビジョニングする

マネージド インスタンス グループのオーバープロビジョニングが推奨されているように、オートスケーラーの構成も、次のようにオーバープロビジョニングする必要があります。

  • 自動スケーリングの使用率目標値を、希望する使用率目標値の 2/3 にします。
  • 引き下げられた使用率目標値に対応するために、オートスケーラーがインスタンスを追加するので、maxNumReplicas を、オーバープロビジョンを考慮しない場合の設定値の 50% 増しになるように設定します。

たとえば、20 のインスタンスでピーク時の負荷を処理でき、その目標使用率が 80% になるようにするには、オートスケーラーを次のように設定します。

  • 目標使用率として 80% ではなく 2/3 × 0.8 = 0.53 すなわち 53% を設定
  • インスタンスの最大数として 20 ではなく 3/2 × 20 = 30 を設定

この設定では、単一ゾーンで障害が発生した場合、インスタンス グループが容量不足になることはありません。使用率目標値を限界より低く設定しているため、残りの 2/3 のインスタンスで、オフライン ゾーンから振り分けられた増加負荷分を処理できるためです。さらにオートスケーラーは、使用率を目標値の 2/3 に維持するために、指定されたインスタンスの最大数まで、新しいインスタンスを追加します。

ただし、負荷の増加分を処理するには、マネージド インスタンス グループをオーバープロビジョニングするだけでは十分でない場合があります。Google の推奨するベスト プラクティスは、ゾーンの停止によってインスタンスの 1/3 が失われて利用率が増加したとしても十分処理できることを確認するため、定期的にアプリケーションの負荷テストを実施することです。

自動スケーリングを有効にする

Console

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

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

  2. インスタンス グループがない場合は作成します。それ以外の場合は、リストで既存のリージョン マネージド インスタンス グループの名前をクリックします。
  3. インスタンス グループの詳細ページで、[グループを編集] ボタンをクリックします。
  4. [自動スケーリング] で [オン] を選択します。
  5. 自動スケーリング構成のプロパティを入力します。
  6. 変更を保存します。

gcloud

gcloud コマンドライン ツールを使用し、set-autoscaling サブコマンドを使用して、--region フラグの後にリージョンの自動スケーリングを有効にします。オートスケーラーの作成に関する詳細は、自動スケーリングのドキュメントをご覧ください。

たとえば次のスニペットでは、example-rmig というサンプルのインスタンス グループに対してオートスケーラーが設定されます。us-east1 はマネージド インスタンス グループのリージョン、example-autoscaler はオートスケーラー名、example-rmig はリージョン マネージド インスタンス グループの名前にそれぞれ置き換えてください。

gcloud compute instance-groups managed set-autoscaling example-rmig \
    --target-cpu-utilization 0.8 --max-num-replicas 5 --region us-east1

API

リージョンの自動スケーリングを API に設定するには、以下の URL に対して POST リクエストを自分のプロジェクト ID とマネージド インスタンス グループのリージョンを指定して作成します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/regionAutoscalers/

リクエストの本文には、nametargetautoscalingPolicy の項目があります。autoscalingPolicycpuUtilizationmaxNumReplicas を定義するものです。

{
 "name": "[AUTOSCALER_NAME]",
 "target": "regions/us-east1/instanceGroupManagers/[INSTANCE_GROUP_NAME]",
 "autoscalingPolicy": {
    "maxNumReplicas": [MAX_NUM_INSTANCES],
    "cpuUtilization": {
       "utilizationTarget": [TARGET_UTILIZATION]
     },
    "coolDownPeriodSec": [SECONDS]
  }
}

例:

{
 "name": "example-autoscaler",
 "target": "regions/us-east1/instanceGroupManagers/example-rmig",
 "autoscalingPolicy": {
    "maxNumReplicas": 10,
    "cpuUtilization": {
       "utilizationTarget": 0.8
     },
    "coolDownPeriodSec": 30
  }
}

オートスケーラーを更新する

リージョン オートスケーラーは、ゾーン オートスケーラーと同じ方法で更新できます。詳しくはオートスケーラーの更新のドキュメントをご覧ください。

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

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

リージョン マネージド インスタンス グループは、外部負荷分散および内部負荷分散に対応するバックエンド サービスのターゲットとして、またはネットワーク負荷分散のターゲット プールの一部として割り当てることができます。

HTTP(S) 負荷分散の場合、リージョン マネージド インスタンス グループでサポートされているのは maxRatePerInstancemaxUtilization だけです。

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

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

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

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

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

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

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

Console

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

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

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

gcloud

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

gcloud beta compute instance-groups managed set-target-pools [INSTANCE_GROUP] \
    --target-pools [TARGET_POOL,..] [--region REGION]

ここで

  • [INSTANCE_GROUP] はインスタンス グループの名前です。
  • [TARGET_POOL] は、このインスタンス グループを追加する 1 つ以上のターゲット プールの名前です。
  • [REGION] はインスタンス グループのリージョンです。

API

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

POST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/regionInstanceGroupManagers/[INSTANCE_GROUP]/setTargetPools

ここで

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

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

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

リージョン マネージド インスタンス グループのゾーン停止をシミュレーションする

リージョン マネージド インスタンス グループが十分にオーバープロビジョニングされており、ゾーンが停止した場合でも継続できることをテストするには、次のサンプルを使用して、1 つのゾーンで障害が発生した場合をシミュレートします。

このスクリプトはデフォルトのシナリオとして、Apache を停止して開始します。使用しているアプリケーションに適さない場合は、Apache を停止および開始するコマンドを、該当する障害と復元のシナリオに置き換えます。

  1. インスタンス グループ内の仮想マシン インスタンスごとに、このスクリプトをデプロイし、継続的に実行します。それには、スクリプトをインスタンス テンプレートに追加するか、カスタム イメージにスクリプトを組み込んで、そのイメージをインスタンス テンプレートで使用します。

    #!/usr/bin/env bash
    
    # Copyright 2016 Google Inc. All Rights Reserved.
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #     http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    
    set -o nounset
    set -o errexit
    set -o pipefail
    
    function GetMetadata() {
      curl -s "$1" -H "Metadata-Flavor: Google"
    }
    
    PROJECT_METADATA_URL="http://metadata.google.internal/computeMetadata/v1/project/attributes"
    INSTANCE_METADATA_URL="http://metadata.google.internal/computeMetadata/v1/instance"
    ZONE=$(GetMetadata "$INSTANCE_METADATA_URL/zone" | cut -d '/' -f 4)
    INSTANCE_NAME=$(hostname)
    
    # We keep track of the state to make sure failure and recovery is triggered only once.
    STATE="healthy"
    while true; do
      if [[ "$ZONE" = "$(GetMetadata $PROJECT_METADATA_URL/failed_zone)" ]] && \
         [[ "$INSTANCE_NAME" = *"$(GetMetadata $PROJECT_METADATA_URL/failed_instance_names)"* ]]; then
        if [[ "$STATE" = "healthy" ]]; then
          STATE="failure"
          # Do something to simulate failure here.
          echo "STARTING A FAILURE"
          /etc/init.d/apache2 stop
        fi
      else
        if [[ "$STATE" = "failure" ]] ; then
          STATE="healthy"
          # Do something to recover here.
          echo "RECOVERING FROM FAILURE"
          /etc/init.d/apache2 start
        fi
      fi
      sleep 5
    done
    
    
  2. 2 つのプロジェクトのメタデータ項目を設定して、ゾーンの障害をシミュレーションします。

    • failed_zone: 停止した場合をシミュレーションするゾーンを設定します(障害が発生するゾーンを 1 つに限定します)。
    • failed_instance_names: オフラインにするインスタンスを名前で選択します(これにより、この文字列を含むインスタンス名のみに障害が限定されます)。

    gcloud コマンドライン ツールを使用して、このメタデータを設定できます。たとえば次のコマンドは、ゾーンの停止を europe-west1-b ゾーンに設定し、instance-base-name で始まる名前のインスタンスにゾーン停止状態を適用します。

    gcloud compute project-info add-metadata --metadata failed_zone='europe-west1-b',failed_instance_names='instance-base-name-'
    
  3. 停止状態をシミュレーションしたら、メタデータキーを削除して障害から復元します。

    gcloud compute project-info remove-metadata --keys failed_zone,failed_instance_names
    

障害が発生したときに、このスクリプトを使用して実行できる障害の事例は次のとおりです。

  • アプリケーションを完全に停止して、マネージド インスタンス グループがどのように対処するかを確認する。
  • インスタンスに対する負荷分散ヘルスチェックの結果が「異常」になるようにする。
  • インスタンスとの間で一部のトラフィックの流れが遮断されるように、iptables を変更する。
  • 仮想マシン インスタンスを停止する。デフォルトでは直後にリージョン マネージド インスタンス グループによってインスタンスが再作成されますが、新しく作成されたインスタンスも、メタデータ値が設定されている限りは、スクリプトが実行されるとすぐにシャットダウンします。その結果、障害ループが発生します。

次のステップ

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

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

Compute Engine ドキュメント