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

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

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

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

アプリ アーキテクチャ

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

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

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

ヘルスチェックは指定のプロトコル(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 に同じヘルスチェックを使用する場合に役立ちます。

コンソール

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

    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. 下部にある [作成] をクリックします。

  2. ヘルスチェック プローブによる 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. [作成] をクリックします。

gcloud

  1. 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) レスポンスを返します。
  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 リポジトリをご覧ください。

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

コンソール

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

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

      [インスタンス テンプレートの作成] に移動

    2. [名前] を webserver-template に設定します。

    3. [ロケーション] セクションの [リージョン] プルダウンで、[europe-west1] を選択します。

    4. [マシンの構成] セクションの [マシンタイプ] プルダウンで、[e2-medium] を選択します。

    5. [ファイアウォール] セクションで、[HTTP トラフィックを許可する] チェックボックスをオンにします。

    6. [詳細オプション] セクションを開き、詳細設定を表示します。複数のサブセクションが表示されます。

    7. [管理] セクションの [自動化] で、[起動スクリプト] に次の内容を入力します。

      apt-get update
      apt-get -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. [作成] をクリックします。

  2. ウェブサーバーをマネージド インスタンス グループとしてデプロイします。

    1. Google Cloud コンソールで、[インスタンス グループの作成] ページに移動します。

      [インスタンス グループの作成] に移動

    2. [名前] を webserver-group に設定します。

    3. [インスタンス テンプレート] で [webserver-template] を選択します。

    4. [リージョン] で europe-west1 を選択します。

    5. [ゾーン] で、[europe-west1-b] を選択します。

    6. [自動スケーリング] セクションの [自動スケーリング モード] で、[オフ: 自動スケーリングしない] を選択します。

    7. [インスタンス数] フィールドまでスクロールして、3 に設定します。

    8. [自動修復] セクションで、次の操作を行います。

      1. [ヘルスチェック] プルダウンで [autohealer-check] を選択します。
      2. [初期遅延] を「300」に設定します。

    9. 他のオプションはデフォルト値のままにします。

    10. [作成] をクリックします。

  3. ウェブサーバーへの 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」と入力して、すべての IP アドレスに対しアクセスを許可します。

    8. [プロトコルとポート] で [TCP] を選択し、「80」と入力します。

    9. 他のオプションはデフォルト値のままにします。

    10. [作成] をクリックします。

gcloud

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

    gcloud compute instance-templates create webserver-template \
        --instance-template-region europe-west1 \
        --machine-type e2-medium \
        --tags http-server \
        --metadata startup-script='
      apt-get update
      apt-get -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'
    
  2. マネージド インスタンス グループを作成します。

    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 300
    
  3. ウェブサーバーへの HTTP リクエストを許可するファイアウォール ルールを作成します。

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

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

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

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

コンソール

  1. ウェブサーバー VM に移動します。

    1. Google Cloud コンソールで、[VM インスタンス] ページに移動します。

      [VM インスタンス] に移動

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

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

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

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

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

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

    1. Google Cloud コンソールで、[VM インスタンス] ページに移動します。

      [VM インスタンス] に移動

    2. ウェブサーバー VM のステータスが変わるまで待ちます。VM 名の横にある緑色のチェックマークが灰色の正方形に変わり、自動修復ツールが異常な VM の再起動を開始したことを示します。

    3. ページの上部にある [更新] を定期的にクリックして、ページを最新の状態にします。

    4. 自動修復プロセスが完了すると、灰色の正方形が緑色のチェックマークに変わり、VM が正常な状態に戻ったことを示します。

gcloud

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

    while : ; do
      gcloud compute instance-groups managed list-instances webserver-group \
      --zone europe-west1-b
      sleep 5  # Wait for 5 seconds
    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: RUNNINGACTION: NONE が表示されている必要があります。表示されない場合は、VM の設定が完了するまで数分待ってから、もう一度試してください。

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

  3. ウェブサーバー VM のアドレスを取得します。

    gcloud compute instances list --filter webserver-group
    

    EXTERNAL_IP 列に示されている任意のウェブサーバー VM の IP アドレスをコピーして、ローカル bash 変数として保存します。

    export IP_ADDRESS=EXTERNAL_IP_ADDRESS
    
  4. ウェブサーバーが設定を完了したことを確認します。サーバーは HTTP 200 OK レスポンスを返します。

    curl --head $IP_ADDRESS/health
    
    HTTP/1.1 200 OK
    Server: gunicorn
    ...
    

    Connection refused エラーを受け取った場合は、サーバーが設定を完了するまで待ってから、もう一度試してください。

  5. ウェブサーバーを異常な状態にします。

    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
    ...
    
  6. 最初のシェル セッションに戻り、マネージド インスタンス グループをモニタリングして自動修復ツールがアクションを実行するまで待ちます。

    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 が再び RUNNINGSTATUSNONEACTION を報告するようになります。これは、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 が誤って削除されて再起動されるリスクがあります)。

  • マネージド インスタンス グループには initial delay 構成設定があります。このデモ用ウェブサーバーに最小限必要な遅延を調べてみてください。(実際には、VM が起動してアプリのリクエストの処理を開始するために必要な時間よりも(10~20%)長い遅延を設定してください。そうしないと、VM が自動修復の起動ループから抜け出せなくなるリスクがあります)。

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

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

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

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