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

このインタラクティブなチュートリアルでは、自動修復を使用して 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.

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Google Cloud プロジェクトで課金が有効になっていることを確認します。

Compute Engine API を有効にします。

API を有効にする

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Google Cloud プロジェクトで課金が有効になっていることを確認します。

Compute Engine API を有効にします。

API を有効にする

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

Google Cloud CLI をインストールします。
gcloud CLI を初期化するには:
```
gcloud init
```
注: Google Cloud CLI をインストールすることなく、Google Cloud コンソールで gcloud CLI を実行できます。Google Cloud コンソールで gcloud CLI を実行するには、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. 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. 下部にある [作成] をクリックします。
ヘルスチェックプローブによる 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

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) レスポンスを返します。
ヘルスチェックプローブによる 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. 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. [作成] をクリックします。
ウェブサーバーをマネージドインスタンスグループとしてデプロイします。
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 秒で十分です。
ウェブサーバーへの 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

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

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'

インスタンスグループを作成する。
```
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 秒で十分です。

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

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

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

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

Console

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

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

gcloud

インスタンスグループのステータスをモニタリングします。終了したら、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 など）が示されているインスタンスがある場合は、そのインタンスが設定を完了するまで待ってから、もう一度試してください。

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

注: Cloud Shell を使用している場合、複数のセッションを開くことができます。
ウェブサーバーインスタンスのアドレスを取得します。
```
gcloud compute instances list --filter webserver-group
```
EXTERNAL_IP 列に示されている任意のウェブサーバーインスタンスの IP アドレスをコピーして、ローカル bash 変数として保存します。
```
export IP_ADDRESS=EXTERNAL_IP_ADDRESS
```
ウェブサーバーが設定を完了したことを確認します。サーバーは HTTP 200 OK レスポンスを返します。
```
curl --head $IP_ADDRESS/health
```
```
HTTP/1.1 200 OK
Server: gunicorn/19.6.0
...
```
Connection refused エラーを受け取った場合は、サーバーが設定を完了するまで待ってから、もう一度試してください。
ウェブサーバーを異常な状態にします。
```
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
...
```
最初のシェルセッションに戻り、インスタンスグループをモニタリングして自動修復ツールがアクションを実行するまで待ちます。
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）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

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

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

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

コンソール

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 上でスケーラブルで復元力の高いウェブアプリケーションを作成する方法の詳細を学ぶ。

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

目標

費用

始める前に

アプリ アーキテクチャ

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

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

Console

gcloud

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

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

Console

gcloud

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

Console

gcloud

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

クリーンアップ

プロジェクトを削除する

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

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

コンソール

gcloud

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

コンソール

gcloud

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

コンソール

gcloud

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

コンソール

gcloud

次のステップ

アプリアーキテクチャ

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

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

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

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