このページは Cloud Translation API によって翻訳されました。

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

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

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

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

目標

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

費用

このチュートリアルでは、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.

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.

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 ファイアウォールルールにより、VM へのトラフィックを許可または拒否できます。
マネージドインスタンスグループ: 同じデモ用ウェブサービスを実行する VM のグループ。
インスタンステンプレート: インスタンスグループ内の各 VM の作成に使用されるテンプレート。

ヘルスチェックとインスタンスグループのシステムアーキテクチャ

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

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

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

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

自動修復を設定するには、カスタムヘルスチェックを作成し、ヘルスチェックブローブを許可するようにネットワークファイアウォールを構成します。

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

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

コンソール

ヘルスチェックを作成します。
1. Google Cloud コンソールで、[ヘルスチェックの作成] ページに移動します。
  
  [ヘルスチェックの作成] に移動
2. [名前] フィールドに「autohealer-check」と入力します。
3. [範囲] を Regional に設定します。
4. [リージョン] プルダウンで、[europe-west1] を選択します。
5. [プロトコル] で HTTP を選択します。
6. [リクエストパス] を /health に設定します。これは、ヘルスチェックで使用する HTTP パスを示します。このチュートリアルのデモ用ウェブサーバーで定義する /health パスは、正常であれば HTTP 200 (OK) レスポンスを返し、異常であれば HTTP 500 (Internal Server Error) レスポンスを返します。
7. [ヘルス条件] を設定します。
  1. [チェック間隔] を「10」に設定します。これは、あるプローブを開始してから次のブローブを開始するまでの時間を定義します。
  2. [タイムアウト] を「5」に設定します。これは、Google Cloud でプローブに対するレスポンスを待ち受ける時間です。この値は、チェック間隔に設定した数値以下にする必要があります。
  3. [正常しきい値] を「2」に設定します。これは、VM が正常であるとみなすために連続して成功しなければならないプローブの数を定義します。
  4. [異常しきい値] を「3」に設定します。これは、VM を異常とみなすために連続して失敗しなければならないプローブの数を定義します。
8. 他のオプションはデフォルト値のままにします。
9. 下部にある [作成] をクリックします。
ヘルスチェックプローブによる HTTP リクエストを許可するファイアウォールルールを作成します。
1. Google Cloud コンソールで、[ファイアウォールルールの作成] ページに移動します。
  
  [ファイアウォールルールの作成] に移動
2. [名前] に「default-allow-http-health-check」と入力します。
3. [ネットワーク] で、[default] を選択します。
4. [ターゲット] で、[All instances in the network] を選択します。
5. [ソースフィルタ] で、IPv4 ranges を選択します。
6. [送信元 IPv4 範囲] に「130.211.0.0/22, 35.191.0.0/16」と入力します。
7. [プロトコルとポート] で [TCP] を選択し、「80」と入力します。
8. 他のオプションはデフォルト値のままにします。
9. [作成] をクリックします。
注: ヘルスチェックプローブは、130.211.0.0/22 から 35.191.0.0/16 までの範囲内のアドレスから送信されます。このチュートリアルでは、ヘルスチェックで HTTP プロトコルを使用しているため、ファイアウォールルールでポート 80 への接続を許可していることを確認してください。詳細については、マネージドインスタンスグループのヘルスチェックと自動修復の設定をご覧ください。

gcloud

health-checks create http コマンドを使用してヘルスチェックを作成します。
```
gcloud compute health-checks create http autohealer-check \
    --region europe-west1 \
    --check-interval 10 \
    --timeout 5 \
    --healthy-threshold 2 \
    --unhealthy-threshold 3 \
    --request-path "/health"
```
- check-interval は、プローブを開始してから次のプローブを開始するまでの時間です。
- timeout は、Google Cloud でプローブに対するレスポンスを待ち受ける時間です。この値は、チェック間隔に設定した数値以下にする必要があります。
- healthy-threshold は、VM を正常とみなすために連続して成功しなければならないプローブの数を定義します。
- unhealthy-threshold は、VM が異常とみなされるために連続して失敗しなければならないプローブの数を定義します。
- request-path は、ヘルスチェックで使用する HTTP パスを示します。このチュートリアルのデモ用ウェブサーバーで定義する /health パスは、正常であれば HTTP 200 (OK) レスポンスを返し、異常であれば HTTP 500 (Internal Server Error) レスポンスを返します。
ヘルスチェックプローブによる 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 リポジトリをご覧ください。

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

コンソール

インスタンステンプレートを作成します。デモ用ウェブサーバーを起動する起動スクリプトを組み込みます。
1. Google Cloud コンソールで、[インスタンステンプレートの作成] ページに移動します。
  
  [インスタンステンプレートの作成] に移動
2. [名前] を webserver-template に設定します。
3. [ロケーション] セクションの [リージョン] プルダウンで、[europe-west1] を選択します。
4. [マシンの構成] セクションの [マシンタイプ] プルダウンで、[e2-medium] を選択します。
5. [ファイアウォール] セクションで、[HTTP トラフィックを許可する] チェックボックスをオンにします。
6. [詳細オプション] セクションを開いて、詳細設定を表示します。複数のサブセクションが表示されます。
7. [管理] セクションの [自動化] で、[起動スクリプト] に次の内容を入力します。
```
apt update && apt -y install git python3-pip python3-venv
git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
python3 -m venv venv
./venv/bin/pip3 install -Ur ./python-docs-samples/compute/managed-instances/demo/requirements.txt
./venv/bin/pip3 install gunicorn
./venv/bin/gunicorn --bind 0.0.0.0:80 app:app --daemon --chdir ./python-docs-samples/compute/managed-instances/demo
```
8. 他のオプションはデフォルト値のままにします。
9. [作成] をクリックします。
ウェブサーバーをマネージドインスタンスグループとしてデプロイします。
1. Google Cloud コンソールで、[インスタンスグループの作成] ページに移動します。
  
  [インスタンスグループの作成] に移動
2. [名前] を webserver-group に設定します。
3. [インスタンステンプレート] で [webserver-template] を選択します。
4. [リージョン] で、europe-west1 を選択します。
5. [ゾーン] で、[europe-west1-b] を選択します。
6. [自動スケーリング] セクションの [自動スケーリングモード] で、[オフ: 自動スケーリングしない] を選択します。
7. [インスタンス数] フィールドまでスクロールして、3 に設定します。
8. [自動復元] セクションで、次の操作を行います。
  1. [ヘルスチェック] プルダウンで [autohealer-check] を選択します。
  2. [初期遅延] を「180」に設定します。
    
    注: 初期遅延は、新しい VM が起動スクリプトの初期化と実行にかかった秒数です。VM の初期遅延期間中、MIG は VM が起動プロセス中にある可能性があるため、失敗したヘルスチェックを無視します。これにより、MIG が VM を早期に再作成するのを防ぐことができます。最初の遅延中にヘルスチェックが正常なレスポンスを受信した場合、起動プロセスが完了し、VM の準備が整っていることを示します。初期遅延の値は 0 ～ 3,600 秒の範囲で指定してください。コンソールでのデフォルト値は 300 です。このチュートリアルのサンプルウェブサーバーの場合、180 秒で十分です。
9. 他のオプションはデフォルト値のままにします。
10. [作成] をクリックします。
ウェブサーバーへの HTTP リクエストを許可するファイアウォールルールを作成します。
1. Google Cloud コンソールで、[ファイアウォールルールの作成] ページに移動します。
  
  [ファイアウォールルールの作成] に移動
2. [名前] に「default-allow-http」と入力します。
3. [ネットワーク] で、[default] を選択します。
4. [ターゲット] で、[Specified target tags] を選択します。
5. [ターゲットタグ] に「http-server」と入力します。
6. [ソースフィルタ] で、IPv4 ranges を選択します。
7. [送信元 IPv4 範囲] に「0.0.0.0/0」と入力します。
8. [プロトコルとポート] で [TCP] を選択し、「80」と入力します。
9. 他のオプションはデフォルト値のままにします。
10. [作成] をクリックします。

gcloud

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

gcloud compute instance-templates create webserver-template \
    --instance-template-region europe-west1 \
    --machine-type e2-medium \
    --tags http-server \
    --metadata startup-script='
  apt update && apt -y install git python3-pip python3-venv
  git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
  python3 -m venv venv
  ./venv/bin/pip3 install -Ur ./python-docs-samples/compute/managed-instances/demo/requirements.txt
  ./venv/bin/pip3 install gunicorn
  ./venv/bin/gunicorn --bind 0.0.0.0:80 app:app --daemon --chdir ./python-docs-samples/compute/managed-instances/demo'

マネージドインスタンスグループを作成する。
```
gcloud compute instance-groups managed create webserver-group \
    --zone europe-west1-b \
    --template projects/PROJECT_ID/regions/europe-west1/instanceTemplates/webserver-template \
    --size 3 \
    --health-check projects/PROJECT_ID/regions/europe-west1/healthChecks/autohealer-check \
    --initial-delay 180
```
注: 初期遅延は、新しい VM が起動スクリプトの初期化と実行にかかった秒数です。VM の初期遅延期間中、MIG は VM が起動プロセス中にある可能性があるため、失敗したヘルスチェックを無視します。これにより、MIG が VM を早期に再作成するのを防ぐことができます。最初の遅延中にヘルスチェックが正常なレスポンスを受信した場合、起動プロセスが完了し、VM の準備が整っていることを示します。初期遅延タイマーは MIG が VM の currentAction フィールドが VERIFYING に変わると開始されます。初期遅延の値は 0～3,600 秒の範囲で指定してください。デフォルト値は 0 です。このチュートリアルのサンプルウェブサーバーの場合、180 秒で十分です。

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

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

マネージドインスタンスグループが VM を作成して検証するまで数分待ちます。

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

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

Console

ウェブサーバー VM に移動します。
1. Google Cloud コンソールで [VM インスタンス] ページに移動します。
  
  [VM インスタンス] に移動
2. webserver-group VM の [外部 IP] 列で、IP アドレスをクリックします。ウェブブラウザに新しいタブが開きます。リクエストがタイムアウトになった場合、またはウェブページが利用できない場合は、サーバーが設定を完了するまで待ってから、もう一度試してください。
デモ用ウェブサーバーが次のようなページを表示します。
デモ用ウェブページで、[Make unhealthy] をクリックします。

これにより、ウェブサーバーがヘルスチェックに失敗します。具体的には、ウェブサーバーにより /health パスが HTTP 500 (Internal Server Error) を返します。[Check health] ボタンをクリックして、実際に確認してみましょう（自動修復ツールが VM の再起動を開始すると、このボタンは機能しなくなります）。
自動修復ツールがアクションを実行するまで待ちます。
1. Google Cloud コンソールで [VM インスタンス] ページに移動します。
  
  [VM インスタンス] に移動
2. ウェブサーバー VM のステータスが変わるまで待ちます。VM 名の横にある緑色のチェックマークが灰色の正方形に変わり、自動修復ツールが異常な VM の再起動を開始したことを示します。
3. ページの上部にある [更新] を定期的にクリックして、ページを最新の状態にします。
4. 自動修復プロセスが完了すると、灰色の正方形が緑色のチェックマークに変わり、VM が正常な状態に戻ったことを示します。

gcloud

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

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

  NAME: webserver-group-0zx6
  ZONE: europe-west1-b
  STATUS: RUNNING
  HEALTH_STATE: HEALTHY
  ACTION: NONE
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

  NAME: webserver-group-4qbx
  ZONE: europe-west1-b
  STATUS: RUNNING
  HEALTH_STATE: HEALTHY
  ACTION: NONE
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

  NAME: webserver-group-m5v5
  ZONE: europe-west1-b
  STATUS: RUNNING
  HEALTH_STATE: HEALTHY
  ACTION: NONE
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

グループ内のすべての VM に STATUS: RUNNING と ACTION: NONE が表示されている必要があります。表示されない場合は、VM の設定が完了するまで数分待ってから、もう一度試してください。

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

注: Cloud Shell を使用している場合、複数のセッションを開くことができます。
ウェブサーバー VM のアドレスを取得します。
```
gcloud compute instances list --filter webserver-group
```
EXTERNAL_IP 列に示されている任意のウェブサーバー VM の IP アドレスをコピーして、ローカル bash 変数として保存します。
```
export IP_ADDRESS=EXTERNAL_IP_ADDRESS
```
ウェブサーバーが設定を完了したことを確認します。サーバーは HTTP 200 OK レスポンスを返します。
```
curl --head $IP_ADDRESS/health
```
```
HTTP/1.1 200 OK
Server: gunicorn
...
```
Connection refused エラーを受け取った場合は、サーバーが設定を完了するまで待ってから、もう一度試してください。
ウェブサーバーを異常な状態にします。
```
curl $IP_ADDRESS/makeUnhealthy > /dev/null
```
これにより、ウェブサーバーがヘルスチェックに失敗します。具体的には、ウェブサーバーにより /health パスが HTTP 500 INTERNAL SERVER ERROR を返します。/health に対してリクエストを送信して、実際に確認してみましょう（自動修復ツールが VM の再起動を開始すると、これは機能しなくなります）。
```
curl --head $IP_ADDRESS/health
```
```
HTTP/1.1 500 INTERNAL SERVER ERROR
Server: gunicorn
...
```
最初のシェルセッションに戻り、マネージドインスタンスグループをモニタリングして自動修復ツールがアクションを実行するまで待ちます。
1. 自動修復プロセスが開始すると、STATUS 列と ACTION 列が更新され、自動修復ツールが異常な VM の再起動を開始したことを示します。
```
  NAME: webserver-group-0zx6
  ZONE: europe-west1-b
  STATUS: STOPPING
  HEALTH_STATE: UNHEALTHY
  ACTION: RECREATING
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

  ...
```
2. 自動修復プロセスが完了すると、VM が再び RUNNING の STATUS と NONE の ACTION を報告するようになり、VM が正常に再起動されたことを示します。
```
  NAME: webserver-group-0zx6
  ZONE: europe-west1-b
  STATUS: RUNNING
  HEALTH_STATE: HEALTHY
  ACTION: NONE
  INSTANCE_TEMPLATE: webserver-template
  VERSION_NAME:
  LAST_ERROR:

  ...
```
3. マネージドインスタンスグループのモニタリングが完了したら、Ctrl+C を押して停止します。
注: VM の起こり得るステータスとアクションの詳細については、インスタンスのライフサイクルとインタンスでの現在のアクションをご覧ください。

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

すべての VM を同時に異常な状態にした場合の動作を確認します。同時に複数の障害が発生した場合の自動修復の動作について詳しくは、自動修復の動作をご覧ください。
可能な限り高速に VM を修復するようにヘルスチェックの構成を更新できますか？（実際には、このチュートリアルで説明した控えめな値を使用するようにヘルスチェックのパラメータを設定してください。そうしないと、実際に問題はないのに VM が誤って削除されて再起動されるリスクがあります）。
マネージドインスタンスグループには initial delay 構成設定があります。このデモ用ウェブサーバーに最小限必要な遅延を調べてみてください。（実際には、VM が起動してアプリケーションリクエストの処理を開始するために必要な時間よりも（10 ～ 20%）長い遅延を設定してください。そうしないと、VM が自動修復の起動ループから抜け出せなくなるリスクがあります）。

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

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

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

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

クリーンアップ

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

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

プロジェクトを削除する

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

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

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

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

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

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

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

コンソール

In the Google Cloud console, go to the Instance groups page.
Go to Instance groups
Select the checkbox for your webserver-group instance group.
To delete the instance group, click Delete.

gcloud

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

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

コンソール

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

[インスタンステンプレート] に移動
インスタンステンプレートの横にあるチェックボックスをオンにします。
ページの上部にある [削除] をクリックします。表示された新しいウィンドウで、[削除] をクリックして削除を確定します。

gcloud

gcloud compute instance-templates delete webserver-template -q

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

console

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

[ヘルスチェック] に移動
ヘルスチェックの横にあるチェックボックスをクリックします。
ページの上部にある [削除] をクリックします。表示された新しいウィンドウで、[削除] をクリックして削除を確定します。

gcloud

gcloud compute health-checks delete autohealer-check -q

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

コンソール

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

[ファイアウォールルール] に移動
default-allow-http と default-allow-http-health-check という名前のファイアウォールルールの横のチェックボックスをクリックします。
ページの上部にある [削除] をクリックします。表示された新しいウィンドウで、[削除] をクリックして削除を確定します。

gcloud

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

次のステップ

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

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

目標

費用

始める前に

アプリ アーキテクチャ

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

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

コンソール

gcloud

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

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

コンソール

gcloud

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

Console

gcloud

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

クリーンアップ

プロジェクトを削除する

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

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

コンソール

gcloud

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

コンソール

gcloud

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

console

gcloud

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

コンソール

gcloud

次のステップ

アプリアーキテクチャ

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

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

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

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