自動修復を使用した高可用性の確保

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

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

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

目標

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

料金

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

  • Compute Engine

始める前に

    Google アカウントにログインします。

    Google アカウントをまだお持ちでない場合は、新しいアカウントを登録します。

    GCP プロジェクトを選択または作成します。

    [リソースの管理] ページに移動

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

    課金を有効にする方法について

    Compute Engine API を有効にします。

    APIを有効にする

コマンドラインで作業する場合は、gcloud コマンドライン ツールをインストールします。

アプリケーション アーキテクチャ

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

ヘルスチェックとインスタンス グループを示すアーキテクチャ図

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

ヘルスチェックは指定のプロトコル(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 での成功基準に関するドキュメントをご覧ください。

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

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

Console

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

    1. GCP Console の [ヘルスチェック] ページに移動します。
      [ヘルスチェック] ページに移動
    2. [ヘルスチェックを作成] をクリックします。
    3. [名前] を「autohealer-check」に設定します。
    4. [プロトコル] で [HTTP] を選択します。
    5. [リクエストパス] を「/health」に設定します。これは、ヘルスチェックで使用する HTTP パスを示します。このチュートリアルのデモ用ウェブサーバーで定義する /health パスは、正常であれば HTTP 200 (OK) レスポンスを返し、異常であれば HTTP 500 (Internal Server Error) レスポンスを返します。
    6. [ヘルス条件] を設定します。
      1. [チェック間隔] を「10」に設定します。これは、あるプローブを開始してから次のブローブを開始するまでの時間を定義します。
      2. [タイムアウト] を「5」に設定します。これは、GCP がプローブに対するレスポンスを待機する時間を定義します。この値は、チェック間隔に設定した数値以下にする必要があります。
      3. [正常しきい値] を「2」に設定します。これは、インスタンスを正常とみなすために連続して成功しなければならないプローブの数を定義します。
      4. [異常しきい値] を「3」に設定します。これは、インスタンスを異常とみなすために連続して失敗しなければならないプローブの数を定義します。
    7. 下部にある [作成] をクリックします。
  2. ヘルスチェック プローブによる HTTP リクエストを許可するファイアウォール ルールを作成します。

    1. GCP Console の [ファイアウォールの作成] ページに移動します。
      [ファイアウォール ルールの作成] ページに移動
    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. [作成] をクリックします。

gcloud

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

    gcloud compute health-checks create http autohealer-check \
        --check-interval 10 \
        --timeout 5 \
        --healthy-threshold 2 \
        --unhealthy-threshold 3 \
        --request-path "/health"
    
    • check-interval は、あるプローブを開始してから次のブローブを開始するまでの時間を定義します。
    • timeout は、GCP がプローブに対するレスポンスを待機する時間を定義します。この値は、チェック間隔に設定した数値以下にする必要があります。
    • 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
    

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

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

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

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

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

Console

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

    1. GCP Console の [インスタンス テンプレート] ページに移動します。
      [インスタンス テンプレート] ページに移動
    2. [インスタンス テンプレートを作成] をクリックします。
    3. [名前] を「webserver-template」に設定します。
    4. [マシンの構成] で micro(f1-micro)を選択します。
    5. [ファイアウォール] で、[HTTP トラフィックを許可する] チェックボックスをオンにします。
    6. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、詳細設定を表示します。いくつかのタブが表示されます。
    7. [管理] タブで、[自動化] を見つけて、次の起動スクリプトを入力します。
      sudo apt-get update && sudo apt-get install git gunicorn3 python3-pip -y
      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. GCP Console の [インスタンス グループ] ページに移動します。
      [インスタンス グループ] ページに移動
    2. [インスタンス グループを作成] をクリックします。
    3. [名前] を「webserver-group」に設定します。
    4. [リージョン] で [europe-west1] を選択します。
    5. [ゾーン] で [europe-west1-b] を選択します。
    6. [インスタンス テンプレート] で [webserver-template] を選択します。
    7. [自動スケーリング] で [オフ] を選択します。
    8. [インスタンス数] を「3」に設定します。
    9. [ヘルスチェック] で [autohealer-check] を選択します。
    10. [初期遅延] を「90」に設定します。
    11. [作成] をクリックします。
  3. ウェブサーバーへの HTTP リクエストを許可するファイアウォール ルールを作成します。

    1. GCP Console の [ファイアウォールの作成] ページに移動します。
      [ファイアウォール ルールの作成] ページに移動
    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 f1-micro \
        --tags http-server \
        --metadata startup-script='
      sudo apt-get update && sudo apt-get install git gunicorn3 python3-pip -y
      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
    
  3. ウェブサーバーへの HTTP リクエストを許可するファイアウォール ルールを作成します。

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

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

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

Console

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

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

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

    緑色のステータス ボタンと青色のアクション ボタンが示されたシンプルなデモ用ウェブべージ

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

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

  3. オートヒーラーがアクションを実行するまで待ちます。

    1. GCP Console の [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. gcloud がインストールされた新しい 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. 最初の Shell セッションに戻り、インスタンス グループをモニタリングしてオートヒーラーがアクションを実行するまで待ちます。

    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. 自動修復プロセスが完了すると、インスタンスが再び STATUS として RUNNINGACTION として NONE を報告するようになります。これは、インスタンスが正常に再起動されたことを意味します。

      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.*'

詳細については、自動修復オペレーションの履歴の表示に関するドキュメントをご覧ください。

クリーンアップ

自動修復のチュートリアルが終了したら、GCP で作成したリソースをクリーンアップして、今後料金が発生しないようにします。次のセクションで、リソースを削除または無効にする方法を説明します。

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

プロジェクトを削除する

  1. GCP Console で [プロジェクト] ページに移動します。

    プロジェクト ページに移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

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

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

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

Console

  1. GCP Console で、[インスタンス グループ] ページに移動します。

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

  2. 次のチェックボックスをオンにします。 webserver-groupインスタンス グループ。
  3. インスタンス グループを削除するには、ページの上部にある [削除]()をクリックします。

gcloud

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

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

Console

  1. GCP Console の [インスタンス テンプレート] ページに移動します。

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

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

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

gcloud

gcloud compute instance-templates delete webserver-template -q

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

Console

  1. GCP Console の [ヘルスチェック] ページに移動します。

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

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

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

gcloud

gcloud compute health-checks delete autohealer-check -q

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

Console

  1. GCP Console の [ファイアウォール ルール] ページに移動します。

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

  2. default-allow-httpdefault-allow-http-health-check というファイアウォール ルールの横にあるチェックボックスをそれぞれクリックします。

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

gcloud

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

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Compute Engine ドキュメント