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

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

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

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

目標

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

費用

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

  • Compute Engine

始める前に

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

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

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

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

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

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

    1. Cloud Console の [ファイアウォール ルールの作成] ページに移動します。
      [ファイアウォール ルールの作成] ページに移動
    2. [名前] に「default-allow-http-health-check」と入力します。
    3. [ネットワーク] で、[default] を選択します。
    4. [ターゲット] で、[All instances in the network] を選択します。
    5. [ソースフィルタ] で、IP ranges を選択します。
    6. [ソース IP の範囲] に、130.211.0.0/2235.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 は、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
    

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

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

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

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

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

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

Console

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

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

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

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

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

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

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

    1. Cloud 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 コマンドライン ツールで新しい 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. 自動修復プロセスが完了すると、インスタンスが再び RUNNINGSTATUSNONEACTION を報告するようになり、インスタンスが正常に再起動されたことを示します。

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

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

クリーンアップ

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

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

プロジェクトを削除する

  1. Cloud Console で [リソースの管理] ページに移動します。

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

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

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

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

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

Console

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

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

  2. webserver-group インスタンス グループのチェックボックスをクリックします。
  3. [削除] をクリックしてインスタンス グループを削除します。

gcloud

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

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

Console

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

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

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

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

gcloud

gcloud compute instance-templates delete webserver-template -q

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

Console

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

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

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

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

gcloud

gcloud compute health-checks delete autohealer-check -q

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

Console

  1. Cloud 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

次のステップ