MIG のインスタンスへのヘルスチェックと自動修復の設定

アプリの可用性を高め、アプリが応答していることを確認するには、マネージド インスタンス グループ(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. GCP 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. GCP Console の [ファイアウォール ルールの作成] ページに移動します。

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

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

    1. GCP 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://www.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://www.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. リージョンまたはゾーンのマネージド インスタンス グループの自動修復ポリシーを構成して、ヘルスチェックを適用します。

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

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

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

    PATCH https://www.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 分ほどかかることがあります。

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

作成中のマネージド インスタンスの場合、その currentActionCREATING となります。グループに自動修復ポリシーが適用されている場合、マネージド インスタンスが作成されて実行中になると、インスタンスの currentActionVERIFYING となり、ヘルスチェッカーがインスタンスのアプリケーションの調査を開始します。アプリケーションが、起動されるまでの時間内にこの初期ヘルスチェックにパスすると、インスタンスが検証され、その 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           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 メソッドに対する POST リクエストを行います。ゾーン マネージド インスタンス グループの場合は、instanceGroupManagers.listManagedInstances メソッドを使用します。

POST https://www.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。インスタンスに対して実行されているアクションはありません。

インスタンスが正常に更新されると、instanceStatus フィールドにインスタンスの現在の状態が反映されます。

グループのステータス

グループレベルで、Compute Engine は isStable フラグを含む status という読み取り専用フィールドに値を設定します。このフラグにアクセスするには、gcloud ツールまたは API を使用します。

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

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

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

status.isStabletrue に設定されている場合は、次のことを意味します。

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

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

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

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

また、--stable フラグ付きで gcloud beta compute instance-groups managed wait-until コマンドを使用して、グループに対して status.isStabletrue に設定されるまで待機することもできます。

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --stable \
    [--zone [ZONE] | --region [REGION]]

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

過去の自動修復イベントを表示するには、gcloud ツールまたは API を使用します。

gcloud

プロジェクト内の自動修復イベントのみを表示するには、filter を指定した 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://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/region/[REGION]/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

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

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

特定の修復オペレーションの詳細を確認するには、そのオペレーションの GET リクエストを送信します。次に例を示します。

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

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

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

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

次のステップ

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

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

Compute Engine ドキュメント