アプリケーションベースのヘルスチェックと自動修復を設定する

このドキュメントでは、マネージドインスタンスグループ（MIG）内の VM を自動修復するようにアプリケーションベースのヘルスチェックを設定する方法について説明します。また、自動修復なしでヘルスチェックを使用する方法、ヘルスチェックを削除する方法、自動修復ポリシーを表示する方法、各 VM のヘルス状態を確認する方法についても説明します。

アプリケーションベースのヘルスチェックを構成して、VM 上のアプリケーションが期待どおりに応答していることを確認できます。構成したヘルスチェックで VM 上のアプリケーションが応答していないことが検出されると、MIG はその VM を unhealthy とマークして修復します。アプリケーションベースのヘルスチェックに基づく VM の修復を「自動修復」といいます。

自動修復をトリガーせずにヘルスチェックを使用できるように、MIG で修復をオフにすることもできます。

MIG での修復の詳細については、高可用性のための VM の修復についてをご覧ください。

始める前に

まだ設定していない場合は、認証を設定します。認証とは、Google Cloud サービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のように Compute Engine に対する認証を行います。

このページのサンプルをどのように使うかに応じて、タブを選択してください。
コンソール

Google Cloud コンソールを使用して Google Cloud サービスと API にアクセスする場合、認証を設定する必要はありません。
gcloud
1. Google Cloud CLI をインストールし、次のコマンドを実行して初期化します。
```
gcloud init
```
  注: すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して、最新バージョンがインストールされていることを確認してください。
2. デフォルトのリージョンとゾーンを設定します。
Terraform

このページの Terraform サンプルをローカル開発環境から使用するには、gcloud CLI をインストールして初期化し、自身のユーザー認証情報を使用してアプリケーションのデフォルト認証情報を設定してください。
1. Google Cloud CLI をインストールします。
2. gcloud CLI を初期化するには:
```
gcloud init
```
3. Google アカウントのローカル認証情報を作成します。
```
gcloud auth application-default login
```
詳細については、ローカル開発環境の認証の設定をご覧ください。
REST

このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。

料金

アプリケーションベースのヘルスチェックを設定すると、デフォルトでは、VM のヘルス状態が変化するたびに、Compute Engine によって Cloud Logging にログエントリが書き込まれます。 Cloud Logging には毎月の無料割り当て量があり、この割り当て量を超過するとロギングのデータ量に応じて課金されます。コストが発生しないようにするには、健全性の変更ログを無効にしてください。

アプリケーションベースのヘルスチェックと自動修復を設定する

MIG でアプリケーションベースのヘルスチェックと自動修復を設定するには、次の作業を行う必要があります。

ヘルスチェックを作成します（まだ作成していない場合）。
MIG で自動修復ポリシーを構成して、ヘルスチェックを適用します。

ヘルスチェックの作成

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

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

このタスクに必要な権限

このタスクを行うには、次の権限が必要です。

ヘルスチェックを作成する場合は、プロジェクトに対する compute.healthChecks.create
使用する場合は、ヘルスチェックに対する compute.healthChecks.use
ファイアウォールを作成する場合は、プロジェクトに対する compute.firewalls.create
ファイアウォールを作成する場合は、ネットワークに対する compute.networks.updatePolicy

これらの権限は、次の事前構成されたロールで利用可能です。

compute.networkAdmin - ヘルスチェックを作成する
compute.securityAdmin - ヘルスチェックを接続するファイアウォールルールを構成する

コンソール

ロードバランシングのヘルスチェックよりも慎重に実施される、自動修復のヘルスチェックを作成します。

たとえば、ポート 80 でのレスポンスを確認するヘルスチェックを作成します。このヘルスチェックでは、VM が UNHEALTHY とマークされて再作成される前にいくつかの障害が許容されます。この例では、ヘルスチェックが 1 回成功すると、VM は healthy とマークされます。ヘルスチェックが連続して 3 回失敗すると、VM は unhealthy とマークされます。
1. Google Cloud コンソールで、ヘルスチェックの作成ページに移動します。
  
  [ヘルスチェックの作成] に移動
2. ヘルスチェックに example-check などの名前を付けます。
3. [スコープ] を選択します。[リージョン] または [グローバル] を選択できます。この例では [グローバル] を選択します。
4. [プロトコル] で、HTTP が選択されていることを確認します。
5. [ポート] に「80」と入力します。
6. [ヘルス条件] セクションで、以下の値を指定します。
  1. [チェック間隔] に「5」と入力します。
  2. [タイムアウト] に「5」と入力します。
  3. [正常しきい値] を設定して、ヘルスチェックが何回連続して正常完了したら、unhealthy とマークされていた VM が healthy に変わるかを決定します。この例では「1」と入力します。
  4. [異常しきい値] を設定して、ヘルスチェックに何回連続して失敗したら、healthy とマークされていた VM が unhealthy に変わるかを決定します。この例では「3」と入力します。
7. [作成] をクリックしてヘルスチェックを作成します。
ヘルスチェックプローブにアプリへの接続を許可するファイアウォールルールを作成します。
注意: ヘルスチェックプローブがファイアウォールルールによってブロックされているとアプリに接続できないため、VM は UNHEALTHY とマークされます。これにより、healthy 状態の VM の自動再作成が開始される可能性があります。
ヘルスチェックプローブは、130.211.0.0/22 と 35.191.0.0/16 の範囲のアドレスから接続を行うため、ネットワークファイアウォールルールがヘルスチェックの接続を許可するようにします。この例では、MIG は default ネットワークを使用し、その VM はポート 80 をリッスンしています。デフォルトネットワークでポート 80 がまだ開いていない場合は、ファイアウォールルールを作成します。
1. Google Cloud コンソールで [ファイアウォールポリシー] ページに移動します。
  
  [ファイアウォールポリシー] に移動
2. [ファイアウォールルールを作成] をクリックします。
3. ファイアウォールルールの [名前] を入力します。例: allow-health-check
4. [ネットワーク] で、default ネットワークを選択します。
5. [ターゲット] で、[All instances in the network] を選択します。
6. [ソースフィルタ] で、IPv4 ranges を選択します。
7. [送信元 IPv4 範囲] に「130.211.0.0/22」と「35.191.0.0/16」を入力します。
8. [プロトコルとポート] で [指定したプロトコルとポート] を選択して、次の操作を行います。
  1. [TCP] を選択します。
  2. [ポート] フィールドに「80」と入力します。
9. [作成] をクリックします。

gcloud

ロードバランシングのヘルスチェックよりも慎重に実施される、自動修復のヘルスチェックを作成します。

たとえば、ポート 80 でのレスポンスを確認するヘルスチェックを作成します。このヘルスチェックでは、VM が UNHEALTHY とマークされて再作成される前にいくつかの障害が許容されます。この例では、ヘルスチェックに 1 回成功すると、VM は healthy とマークされます。連続して 3 回失敗すると、VM は unhealthy とマークされます。次のコマンドで、グローバルヘルスチェックが作成されます。
```
gcloud compute health-checks create http example-check --port 80 \
   --check-interval 30s \
   --healthy-threshold 1 \
   --timeout 10s \
   --unhealthy-threshold 3 \
   --global
```
注: HTTP、HTTPS、TCP、SSL（TLS）プロトコルをサポートする新しいヘルスチェックを使用してください。従来の Compute Engine HTTP / HTTPS ヘルスチェックも引き続き機能します。
ヘルスチェックプローブにアプリへの接続を許可するファイアウォールルールを作成します。

注意: ヘルスチェックプローブがファイアウォールルールによってブロックされているとアプリに接続できないため、VM は UNHEALTHY とマークされます。これにより、良好状態の VM の自動再作成が開始される可能性があります。
ヘルスチェックプローブは、130.211.0.0/22 と 35.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
```

Terraform

google_compute_http_health_check リソースを使用してヘルスチェックを作成します。

たとえば、ポート 80 でのレスポンスを確認するヘルスチェックを作成します。このヘルスチェックでは、VM が UNHEALTHY とマークされて再作成される前にいくつかの障害が許容されます。この例では、ヘルスチェックに 1 回成功すると、VM は healthy とマークされます。連続して 3 回失敗すると、VM は unhealthy とマークされます。次のリクエストで、グローバルヘルスチェックが作成されます。
```
resource "google_compute_http_health_check" "default" {
  name                = "example-check"
  timeout_sec         = 10
  check_interval_sec  = 30
  healthy_threshold   = 1
  unhealthy_threshold = 3
  port                = 80
}
```
google_compute_firewall リソースを使用してファイアウォールを作成します。

注意: ヘルスチェックプローブがファイアウォールルールによってブロックされているとアプリに接続できないため、VM は UNHEALTHY とマークされます。これにより、良好状態の VM の自動再作成が開始される可能性があります。
ヘルスチェックプローブは、130.211.0.0/22 と 35.191.0.0/16 の範囲のアドレスから接続を行うため、ファイアウォールルールがヘルスチェックの接続を許可するようにします。この例では、MIG は default ネットワークを使用し、その VM はポート 80 をリッスンしています。デフォルトネットワークでポート 80 がまだ開いていない場合は、ファイアウォールルールを作成します。
```
resource "google_compute_firewall" "default" {
  name          = "allow-health-check"
  network       = "default"
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16"]
  allow {
    protocol = "tcp"
    ports    = [80]
  }
}
```

Terraform 構成を適用または削除する方法については、基本的な Terraform コマンドをご覧ください。

REST

ロードバランシングのヘルスチェックよりも慎重に実施される、自動修復のヘルスチェックを作成します。

たとえば、ポート 80 でのレスポンスを確認するヘルスチェックを作成します。このヘルスチェックでは、VM が UNHEALTHY とマークされて再作成される前にいくつかの障害が許容されます。この例では、ヘルスチェックに 1 回成功すると、VM は healthy とマークされます。連続して 3 回失敗すると、VM は 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
}
```
注: HTTP、HTTPS、TCP、SSL（TLS）プロトコルをサポートする新しいヘルスチェックを使用してください。従来の Compute Engine HTTP / HTTPS ヘルスチェックも引き続き機能します。
ヘルスチェックプローブにアプリへの接続を許可するファイアウォールルールを作成します。
注意: ヘルスチェックプローブがファイアウォールルールによってブロックされているとアプリに接続できないため、VM は UNHEALTHY とマークされます。これにより、healthy 状態の VM の自動再作成が開始される可能性があります。
ヘルスチェックプローブは、130.211.0.0/22 と 35.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"
  }
 ]
}
```
PROJECT_ID は、実際のプロジェクト ID に置き換えます。

MIG で自動修復ポリシーを構成する

1 つの MIG でヘルスチェックの適用のために設定できる自動修復ポリシーは 1 つだけです。

MIG では、自動修復にリージョンヘルスチェックまたはグローバルヘルスチェックを使用できます。リージョンヘルスチェックにより、リージョン間の依存関係が軽減され、データ所在地に到達できるようになります。グローバルヘルスチェックは、複数のリージョンの MIG に同じヘルスチェックを使用する場合に役立ちます。

自動修復ポリシーを構成する前に、次の作業を行います。

ヘルスチェックをまだ作成していない場合は、作成します。
新しいヘルスチェックの設定中に自動修復が誤ってトリガーされないようにするには、まず MIG で修復を無効にしてから、自動修復ポリシーを構成する必要があります。

このタスクに必要な権限

このタスクを行うには、次の権限が必要です。

MIG に対する compute.instanceGroupManagers.update 権限

これらの権限は、次の事前構成されたロールで利用可能です。

compute.instanceAdmin.v1 - MIG 内の自動修復ポリシーの作成と更新を行う

コンソール

Google Cloud コンソールの [インスタンスグループ] ページに移動します。

[インスタンスグループ] に移動
リストの [名前] 列で、ヘルスチェックを適用する MIG の名前をクリックします。
[編集] をクリックして、この MIG を変更します。
[VM インスタンスのライフサイクル] セクションの [自動修復] で、グローバルまたはリージョンのヘルスチェックを選択します。
[初期遅延] 設定を変更または保持します。

初期遅延は、新しい VM が起動スクリプトを初期化して実行するために要する秒数です。VM の初期遅延期間中、MIG は VM が起動プロセス中にある可能性があるため、失敗したヘルスチェックを無視します。これにより、MIG が VM を早期に再作成するのを防ぐことができます。最初の遅延中にヘルスチェックが正常なレスポンスを受信した場合、起動プロセスが完了し、VM の準備が整っていることを示します。初期遅延タイマーは、VM の currentAction フィールドが VERIFYING に変わると開始されます。初期遅延の値は 0～3,600 秒の範囲で指定してください。コンソールでのデフォルト値は 300 秒です。
[保存] をクリックして変更を適用します。

gcloud

既存の MIG で自動修復ポリシーを構成するには、update コマンドを使用します。

たとえば、既存のゾーン MIG で自動修復ポリシーを構成するには、次のコマンドを使用します。

gcloud compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

MIG の作成時に自動修復ポリシーを構成するには、create コマンドを使用します。

たとえば、ゾーン MIG の作成時に自動修復ポリシーを構成するには、次のコマンドを使用します。

gcloud compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

次のように置き換えます。

MIG_NAME: 自動修復を設定する MIG の名前。
SIZE: グループ内の VM の数。
INSTANCE_TEMPLATE_URL: グループ内に VM を作成するために使用するインスタンステンプレートの部分的な URL。次に例を示します。
- リージョンインスタンステンプレート: projects/example-project/regions/us-central1/instanceTemplates/example-template
- グローバルインスタンステンプレート: projects/example-project/global/instanceTemplates/example-template。
HEALTH_CHECK_URL: 自動修復用に設定するヘルスチェックの部分的な URL。リージョンヘルスチェックを使用する場合は、リージョンヘルスチェックの部分的な URL を指定する必要があります。次に例を示します。
- リージョンヘルスチェック: projects/example-project/regions/us-central1/healthChecks/example-health-check。
- グローバルヘルスチェック: projects/example-project/global/healthChecks/example-health-check。
INITIAL_DELAY: 新しい VM が起動スクリプトを初期化して実行するために要する秒数。VM の初期遅延期間中、MIG は VM が起動プロセス中にある可能性があるため、失敗したヘルスチェックを無視します。これにより、MIG が VM を早期に再作成するのを防ぐことができます。最初の遅延中にヘルスチェックが正常なレスポンスを受信した場合、起動プロセスが完了し、VM の準備が整っていることを示します。初期遅延タイマーは、VM の currentAction フィールドが VERIFYING に変わると開始されます。初期遅延の値は 0～3600 秒の範囲で指定してください。デフォルト値は 0 です。
ZONE: MIG が配置されているゾーン。リージョン MIG の場合は、--region フラグを使用します。

Terraform

MIG で自動修復ポリシーを構成するには、auto_healing_policies ブロックを使用します。

次のサンプルでは、ゾーン MIG で自動修復ポリシーを構成します。サンプルで使用されているリソースの詳細については、google_compute_instance_group_managerをご覧ください。リージョン MIG の場合は、google_compute_region_instance_group_manager リソースを使用します。

resource "google_compute_instance_group_manager" "default" {
  name               = "igm-with-hc"
  base_instance_name = "test"
  target_size        = 3
  zone               = "us-central1-f"
  version {
    instance_template = google_compute_instance_template.default.id
    name              = "primary"
  }
  auto_healing_policies {
    health_check      = google_compute_http_health_check.default.id
    initial_delay_sec = 30
  }
}

Terraform 構成を適用または削除する方法については、基本的な Terraform コマンドをご覧ください。

REST

既存の MIG で自動修復ポリシーを構成するには、patch メソッドを次のように使用します。

ゾーン MIG の場合は、instanceGroupManager.patch メソッドを使用します。
リージョン MIG の場合は、regionInstanceGroupManager.patch メソッドを使用します。

たとえば、既存のゾーン MIG で自動修復を設定するには、次の呼び出しを行います。

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
  {
    "healthCheck": "HEALTH_CHECK_URL",
    "initialDelaySec": INITIAL_DELAY
  }
  ]
}

MIG の作成時に自動修復ポリシーを構成するには、insert メソッドを次のように使用します。

ゾーン MIG の場合は、instanceGroupManager.insert メソッドを使用します。
リージョン MIG の場合は、 regionInstanceGroupManager.insert メソッドを使用します。

たとえば、ゾーン MIG の作成時に自動修復ポリシーを構成するには、次の呼び出しを行います。

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers

{
  "name": "MIG_NAME",
  "targetSize": SIZE,
  "instanceTemplate": "INSTANCE_TEMPLATE_URL"
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
}

次のように置き換えます。

PROJECT_ID: プロジェクト ID。
MIG_NAME: 自動修復を設定する MIG の名前。
SIZE: グループ内の VM の数。
INSTANCE_TEMPLATE_URL: グループ内に VM を作成するために使用するインスタンステンプレートの部分的な URL。次に例を示します。
- リージョンインスタンステンプレート: projects/example-project/regions/us-central1/instanceTemplates/example-template
- グローバルインスタンステンプレート: projects/example-project/global/instanceTemplates/example-template。
HEALTH_CHECK_URL: 自動修復用に設定するヘルスチェックの部分的な URL。次に例を示します。
- リージョンヘルスチェック: projects/example-project/regions/us-central1/healthChecks/example-health-check。
- グローバルヘルスチェック: projects/example-project/global/healthChecks/example-health-check。
INITIAL_DELAY: 新しい VM が起動スクリプトを初期化して実行するために要する秒数。VM の初期遅延期間中、MIG は VM が起動プロセス中にある可能性があるため、失敗したヘルスチェックを無視します。これにより、MIG が VM を早期に再作成するのを防ぐことができます。最初の遅延中にヘルスチェックが正常なレスポンスを受信した場合、起動プロセスが完了し、VM の準備が整っていることを示します。初期遅延タイマーは、VM の currentAction フィールドが VERIFYING に変わると開始されます。初期遅延の値は 0～3600 秒の範囲で指定してください。デフォルト値は 0 です。
ZONE: MIG が配置されているゾーン。リージョン MIG の場合は、URL で regions/REGION を使用します。

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

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

自動修復ポリシーを構成する前に MIG で修復をオフにした場合は、VM のヘルス状態をモニタリングしてヘルスチェックが想定どおりに機能していることを確認してから、MIG で VM の修復をオンに戻します。

自動修復なしでヘルスチェックを使用する

MIG で自動修復なしで構成されたヘルスチェックを使用するには、MIG で修復をオフにします。これは、アプリケーションのヘルス状態のモニタリングだけのためにヘルスチェックを使用する場合や、ヘルスチェックに基づいて独自の修復ロジックを実装する場合に便利です。

unhealthy 状態の VM を修復するように MIG の設定を戻すには、失敗した VM および unhealthy 状態の VM を修復するように MIG を設定するをご覧ください。

ヘルスチェックを削除する

自動修復ポリシーで構成されたヘルスチェックを削除する方法は次のとおりです。

コンソール

Google Cloud コンソールの [インスタンスグループ] ページに移動します。

[インスタンスグループ] に移動
1. ヘルスチェックを削除する MIG の名前をクリックします。
2. [編集] をクリックして、この MIG を変更します。
3. [VM インスタンスのライフサイクル] セクションの [自動修復] で、[ヘルスチェックをしない] を選択します。
4. [保存] をクリックして変更を適用します。

gcloud

自動修復ポリシーでヘルスチェック構成を削除するには、update コマンドで --clear-autohealing フラグを次のように使用します。

gcloud compute instance-groups managed update MIG_NAME \
    --clear-autohealing

MIG_NAME は、MIG の名前に置き換えます。

REST

自動修復ポリシーでヘルスチェック構成を削除するには、自動修復ポリシーを空の値に設定します。

ゾーン MIG の場合は、instanceGroupManagers.patch メソッドを使用します。
リージョン MIG の場合は、regionInstanceGroupManagers.patch メソッドを使用します。

たとえば、ゾーン MIG でヘルスチェックを削除するには、次のリクエストを行います。

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
    {}
  ]
}

次のように置き換えます。

PROJECT_ID: プロジェクト ID。
MIG_NAME: 自動修復を設定する MIG の名前。
ZONE: MIG が配置されているゾーン。リージョン MIG の場合は、regions/REGION を使用します。

MIG で自動修復ポリシーを表示する

MIG の自動修復ポリシーを表示する手順は次のとおりです。

コンソール

Google Cloud コンソールの [インスタンスグループ] ページに移動します。

[インスタンスグループ] に移動
自動修復ポリシーを表示する MIG の名前をクリックします。
[詳細] タブに移動します。
[VM インスタンスのライフサイクル] セクションの [自動修復] フィールドに、自動修復ポリシーで構成されたヘルスチェックと初期遅延が表示されます。

gcloud

MIG の自動修復ポリシーを表示するには、次のコマンドを使用します。

gcloud compute instance-groups managed describe MIG_NAME \
    --format="(autoHealingPolicies)"

MIG_NAME は、MIG の名前に置き換えます。

出力例は次のとおりです。

autoHealingPolicies:
  healthCheck: https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check
  initialDelaySec: 300

REST

MIG の自動修復ポリシーを表示するには、次のように REST メソッドを使用します。

ゾーン MIG の場合は、instanceGroupManagers.get メソッドを使用します。
リージョン MIG の場合は、 regionInstanceGroupManagers.get メソッドを使用します。

たとえば、ゾーン MIG の自動修復ポリシーを表示するには、次のリクエストを送信します。

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

レスポンスの本文で、autoHealingPolicies[] オブジェクトを確認します。

レスポンスの例を次に示します。

{
  ...
  "autoHealingPolicies": [
    {
      "healthCheck": "https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check",
      "initialDelaySec": 300
    }
  ],
  ...
}

次のように置き換えます。

PROJECT_ID: プロジェクト ID。
MIG_NAME: 自動修復を設定する MIG の名前。
ZONE: MIG が配置されているゾーン。リージョン MIG の場合は、regions/REGION を使用します。

ステータスの確認

MIG でアプリケーションベースのヘルスチェックを設定したら、VM が実行中であり、そのアプリケーションが応答していることを次の方法で確認できます。

VM が healthy かどうかを確認する
VM での現在のアクションを確認する
MIG が安定しているかどうかを確認する

VM が healthy かどうかを確認する

MIG でアプリケーションベースのヘルスチェックが構成済みである場合は、各マネージドインスタンスのヘルス状態を確認できます。

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

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

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

このタスクに必要な権限

このタスクを行うには、次の権限が必要です。

MIG に対する compute.instanceGroupManagers.get 権限

コンソール

Google Cloud コンソールの [インスタンスグループ] ページに移動します。

[インスタンスグループ] に移動
リストの [名前] 列で、確認する MIG の名前をクリックします。ページが開き、インスタンスグループプロパティと、グループに含まれる VM のリストが表示されます。
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 のヘルス状態が表示されます。

REST

リージョンの 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 で、初期化時間を経過した場合には、MIG はすぐに修復を試みます。
VM のヘルス状態が UNKNOWN の場合、MIG は VM をすぐには修復しません。これは、ヘルスチェックシグナルが一時的に利用できない VM を不要に修復することを防ぐためです。

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

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

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

VM での現在のアクションを確認する

MIG は VM インスタンスの作成中に、対象インスタンスの読み取り専用 currentAction フィールドを CREATING に設定します。自動修復ポリシーがグループに接続されている場合は、VM が作成されて実行されると、MIG がインスタンスの現在のアクションを VERIFYING に設定し、ヘルスチェッカーが VM のアプリケーションの調査を開始します。アプリケーションの起動に要する時間内にこの初期ヘルスチェックにパスすると、VM が確認され、MIG が VM の currentAction フィールドを NONE に変更します。

VM での現在のアクションを確認するには、VM での現在のアクションを表示するをご覧ください。

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

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

グループ内のすべての VM が正常に稼働している（つまり、各マネージドインスタンスの currentAction フィールドが NONE に設定されている）場合、MIG は status.isStable フィールドを true に設定します。MIG の安定性は、自動修復ポリシー以外のグループ構成にも依存します。たとえば、グループが自動スケーリングされており、スケールインまたはスケールアウト中である場合、MIG はオートスケーラーのオペレーションに基づいて status.isStable フィールドを false に設定します。

MIG の status.isStable フィールドの値を確認するには、MIG が安定しているかどうかを確認するをご覧ください。

自動修復オペレーション履歴を表示する

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

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

REST

リージョン 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 の場合は、zoneOperations リソースを使用します。

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

アプリケーション ベースのヘルスチェックと自動修復を設定する

始める前に

コンソール

gcloud

Terraform

REST

料金

アプリケーション ベースのヘルスチェックと自動修復を設定する

ヘルスチェックの作成

このタスクに必要な権限

コンソール

gcloud

Terraform

REST

MIG で自動修復ポリシーを構成する

このタスクに必要な権限

コンソール

gcloud

Terraform

REST

自動修復なしでヘルスチェックを使用する

ヘルスチェックを削除する

コンソール

gcloud

REST

MIG で自動修復ポリシーを表示する

コンソール

gcloud

REST

ステータスの確認

VM が healthy かどうかを確認する

このタスクに必要な権限

コンソール

gcloud

REST

ヘルス状態

VM での現在のアクションを確認する

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

自動修復オペレーション履歴を表示する

gcloud

REST

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

次のステップ

アプリケーションベースのヘルスチェックと自動修復を設定する

アプリケーションベースのヘルスチェックと自動修復を設定する