高可用性アプリでの自動修復の使用

---

このインタラクティブなチュートリアルでは、自動修復を使用して Compute Engine 上で高可用性アプリケーションを構築する方法を説明します。

高可用性アプリケーションは、最小限のレイテンシとダウンタイムでクライアントに対応するよう意図されています。アプリがクラッシュまたはフリーズすると、可用性が低下します。可用性が低下したアプリケーションのクライアントは、高レイテンシやダウンタイムの影響を受ける可能性があります。

自動修復を使用すると、可用性が損なわれたアプリケーションを自動的に再起動できます。自動修復により障害が発生したインスタンスがすばやく検出され、そのインスタンスが自動的に再作成されるため、クライアントに再び対応できるようになります。自動修復を使用すれば、障害の発生後に手動でアプリを運用中の状態に戻す必要がなくなります。

目標

• ヘルスチェックと自動修復ポリシーを構成する。
• マネージド インスタンス グループでデモ用ウェブサービスを設定する。
• ヘルスチェック失敗をシミュレートして自動修復による復元プロセスを確認する。

費用

このチュートリアルでは、Google Cloud の課金対象となる以下のコンポーネントを使用します。

• Compute Engine

始める前に

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the Compute Engine API.

Enable the API

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the Compute Engine API.

Enable the API

コマンドラインから作業する場合は、Google Cloud CLI をインストールします。

• Install the Google Cloud CLI.

• To initialize the gcloud CLI, run the following command:

  gcloud init

  Note: You can run the gcloud CLI in the Google Cloud console without installing the Google Cloud CLI. To run the gcloud CLI in the Google Cloud console, use Cloud Shell.

アプリ アーキテクチャ

アプリには、次の Compute Engine コンポーネントが含まれています。

• ヘルスチェック: 障害が発生した VM インスタンスを検出するために自動修復ツールが使用する HTTP ヘルスチェック ポリシー。
• ファイアウォール ルール: Google Cloud ファイアウォール ルールにより、インスタンスへのトラフィックを許可または拒否できます。
• マネージド インスタンス グループ: 同じデモ用ウェブサービスを実行するインスタンスのグループ。
• インスタンス テンプレート: インスタンス グループ内の各インスタンスを作成するために使用されるテンプレート。

ヘルスチェック プローブでデモ用ウェブサービスを調査する仕組み

ヘルスチェックは指定のプロトコル（HTTP(S)、SSL、TCP など）を使用して、プローブ リクエストをインスタンスに送信します。詳細については、ヘルスチェックの仕組みとヘルスチェックのカテゴリ、プロトコル、ポートをご覧ください。

このチュートリアルでのヘルスチェックは、ポート 80 上で HTTP パス /health を調査する HTTP ヘルスチェックです。HTTP ヘルスチェックの場合、HTTP パスが HTTP 200 (OK) レスポンスを返した場合にのみ、プローブ リクエストがチェックに合格します。このチュートリアルのデモ用ウェブサーバーで定義する /health パスは、正常であれば HTTP 200 (OK) レスポンスを返し、異常であれば HTTP 500 (Internal Server Error) レスポンスを返します。詳細については、HTTP、HTTPS、HTTP/2 での成功基準をご覧ください。

ヘルスチェックを作成する

自動修復を設定するには、カスタム ヘルスチェックを作成し、ヘルスチェック ブローブを許可するようにネットワーク ファイアウォールを構成します。リージョン ヘルスチェックまたはグローバル ヘルスチェックのいずれかを使用できます。リージョン ヘルスチェックにより、リージョン間の依存関係が軽減され、データ所在地に到達できます。グローバル ヘルスチェックは、複数のリージョンの MIG に同じヘルスチェックを使用する場合に役立ちます。このチュートリアルでは、グローバル ヘルスチェックを作成します。

上級者向けのヒント: ロード バランシングと自動修復には、それぞれ別のヘルスチェックを使用します。負荷分散のヘルスチェックは、応答しないインスタンスを検出し、トラフィックをそうしたインスタンスに配信しないために使用されます。自動修復のヘルスチェックは、障害が発生したインスタンスを検出して再作成するために使用されます。そのため、負荷分散のヘルスチェックほど積極的に使用しないほうが望ましいと言えます。これらのサービスに同じヘルスチェックを使用すると、応答しないインスタンスと障害が発生したインスタンスが区別できなくなり、不必要なレイテンシや非可用性が発生する原因となります。
詳細については、適切な自動修復ヘルスチェックについてをご覧ください。

Console

1. ヘルスチェックを作成します。

   1. Google Cloud コンソールで、[ヘルスチェック] ページに移動します。

      [ヘルスチェック] に移動

   2. [ヘルスチェックを作成] をクリックします。

   3. [名前] フィールドに「autohealer-check」と入力します。

   4. [範囲] を Global に設定します。自動修復には、リージョン ヘルスチェックまたはグローバル ヘルスチェックのいずれかを使用できます。

   5. [プロトコル] で HTTP を選択します。

   6. [リクエストパス] を /health に設定します。これは、ヘルスチェックで使用する HTTP パスを示します。このチュートリアルのデモ用ウェブサーバーで定義する /health パスは、正常であれば HTTP 200 (OK) レスポンスを返し、異常であれば HTTP 500 (Internal Server Error) レスポンスを返します。

   7. [ヘルス条件] を設定します。

      1. [チェック間隔] を「10」に設定します。これは、あるプローブを開始してから次のブローブを開始するまでの時間を定義します。
      2. [タイムアウト] を「5」に設定します。これは、Google Cloud でプローブに対するレスポンスを待ち受ける時間です。この値は、チェック間隔に設定した数値以下にする必要があります。
      3. [正常しきい値] を「2」に設定します。これは、インスタンスを正常とみなすために連続して成功しなければならないプローブの数を定義します。
      4. [異常しきい値] を「3」に設定します。これは、インスタンスを異常とみなすために連続して失敗しなければならないプローブの数を定義します。

   8. 下部にある [作成] をクリックします。

2. ヘルスチェック プローブによる HTTP リクエストを許可するファイアウォール ルールを作成します。

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

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

   2. [名前] に「default-allow-http-health-check」と入力します。

   3. [ネットワーク] で、[default] を選択します。

   4. [ターゲット] で、[All instances in the network] を選択します。

   5. [ソースフィルタ] で、IP ranges を選択します。

   6. [ソース IP の範囲] に、130.211.0.0/22 と 35.191.0.0/16 を入力します。

   7. [プロトコルとポート] で [tcp] を選択し、「80」と入力します。

   8. [作成] をクリックします。

   注: ヘルスチェック プローブは、130.211.0.0/22 から 35.191.0.0/16 までの範囲内のアドレスから送信されます。このチュートリアルでは、ヘルスチェックで HTTP プロトコルを使用しているため、ファイアウォール ルールでポート 80 への接続を許可していることを確認してください。詳細については、マネージド インスタンス グループのヘルスチェックと自動修復の設定をご覧ください。

gcloud

1. health-checks create http コマンドを使用して、グローバル ヘルスチェックを作成します。

   gcloud compute health-checks create http autohealer-check \
       --global \
       --check-interval 10 \
       --timeout 5 \
       --healthy-threshold 2 \
       --unhealthy-threshold 3 \
       --request-path "/health"
   

   • check-interval は、プローブを開始してから次のプローブを開始するまでの時間です。
   • timeout は、Google Cloud でプローブに対するレスポンスを待ち受ける時間です。この値は、チェック間隔に設定した数値以下にする必要があります。
   • healthy-threshold は、インスタンスを正常とみなすために連続して成功しなければならないプローブの数を定義します。
   • unhealthy-threshold は、インスタンスを異常とみなすために連続して失敗しなければならないプローブの数を定義します。
   • request-path は、ヘルスチェックで使用する HTTP パスを示します。このチュートリアルのデモ用ウェブサーバーで定義する /health パスは、正常であれば HTTP 200 (OK) レスポンスを返し、異常であれば HTTP 500 (Internal Server Error) レスポンスを返します。

2. ヘルスチェック プローブによる HTTP リクエストを許可するファイアウォール ルールを作成します。

   gcloud compute firewall-rules create default-allow-http-health-check \
       --network default \
       --allow tcp:80 \
       --source-ranges 130.211.0.0/22,35.191.0.0/16
   

   注: ヘルスチェック プローブは、範囲 130.211.0.0/22 および 35.191.0.0/16 のアドレスから送信されます。このチュートリアルでは、ヘルスチェックで HTTP プロトコルを使用しているため、ファイアウォール ルールでポート 80 への接続を許可していることを確認してください。詳細については、マネージド インスタンス グループのヘルスチェックと自動修復の設定をご覧ください。

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

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

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

ウェブサービスを設定する

このチュートリアルでは、GitHub に保存されているウェブアプリを使用します。アプリの実装の詳細については、GoogleCloudPlatform/python-docs-samples GitHub リポジトリをご覧ください。

デモ用ウェブサービスを設定するには、起動時にデモ用ウェブサーバーを起動するインスタンス テンプレートを作成します。そのインスタンス テンプレートを使用してマネージド インスタンス グループをデプロイし、自動修復を有効にします。

Console

1. インスタンス テンプレートを作成します。デモ用ウェブサーバーを起動する起動スクリプトを組み込みます。

   1. Google Cloud コンソールで、[インスタンス テンプレート] ページに移動します。

      [インスタンス テンプレート] に移動

   2. [インスタンス テンプレートを作成] をクリックします。

   3. [名前] を webserver-template に設定します。

   4. [マシンの構成] で micro（e2-micro）を選択します。

   5. [ファイアウォール] で、[HTTP トラフィックを許可する] チェックボックスをオンにします。

   6. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、詳細設定を表示します。複数のタブが表示されます。

   7. [管理] タブの [自動化] にある [起動スクリプト] に、次の内容を入力します。

      sudo apt update && sudo apt -y install git gunicorn3 python3-pip
      git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
      cd python-docs-samples/compute/managed-instances/demo
      sudo pip3 install -r requirements.txt
      sudo gunicorn3 --bind 0.0.0.0:80 app:app --daemon
      

   8. [作成] をクリックします。

2. ウェブサーバーをマネージド インスタンス グループとしてデプロイします。

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

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

   2. [インスタンス グループを作成] をクリックします。

   3. [名前] を webserver-group に設定します。

   4. [リージョン] で、[europe-west1] を選択します。

   5. [ゾーン] で、[europe-west1-b] を選択します。

   6. [インスタンス テンプレート] で [webserver-template] を選択します。

   7. [自動スケーリング] で [自動スケーリングしない] を選択します。

   8. [インスタンス数] を「3」に設定します。

   9. [ヘルスチェック] で [autohealer-check] を選択します。

   10. [初期遅延] を「90」に設定します。

   11. [作成] をクリックします。

   注: 初期遅延は、新しい VM が起動スクリプトの初期化と実行にかかった秒数です。VM の初期遅延期間中、MIG は VM が起動プロセス中にある可能性があるため、失敗したヘルスチェックを無視します。これにより、MIG が VM を早期に再作成するのを防ぐことができます。最初の遅延中にヘルスチェックが正常なレスポンスを受信した場合、起動プロセスが完了し、VM の準備が整っていることを示します。初期遅延の値は 0～3,600 秒の範囲で指定してください。コンソールでのデフォルト値は 300 です。このチュートリアルのサンプル ウェブサーバーの場合、90 秒で十分です。

3. ウェブサーバーへの HTTP リクエストを許可するファイアウォール ルールを作成します。

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

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

   2. [名前] に「default-allow-http」と入力します。

   3. [ネットワーク] で、[default] を選択します。

   4. [ターゲット] で、[Specified target tags] を選択します。

   5. [ターゲットタグ] に「http-server」と入力します。

   6. [ソースフィルタ] で、IP ranges を選択します。

   7. [ソース IP の範囲] に「0.0.0.0/0」と入力します。

   8. [プロトコルとポート] で [tcp] を選択し、「80」と入力します。

   9. [作成] をクリックします。

gcloud

1. インスタンス テンプレートを作成します。デモ用ウェブサーバーを起動する起動スクリプトを組み込みます。

   gcloud compute instance-templates create webserver-template \
       --machine-type e2-micro \
       --tags http-server \
       --metadata startup-script='
     sudo apt update && sudo apt -y install git gunicorn3 python3-pip
     git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
     cd python-docs-samples/compute/managed-instances/demo
     sudo pip3 install -r requirements.txt
     sudo gunicorn3 --bind 0.0.0.0:80 app:app --daemon'
   

2. インスタンス グループを作成します。

   gcloud compute instance-groups managed create webserver-group \
       --zone europe-west1-b \
       --template webserver-template \
       --size 3 \
       --health-check autohealer-check \
       --initial-delay 90
   

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

3. ウェブサーバーへの HTTP リクエストを許可するファイアウォール ルールを作成します。

   gcloud compute firewall-rules create default-allow-http \
       --network default \
       --allow tcp:80 \
       --target-tags http-server
   

ヘルスチェック失敗をシミュレートする

ヘルスチェックの失敗をシミュレートするために、デモ用ウェブサーバーにはヘルスチェックを強制的に失敗させる手段が用意されています。

Console

1. ウェブサーバー インスタンスに移動します。

   1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

      [VM インスタンス] に移動

   2. [外部 IP] 列で、任意の webserver-group インスタンスの IP アドレスをクリックします。ウェブブラウザに新しいタブが開きます。リクエストがタイムアウトになった場合、またはウェブページが利用できない場合は、サーバーが設定を完了するまで待ってから、もう一度試してください。

   デモ用ウェブサーバーが次のようなページを表示します。

   

2. デモ用ウェブページで、[Make unhealthy] をクリックします。

   これにより、ウェブサーバーがヘルスチェックに失敗します。具体的には、ウェブサーバーにより /health パスが HTTP 500 (Internal Server Error) を返します。[Check health] ボタンをクリックして、実際に確認してみましょう（自動修復ツールがインスタンスの再起動を開始すると、このボタンは機能しなくなります）。

3. 自動修復ツールがアクションを実行するまで待ちます。

   1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

      [VM インスタンス] に移動

   2. ウェブサーバー インスタンスのステータスが変わるまで待ちます。インスタンス名の横にある緑色のチェックマークが灰色の正方形に変わり、自動修復ツールが異常なインスタンスの再起動を開始したことを示します。

   3. ページの上部にある [更新] を定期的にクリックして、ページを最新の状態にします。

   4. 自動修復プロセスが完了すると、灰色の正方形が緑色のチェックマークに変わり、インスタンスが正常な状態に戻ったことを示します。

gcloud

1. インスタンス グループのステータスをモニタリングします。終了したら、Ctrl+C を押して終了します。

   while : ; do \
       gcloud compute instance-groups managed list-instances webserver-group \
       --zone europe-west1-b \
       ; done
   

   NAME                 ZONE            STATUS   ACTION  INSTANCE_TEMPLATE   VERSION_NAME  LAST_ERROR
   webserver-group-d5tz  europe-west1-b  RUNNING  NONE    webserver-template
   webserver-group-q6t9  europe-west1-b  RUNNING  NONE    webserver-template
   webserver-group-tbpj  europe-west1-b  RUNNING  NONE    webserver-template
   

   RUNNING 以外のステータス（STAGING など）が示されているインスタンスがある場合は、そのインタンスが設定を完了するまで待ってから、もう一度試してください。

2. Google Cloud CLI をインストールして新しい Cloud Shell セッションを開きます。

   注: Cloud Shell を使用している場合、複数のセッションを開くことができます。

3. ウェブサーバー インスタンスのアドレスを取得します。

   gcloud compute instances list --filter webserver-group
   

   EXTERNAL_IP 列に示されている任意のウェブサーバー インスタンスの IP アドレスをコピーして、ローカル bash 変数として保存します。

   export IP_ADDRESS=EXTERNAL_IP_ADDRESS
   

4. ウェブサーバーが設定を完了したことを確認します。サーバーは HTTP 200 OK レスポンスを返します。

   curl --head $IP_ADDRESS/health
   

   HTTP/1.1 200 OK
   Server: gunicorn/19.6.0
   ...
   

   Connection refused エラーを受け取った場合は、サーバーが設定を完了するまで待ってから、もう一度試してください。

5. ウェブサーバーを異常な状態にします。

   curl $IP_ADDRESS/makeUnhealthy > /dev/null
   

   これにより、ウェブサーバーがヘルスチェックに失敗します。具体的には、ウェブサーバーにより /health パスが HTTP 500 INTERNAL SERVER ERROR を返します。/health に対してリクエストを送信して、実際に確認してみましょう（自動修復ツールがインスタンスの再起動を開始すると、これは機能しなくなります）。

   curl --head $IP_ADDRESS/health
   

   HTTP/1.1 500 INTERNAL SERVER ERROR
   Server: gunicorn/19.6.0
   ...
   

6. 最初のシェル セッションに戻り、インスタンス グループをモニタリングして自動修復ツールがアクションを実行するまで待ちます。

   1. 自動修復プロセスが開始すると、STATUS 列と ACTION 列が更新され、自動修復ツールが異常なインスタンスの再起動を開始したことを示します。

      NAME                 ZONE            STATUS    ACTION      INSTANCE_TEMPLATE   VERSION_NAME  LAST_ERROR
      webserver-group-d5tz  europe-west1-b  RUNNING   NONE        webserver-template
      webserver-group-q6t9  europe-west1-b  RUNNING   NONE        webserver-template
      webserver-group-tbpj  europe-west1-b  STOPPING  RECREATING  webserver-template
      

   2. 自動修復プロセスが完了すると、インスタンスが再び RUNNING の STATUS と NONE の ACTION を報告するようになり、インスタンスが正常に再起動されたことを示します。

      NAME                 ZONE            STATUS   ACTION  INSTANCE_TEMPLATE   VERSION_NAME  LAST_ERROR
      webserver-group-d5tz  europe-west1-b  RUNNING  NONE    webserver-template
      webserver-group-q6t9  europe-west1-b  RUNNING  NONE    webserver-template
      webserver-group-tbpj  europe-west1-b  RUNNING  NONE    webserver-template
      

   3. インスタンス グループのモニタリングが終了したら、Ctrl+C を押して停止させます。

   注: インスタンスの起こり得るステータスとアクションの詳細については、インスタンスのライフサイクルとインタンスでの現在のアクションをご覧ください。

この演習は何回でも繰り返せます。たとえば、次のことを試してみます。

• すべてのインスタンスを同時に異常な状態にした場合の動作を確認します。同時に複数の障害が発生した場合の自動修復の動作について詳しくは、自動修復の動作をご覧ください。

• 可能な限り高速にインスタンスを修復するようにヘルスチェックの構成を更新する方法を調べます（実際には、このチュートリアルで説明した控えめな値を使用するようにヘルスチェックのパラメータを設定してください。そうしないと、実際に問題はないのにインスタンスが誤って削除されて再起動されるリスクがあります）。

• インスタンス グループには initial delay 構成設定があります。このデモ用ウェブサーバーに最小限必要な遅延を調べてみてください。（実際には、インスタンスが起動してアプリケーション リクエストの処理を開始するために必要な時間よりも（10～20%）長い遅延を設定してください。そうしないと、インスタンスが自動修復の起動ループから抜け出せなくなるリスクがあります）。

自動修復ツールの履歴を確認する（オプション）

自動修復ツールによるオペレーションの履歴を表示するには、次の gcloud コマンドを使用します。

gcloud compute operations list --filter='operationType~compute.instances.repair.*'

詳細については、自動修復オペレーション履歴の表示をご覧ください。

クリーンアップ

チュートリアルが終了したら、作成したリソースをクリーンアップして、割り当ての使用を停止し、課金されないようにできます。次のセクションで、リソースを削除または無効にする方法を説明します。

このチュートリアル用に別個のプロジェクトを作成した場合は、プロジェクトごと削除します。それ以外の場合、プロジェクトに保持しておきたいリソースがあれば、このチュートリアルで作成した特定のリソースのみを削除します。

プロジェクトを削除する

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

特定のリソースを削除する

このチュートリアルに使用したプロジェクトを削除できない場合、チュートリアルのリソースを個別に削除します。

インスタンス グループを削除する

コンソール

1. In the Google Cloud console, go to the Instance groups page.

   Go to Instance groups

2. Select the checkbox for your webserver-group instance group.
3. To delete the instance group, click Delete.

gcloud

gcloud compute instance-groups managed delete webserver-group --zone europe-west1-b -q

インスタンス テンプレートを削除する

注: インスタンス テンプレートを削除する前に、インスタンス グループを削除する必要があります。マネージド インスタンス グループでインスタンス テンプレートを使用している場合、そのインスタンス テンプレートを削除することはできません。

コンソール

1. Google Cloud コンソールで、[インスタンス テンプレート] ページに移動します。

   [インスタンス テンプレート] に移動

2. インスタンス テンプレートの横にあるチェックボックスをオンにします。

3. ページの上部にある [削除] をクリックします。表示された新しいウィンドウで、[削除] をクリックして削除を確定します。

gcloud

gcloud compute instance-templates delete webserver-template -q

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

注: ヘルスチェックを削除する前に、インスタンス グループを削除する必要があります。他のリソースでヘルスチェックを使用している場合、そのヘルスチェックを削除することはできません。

コンソール

1. Google Cloud コンソールで、[ヘルスチェック] ページに移動します。

   [ヘルスチェック] に移動

2. ヘルスチェックの横にあるチェックボックスをクリックします。

3. ページの上部にある [削除] をクリックします。表示された新しいウィンドウで、[削除] をクリックして削除を確定します。

gcloud

gcloud compute health-checks delete autohealer-check -q

ファイアウォール ルールを削除する

コンソール

1. Google Cloud コンソールで [ファイアウォール ルール] ページに移動します。

   [ファイアウォール ルール] に移動

2. default-allow-http と default-allow-http-health-check という名前のファイアウォール ルールの横のチェックボックスをクリックします。

3. ページの上部にある [削除] をクリックします。表示された新しいウィンドウで、[削除] をクリックして削除を確定します。

gcloud

gcloud compute firewall-rules delete default-allow-http default-allow-http-health-check -q

次のステップ

• 別のチュートリアルを試す
  • 可用性の高いアプリケーションでのロード バランシングの使用。
  • スケーラビリティの高いアプリケーションでの自動スケーリングの使用。
• マネージド インスタンス グループの詳細を学ぶ。
• 堅牢なシステムの設計の詳細を学ぶ。
• Google Cloud 上でスケーラブルで復元力の高いウェブ アプリケーションを作成する方法の詳細を学ぶ。