ヘルスチェックと自動修復の設定

マネージド インスタンス グループ(MIG)は、仮想マシン(VM)インスタンスを実行可能な状態(RUNNING 状態)にしておくことで、アプリケーションの高可用性を維持します。マネージド インスタンスが実行を停止し、状態の変更が MIG によって開始されなかった場合、MIG はそのインスタンスを自動的に再作成します。一方、MIG が RUNNING からインスタンスを意図的に停止した場合(たとえば、オートスケーラーがインスタンスを削除した場合)、そのインスタンスは再作成されません。

MIG によって開始されないインスタンスの状態の変更は次のとおりです。

ただし、インスタンスの状態に基づいてアプリケーションの健全性を判断することは不十分な場合があります。たとえば、インスタンスが RUNNING かどうかの確認では、フリーズ、過負荷、クラッシュなどのアプリケーションの障害は検出されません。

アプリケーションの可用性をさらに高め、アプリケーションが応答していることを確認するには、MIG の自動修復ポリシーを構成します。

自動修復ポリシーは、アプリケーション ベースのヘルスチェックを使用して、アプリケーションが期待どおりに応答していることを確認します。アプリケーションのレスポンスを確認することで、単に VM が RUNNING 状態かどうかを検証するより正確な結果を得られます。

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

自動修復の動作

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

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

自動修復では、VM を初期化している間にその VM の再作成が行われることはありません。詳細については、autoHealingPolicies[].initialDelaySec プロパティをご覧ください。この設定は、起動プロセス中の VM に対する自動修復のチェックを遅らせて、VM が早期に再作成されることを防ぎます。初期遅延タイマーは、VM の currentActionVERIFYING のときに開始されます。

マネージド インスタンス グループにヘルスチェックを初めて適用する場合、モニタリングが開始するまでに 30 分ほどかかることがあります。

自動修復とディスク

VM をそのテンプレートに基づいて再作成する際の自動修復ツールの動作は、ディスクタイプによって異なります。ディスク構成によっては、自動修復ツールが VM を再作成しようとしたときに失敗することがあります。

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

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

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

VM の重要な設定を保持する必要がある場合は、インスタンス テンプレート内のカスタム イメージを使用することをおすすめします。カスタム イメージには、必要なカスタム設定が含まれます。インスタンス テンプレートのカスタム イメージを指定すると、MIG は、必要なカスタム設定を含むカスタム イメージを使用して VM を再作成します。

ヘルスチェックと自動修復ポリシーの設定

1 つの MIG に設定できる自動修復ポリシーは 1 つだけです。

最大で 50 個までの MIG に単一のヘルスチェックを適用できます。50 個を超えるグループがある場合は、複数のヘルスチェックを作成します。

ヘルスチェックの設定例

次の例は、MIG でヘルスチェックを使用する方法を示しています。この例では、ポート 80 でウェブサーバーのレスポンスを確認するヘルスチェックを作成します。ヘルスチェック プローブが各ウェブサーバーに接続できるように、ファイアウォール ルールを構成します。最後に、グループの自動修復ポリシーを設定して、MIG にヘルスチェックを適用します。

Console

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

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

    1. Google Cloud Console で、ヘルスチェックの作成ページに移動します。

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

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

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

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

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

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

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

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

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

gcloud

このガイドのコマンドラインの例を使用するには、gcloudコマンドライン ツールをインストールするか、Cloud Shell を使用します。

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

    たとえば、ポート 80 でのレスポンスを確認するヘルスチェックを作成します。このヘルスチェックでは、VM が UNHEALTHY とマークされて再作成される前にいくつかの障害が許容されます。この例では、ヘルスチェックに 1 回成功すると、VM は 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の範囲のアドレスから接続を行うため、ファイアウォール ルールがヘルスチェックの接続を許可するようにします。この例では、MIG は default ネットワークを使用し、その VM はポート 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. リージョンまたはゾーンの MIG の自動修復ポリシーを構成して、ヘルスチェックを適用します。

    update コマンドを使用して、ヘルスチェックを MIG に適用します。

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

    例:

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

API

このガイドの API の例を使用する場合は、API アクセスを設定します。

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

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

    POST https://compute.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の範囲のアドレスから接続を行うため、ファイアウォール ルールがヘルスチェックの接続を許可するようにします。この例では、MIG は default ネットワークを使用し、その VM はポート 80 をリッスンしています。デフォルト ネットワークでポート 80 がまだ開いていない場合は、ファイアウォール ルールを作成します。

    POST https://compute.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. リージョンまたはゾーンの MIG の自動修復ポリシーを構成して、ヘルスチェックを適用します。

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

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

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

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

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

    アプリケーションの自動修復をオフにするには、自動修復ポリシーを空の値 autoHealingPolicies[] に設定します。autoHealingPolicies[] を使用すると、MIG は RUNNING 状態でない VM のみを再作成します。

    instanceGroupManagers.autoHealingPolicies フィールドを読み取ることで、MIG の自動修復ポリシーを取得できます。MIG リソースは、次のいずれかの方法で取得できます。

グループの作成またはヘルスチェックの構成の更新が完了してから、グループ内のインスタンスのモニタリングが開始されるまで 30 分ほどかかることがあります。モニタリングが開始されると、Compute Engine は自動修復構成に基づいてインスタンスを healthy とマーク(または再作成)します。たとえば、初期遅延を 5 分、ヘルスチェック間隔を 1 分、正常しきい値を 1 チェックに構成した場合、タイムラインは次のようになります。

  • 自動修復でグループ内のインスタンスのモニタリングが開始されるまでの 30 分の遅延
  • + 5 分(構成された初期遅延)
  • + 1 分(チェック間隔 × 正常なしきい値(60 秒 × 1))
  • = インスタンスが正常としてマークされるか、再作成されるまでに 36 分

ステータスの確認

VM が作成されていること、またそのアプリケーションが応答していることを確認するには、各 VM の現在のヘルス状態を調べるか、各 VM の現在のアクションを確認するか、グループのステータスを確認します。

VM が正常かどうかの確認

MIG の自動修復を構成した場合は、各マネージド インスタンスのヘルス状態を確認できます。

マネージド インスタンスのヘルス状態を次のように検査します。

  • 自動修復されていない異常な VM を特定します。VM は、次の状況で異常であると診断されても、すぐに修復されない場合があります。
    • VM がまだ起動していて、初期遅延が経過していない。
    • かなりの割合の異常なインスタンスが、自動修復中である。自動修復ツールでは、グループがインスタンスのサブセットを実行し続けるように、自動修復がさらに遅延します。
  • ヘルスチェック設定のエラーを検出します。たとえば、インスタンスが TIMEOUT のヘルス状態を報告する際に、正しく構成されていないファイアウォール ルールや無効なアプリケーション ヘルスチェック エンドポイントを検出できます。
  • VM がRUNNINGステータスに移行する時点と VM が HEALTHY ヘルス状態に移行する時点との間の時間を測定することにより、設定用の初期遅延値を定めます。list-instances メソッドをポーリングすることにより、このギャップを測定できます。

ヘルス状態を確認するには、コンソールgcloud コマンドライン ツール、または API を使用します。

Console

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

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

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

  3. VM が異常な場合は、[ヘルスチェックのステータス] 列でヘルス状態を確認できます。

gcloud

list-instances サブコマンドを使用します。

gcloud compute instance-groups managed list-instances instance-group
NAME              ZONE                  STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE                            VERSION_NAME  LAST_ERROR
igm-with-hc-fvz6  europe-west1          RUNNING  HEALTHY       NONE    my-template
igm-with-hc-gtz3  europe-west1          RUNNING  HEALTHY       NONE    my-template

HEALTH_STATE 列に、各 VM のヘルス状態が表示されます。

API

リージョンの MIG の場合は、listManagedInstances メソッドに対して POST リクエストを作成します。

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

ゾーンの MIG の場合は、ゾーン MIG listManagedInstances メソッドを使用します。

POST https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group/listManagedInstances

リクエストは、次のようなレスポンスを返します。レスポンスには、各マネージド インスタンスの instanceHealth フィールドが含まれます。

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-5485",
   "instanceStatus": "RUNNING",
   "currentAction": "NONE",
   "lastAttempt": {
   },
   "id": "6159431761228150698",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template",
   "version": {
    "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template"
   },
   "instanceHealth": [
    {
     "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "HEALTHY"
    }
   ]
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-sfdp",
   "instanceStatus": "STOPPING",
   "currentAction": "DELETING",
   "lastAttempt": {
   },
   "id": "6622324799312181783",
   "instanceHealth": [
    {
     "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "TIMEOUT"
    }
   ]
  }
 ]
}

ヘルス状態

次のような VM のヘルス状態があります。

  • HEALTHY: VM にアクセス可能です。アプリケーション ヘルスチェック エンドポイントへの接続を確立できます。レスポンスはヘルスチェックで定義された要件を満たしています。
  • DRAINING: VM はドレイン中です。VM への既存の接続が完了するまでの時間はありますが、新しい接続は受け入れられません。
  • UNHEALTHY: VM はアクセス可能ですが、ヘルスチェックで定義された要件を満たしていません。
  • TIMEOUT: VM にアクセスできません。アプリケーション ヘルスチェックエンドポイントへの接続を確立できません。または VM のサーバーが指定されたタイムアウト内に応答しません。これは、たとえば、ファイアウォール ルールが正しく構成されていない、VM のサーバー アプリケーションが過負荷状態であるといったことが原因である可能性があります。
  • UNKNOWN: ヘルスチェック システムが VM を認識していないか、現在のヘルス状態が不明です。MIG の新しい VM のモニタリングを開始するまでに、30 分ほどかかることがあります。

新しい VM は、ヘルスチェック システムによって検証されるまで、UNHEALTHY 状態を返します。

VM が修復されるかどうかは、ヘルス状態によって異なります。

  • VM のヘルス状態が UNHEALTHY または TIMEOUT で、初期化時間を経過した場合には、自動修復サービスはすぐに修復を試みます。
  • VM のヘルス状態が UNKNOWN の場合、すぐには修復されません。これは、ヘルスチェック シグナルが一時的に利用できない VM を不要に修復することを防ぐためです。

次の場合、自動修復の開始が遅れることがあります。

  • VM が、複数の連続した修復の後に、異常状態のままの場合。
  • 異常な VM がグループ内でかなりの割合を占める場合。

ユーザーから、VM のヘルス状態の値に関してのフィードバック、ユースケース、課題事項といった情報を求めています。mig-discuss@google.com にフィードバックをお寄せください。

VM での現在のアクションの表示

VM が作成中の場合、そのインスタンスの currentActionCREATING となります。自動修復ポリシーがグループに適用されている場合、VM が作成されて実行されると、インスタンスは VERIFYINGcurrentAction となり、ヘルス チェッカーが VM のアプリケーションの調査を開始します。アプリケーションが、起動されるまでの時間内にこの初期ヘルスチェックにパスすると、VM が検証され、その currentActionNONE に変わります。

実行されている currentAction とマネージド インスタンス グループの各インスタンスの status を確認するには、gcloud コマンドライン ツールまたは API を使用します。

gcloud

gcloud compute instance-groups managed list-instances instance-group-name \
[--filter="zone:(zone)" | --filter="region:(region)"]

gcloud は、インスタンス グループ内のインスタンスのリスト、インスタンスのステータス、現在のアクションを返します。次に例を示します。

NAME               ZONE           STATUS    ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f            CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING  DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING   NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING   NONE      my-old-template

API

API で、regionInstanceGroupManagers.listManagedInstances メソッドに GET リクエストを送信します。ゾーン マネージド インスタンス グループの場合は、instanceGroupManagers.listManagedInstances メソッドを使用します。

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

API は、グループの各インスタンスの instanceStatuscurrentAction を含めたリストを返します。

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  }
 ]
}

マネージド インスタンス グループに含まれる各インスタンスのステータスは、それぞれのインスタンスの instanceStatus フィールドで記述されます。有効な instanceStatus フィールドのリストを確認するには、インスタンスのステータスの確認をご覧ください。

インスタンスでなんらかの変更が行われている場合、currentAction フィールドに次のいずれかのアクションが入力されます。これは変更の進捗状況を追跡するのに役立ちます。それ以外の場合、currentAction フィールドは NONE になります。

有効な currentAction の値は次のとおりです。

  • ABANDONING。インスタンスはマネージド インスタンス グループから削除中です。
  • CREATING。インスタンスは作成中です。
  • CREATING_WITHOUT_RETRIES。再試行なしでインスタンスを作成しています。インスタンスが最初の試行で作成できなかった場合、マネージド インスタンス グループはインスタンスの置換を行いません。
  • DELETING。インスタンスは削除中です。
  • RECREATING。インスタンスは置換中です。
  • REFRESHING。インスタンスは現在のターゲット プールから削除中で、現在のターゲット プールのリスト(このリストは既存のターゲット プールと同じ場合も異なる場合もあります)に再度追加中です。
  • RESTARTING。インスタンスは stop メソッドと start メソッドを使用して再起動中です。
  • VERIFYING。インスタンスは作成済みで、検証中です。
  • NONE。インスタンスに対して実行されているアクションはありません。

MIG が安定しているかどうかの確認

グループレベルで、Compute Engine は、isStable フラグを含む status という読み取り専用フィールドに値を設定します。

グループ内のすべての VM が実行中で正常な場合(つまり、各マネージド インスタンスの currentActionNONE となっている場合)は、status.isStable==true となります。MIG の安定性は、自動修復ポリシー以外のグループ構成にも依存します。たとえば、グループが自動スケーリングされる場合、現在スケールインまたはスケールアウト中であれば、オートスケーラーのオペレーションにより isStable==false となります。

マネージド インスタンス グループが正常に稼働していることを確認するには、status.isStable フィールドの値を調べます。

gcloud

インスタンス グループ describe コマンドを使用します。

gcloud compute instance-groups managed describe instance-group-name \
    [--zone zone | --region region]

gcloud ツールは、status.isStable フィールドを含むインスタンス グループに関する詳細情報を返します。

グループが安定するまでスクリプトを一時停止するには、wait-until コマンドを使用し、--stable フラグを指定します。次に例を示します。

gcloud compute instance-groups managed wait-until instance-group-name \
    --stable \
    [--zone zone | --region region]
Waiting for group to become stable, current operations: deleting: 4
Waiting for group to become stable, current operations: deleting: 4
...
Group is stable

status.isStable がグループに true を設定した後に、このコマンドの結果が返されます。

API

ゾーン MIG の場合は、GET リクエストを instanceGroupManagers.get メソッドに対して作成します。

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name/get

リージョン マネージド インスタンス グループの場合は、zones/zoneregions/region に置き換えます。

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

API は、status.isStable フィールドを含めて、インスタンス グループの詳細情報を返します。

status.isStablefalse の場合、これは変更がアクティブか、保留中か、またはマネージド インスタンス グループ自体が変更中であることを意味します。

status.isStabletrue の場合は、次のことを意味します。

  • なんらかの変更が行われているインスタンスがマネージド インスタンス グループ内に 1 つもなく、すべてのインスタンスの currentActionNONE となっている。
  • 変更が保留中になっているインスタンスがマネージド インスタンス グループ内に 1 つもない。
  • マネージド インスタンス グループ自体も変更されていない。

マネージド インスタンス グループの変更はさまざまな原因で発生します。次に例を示します。

  • 新しいインスタンス テンプレートのロールアウトをリクエストした。
  • グループ内のインスタンスの作成、削除、サイズ変更、または更新をリクエストした。
  • オートスケーラーからグループのサイズ変更がリクエストされた。
  • 自動修復ツールリソースが、マネージド インスタンス グループ内の正常な状態でないインスタンスを少なくとも 1 つ置き換えた。
  • リージョン マネージド インスタンス グループ内の一部のインスタンスが再配布された。

すべてのアクションが終了すると、そのマネージド インスタンス グループの status.isStabletrue に再び設定されます。

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

gcloud ツールあるいは API を使用して、過去の自動修復イベントを確認できます。

gcloud

プロジェクトの自動修復イベントのみを確認するには、フィルタ付きの 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

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

GET https://compute.googleapis.com/compute/v1/projects/project-id/region/region/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

ゾーン MIG の場合は、zoneOoperations リソースを使用します。

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

特定の修復オペレーションの詳細については、そのオペレーションに関する GET リクエストを送信してください。例:

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

適切な自動修復ヘルスチェックについて

自動修復で使用するヘルスチェックは、インスタンスを予防的に削除、再作成しないよう、慎重に実施しなければなりません。自動修復ツールによるヘルスチェックを積極的に実施しすぎると、自動修復ツールがビジー状態のインスタンスを障害が発生したものと誤って判断し、不必要にインスタンスを再起動して可用性を低下させる可能性があります。

  • unhealthy-threshold1 以上にする必要があります。この値は、3 以上に設定するのが理想的です。これにより、発生頻度の低いネットワーク パケットの損失などの障害を回避できます。
  • healthy-threshold。ほとんどのアプリは値 2 で十分です。
  • timeout。この時間値には十分な値を設定します(予想されるレスポンス時間の 5 倍以上)。これにより、ビジー状態のインスタンスや低速のネットワーク接続などの予期しない遅延を回避できます。
  • check-interval。この値は、1 秒からタイムアウトの 2 倍までの値にする必要があります。長すぎず、短すぎない値を設定してください。値が長すぎると、失敗したインスタンスがすぐに捕捉されません。値が短すぎると、毎秒かなりの数のヘルスチェック プローブが送信されるため、インスタンスとネットワークがビジー状態になる可能性があります。

次のステップ