リージョン MIG について

リージョン内の複数の VM を分散するマネージド インスタンス グループ（MIG）は、リージョン MIG とも呼ばれます。単一のゾーンに制限された MIG は、ゾーン MIG とも呼ばれます。

リージョン MIG を使用すると、MIG ベースのワークロードの復元力を高めることができます。ワークロードをリージョン内の複数のゾーンに分散すると、1 つのゾーン内のすべてのインスタンスで障害が発生するような極端なケースから保護できます。

このドキュメントには、リージョン MIG に関するコンセプト情報が記載されています。

リージョン MIG を作成する方法については、複数のゾーンでの MIG の作成をご覧ください。

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

Google では、次の理由からゾーン MIG ではなくリージョン MIG を推奨しています。

  • リージョン MIG では、最大 2,000 個のインスタンスを管理できます（ゾーン MIG の 2 倍）。さらにインスタンスが必要な場合は、リージョン MIG のサイズ上限を引き上げて 4,000 インスタンスにします。
  • リージョン MIG を使用すると、アプリケーションの負荷を複数のゾーンに分散できます。アプリケーションが単一ゾーンに構成することも、異なるゾーンで複数のゾーン MIG を管理する必要もありません。

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

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

  • 残りのゾーンのリージョン MIG に含まれるインスタンスによって引き続きトラフィックが処理されます。新しいインスタンスの追加やインスタンスの再分散は行われません（自動スケーリングが設定されている場合を除く）。

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

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

リージョン MIG の追加構成オプション

リージョン MIG の作成は、ゾーン MIG の作成と似ていますが、次のようなオプションがあります。

これらのオプションについては、次のセクションで説明します。

ゾーンの選択

デフォルトでは、リージョン MIG は 3 つのゾーンにマネージド インスタンスを均等に分散します。さまざまな理由で、アプリケーションに特定のゾーンを選択することが必要になる場合があります。たとえば、インスタンスに GPU が必要な場合は、GPU をサポートするゾーンのみを選択します。また、特定のゾーンでのみ使用可能な永続ディスクや予約が存在する場合もあります。

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

MIG の構成で指定したハードウェアをサポートするゾーンを MIG で自動的に使用するには、MIG のターゲット分配形態を BALANCED、ANY、または ANY_SINGLE_ZONE に設定して、リージョンのすべてのゾーンを選択します。MIG はリソースの可用性を自動的にチェックし、リソースのあるゾーン内でのみインスタンスのスケジュールを設定します。詳細については、ターゲット分配形態をご覧ください。

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

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

Google では、より多くのゾーンで特別なハードウェアを利用可能にすることで、インフラストラクチャを定期的に拡張しています。リージョン MIG はハードウェアの可用性を定期的にチェックし、必要なマシンをサポートするゾーンでのインスタンスのスケジュール設定を自動的に開始します。なんらかの理由で、一部のゾーンでインスタンスを実行しない場合は、グループの作成時にそのゾーンを選択しないでください。

リージョン MIG を作成してゾーンを選択する方法については、リージョン MIG の作成をご覧ください。

ターゲット分配形態

デフォルトでは、リージョン MIG は選択されたゾーン全体にマネージド インスタンスを分散します。ただし、一部のゾーンで利用できないハードウェアを使用する場合や、ゾーン予約の使用を優先する場合は、別の分散方法が必要になります。

リージョン MIG がリージョン内のゾーン間でインスタンスを分散する方法を構成するには、MIG のターゲット分配形態を設定します。次のオプションが用意されています。

  • EVEN（デフォルト）: 選択されたゾーン全体で同じ数の VM を完成、維持するために、VM の作成と削除が行われます。EVEN 分配では、2 つのゾーン間の VM の数の差が 1 つ以内になります。これは、高可用性サービスを提供するワークロードに適しています。
  • BALANCED: リソースが利用可能なゾーンで VM の作成を優先しますが、選択したゾーンに可能な限り均等に VM を分配して、ゾーン障害の影響を最小限に抑えます。これは、高可用性サービスを提供するワークロードやバッチ ワークロードに適しています。
  • ANY: リクエストされた数の VM を現在のリソース制約内で用意し、未使用のゾーン予約を最大限利用できるように、VM インスタンスの作成時にゾーンを選択します。高可用性が不要なバッチ ワークロードに適しています。
  • ANY SINGLE ZONE: 1 つのゾーン内にすべての VM インスタンスを作成するグループです。ゾーンは、ハードウェア サポート、現在のリソースと割り当ての可用性、および一致する予約に基づいて選択されます。VM 間の大規模な通信が必要なワークロードには、コンパクトなインスタンス配置ポリシーと組み合わせて使用することをおすすめします。

MIG を作成するときに、その形態を BALANCED、ANY、または ANY_SINGLE_ZONE に設定した場合、MIG の構成で指定したハードウェアをサポートするゾーンを手動で確認する必要はありません。リージョン内のすべてのゾーンを選択して、その形態を BALANCED、ANY、または ANY_SINGLE_ZONE に設定したうえで、リージョン MIG がリソースの可用性をチェックし、リソースのあるゾーンでのみインスタンスをスケジュール設定します。

ワークロード要件と必要な MIG 機能に応じてオプションを選択します。詳細については、比較表とユースケースをご覧ください。

新規または既存の MIG のターゲット分配形態を構成する方法については、ゾーン間でのインスタンスの分散ポリシーの設定をご覧ください。

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

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

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

ゾーン間で均等な分散を維持するために、インスタンス数の多いゾーンからインスタンスを削除し、インスタンス数の少ないゾーンに新しいインスタンスを追加します。その際、削除されるインスタンスは自動的に選択されます。

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

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

インスタンスの自動再分配が行われないようにするには、プロアクティブなインスタンスの再分配を無効にします。

プロアクティブなインスタンスの再分散を無効にすると、次のような場合に便利です。

  • 実行中の他のインスタンスに影響を与えずに、インスタンスを削除または放棄する。たとえば、ジョブの完了後、他のワーカーに影響を与えずにバッチワーカー インスタンスを削除できます。
  • ステートフル ワークロードが実行されているインスタンスが、プロアクティブな再分散により自動的に削除されないようにする。
  • MIG のターゲット分配形態を BALANCED または ANY_SINGLE_ZONE に設定する
プロアクティブな再配布を無効にすると、ゾーン障害が発生したときの処理能力に影響する可能性があります。
プロアクティブな再分散を無効にした後の不均等な分散状況

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

ゾーン MIG との動作の違い

ゾーン MIG とリージョン MIG の主な違いは、リージョン MIG では複数のゾーンを使用できることです。

リージョン MIG のマネージド インスタンスは、リージョン内のゾーン間で分散されるため、次の MIG 機能の動作が若干異なります。

リージョン MIG の自動スケーリング

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

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

  • オートスケーラーは、各ゾーンの最大自動スケーリング シグナルに基づいて、VM を作成するゾーンを決定します。たとえば、CPU 使用率に基づいてスケーリングする場合、オートスケーラーは使用率が高いゾーンに VM をより多く作成します。

  • ゾーンにさまざまなシグナル値が存在する場合、自動スケーリングによって VM の分散が不均等になる可能性があります。このような場合、オートスケーラーは VM の少ないゾーンに追加の VM を作成することで、ゾーン間で負荷を分散しようとします。VM が追加されたゾーンが負荷を引き継ぐと、ゾーン間の VM 数のバランスが取れます。

  • ゾーンのシグナル値がスケールアウトをトリガーしても、リージョン MIG の全体的なシグナル値に追加の VM は必要ないか、別のゾーンに追加の VM が必要な場合、オートスケーラーが VM を追加し、削除する場合は、直ちにいずれかのゾーンから削除します。

  • スケーリング スケジュールや一部のモニタリング指標など、自動スケーリング シグナルがリージョン MIG 全体に適用される場合、オートスケーラーはできるだけ均等に VM を複数のリージョンに分散します。

  • ターゲット分配形態を BALANCED に設定すると、オートスケーラーはゾーン間のリソースの可用性を認識します。オートスケーラーは、MIG の構成で指定された VM に対して割り当てと容量が十分にあるゾーンにのみ VM をプロアクティブに作成します。

リージョン MIG の更新

グループの作成後にリージョン MIG のゾーンを変更または更新することはできません。ただし、グループのターゲット分配形態を設定すると、異なるゾーンの使用に優先順位をつけられます。たとえば、予約済みリソースがある場合や、すべてのゾーンでは使用できないハードウェアが必要な場合です。

新しいテンプレートをリージョン MIG にロールアウトする場合は、リージョン MIG の更新をご覧ください。

MIG でインスタンスを追加または削除する方法は、リージョン MIG とゾーン MIG で変わりません。MIG で VM の追加と削除を行うをご覧ください。

MIG でステートフル ディスクまたはステートフル メタデータを構成する場合は、ステートフル MIG の構成をご覧ください。

オーバープロビジョニングで可用性を向上させる方法

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

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

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

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

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

MIG のサイズは作成時に設定します。インスタンスは作成後に追加または削除できます。

オートスケーラーは、負荷に基づいてグループ内のインスタンスを自動的に追加または削除するように構成できます。

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

1 つのゾーン内のすべてのインスタンスが使用不能になっても、残りのインスタンスが必要最小限のインスタンス数を満たすように、十分なインスタンスをプロビジョニングすることをおすすめします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ