このインタラクティブなチュートリアルでは、自動修復を使用して Compute Engine 上で高可用性アプリケーションを構築する方法を説明します。
高可用性アプリケーションは、最小限のレイテンシとダウンタイムでクライアントに対応するよう意図されています。アプリがクラッシュまたはフリーズすると、可用性が低下します。可用性が低下したアプリケーションのクライアントは、高レイテンシやダウンタイムの影響を受ける可能性があります。
自動修復を使用すると、可用性が損なわれたアプリケーションを自動的に再起動できます。自動修復により障害が発生したインスタンスがすばやく検出され、そのインスタンスが自動的に再作成されるため、クライアントに再び対応できるようになります。自動修復を使用すれば、障害の発生後に手動でアプリを運用中の状態に戻す必要がなくなります。
目標
- ヘルスチェックと自動修復ポリシーを構成する。
- マネージド インスタンス グループでデモ用ウェブサービスを設定する。
- ヘルスチェック失敗をシミュレートして自動修復による復元プロセスを確認する。
費用
このチュートリアルでは、Google Cloud の課金対象となる以下のコンポーネントを使用します。- Compute Engine
始める前に
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Make sure that billing is enabled for your Google Cloud project.
Enable the Compute Engine API.
コマンドラインから作業する場合は、Google Cloud CLI をインストールします。
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
アプリ アーキテクチャ
アプリには、次の 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 に同じヘルスチェックを使用する場合に役立ちます。このチュートリアルでは、グローバル ヘルスチェックを作成します。
ヘルスチェックを作成します。
Google Cloud コンソールで、[ヘルスチェック] ページに移動します。
[ヘルスチェックを作成] をクリックします。
[名前] フィールドに「
autohealer-check
」と入力します。[範囲] を
Global
に設定します。自動修復には、リージョン ヘルスチェックまたはグローバル ヘルスチェックのいずれかを使用できます。[プロトコル] で
HTTP
を選択します。[リクエストパス] を
/health
に設定します。これは、ヘルスチェックで使用する HTTP パスを示します。このチュートリアルのデモ用ウェブサーバーで定義する/health
パスは、正常であればHTTP 200 (OK)
レスポンスを返し、異常であればHTTP 500 (Internal Server Error)
レスポンスを返します。[ヘルス条件] を設定します。
- [チェック間隔] を「
10
」に設定します。これは、あるプローブを開始してから次のブローブを開始するまでの時間を定義します。 - [タイムアウト] を「
5
」に設定します。これは、Google Cloud でプローブに対するレスポンスを待ち受ける時間です。この値は、チェック間隔に設定した数値以下にする必要があります。 - [正常しきい値] を「
2
」に設定します。これは、インスタンスを正常とみなすために連続して成功しなければならないプローブの数を定義します。 - [異常しきい値] を「
3
」に設定します。これは、インスタンスを異常とみなすために連続して失敗しなければならないプローブの数を定義します。
- [チェック間隔] を「
下部にある [作成] をクリックします。
ヘルスチェック プローブによる HTTP リクエストを許可するファイアウォール ルールを作成します。
Google Cloud コンソールで、[ファイアウォール ルールの作成] ページに移動します。
[名前] に「
default-allow-http-health-check
」と入力します。[ネットワーク] で、[
default
] を選択します。[ターゲット] で、[
All instances in the network
] を選択します。[ソースフィルタ] で、
IP ranges
を選択します。[ソース IP の範囲] に、
130.211.0.0/22
と35.191.0.0/16
を入力します。[プロトコルとポート] で [tcp] を選択し、「
80
」と入力します。[作成] をクリックします。
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
適切な自動修復ヘルスチェックについて
自動修復で使用するヘルスチェックは、インスタンスを予防的に削除、再作成しないよう、慎重に実施しなければなりません。自動修復ツールによるヘルスチェックを積極的に実施しすぎると、自動修復ツールがビジー状態のインスタンスを障害が発生したものと誤って判断し、不必要にインスタンスを再起動して可用性を低下させる可能性があります。
unhealthy-threshold
。1
以上にする必要があります。この値は、3
以上に設定するのが理想的です。これにより、発生頻度の低いネットワーク パケットの損失などの障害を回避できます。healthy-threshold
。ほとんどのアプリは値2
で十分です。timeout
。この時間値には十分な値を設定します(予想されるレスポンス時間の 5 倍以上)。これにより、ビジー状態のインスタンスや低速のネットワーク接続などの予期しない遅延を回避できます。check-interval
。この値は、1 秒からタイムアウトの 2 倍までの値にする必要があります。長すぎず、短すぎない値を設定してください。値が長すぎると、失敗したインスタンスがすぐに捕捉されません。値が短すぎると、毎秒かなりの数のヘルスチェック プローブが送信されるため、インスタンスとネットワークがビジー状態になる可能性があります。
ウェブサービスを設定する
このチュートリアルでは、GitHub に保存されているウェブアプリを使用します。アプリの実装の詳細については、GoogleCloudPlatform/python-docs-samples GitHub リポジトリをご覧ください。
デモ用ウェブサービスを設定するには、起動時にデモ用ウェブサーバーを起動するインスタンス テンプレートを作成します。そのインスタンス テンプレートを使用してマネージド インスタンス グループをデプロイし、自動修復を有効にします。
インスタンス テンプレートを作成します。デモ用ウェブサーバーを起動する起動スクリプトを組み込みます。
Google Cloud コンソールで、[インスタンス テンプレート] ページに移動します。
[インスタンス テンプレートを作成] をクリックします。
[名前] を
webserver-template
に設定します。[マシンの構成] で
micro
(e2-micro)を選択します。[ファイアウォール] で、[HTTP トラフィックを許可する] チェックボックスをオンにします。
[管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、詳細設定を表示します。複数のタブが表示されます。
[管理] タブの [自動化] にある [起動スクリプト] に、次の内容を入力します。
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
[作成] をクリックします。
ウェブサーバーをマネージド インスタンス グループとしてデプロイします。
Google Cloud コンソールの [インスタンス グループ] ページに移動します。
[インスタンス グループを作成] をクリックします。
[名前] を
webserver-group
に設定します。[リージョン] で、[
europe-west1
] を選択します。[ゾーン] で、[
europe-west1-b
] を選択します。[インスタンス テンプレート] で [
webserver-template
] を選択します。[自動スケーリング] で [自動スケーリングしない] を選択します。
[インスタンス数] を「
3
」に設定します。[ヘルスチェック] で [
autohealer-check
] を選択します。[初期遅延] を「
90
」に設定します。[作成] をクリックします。
ウェブサーバーへの HTTP リクエストを許可するファイアウォール ルールを作成します。
Google Cloud コンソールで、[ファイアウォール ルールの作成] ページに移動します。
[名前] に「
default-allow-http
」と入力します。[ネットワーク] で、[
default
] を選択します。[ターゲット] で、[
Specified target tags
] を選択します。[ターゲットタグ] に「
http-server
」と入力します。[ソースフィルタ] で、
IP ranges
を選択します。[ソース IP の範囲] に「
0.0.0.0/0
」と入力します。[プロトコルとポート] で [tcp] を選択し、「
80
」と入力します。[作成] をクリックします。
インスタンス テンプレートを作成します。デモ用ウェブサーバーを起動する起動スクリプトを組み込みます。
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
ウェブサーバーへの HTTP リクエストを許可するファイアウォール ルールを作成します。
gcloud compute firewall-rules create default-allow-http \ --network default \ --allow tcp:80 \ --target-tags http-server
ヘルスチェック失敗をシミュレートする
ヘルスチェックの失敗をシミュレートするために、デモ用ウェブサーバーにはヘルスチェックを強制的に失敗させる手段が用意されています。
ウェブサーバー インスタンスに移動します。
Google Cloud コンソールで [VM インスタンス] ページに移動します。
[外部 IP] 列で、任意の
webserver-group
インスタンスの IP アドレスをクリックします。ウェブブラウザに新しいタブが開きます。リクエストがタイムアウトになった場合、またはウェブページが利用できない場合は、サーバーが設定を完了するまで待ってから、もう一度試してください。
デモ用ウェブサーバーが次のようなページを表示します。
デモ用ウェブページで、[Make unhealthy] をクリックします。
これにより、ウェブサーバーがヘルスチェックに失敗します。具体的には、ウェブサーバーにより
/health
パスがHTTP 500 (Internal Server Error)
を返します。[Check health] ボタンをクリックして、実際に確認してみましょう(自動修復ツールがインスタンスの再起動を開始すると、このボタンは機能しなくなります)。自動修復ツールがアクションを実行するまで待ちます。
Google Cloud コンソールで [VM インスタンス] ページに移動します。
ウェブサーバー インスタンスのステータスが変わるまで待ちます。インスタンス名の横にある緑色のチェックマークが灰色の正方形に変わり、自動修復ツールが異常なインスタンスの再起動を開始したことを示します。
ページの上部にある [更新] を定期的にクリックして、ページを最新の状態にします。
自動修復プロセスが完了すると、灰色の正方形が緑色のチェックマークに変わり、インスタンスが正常な状態に戻ったことを示します。
インスタンス グループのステータスをモニタリングします。終了したら、
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 セッションを開きます。
ウェブサーバー インスタンスのアドレスを取得します。
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 ...
最初のシェル セッションに戻り、インスタンス グループをモニタリングして自動修復ツールがアクションを実行するまで待ちます。
自動修復プロセスが開始すると、
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
自動修復プロセスが完了すると、インスタンスが再び
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
インスタンス グループのモニタリングが終了したら、
Ctrl+C
を押して停止させます。
この演習は何回でも繰り返せます。たとえば、次のことを試してみます。
すべてのインスタンスを同時に異常な状態にした場合の動作を確認します。同時に複数の障害が発生した場合の自動修復の動作について詳しくは、自動修復の動作をご覧ください。
可能な限り高速にインスタンスを修復するようにヘルスチェックの構成を更新する方法を調べます(実際には、このチュートリアルで説明した控えめな値を使用するようにヘルスチェックのパラメータを設定してください。そうしないと、実際に問題はないのにインスタンスが誤って削除されて再起動されるリスクがあります)。
インスタンス グループには
initial delay
構成設定があります。このデモ用ウェブサーバーに最小限必要な遅延を調べてみてください。(実際には、インスタンスが起動してアプリケーション リクエストの処理を開始するために必要な時間よりも(10~20%)長い遅延を設定してください。そうしないと、インスタンスが自動修復の起動ループから抜け出せなくなるリスクがあります)。
自動修復ツールの履歴を確認する(オプション)
自動修復ツールによるオペレーションの履歴を表示するには、次の gcloud
コマンドを使用します。
gcloud compute operations list --filter='operationType~compute.instances.repair.*'
詳細については、自動修復オペレーション履歴の表示をご覧ください。
クリーンアップ
チュートリアルが終了したら、作成したリソースをクリーンアップして、割り当ての使用を停止し、課金されないようにできます。次のセクションで、リソースを削除または無効にする方法を説明します。
このチュートリアル用に別個のプロジェクトを作成した場合は、プロジェクトごと削除します。それ以外の場合、プロジェクトに保持しておきたいリソースがあれば、このチュートリアルで作成した特定のリソースのみを削除します。
プロジェクトを削除する
- In the Google Cloud console, go to the Manage resources page.
- 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.
-
Select the checkbox for
your
webserver-group
instance group. - To delete the instance group, click Delete.
gcloud compute instance-groups managed delete webserver-group --zone europe-west1-b -q
インスタンス テンプレートを削除する
Google Cloud コンソールで、[インスタンス テンプレート] ページに移動します。
インスタンス テンプレートの横にあるチェックボックスをオンにします。
ページの上部にある
[削除] をクリックします。表示された新しいウィンドウで、[削除] をクリックして削除を確定します。
gcloud compute instance-templates delete webserver-template -q
ヘルスチェックを削除する
Google Cloud コンソールで、[ヘルスチェック] ページに移動します。
ヘルスチェックの横にあるチェックボックスをクリックします。
ページの上部にある
[削除] をクリックします。表示された新しいウィンドウで、[削除] をクリックして削除を確定します。
gcloud compute health-checks delete autohealer-check -q
ファイアウォール ルールを削除する
Google Cloud コンソールで [ファイアウォール ルール] ページに移動します。
default-allow-http
とdefault-allow-http-health-check
という名前のファイアウォール ルールの横のチェックボックスをクリックします。ページの上部にある
[削除] をクリックします。表示された新しいウィンドウで、[削除] をクリックして削除を確定します。
gcloud compute firewall-rules delete default-allow-http default-allow-http-health-check -q
次のステップ
- 別のチュートリアルを試す
- マネージド インスタンス グループの詳細を学ぶ。
- 堅牢なシステムの設計の詳細を学ぶ。
- Google Cloud 上でスケーラブルで復元力の高いウェブ アプリケーションを作成する方法の詳細を学ぶ。