インスタンス グループ

仮想マシン(VM)インスタンスのグループを作成して管理すれば、プロジェクト内のインスタンスを個別に制御する必要はありません。Compute Engine では、マネージド非マネージドの 2 種類のインスタンス グループを使用できます。

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

マネージド インスタンス グループは、インスタンス テンプレートを使用して同一インスタンスのグループを作成します。マネージド インスタンス グループは 1 つのエンティティとして制御します。マネージド インスタンス グループに含まれるインスタンスに変更を加える場合、インスタンス グループ全体にその変更を適用します。マネージド インスタンス グループには同一のインスタンスが含まれるため、次の機能が提供されます。

  • アプリケーションにコンピューティング リソースがさらに必要な場合は、マネージド インスタンス グループによってグループ内のインスタンス数が自動的にスケーリングされます。
  • マネージド インスタンス グループは負荷分散サービスを使用してネットワーク トラフィックをグループ内のすべてのインスタンスに分散します。
  • グループ内のインスタンスがインスタンス グループのコマンド以外のアクションによって停止、クラッシュ、削除された場合、マネージド インスタンス グループがそのインスタンスを自動的に再作成して、その処理タスクを再開できるようにします。再作成されるインスタンスは、グループが別のインスタンス テンプレートを参照していても、前のインスタンスと同じ名前、同じインスタンス テンプレートを使用します。
  • マネージド インスタンス グループは、グループ内の異常な状態のインスタンスを自動的に特定し、再作成できるため、すべてのインスタンスを最適な状態で実行できます。
  • マネージド インスタンス グループ アップデータを使用すると、マネージド インスタンス グループ内のインスタンスに新しいバージョンのソフトウェアを簡単にデプロイできます。また、その際にはデプロイの速度とスコープのほか、サービス中断のレベルも制御できます。

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

2 つのタイプのマネージド インスタンス グループを作成できます。

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

ゾーン間通信によってレイテンシが少し長くなることを回避する場合や、各ゾーン内のグループのサイズをきめ細かく管理する必要がある場合は、ゾーン マネージド インスタンス グループを選択します。

マネージド インスタンス グループとネットワーク

デフォルトでは、グループ内のインスタンスは default ネットワークに配置され、リージョンの範囲内の IP アドレスがランダムに割り当てられます。または、カスタムモード VPC ネットワークと狭い IP 範囲を使用するサブネットを作成し、インスタンス テンプレートでそのサブネットを指定すると、グループの IP 範囲を制限できます。そのようにすることで、ファイアウォール ルールを簡単に作成できます。

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

マネージド インスタンス グループと自動スケーリング

マネージド インスタンス グループでは自動スケーリング機能がサポートされているため、負荷の増減に応じて、マネージド インスタンス グループからインスタンスを動的に追加または削除できます。自動スケーリングを有効にし、スケーリング方法を決定する自動スケーリング ポリシーを選択します。適用可能な自動スケーリングのポリシーには、CPU 使用率、負荷分散容量、Stackdriver Monitoring の指標や、Google Cloud Pub/Sub のようなキューベースのワークロードに基づくスケーリングなどがあります。

自動スケーリングではインスタンスをグループから追加および削除する必要があるため、オートスケーラーで同一のインスタンスが維持されるよう、自動スケーリングが使用できるのはマネージド インスタンス グループのみになります。異種のインスタンスが含まれる可能性のある非マネージド インスタンス グループでは、自動スケーリングは機能しません。

詳細については、インスタンスのグループの自動スケーリングをご覧ください。

マネージド インスタンス グループと自動修復

マネージド インスタンス グループは、インスタンスを実行可能な状態(RUNNING 状態)にしておくことで、アプリケーションの高可用性を維持します。マネージド インスタンス グループでは、RUNNING 状態でないインスタンスは自動的に再作成されます。ただし、インスタンスの状態に依存して再作成するだけでは不十分なこともあります。アプリケーションがフリーズまたはクラッシュしたときやメモリが不足したときも、インスタンスを再作成したい場合があります。

アプリケーション ベースの自動修復は、フリーズ、クラッシュ、過負荷などのアプリケーション固有の問題を検出するヘルスチェック シグナルに依存して行われるため、アプリケーションの可用性の向上に役立ちます。ヘルスチェックによりインスタンスでアプリケーションがエラーになっていると判断されると、そのインスタンスはマネージド インスタンス グループにより自動的に再作成されます。

ヘルスチェック

マネージド インスタンス グループをモニタリングするために使用されるヘルスチェックは、負荷分散のためのヘルスチェックと似ていますが、動作に多少の違いがあります。負荷分散のヘルスチェックは、応答していないインスタンスから正常なインスタンスにトラフィックを振り替えるのに役立ちます。これらのヘルスチェックによって Compute Engine でインスタンスが再作成されることはありません。一方、マネージド インスタンス グループのヘルスチェックでは、インスタンスが UNHEALTHY になった場合、インスタンスの削除と再作成を求める通知が事前に送信されます。

大半のシナリオでは、負荷分散と自動修復にそれぞれ別のヘルスチェックを使用します。負荷分散のヘルスチェックは、インスタンスがユーザー トラフィックを受信しているかどうかを確認するものなので、積極的な実施が可能であり、また積極的に実施すべきです。サービスを期待しているお客様のために、応答していないインスタンスをすばやくキャッチし、必要に応じてトラフィックをリダイレクトできるようにします。対照的に、自動修復のヘルスチェックでは、障害が発生しているインスタンスが Compute Engine によってプロアクティブに置き換えられるので、このヘルスチェックは負荷分散のヘルスチェックより慎重に実施しなければなりません。

自動修復の動作

自動修復は、VM インスタンスの作成に使用された元のインスタンス テンプレート(マネージド インスタンス グループ内の現在のインスタンス テンプレートとは限りません)を使用して、異常なインスタンスを再作成します。たとえば、VM インスタンスが instance-template-a で作成された後、OPPORTUNISTIC モードで instance-template-b を使用するようにマネージド インスタンス グループを更新した場合、自動修復は引き続き instance-template-a を使用してインスタンスを再作成します。これは、自動修復による再作成はユーザーではなく Compute Engine によって行われ、Compute Engine には VM インスタンスが新しいテンプレートを使用すべきであるという前提がないためです。新しいテンプレートを適用する場合は、マネージド インスタンス グループのインスタンス テンプレートを変更するをご覧ください。

同時に自動修復されるインスタンスの数は、マネージド インスタンス グループのサイズよりも小さくなります。このため、自動修復ポリシーがワークロードに適合していない場合やファイアウォール ルールが誤って構成されている場合、あるいはネットワーク接続やインフラストラクチャの問題により、すべての正常なインスタンスが誤って異常と認識される場合でも、グループはインスタンスのサブセットを実行し続けることができます。ただし、ゾーン マネージド インスタンス グループにインスタンスが 1 つしかない場合や、リージョン マネージド インスタンス グループにゾーンあたり 1 つのインスタンスしかない場合、自動修復はそのようなインスタンスが異常になったときに再作成を行います。

autoHealingPolicies[].initialDelaySec プロパティで指定されているとおり、自動修復では、UNHEALTHY 状態のインスタンスを初期化している間はそのインスタンスの再作成が行われません。この設定は、起動プロセス中のインスタンスに対する自動修復のチェックを遅らせて、インスタンスの早すぎる再作成を防ぎます。初期遅延タイマーは、インスタンスの currentActionVERIFYING になるとスタートします。

自動修復とディスク

インスタンスをそのテンプレートに基づいて再作成するとき、自動修復ツールはそれぞれのディスクタイプを異なる方法で処理します。ディスク構成によっては、自動修復ツールがマネージド インスタンスを再作成しようとしたときに失敗することがあります。

タイプ autodelete 自動修復オペレーション中の動作
新しい永続ディスク true インスタンスのテンプレートで指定されたとおりにディスクが再作成されます。ディスクとそのインスタンスが再作成されると、そのディスクに書き込まれたデータは失われます。
新しい永続ディスク false 元のディスクは接続を解除されますが、利用可能な状態に維持されます。ただし、Compute Engine は既存のディスクを再作成できないため、VM インスタンスの再作成は失敗します。
既存の永続ディスク true 元のディスクは削除されます。Compute Engine は削除されたディスクをインスタンスに再接続できないため、VM インスタンスの再作成は失敗します。
既存の永続ディスク false 元のディスクは、インスタンスのテンプレートで指定されたとおりに再接続されます。ディスクのデータは保持されます。ただし、既存の読み取り / 書き込みディスクでは、単一の永続ディスクを読み取り / 書き込みモードで複数のインスタンスに接続できないため、マネージド インスタンス グループは 1 つの VM しか持つことができません。
新しいローカル SSD なし インスタンスのテンプレートで指定されたとおりにディスクが再作成されます。ローカル SSD のデータは、インスタンスの再作成または削除の際に失われます。

自動修復ツールは、インスタンスのテンプレートで指定されていないディスク(VM の作成後に手動で VM に接続したディスクなど)は再接続しません。

ディスクに書き込まれた重要なデータを保持するには、次のような予防措置を取る必要があります。

  • 定期的に永続ディスクのスナップショットを作成します。

  • データを別のソース(Cloud Storage など)にエクスポートします。

インスタンスの重要な設定を保持する必要がある場合は、インスタンス テンプレート内のカスタム イメージ(必要なカスタム設定を含む)を使用することをおすすめします。これにより、インスタンスの再作成時に、指定したカスタム イメージがマネージド インスタンス グループによって使用されます。

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

マネージド インスタンス グループ内のインスタンスに新しいバージョンのソフトウェアを簡単にデプロイできます。更新のロールアウトは仕様に対して自動的に適用されます。アプリケーションの中断を制御するために、更新の速度とスコープを制御できます。部分的ロールアウトを実行して、カナリアテストを行うこともできます。マネージド インスタンス グループの更新をご覧ください。

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

非マネージド インスタンス グループは、任意にグループに追加したりグループから削除したりできる別種のインスタンスのグループです。非マネージド インスタンス グループは自動スケーリング、ローリング更新サポート、インスタンス テンプレートの使用に対応していないため、可能な場合はマネージド インスタンス グループを作成することをおすすめしています。非マネージド インスタンス グループは、負荷分散を既存の構成、または別種のインスタンスのグループに適用する必要がある場合にのみ使用します。

インスタンス テンプレートに従わない別種のインスタンスを作成する必要がある場合は、非マネージド インスタンス グループをご覧ください。

インスタンス グループと負荷分散

Google Cloud Platform で利用可能なすべての負荷分散構成では、ロードバランサのバックエンド サービスから配信されるトラフィックを処理できるバックエンド(インスタンス グループ、ターゲット プール、またはネットワーク エンドポイント グループ)を指定する必要があります。

HTTP(S) 負荷分散、内部負荷分散、TCP プロキシ負荷分散、SSL プロキシ負荷分散では、インスタンス グループをバックエンド サービスに割り当てることができます。バックエンド サービスはバックエンドを管理するための集中管理サービスであり、ロードバランサに対するユーザー リクエストを処理するインスタンスを管理します。各バックエンド サービスには 1 つ以上のバックエンドが含まれ、各バックエンドには 1 つのインスタンス グループが含まれます。バックエンド サービスは使用できるインスタンス、処理可能なトラフィック量、現在処理しているトラフィック量を認識します。マネージドまたは非マネージドのいずれかのインスタンス グループをバックエンド サービスに割り当てることができます。

ネットワーク負荷分散の場合、ターゲット プールに個別の VM インスタンスを追加するか、またはターゲット プールに 1 つ以上のマネージド インスタンス グループを割り当てて、サーバーによってそのインスタンス グループに含まれるすべてのインスタンスが指定されたターゲット プールに追加されるようにする必要があります。

さまざまな負荷分散構成の詳細については、負荷分散のドキュメントをご覧ください。

次のステップ

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

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

Compute Engine ドキュメント