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

マネージド インスタンス グループ(MIG)は、仮想マシン(VM)インスタンスを実行可能な状態(RUNNING 状態)にしておくことで、アプリケーションの高可用性を維持します。インスタンスが RUNNING を停止し、状態の変更が MIG によって開始されなかった場合(たとえば、オートスケーラーの判断ではなくハードウェアの障害の場合)、MIG はそのインスタンスを自動的に再作成します。ただし、アプリケーションの健全性を判断するには、インスタンスの状態の確認だけでは、十分ではありません。たとえば、インスタンスが RUNNING であるかどうかの確認では、フリーズ、過負荷、クラッシュなどのアプリケーションの障害は検出されません。

アプリケーションの可用性を高め、アプリケーションが応答していることを確認するには、マネージド インスタンス グループ(MIG)の自動修復ポリシーを構成します。

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

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

自動修復の動作

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

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

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

自動修復とディスク

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

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

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

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

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

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

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

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

1 つのマネージド インスタンス グループに設定できる自動修復ポリシーは 1 つだけです。

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

ヘルスチェックの設定例

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

Console

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

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

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

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

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

    ヘルスチェック プローブ130.211.0.0/2235.191.0.0/16の範囲のアドレスから接続を行うため、ネットワーク ファイアウォール ルールがヘルスチェックの接続を許可するようにします。この例のマネージド インスタンス グループは、default ネットワークを使用し、そのインスタンスはポート 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. リージョンまたはゾーンのマネージド インスタンス グループの自動修復ポリシーを構成して、ヘルスチェックを適用します。

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

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

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

    自動修復でグループ内のインスタンスのモニタリングが開始されるまでに、15 分ほどかかることがあります。

gcloud

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

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

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

    update コマンドを使用して、ヘルスチェックをマネージド インスタンス グループに適用します。

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

    例:

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

    自動修復でグループ内のインスタンスのモニタリングが開始されるまでに、15 分ほどかかることがあります。

API

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

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

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

    POST https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
    
    {
     "name": "allow-health-check",
     "network": "https://compute.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. リージョンまたはゾーンのマネージド インスタンス グループの自動修復ポリシーを構成して、ヘルスチェックを適用します。

    自動修復ポリシーは、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 の設定は、起動プロセス中のインスタンスに対する自動修復を遅らせて、インスタンスが早期に再作成されることを防ぎます。初期遅延タイマーは、インスタンスの currentActionVERIFYING になると開始されます。

    自動修復でグループ内のインスタンスのモニタリングが開始されるまでに、15 分ほどかかることがあります。

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

    instanceGroupManagers.autoHealingPolicies フィールドを読み取ることで、マネージド インスタンス グループの自動修復ポリシーを取得できます。次のいずれかのメソッドを使用して、マネージド インスタンス グループ リソースを取得できます。

    • instanceGroupManagers.get は、指定されたゾーン マネージド インスタンス グループ リソースを返します。
    • instanceGroupManagers.list は、指定されたプロジェクトとゾーン内にある、すべてのゾーン マネージド インスタンス グループを返します。
    • regionInstanceGroupManagers.get は、指定されたリージョン マネージド インスタンス グループ リソースを返します。
    • regionInstanceGroupManagers.list は、指定されたプロジェクトとリージョン内にある、すべてのリージョン マネージド インスタンス グループを返します。

ステータスの確認

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

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

インスタンスが正常かどうかの確認

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

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

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

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

Console

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

    [インスタンス グループ] ページに移動します。

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

  3. インスタンスが unhealthy の場合は、Health issues 列でヘルス状態を確認できます。

gcloud

list-instancesサブコマンドを使用してください。

gcloud beta 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列に、各インスタンスのヘルス状態が表示されます。

API

リージョン マネージド インスタンス グループの場合は、listManagedInstancesメソッドに対してPOSTリクエストを作成します。

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

ゾーン マネージド インスタンス グループの場合は、ゾーン マネージド インスタンス グループlistManagedInstancesメソッドを使用します。

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

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

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

ヘルス状態

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

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

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

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

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

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

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

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

インスタンスでの現在のアクションの表示

マネージド インスタンスが作成中の場合、currentActionCREATING となります。自動修復ポリシーがグループに適用されている場合、マネージド インスタンスが作成されて実行されると、インスタンスは VERIFYINGcurrentAction となり、ヘルス チェッカーがインスタンスのアプリケーションの調査を開始します。アプリケーションが、起動されるまでの時間内にこの初期ヘルスチェックにパスすると、インスタンスが検証され、その 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://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/instance-template-name",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://compute.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 という読み取り専用フィールドに値を設定します。

グループ内のすべてのインスタンスが実行中で正常な場合(つまり、各マネージド インスタンスの currentActionNONE となっている場合)は、status.isStable==true となります。マネージド インスタンス グループの安定性は、自動修復ポリシー以外のグループ構成にも依存します。たとえば、グループが自動スケーリングされる場合、現在スケールアップ中であれば、オートスケーラーのオペレーションにより 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 beta 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 の場合は、POST リクエストを instanceGroupManagers.get メソッドに対して作成します。

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

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

POST 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

リージョン マネージド インスタンス グループの場合、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

ゾーン マネージド インスタンス グループの場合は 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 倍までの値にする必要があります。長すぎず、短すぎない値を設定してください。値が長すぎると、失敗したインスタンスがすぐに捕捉されません。値が短すぎると、毎秒かなりの数のヘルスチェック プローブが送信されるため、インスタンスとネットワークがビジー状態になる可能性があります。

次のステップ