リージョン MIG を使用したインスタンスの分散

このページでは、リージョンマネージドインスタンスグループ（MIG）を作成する方法について説明します。ゾーン（シングルゾーン）MIG を作成することもできます。ゾーン MIG とリージョン MIG はどちらも、自動修復、負荷分散、自動スケーリング、自動更新、ステートフルワークロードをサポートしています。

リージョン MIG のマネージドインスタンスは単一のリージョン内の複数のゾーンに均等に分散しているため、リージョン MIG はゾーン MIG に比べて高い可用性を備えています。ただし、リージョン MIG には、ゾーン MIG とは異なる制限事項があります。

ゾーンやリージョンのどちらの MIG の場合でも、それぞれのマネージドインスタンスでは、共通のインスタンステンプレートとオプションのステートフル構成が基になっています。各マネージドインスタンスは、MIG 内のデータエンティティで、実際の VM インスタンスの現在のステータスと目的の状態を含んでいます。MIG は、実際の VM の可用性を積極的に維持することによって RUNNING 状態を保ち、アプリケーションの高可用性を確保します。

インスタンスグループとその機能の詳細については、インスタンスグループの概要をご覧ください。

始める前に

このガイドの API の例を使用する場合は API アクセスを設定します。
このガイドのコマンドラインの例を使用する場合、gcloud コマンドラインツールをインストールしてください。
インスタンステンプレートのドキュメントを読みます。
マネージドインスタンスグループ（MIG）のドキュメントを読みます。
リージョンとゾーンのドキュメントを読みます。

制限事項

各リージョン MIG には、最大 2,000 個の VM を含めることができます。
MIG の更新時、1 回のリクエストで指定できる VM 数は最大 1,000 個です。
リージョン MIG には、maxRate 分散オプションを使用するロードバランサを使用できません。
Cloud Monitoring 指標に基づく自動スケーリングで使用する場合は、次の制限事項があります。
- シングルゾーン MIG とは異なり、リージョン MIG では、インスタンスごとの指標のフィルタリングをサポートしていません。
- シングルゾーン MIG とは異なり、リージョン MIG では、グループごとの指標を使用した自動スケーリングをサポートしていません。

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

Google では、ゾーン MIG よりもリージョン MIG をおすすめしています。その理由は、リージョン MIG を使用すると、アプリケーションを 1 つのゾーンに制限することや、異なるゾーンで複数のインスタンスグループを管理することなく、アプリケーションの負荷を複数のゾーンに分散できるためです。複数のゾーンを使用することで、ゾーン障害の発生や、単一ゾーンでインスタンスグループ全体の誤動作が起こる不測の事態からトラフィックが保護されます。このような事態が起きた場合でも、アプリケーションは同じリージョンの別のゾーンで実行しているインスタンスからトラフィックの処理を続行できます。

1 つのゾーンで障害が発生した場合、または 1 つのゾーン内の VM のグループが応答しなくなった場合でも、リージョン MIG は次のように VM のサポートを続行します。

残りのゾーンのリージョン MIG に含まれる VM によって引き続きトラフィックが処理されます。自動スケーリングを設定しない限り、新しい VM の追加や VM の再配布は行われません。
障害が発生したゾーンが回復すると、MIG はそのゾーンからのトラフィック処理を再開します。

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

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

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

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

ゾーン間で均等に分散させるには、VM の多いゾーンの VM を削除し、VM の少ないゾーンに VM を追加します。削除する VM は、グループにより自動的に選択されます。

プロアクティブな再配布によってゾーン間の均等な配布を再確立します。 — **プロアクティブな再配布の例**

たとえば、リージョン MIG で、3 つのゾーン a、b、c に 4 つのインスタンスが分散しているとします。c で 3 つのマネージドインスタンスが削除されると、ゾーン間でインスタンスが均等に分配されるようにグループの再調整が行われます。この場合、2 つのインスタンス（ゾーン a と b のそれぞれ 1 つずつ）が削除され、ゾーン c に 2 つのインスタンスが作成されます。これにより、各ゾーンのインスタンス数が 3 つになり、均等な分配が確保されます。削除されるインスタンスを選択することはできません。新しいインスタンスを起動する際、グループの容量が一時的に失われます。

VM の自動再配布が行われないようにするには、リージョン MIG を作成または更新する際のプロアクティブなインスタンスの再配布を無効にします。

この設定は、次のような必要がある場合に役立ちます。

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

プロアクティブな再配布を無効にすると、ゾーン障害が発生したときの処理能力に影響を与える可能性があります。 — プロアクティブな再配布を無効にした後の不均等な分配状況

プロアクティブなインスタンスの再配布を無効にすると、MIG はバランス調整のために VM のプロアクティブな追加や削除は行いません。しかし、サイズ変更オペレーションの際には状況に応じて調整を行うため、グループのバランスを調整する機会が完全に失われるわけではありません。たとえば、スケールインすると、グループは自動的に再スケーリングの際により大きなゾーンから VM を削除します。スケールアウトのときには、小さなゾーンに VM を追加します。

正しい MIG サイズをプロビジョニングして可用性を確保する

さまざまなイベントにより、1 つ以上の VM が使用できなくなる場合があります。この問題は、次に挙げる複数の Google Cloud サービスを使用することで軽減できます。

リージョン MIG を使用すると、アプリケーションが複数のゾーンに分散されます。
自動修復を使用すると、障害が発生した VM が再作成されます。
負荷分散を使用すると、ユーザートラフィックが自動的に使用不可の VM から切り離されます。

ただし、これらのサービスを使用していても、同時に使用不可となった VM の数が多すぎる場合は、問題が解決しない可能性があります。

1 つのゾーンで障害が発生する、インスタンスグループ全体が応答しなくなるなどの極端な場合に備えて、MIG をオーバープロビジョニングすることを強くおすすめします。アプリケーションのニーズに応じてグループをオーバープロビジョニングすることで、ゾーンや VM のグループが応答しなくなった場合にシステムが完全に機能しなくなることを防止します。

Google では、ユーザーがアプリケーションを使用できる状態を保つという点を優先して、オーバープロビジョニングに関する推奨事項を作成しています。この推奨事項には、アプリケーションが日常的に必要とする以上の VM のプロビジョニングと支払いが含まれています。オーバープロビジョニングの決定は、アプリケーションのニーズとコストの上限に基づいて行ってください。

推奨されるグループサイズを見積もる

Compute Engine では、1 つのゾーン内のすべての VM が使用できない場合でも、残りの VM で必要最小限の VM 数を満たすように VM をプロビジョニングすることをおすすめします。

次の表を使用して、グループの最小推奨サイズを決定します。

ゾーン数	追加の VM	推奨される合計 VM
2	+100%	200%
3	＋50%	150%
4	+33%	133%

追加する VM の推奨数は、MIG が配置されているゾーンの数に反比例します。したがって、より多くのゾーンにアプリケーションを均等に分配することにより、追加する VM の数を減らすことができます。

3 つ以上のゾーンでリージョン MIG をプロビジョニングする

3 つ以上のゾーンを持つリージョンでリージョン MIG を作成する場合は、グループを 50% 以上オーバープロビジョニングすることをおすすめします。デフォルトでは、リージョン MIG は 3 つのゾーンに VM を作成します。3 つのゾーンに VM を配置することで、少なくとも 2/3 の処理能力を確保でき、1 つのゾーンに障害が発生した場合、リージョン内にある他の 2 つのゾーンでトラフィックを中断せずに処理できます。150% までオーバープロビジョニングすると、能力の 1/3 が失われても、残りのゾーンでトラフィックに 100% 対応できます。

たとえば、3 つのゾーンにまたがる MIG に 20 個の VM が必要な場合は、少なくとも VM の 50% を追加することをおすすめします。この場合、20 の 50% に相当する 10 個の VM が追加され、グループ内の VM の総数は 30 個になります。サイズが 30 のリージョン MIG を作成すると、次のように、グループによって VM が 3 つのゾーンにできる限り均等に配布されます。

ゾーン	VM 数
example-zone-1	10
example-zone-2	10
example-zone-3	10

あるゾーンで障害が発生しても、引き続き 20 個の VM によりトラフィックが処理されます。

2 つのゾーンでリージョン MIG をプロビジョニングする

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

ゾーン	VM 数
example-zone-1	20
example-zone-2	20

グループ内の VM の数を 2 つのゾーンに簡単に分割できない場合、Compute Engine では VM を可能な限り均等に分割し、残りの VM はランダムにどちらか一方のゾーンに配置します。

1 つのゾーンでリージョン MIG をプロビジョニングする

1 つのゾーンのみでもリージョン MIG を作成できます。これはゾーン MIG の作成に似ています。

単一ゾーンのリージョン MIG を作成すると、高可用性アプリケーションに最低限の保証しか提供できなくなるため、おすすめしません。ゾーンに障害が発生すると、MIG 全体が使用できなくなり、ユーザーの処理が中断するおそれがあります。

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

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

ゾーン数を選択したり、グループを実行する特定のゾーンを選択したりする場合には、最初にグループを作成する際に選択を行う必要があります。作成時に特定のゾーンを選択した場合、後でそのゾーンの変更や更新はできません。

1 つのリージョン内で 4 つ以上のゾーンを選択するには、個々のゾーンを明示的に指定する必要があります。たとえば、リージョン内の 4 つのゾーンすべてを選択するには、リクエストで 4 つのゾーンすべてを明示的に指定する必要があります。そうしないと、Compute Engine はデフォルトで 3 つのゾーンを選択します。
特定リージョン内の 2 つ以下のゾーンを選択するには、個々のゾーンを明示的に指定する必要があります。リージョンに含まれているゾーンが 2 つしかない場合でも、リクエストではゾーンを明示的に指定する必要があります。

特定のゾーンを選択した場合や、リージョンだけを選択して Compute Engine にそのリージョン内のすべてのゾーンに VM を作成させる場合のいずれにおいても、デフォルトでは新しい VM はすべてのゾーンにわたって均等に配分されます。指定された数のゾーンでアプリをサポートするために十分な VM がプロビジョニングされているか確認することを推奨します。

リージョン MIG を作成する

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

各ゾーンにグループの VM をサポートする十分なキャパシティがない場合、Compute Engine は可能な限り多くの VM を作成し、追加の割り当てが使用可能になると、引き続き残りの VM の作成を試みます。

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

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

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

Console

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

gcloud

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

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 compute instance-groups managed create example-rmig \
    --template example-template --base-instance-name example-instances \
    --size 30 --instance-redistribution-type NONE

API

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

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

POST https://compute.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: グループの一部として作成された各 VM インスタンスのインスタンス名。たとえば、ベースインスタンス名が example-instance の場合、example-instance-[RANDOM_STRING] のような名前のインスタンスが作成されます。ここで、[RANDOM_STRING] はサーバーによって生成されます。
instance-template-name: 使用するインスタンステンプレート。
instance-group-name: MIG の名前。
target-size: グループの VM のターゲット数。

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

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers

{
  "baseInstanceName": "base-instance-name",
  "instanceTemplate": "global/instanceTemplates/instance-template-name",
  "name": "instance-group-size",
  "targetSize": "target-size",
  "distributionPolicy": {
     "zones": [
       {"zone": "zones/zone"},
       {"zone": "zones/zone"}
      ]
   }
}

たとえば、次のようにすると、us-east1-b ゾーンと us-east1-c ゾーンにわたり、10 個のマネージドインスタンスが分配された example-rmig という名前のリージョン MIG が作成されます。

POST https://compute.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 プロパティを追加し、instanceRedistributionType を NONE に設定します。

自動スケーリングが有効になっている場合は、プロアクティブなインスタンスの再配布を無効にできません。

POST https://compute.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",
  "updatePolicy": {
     "instanceRedistributionType": "NONE"
   },
}

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

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

Console

Cloud Console で、[インスタンスグループ] ページに移動します。
[インスタンスグループ] ページに移動
インスタンスを表示するリージョン MIG の名前をクリックします。

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

gcloud

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

gcloud compute instance-groups managed list-instances instance-group-name --region region

以下を置き換えます。

instance-group-name: MIG の名前。
region: MIG のリージョン。

たとえば、次のコマンドでは、リージョン us-east1 の example-rmig という名前の MIG に属するインスタンスを一覧表示します。

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

API

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

GET https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name

例:

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

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

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

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

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

プロアクティブなインスタンスの再配布を使用すると、リージョン内のゾーン間で VM 数が均等に保たれます。この構成により、ゾーンレベルで障害が発生した場合のアプリケーションの可用性が最大化されます。

プロアクティブなインスタンスの再配布は、リージョン MIG ではデフォルトで有効になっていますが、自動スケーリングが有効になっていない MIG では無効にできます。プロアクティブなインスタンスの再配布を無効にすると、VM はゾーン間でプロアクティブに再配布されません。これは、次のような場合に役立ちます。

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

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

プロアクティブなインスタンスの再配布が無効になっている MIG のサイズを変更すると、状況に応じてグループ内の調整が行われるため、グループのバランスを調整する機会が完全に失われるわけではありません。グループのサイズを大きくすると、VM 数が最も少ないゾーンに VM が追加されます。グループのサイズを小さくすると、VM 数が最も多いゾーンから VM が削除されます。

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

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

Console

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

gcloud

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

gcloud compute instance-groups managed create instance-group-name \
    --template template \
    --size target-size \
    --zones zones \
    --instance-redistribution-type NONE

以下を置き換えます。

instance-group-name: MIG の名前。
template: グループに使用するインスタンステンプレートの名前。
target-size: グループのターゲットサイズ。
zones: VM のデプロイが必要な単一リージョン内のゾーンのリスト。

例:

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

API

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

POST https://compute.googleapis.com/compute/v1/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" } }

Replace the following:

project-id. The project ID for this request.
region. The region for the instance group.
instance-group-name. The name for the MIG.
base-instance-name. The name prefix for each instance. The instance name suffix is auto generated.
template. The name of the instance template to use for the group.
target-size. The target size of the instance group.
zone. The name of a zone in the single region where you need to deploy VMs.

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

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

Console

Cloud Console で、[インスタンスグループ] ページに移動します。
[インスタンスグループ] ページに移動
更新する MIG を選択し、[グループの編集] をクリックします。
自動スケーリングモードがオフになっていることを確認します。
[インスタンスの再配布] を [オフ] に設定し、自動再配布を無効にします。
[保存] をクリックします。

gcloud

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

gcloud compute instance-groups managed update instance-group-name
    --instance-redistribution-type NONE 

    --region region

以下を置き換えます。

instance-group-name: MIG の名前。
region: インスタンスグループのリージョン。

API

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

 PATCH https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/[instance-group-name

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

以下を置き換えます。

project-id: このリクエストのプロジェクト ID。
region: インスタンスグループのリージョン。
instance-group-name: 自動スケーリングされていない MIG の名前。

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

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

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

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

ゾーン間の VM 数が不均等な（2 つのゾーン間の VM 数の差が 2 以上の）状態にある間、そのリージョン MIG ではプロアクティブなインスタンスの再配布を有効にできません。これは、不均等を是正するために、VM 数の多いゾーンから VM が自動的に削除されないようにするためです。

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

Compute Engine には MIG の自動スケーリング機能が備えられています。これを使用すると、負荷の増減に基づいた VM の追加（スケールアウト）と削除（スケールイン）がグループで自動的に実行されます。

リージョン MIG の自動スケーリングを有効にすると、この機能は次のように動作します。

自動スケーリングのポリシーは、個別のゾーンではなく、グループ全体に適用されます。たとえば、オートスケーラーを有効にして CPU 使用率 66% を目標にした場合、オートスケーラーによってグループ内のすべての VM が追跡され、すべてのゾーンのすべての VM で平均 66% の使用率が維持されます。
自動スケーリングでは、利用可能なゾーンに VM が可能な限り均等に分散されます。一般にオートスケーラーはサイズの小さいゾーンを大きくし、ロードバランサなどを介して大きいゾーンから負荷が振り分けられるようにして、ゾーンのサイズのバランスを保ちます。カスタムのロードバランサを構成することはおすすめしません。カスタムのロードバランサはゾーンが 1 つだけの場合に適しており、予期しない動作が発生する可能性があります。
ワークフローが 3 つのゾーンで VM を均等に使用しているときに、1 つのゾーンまたは 1 つのゾーン内の VM グループに障害が発生した場合、処理能力の 1/3 が失われることになりますが、残りの 2/3 は他のゾーンで維持されます。あるゾーンが停止した場合に残りのサーバーへの負荷集中を回避するため、自動スケーリングが有効な MIG をオーバープロビジョニングしておくことをおすすめします。
リソース（プリエンプティブル VM など）がゾーンで一時的に利用できなくなった場合、グループはそのゾーンで VM の作成を試み続けます。リソースが再び利用可能になると、グループ内で実行中の VM は適切な数に戻ります。
負荷分散を有効にしている場合にゾーンでリソースが利用できなくなり、そのゾーンの既存のリソースの使用率が高くなると、使用率の低いゾーンに新しい VM が作成されることがあります。これにより、一時的に分散が不均等になる可能性があります。

オートスケーラーは、グループに指定された上限の 1/n までの VM をゾーンに追加します（n はプロビジョニングされたゾーンの数）。たとえば、デフォルトの 3 ゾーンを使用しており、自動スケーリング用に構成された maxNumReplicas の値が 15 の場合、オートスケーラーによって追加される VM は、グループのゾーンごとに最大 1/3 × 15 = 5 個になります。1 つのゾーンに障害が発生した場合、オートスケーラーが設定できる数は、残り 2 つのゾーンであわせて maxNumReplicas の値の 2/3 までになります。

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

MIG のオーバープロビジョニングが推奨されているように、オートスケーラーの構成でも、次のようにオーバープロビジョニングを行う必要があります。

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

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

目標使用率には、80% ではなく 53% を設定（2/3 × 0.8 = 0.53）
VM の最大数には、20 ではなく 30 を設定（3/2 × 20 = 30）

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

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

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

Console

Cloud Console で、[インスタンスグループ] ページに移動します。
[インスタンスグループ] ページに移動
インスタンスグループがない場合は作成します。ある場合は、リストにある既存のリージョン MIG の名前をクリックします。
インスタンスグループの詳細ページで、[グループを編集] ボタンをクリックします。
[自動スケーリング] で [オン] を選択します。
自動スケーリング構成のプロパティを入力します。
変更を保存します。

gcloud

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

たとえば、次のスニペットは、サンプルインスタンスグループのオートスケーラーを設定します。us-east1 をマネージドインスタンスグループのリージョンに置き換え、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 に設定するには、regionAutoscalers.insert メソッド（/compute/docs/reference/rest/v1/regionAutoscalers/insert）を呼び出します。

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

リクエスト本文には name、target、autoscalingPolicy フィールドを含める必要があります。autoscalingPolicy で cpuUtilization と maxNumReplicas を定義する必要があります。

わかりやすいよう、オートスケーラーのリソースには、これを使用する MIG リソースにちなんだ名前を付けることをおすすめします。

{
 "name": "<var>autoscaler-name</var>",
 "target": "regions/us-east1/instanceGroupManagers/<var>instance-group-name</var>",
 "autoscalingPolicy": {
    "maxNumReplicas": <var>max-number-of-instances</var>,
    "cpuUtilization": {
       "utilizationTarget": <var>target-utilization</var>
     },
    "coolDownPeriodSec": <var>seconds</var>
  }
}

例:

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

オートスケーラーの更新

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

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

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

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

HTTP(S) 負荷分散の場合、リージョン MIG では maxRatePerInstance と maxUtilization のみがサポートされています。

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

次のタイプの負荷分散サービスを作成するためには、バックエンドサービスが必要です。

外部 HTTP(S) 負荷分散
内部 HTTP(S) 負荷分散
SSL プロキシ負荷分散
TCP プロキシ負荷分散
内部 TCP / UDP 負荷分散

バックエンドサービスには複数のバックエンドを含めることができます。インスタンスグループはバックエンドの一種です。インスタンスグループ内のインスタンスがロードバランサからのトラフィックに応答します。それにより、バックエンドサービスは使用できるインスタンス、処理可能なトラフィック数、現在処理しているトラフィック数を認識するようになります。また、バックエンドサービスはヘルスチェックをモニタリングし、異常なインスタンスにはトラフィックを送信しません。

マネージドインスタンスグループをバックエンドサービスに追加するには、以下の手順を実施します。

Console

Cloud Console の [負荷分散] ページに移動します。
[負荷分散] ページに移動
マネージドインスタンスグループを追加するバックエンドサービスの名前をクリックします。
[編集] をクリックします。
[+ バックエンドを追加] をクリックします。
追加するインスタンスグループを選択します。
変更するオプション設定があれば編集します。
変更を保存します。

gcloud

gcloud コマンドラインツールで、add-backend コマンドを使用します。

    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
        --instance-group=INSTANCE_GROUP \
        [--instance-group-region=INSTANCE_GROUP_REGION | --instance-group-zone=INSTANCE_GROUP_ZONE] \
        --balancing-mode=BALANCING_MODE

マネージドインスタンスグループの負荷分散モードに応じて、パラメータを追加する必要があります。詳細については、SDK の add-backend コマンドをご覧ください。

API

REST API を使用してバックエンドサービスを追加するには、backendServices をご覧ください。

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

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

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

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

Console

Cloud Console の [ターゲットプール] ページに移動します。
[ターゲットプール] ページに移動
インスタンスグループを追加するターゲットプールをクリックします。
[編集] ボタンをクリックします。
[VM インスタンス] セクションまで下にスクロールして、[インスタンスグループを選択] をクリックします。
プルダウンメニューからインスタンスグループを選択します。
変更を保存します。

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://compute.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"
  ]
}

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

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

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

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

zone_failure/failure.sh

GitHub で表示

#!/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 つのプロジェクトのメタデータ項目を設定して、ゾーンの障害をシミュレーションします。
- failed_zone: 停止した場合をシミュレーションするゾーンを設定します（障害が発生するゾーンを 1 つに限定します）。
- failed_instance_names: オフラインにする VM を名前で選択します（これにより、この文字列を含む VM 名のみに障害が限定されます）。
gcloud コマンドラインツールを使用して、このメタデータを設定できます。たとえば、次のコマンドではゾーンの停止を europe-west1-b ゾーンに設定し、instance-base-name で始まる名前の VM にゾーン停止状態を適用します。
```
gcloud compute project-info add-metadata --metadata failed_zone='europe-west1-b',failed_instance_names='instance-base-name-'
```
停止状態をシミュレーションしたら、メタデータキーを削除して障害から復元します。
```
gcloud compute project-info remove-metadata --keys failed_zone,failed_instance_names
```

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

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

次のステップ

リージョン MIG と負荷分散を使用した高可用性アプリケーションの構築方法を習得する。
負荷分散の詳細を読む。
自動スケーリングの詳細を読む。
拡張性と復元性の高いウェブアプリケーションを構築する方法の詳細を知る。
Google Cloud Platform での障害復旧の詳細を知る。

リージョン MIG を使用したインスタンスの分散

始める前に

制限事項

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

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

正しい MIG サイズをプロビジョニングして可用性を確保する

推奨されるグループサイズを見積もる

3 つ以上のゾーンでリージョン MIG をプロビジョニングする

2 つのゾーンでリージョン MIG をプロビジョニングする

1 つのゾーンでリージョン MIG をプロビジョニングする

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

リージョン MIG を作成する

Console

gcloud

API

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

Console

gcloud

API

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

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

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

Console

gcloud

API

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

Console

gcloud

API

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

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

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

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

Console

gcloud

API

オートスケーラーの更新

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

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

Console

gcloud

API

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

Console

gcloud

API

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

次のステップ

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

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

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

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

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

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

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

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