Google Cloud Load Balancing 用の TCP プロキシの設定

Google Cloud Platform(GCP)TCP プロキシの負荷分散により、世界中のすべてのユーザーに対して単一の IP アドレスを使用できます。GCP TCP プロキシの負荷分散では、ユーザーに最も近いインスタンスにトラフィックが自動的にルーティングされます。

Cloud TCP プロキシは HTTP 以外のトラフィックを対象としています。HTTP トラフィックの場合は、代わりに HTTP(S)負荷分散を使用することをおすすめします。SSL トラフィックの場合は、SSL プロキシの負荷分散を使用してください。

目次

概要

TCP トラフィックに TCP プロキシを使用すると、グローバル負荷分散層で顧客の TCP セッションを停止し、TCP または SSL を使用して仮想マシン インスタンスにトラフィックを転送できます。

SSL プロキシは、グローバル負荷分散サービスです。複数のリージョンにインスタンスをデプロイできます。また、グローバル負荷分散によってユーザーに最も近いリージョンにトラフィックが自動的に転送されます。リージョンの容量に達すると、ロードバランサは使用可能な容量を持つ別のリージョンに新しい接続を自動的に転送します。既存のユーザー接続は現在のリージョンにそのまま残ります。

TCP プロキシの利点:

  • 高度なルーティング機能 - ロードバランサによって、容量のあるバックエンドのロケーションにリクエストをルーティングできます。それに対して、L3/L4 ロードバランサは容量に注意を払わずにリージョンのバックエンドにルーティングする必要があります。より高度なルーティングを使用すると、x*N ではなく、N+1 または N+2 でプロビジョニングできるようになります。
  • セキュリティ パッチ - TCP スタックで脆弱性が生じると、インスタンスの安全が確保されるように、ロードバランサで自動的にパッチが適用されます。
  • TCP プロキシでは、次のポートがサポートされています: 25、43、110、143、195、443、465、587、700、993、995

注:

  • TCP プロキシで HTTP を処理することもできますが、推奨されません。HTTP トラフィックの場合は、代わりに HTTP 負荷分散を使用してください。詳細については、よくある質問をご覧ください。

次に、TCP プロキシの仕組みを説明し、複数のインスタンスにトラフィックが負荷分散されるように TCP プロキシを設定する方法について詳しく説明していきます。

TCP プロキシを使用した Google Cloud Load Balancing

グローバル負荷分散層に TCP プロキシを設定すると、TCP 接続で受信するトラフィックはグローバル層で停止され、使用可能な最も近いインスタンス グループにプロキシ処理されます。

この例では、Iowa と Boston のユーザーからのトラフィックはグローバル負荷分散層で停止され、分割された接続は選択されたバックエンド サービスに向かうように設定されます。

TCP ターミネーションを使用した Google Cloud Load Balancing(クリックして拡大)
TCP ターミネーションを使用した Google Cloud Load Balancing(クリックして拡大)

TCP 負荷分散の設定

この例では、us-central1us-east1 の 2 つのリージョンに存在するシンプルなサービスに対してグローバル TCP 負荷分散を設定する方法を示します。例で示されているサービスは、ポート 110 で応答するように構成された Apache サーバーのセットです。多くのブラウザではポート 110 は許可されないため、curl を使用する最終テストを行います。

以下を設定します。

  1. 2 つのリージョンに分散している 4 つのインスタンス
  2. インスタンスを保持するインスタンス グループ
  3. インスタンスの正常性をチェックするヘルスチェック
  4. グループ内のインスタンスをモニタリングし、設定された使用率を超過しないようにするバックエンド サービス
  5. TCP プロキシ自体
  6. ユーザーのトラフィックをプロキシに送信するパブリック静的 IP アドレスと転送ルール
  7. ロードバランサおよびヘルス チェッカーからの、インスタンスへのトラフィックを許可するファイアウォール ルール

その後、設定をテストします。

インスタンスとインスタンス グループの設定

このセクションでは、簡単なインスタンス グループを作成し、それらにインスタンスを追加して、ヘルスチェックを行ってからそれらのインスタンスをバックエンド サービスに追加する方法を説明します。通常、実働システムではインスタンス テンプレートに基づいてマネージド インスタンス グループを使用しますが、初期テストにはこの設定のほうがより簡単に行えます。

インスタンスの設定

テストの目的で、4 つのインスタンス、2 つのインスタンスのグループのそれぞれ 2 つに Apache をインストールしてください。通常、HTTP トラフィックには TCP 負荷分散を使用しませんが、Apache は広く使用されており、テスト用に簡単に設定できます。

これらのインスタンスはすべて tcp-lb のタグで作成されます。このタグは後でファイアウォール ルールによって使用されます。

gcloud


  1. ゾーン us-central1-big-us-central1-1 を作成します。

    gcloud compute instances create ig-us-central1-1 \
        --image-family debian-8 \
        --image-project debian-cloud \
        --tags tcp-lb \
        --zone us-central1-b \
        --metadata startup-script="#! /bin/bash
          sudo apt-get update
          sudo apt-get install apache2 -y
          sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
          sudo sed -i '/\<VirtualHost \*:80\>/c\\<VirtualHost \*:110\>' /etc/apache2/sites-enabled/000-default.conf
          sudo service apache2 restart
          echo '<!doctype html><html><body><h1>TCP load balanced instance - US central 1</h1></body></html>' | tee /var/www/html/index.html
          EOF"
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instances/ig-us-central1-1].
    NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-central1-1 us-central1-b n1-standard-1             10.240.0.8  23.251.150.133 RUNNING

  2. ゾーン us-central1-big-us-central1-2 を作成します。

    gcloud compute instances create ig-us-central1-2 \
        --image-family debian-8 \
        --image-project debian-cloud \
        --tags tcp-lb \
        --zone us-central1-b \
         --metadata startup-script="#! /bin/bash
           sudo apt-get update
           sudo apt-get install apache2 -y
           sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
           sudo sed -i '/\<VirtualHost \*:80\>/c\\<VirtualHost \*:110\>' /etc/apache2/sites-enabled/000-default.conf
           sudo service apache2 restart
           echo '<!doctype html><html><body><h1>TCP load balanced instance - US central 2</h1></body></html>' | tee /var/www/html/index.html
           EOF"
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instances/ig-us-central1-2].
    NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-central1-2 us-central1-b n1-standard-1             10.240.0.11 23.251.148.160 RUNNING

  3. ゾーン us-east1-big-us-east1-1 を作成します。

    gcloud compute instances create ig-us-east1-1 \
        --image-family debian-8 \
        --image-project debian-cloud \
        --tags tcp-lb \
        --zone us-east1-b \
        --metadata startup-script="#! /bin/bash
          sudo apt-get update
          sudo apt-get install apache2 -y
          sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
          sudo sed -i '/\<VirtualHost \*:80\>/c\\<VirtualHost \*:110\>' /etc/apache2/sites-enabled/000-default.conf
          sudo service apache2 restart
          echo '<!doctype html><html><body><h1>TCP load balanced instance - US east 1</h1></body></html>' | tee /var/www/html/index.html
          EOF"
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instances/ig-us-east1-1].
    NAME          ZONE       MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-east1-1 us-east1-b n1-standard-1             10.240.0.12 104.196.31.214 RUNNING

  4. ゾーン us-east1-big-us-east1-2 を作成します。

    gcloud compute instances create ig-us-east1-2 \
        --image-family debian-8 \
        --image-project debian-cloud \
        --tags tcp-lb \
        --zone us-east1-b \
        --metadata startup-script="#! /bin/bash
          sudo apt-get update
          sudo apt-get install apache2 -y
          sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
          sudo sed -i '/\<VirtualHost \*:80\>/c\\<VirtualHost \*:110\>' /etc/apache2/sites-enabled/000-default.conf
          sudo service apache2 restart
          echo '<!doctype html><html><body><h1>TCP load balanced instance - US east 2</h1></body></html>' | tee /var/www/html/index.html
          EOF"
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instances/ig-us-east1-2].
    NAME          ZONE       MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-east1-2 us-east1-b n1-standard-1             10.240.0.13 104.196.25.101 RUNNING

各ゾーンでのインスタンス グループの作成とインスタンスの追加

gcloud


  1. us-ig1 インスタンス グループを作成します。

    gcloud compute instance-groups unmanaged create us-ig1 \
        --zone us-central1-b
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instanceGroups/us-ig1].
    NAME    LOCATION       SCOPE  NETWORK  MANAGED  INSTANCES
    us-ig1  us-central1-b  zone                     0
    

  2. インスタンス グループの名前付きポートを作成します。

    gcloud compute instance-groups set-named-ports us-ig1 \
        --named-ports tcp110:110 \
        --zone us-central1-b
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instanceGroups/us-ig2].

  3. ig-us-central1-1ig-us-central1-2us-ig1 に追加します。

    gcloud compute instance-groups unmanaged add-instances us-ig1 \
        --instances ig-us-central1-1,ig-us-central1-2 \
        --zone us-central1-b
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instanceGroups/us-ig1].

  4. us-ig2 インスタンス グループを作成します。

    gcloud compute instance-groups unmanaged create us-ig2 \
        --zone us-east1-b
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instanceGroups/us-ig2].
    NAME    LOCATION    SCOPE  NETWORK  MANAGED  INSTANCES
    us-ig2  us-east1-b  zone                     0
    

  5. インスタンス グループの名前付きポートを作成します。

    gcloud compute instance-groups set-named-ports us-ig2 \
        --named-ports tcp110:110 \
        --zone us-east1-b
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instanceGroups/us-ig2].

  6. ig-us-east1-1ig-us-east1-2us-ig2 に追加します。

    gcloud compute instance-groups unmanaged add-instances us-ig2 \
        --instances ig-us-east1-1,ig-us-east1-2 \
        --zone us-east1-b
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/instanceGroups/us-ig2].

これで、それぞれが 2 つのインスタンスを持つ 2 つのリージョンに 1 つのインスタンス グループができました。

ロードバランサの設定

gcloud


ヘルスチェックの作成

gcloud compute health-checks create tcp my-tcp-health-check --port 110

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks/my-tcp-health-check].
NAME                PROTOCOL
my-tcp-health-check TCP

バックエンド サービスの作成

gcloud compute backend-services create my-tcp-lb \
    --global \
    --protocol TCP \
    --health-checks my-tcp-health-check \
    --timeout 5m \
    --port-name tcp110

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/my-tcp-lb].
NAME      BACKENDS PROTOCOL
my-tcp-lb          TCP

あるいは、--protocol SSL を使用して、ロードバランサからインスタンスへの暗号化された通信を設定することもできます。

バックエンド サービスへのインスタンス グループの追加

gcloud compute backend-services add-backend my-tcp-lb \
    --global \
    --instance-group us-ig1 \
    --instance-group-zone us-central1-b \
    --balancing-mode UTILIZATION \
    --max-utilization 0.8

Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/my-tcp-lb].

gcloud compute backend-services add-backend my-tcp-lb \
    --global \
    --instance-group us-ig2 \
    --instance-group-zone us-east1-b \
    --balancing-mode UTILIZATION \
    --max-utilization 0.8

Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/my-tcp-lb].

グローバル静的 IP アドレスの予約

顧客は、この IP アドレスを使用して負荷分散されたサービスにアクセスします。

gcloud compute addresses create tcp-lb-static-ip --global

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/addresses/tcp-lb-static-ip].
NAME                 REGION ADDRESS        STATUS
tcp-lb-static-ip     [LB_STATIC_IP]        RESERVED

ターゲット TCP プロキシの設定

プロキシ ヘッダーをオンにする場合は、none ではなく PROXY_V1 に設定します。

gcloud alpha compute target-tcp-proxies create my-tcp-lb-target-proxy \
    --backend-service my-tcp-lb \
    --proxy-header NONE

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/targetSslProxies/my-tcp-lb-target-proxy].
NAME                   PROXY_HEADER SERVICE
my-tcp-lb-target-proxy NONE         my-tcp-lb

グローバル転送ルールの設定

gcloud alpha compute forwarding-rules create my-tcp-lb-forwarding-rule \
    --global \
    --target-tcp-proxy my-tcp-lb-target-proxy \
    --address tcp-lb-static-ip \
    --ports 110

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/forwardingRules/my-tcp-lb-forwarding-rule].
NAME                         REGION IP_ADDRESS     IP_PROTOCOL TARGET
my-tcp-lb-forwarding-rule           [LB_STATIC_IP] TCP         my-tcp-lb-target-proxy

TCP ロードバランサのファイアウォール ルールの作成

ロードバランサとヘルス チェッカーからインスタンスへのトラフィックを許可するファイアウォール ルールを設定します。ここでは、TCP ポート 110 を開きます。ヘルスチェックでも同じポートが使用されます。

gcloud


 gcloud compute firewall-rules create allow-tcplb-and-health \
     --source-ranges 130.211.0.0/22,35.191.0.0/16 \
     --target-tags tcp-lb \
     --allow tcp:110

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-tcp110-130-211-0-0-22].
NAME                     NETWORK SRC_RANGES                   RULES      SRC_TAGS TARGET_TAGS
allow-tcplb-and-health   default 130.211.0.0/22,35.191.0.0/16 tcp:110             tcp-lb

ロードバランサのテスト

ポート 110 は多くのブラウザでブロックされているため、curl などを使用して、ロードバランサが稼働していることを確認する必要があります。

curl http://[LB_STATIC_IP]:110
  • [LB_STATIC_IP]: 上記で tcp-lb-static-ip に割り当てたグローバル IP アドレス。

その他のコマンド

ターゲット TCP プロキシのリスト

gcloud alpha compute target-tcp-proxies list
NAME                PROXY_HEADER SERVICE            SSL_CERTIFICATES
my-target-tcp-proxy NONE         my-backend-service

ターゲット TCP プロキシの記述

gcloud alpha compute target-tcp-proxies describe my-target-tcp-proxy
creationTimestamp: '2016-02-20T20:55:17.633-08:00'
id: '9208913598676794842'
kind: compute#targetTcpProxy
name: my-target-tcp-proxy
proxyHeader: NONE
selfLink: https://www.googleapis.com/compute/alpha/projects/[PROJECT_ID]/global/targetTcpProxies/my-target-tcp-proxy
service: https://www.googleapis.com/compute/alpha/projects/[PROJECT_ID]/global/backendServices/my-backend-service
sslCertificates:

ターゲット TCP プロキシの削除

ターゲット プロキシを削除するには、まず、そのターゲット プロキシを参照しているグローバル転送ルールを削除する必要があります。

  1. グローバル転送ルールを削除します。

    gcloud alpha compute forwarding-rules delete my-global-forwarding-rule \
        --global
    

    The following global forwarding rules will be deleted:
     - [my-global-forwarding-rule]

    Do you want to continue (Y/n)? y

    Deleted [https://www.googleapis.com/compute/alpha/projects/[PROJECT_ID]/global/forwardingRules/my-global-forwarding-rule].

  2. TCP プロキシを削除します。

    gcloud alpha compute target-tcp-proxies delete my-target-tcp-proxy
    

    The following target tcp proxies will be deleted:
     - [my-target-tcp-proxy]

    Do you want to continue (Y/n)? y

    Deleted [https://www.googleapis.com/compute/alpha/projects/[PROJECT_ID]/global/targetTcpProxies/my-target-tcp-proxy].

ターゲット TCP プロキシのバックエンド サービスの更新

update コマンドを使用して、異なるバックエンド サービスで TCP プロキシをポイントできます。この例では、新しいバックエンド サービスを作成し、そこでプロキシを指示します。その後、元のプロキシを指示し直します。

  1. 同じヘルスチェックを使用して、2 番目のバックエンド サービスを作成します。

    gcloud alpha compute backend-services create my-other-backend-service \
        --global \
        --protocol TCP \
        --health-checks my-tcp-health-check \
        --port-name tcp110
    

     Created [https://www.googleapis.com/compute/alpha/projects/[PROJECT_ID]/global/backendServices/my-other-backend-service].
     NAME                     BACKENDS PROTOCOL
     my-other-backend-service          TCP

  2. 新しいバックエンドで TCP プロキシを指示します。

    gcloud alpha compute target-tcp-proxies update my-target-tcp-proxy --backend-service my-other-backend-service
    

    Updated [https://www.googleapis.com/compute/alpha/projects/[PROJECT_ID]/global/targetTcpProxies/my-target-tcp-proxy].

  3. このバックエンド サービスにはインスタンスが含まれていないため、この時点でプロキシを使用しようとしても、ウェブページは取得できません。テストを続行するには、最初のバックエンド サービスで TCP プロキシを指示し直します。

    gcloud alpha compute target-tcp-proxies update my-target-tcp-proxy --backend-service my-backend-service
    

    Updated [https://www.googleapis.com/compute/alpha/projects/[PROJECT_ID]/global/targetTcpProxies/my-target-tcp-proxy].

プロキシの PROXY プロトコル ヘッダーの更新

このコマンドを使用して、既存のターゲット TCP プロキシの PROXY プロトコル ヘッダーを変更します。

gcloud alpha compute target-tcp-proxies update my-target-tcp-proxy \
  --proxy-header [NONE | PROXY_V1]
Updated [https://www.googleapis.com/compute/alpha/projects/[PROJECT_ID]/global/targetTcpProxies/my-target-tcp-proxy].

クライアント接続情報を保持するための PROXY プロトコル

TCP プロキシを使用した Google Cloud Load Balancing では、クライアントからの TCP 接続が停止され、インスタンスへの新しい接続が作成されるため、デフォルトで元のクライアント IP とポート情報は保持されません。

この情報を保持し、インスタンスに送信する必要がある場合、PROXY プロトコル(バージョン 1)を有効にする必要があります。この場合、ソース IP アドレス、宛先 IP アドレス、およびポート番号などの元の接続情報を含むヘッダーがさらに追加され、リクエストの一部としてインスタンスに送信されます。

ユーザー トラフィックにこのパラメータを設定する場合、同じポートでトラフィックを処理し、ヘルスチェックを行うときは、ヘルスチェックに対しても設定する必要があります。

一般に、PROXY プロトコル ヘッダーはユーザーが読み取れる単一の行であり、次のような形式になります。

PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n

PROXY プロトコルの例を以下に示します。

PROXY TCP4 192.0.2.1 198.51.100.1 15221 110\r\n

この例の場合、クライアント IP は 192.0.2.1、負荷分散 IP は 198.51.100.1、クライアント ポートは 15221、宛先ポートは 110 です。

クライアント IP が不明な場合、ロードバランサは次の形式で PROXY プロトコル ヘッダーを生成します。

PROXY UNKNOWN\r\n

ヘルスチェック

ヘルスチェックでは、どのインスタンスが新しい接続を受け取れるかが判別されます。ヘルス チェッカーは指定された間隔でインスタンスをプローブします。指定された回数続けてプローブに対するレスポンスに失敗したインスタンスには UNHEALTHY のマークが付けられます。そのインスタンスには新しい接続は送信されませんが、既存の接続は継続できます。ヘルス チェッカーは異常なインスタンスのポーリングを続けます。インスタンスが指定された回数続けてプローブへのレスポンスに成功すると、そのインスタンスには再度 HEALTHY のマークが付けられ、新しい接続を受け取れるようになります。

SSL または TCP ヘルスチェックのいずれかを設定して、バックエンド インスタンスの正常性を判別できます。ロードバランサとインスタンスの間に SSL を使用している場合、SSL ヘルスチェックを使用します。ロードバランサとインスタンスの間にプレーンな TCP を使用している場合、TCP ヘルスチェックを使用します。設定が完了すると、設定されたインスタンス グループ内のすべてのインスタンスに、指定されたポートを使用して一定の間隔で、ヘルスチェックのプローブが送信されます。

ヘルスチェックのタイプを SSL に設定すると、各インスタンスに SSL 接続が開かれます。ヘルスチェックをのタイプを TCP に設定すると、TCP 接続が開かれます。ヘルスチェック自体は、次のいずれかのチェックを使用できます。

  • 単純なハンドシェークによるヘルスチェック(デフォルト): ヘルス チェッカーは単純な TCP または SSL ハンドシェークを試みます。成功すると、インスタンスはプローブのラウンドに合格します。
  • リクエスト / レスポンスによるヘルスチェック: TCP ハンドシェークまたは SSL ハンドシェークの完了後にヘルス チェッカーが送信するリクエスト ストリングを指定します。設定したレスポンス ストリングを返した場合、そのインスタンスはプローブのラウンドに合格します。リクエスト ストリングとレスポンス ストリングには、いずれも最大で 1,024 バイトを使用できます。

新しいインスタンスで、指定した回数続けて(デフォルトは 2 回)プローブが成功すると、そのインスタンスには HEALTHY のマークが付けられます。HEALTHY のインスタンスで、指定した回数続けて(デフォルトで 2 回)プローブに失敗すると、そのインスタンスには UNHEALTHY のマークが付けられます。指定した回数続けて(デフォルトで 2 回)プローブにもう一度成功すると、そのインスタンスには再度 HEALTHY のマークが付けられます。ヘルスチェックに失敗したインスタンス上でも、既存の接続は続行できます。

ユーザー トラフィック用に PROXY プロトコルを設定した場合、ヘルスチェック用にも設定する必要があります。

ヘルスチェックの作成

gcloud compute health-checks create [tcp | ssl] my-tcp-health-check \
    [--port PORT ]  \
    ...other options

ロードバランサとインスタンスの間のトラフィックを暗号化している場合、SSL ヘルスチェックを使用します。トラフィックが暗号化されていない場合、TCP ヘルスチェックを使用します。

ヘルスチェックの create オプション

  • --check-interval [CHECK_INTERVAL]; default=5s
    インスタンスにヘルスチェックのプローブを送信する頻度。たとえば、10s に設定すると、プローブは 10 秒ごとに送信されます。このフラグには、秒には s、分には m の単位を使用できます。
  • --description [DESCRIPTION]
    ヘルスチェックの説明(省略可)。文字列にスペースが含まれる場合は引用符で囲む必要があります。
  • --healthy-threshold [HEALTHY_THRESHOLD]; default=2
    ヘルスチェックのプローブが連続して成功する必要がある回数。この回数を満たさなければ、異常なインスタンスに HEALTHY のマークが付けられます。
  • --port [PORT]; default=80(TCP の場合)、443(SSL の場合)
    このヘルスチェックがモニタリングする TCP ポート番号。
  • --request
    ヘルス チェッカーがインスタンスに送信できる、最大で 1024 文字の任意の文字列。ヘルス チェッカーは、--response フィールドに指定されたストリングのインスタンスからレスポンスを探します。--response が設定されていない場合、ヘルス チェッカーはレスポンスを待機せず、TCP または SSL ハンドシェークが成功すると、プローブは成功したとみなします。
  • --response
    ヘルス チェッカーがインスタンスから受け取ることを期待する、最大で 1024 文字の任意の文字列。レスポンスが正確に受け取られなければ、ヘルスチェックのプローブは失敗します。--response は設定されているが --request は設定されていない場合、ヘルス チェッカーはレスポンスを待機します。ハンドシェークが成功した場合のレスポンスとして、システムによって自動的になんらかのメッセージが送信される場合以外は、必ず --response--request と明確に一致するように設定します。
  • --timeout [TIMEOUT]; default=5s
    この期間内にヘルス チェッカーがインスタンスから有効なレスポンスを受け取らなければ、プローブは失敗したとみなされます。たとえば、10s を指定すると、チェッカーは 10 秒間待ってからプローブが失敗したとみなします。このフラグには、秒には s、分には m の単位を使用できます。
  • --unhealthy-threshold [UNHEALTHY_THRESHOLD]; default=2
    ヘルスチェックのプローブが連続して失敗する回数。この値に達すると、正常なインスタンスに UNHEALTHY のマークが付けられます。
  • --proxy-header [NONE | PROXY_V1]
    ヘルスチェックに対してプロキシ プロトコル ヘッダーをアクティブ化できます。正常性をチェックし、同じポートでコンテンツを提供している場合、ロードバランサの設定と一致するようにヘルスチェックの --proxy-header を設定できます。別のポートを使用している場合、必要に応じて、これをヘルスチェック用に設定しても、しなくてもかまいません。

ヘルスチェックの一覧表示

現在のプロジェクト内のすべてのヘルスチェックを一覧表示します。

gcloud compute health-checks list
NAME                PROTOCOL
my-tcp-health-check TCP

ヘルスチェックの記述

特定のヘルスチェックに関する詳細情報を提供します。

gcloud compute health-checks describe my-tcp-health-check
checkIntervalSec: 5
creationTimestamp: '2016-02-20T20:47:26.034-08:00'
description: ''
healthyThreshold: 2
id: '1423984233044836273'
kind: compute#healthCheck
name: my-tcp-health-check
selfLink: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks/my-tcp-health-check
tcpHealthCheck:
  port: 110
timeoutSec: 5
type: TCP
unhealthyThreshold: 2

ヘルスチェックの更新

ヘルスチェックでパラメータを変更するには、次のコマンドを実行し、いずれかの create パラメータで渡します。指定したすべてのパラメータが変更されます。指定されていないパラメータは、同じまま変化しません。

gcloud compute health-checks [tcp|ssl] update
    [--options]

例:

gcloud compute health-checks update tcp my-tcp-health-check \
    --description "TCP health check"
Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks/my-tcp-health-check].

接続ドレイン

バックエンド サービスで接続ドレインを有効にすると、トラフィックを処理しているインスタンスが停止されたり、手動で削除されたり、自動スケーラ-によって削除されたりした場合に、ユーザーに対する中断を最小限に抑えることができます。接続ドレインの詳細については、接続ドレインの有効化を参照してください。

推奨

  • クライアントの接続情報を保持する必要がある場合、PROXY プロトコル バージョン 1 ヘッダーを先頭に追加してロードバランサを構成する必要があります。

トラブルシューティング

ロードバランサの IP からページをロードできない

多くのブラウザでポート 110 は制限されたポートであるため、curl などのツールを使用してロードバランサをテストする必要があります。curl を介してページに到達できない場合、このセクションの残りの部分でトラブルシューティングの手順を確認してください。

インスタンスの正常性の確認

インスタンスが HEALTHY であることを確認します。

gcloud compute backend-services get-health my-backend-service
---
backend: https://www.googleapis.com/resourceviews/v1beta1/projects/[PROJECT_ID]/zones/us-central1-b/resourceViews/us-ig1
status:
  kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/zones/us-east1-b/instanceGroups/us-ig2
status:
  kind: compute#backendServiceGroupHealth

ファイアウォール ルールが正しいことの確認

  • ヘルス チェッカーとロードバランサの両方で 130.211.0.0/2235.191.0.0/16 が開いている必要があります。
  • たとえば、tcp:110 はファイアウォールで 130.211.0.0/22 と 35.191.0.0/16 から許可されている必要があります。
  • インスタンス タグを使用している場合、ファイアウォール ルールでそのタグが TARGET_TAGS としてリストにあることを確認し、すべてのインスタンスにそのタグがあることを確認します。この例では、インスタンスには tcp-lb のタグが付けられています。

    gcloud compute firewall-rules list

    NAME                      NETWORK SRC_RANGES                    RULES          SRC_TAGS TARGET_TAGS
    allow-tcplb-and-health    default 130.211.0.0/22,35.191.0.0/16  tcp:110                 tcp-lb

各インスタンスに到達可能なことの確認

インスタンスに個別にアクセスできるファイアウォール ルールを一時的に設定し、特定のインスタンスからページをロードできるか試してみます。

  1. ファイアウォールを開いて、ソースからタグ付けされたインスタンスへのトラフィックを許可します。

    gcloud compute firewall-rules create allow-tcp110-0-0-0-0   \
      --source-ranges 0.0.0.0/0   \
      --target-tags tcp-lb    \
      --allow tcp:110
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-tcp110-0-0-0-0].
    NAME                 NETWORK SRC_RANGES RULES   SRC_TAGS TARGET_TAGS
    allow-tcp110-0-0-0-0 default 0.0.0.0/0  tcp:110          tcp-lb

  2. いずれかのインスタンスの EXTERNAL_IP アドレスを見つけます。

    gcloud compute instances list
    

    NAME             ZONE           MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
    ig-us-central1-1 us-central1-b  n1-standard-1             10.240.0.8  EXTERNAL_IP RUNNING
    ig-us-central1-2 us-central1-b  n1-standard-1             10.240.0.11 EXTERNAL_IP RUNNING
    ig-us-east1-1    us-east1-b     n1-standard-1             10.240.0.12 EXTERNAL_IP RUNNING
    ig-us-east1-2    us-east1-b     n1-standard-1             10.240.0.13 EXTERNAL_IP RUNNING

  3. 次に、ブラウザから直接 1 つ以上のインスタンスにアクセスします。

    https://[EXTERNAL_IP]
    
  4. この方法でインスタンスにアクセスできない場合、ソフトウェアが正しく実行されているか確認します。正しく実行されている場合、ロードバランサのファイアウォールが正しいか確認します。

    gcloud compute firewall-rules describe allow-tcp110-130-211-0-0-22
    

    allowed:
    - IPProtocol: tcp
      ports:
      - '110'
    creationTimestamp: '2016-02-20T22:27:15.094-08:00'
    description: ''
    id: '5304629236729177644'
    kind: compute#firewall
    name: allow-tcp110-130-211-0-0-22
    network: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/default
    selfLink: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-tcp110-130-211-0-0-22
    sourceRanges:
    - 130.211.0.0/110
    targetTags:
    - tcp-lb

  5. インスタンスが機能していることを確認したら、「from anywhere」ファイアウォールを削除します。

    gcloud compute firewall-rules delete allow-tcp110-0-0-0-0
    

    The following firewalls will be deleted:
     - [allow-tcp110-0-0-0-0]

    Do you want to continue (Y/n)? y

    Deleted [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-tcp110-0-0-0-0].

よくある質問

TCP プロキシ負荷分散ではなく HTTP(S)負荷分散を使用する必要があるのはどのような場合ですか?

TCP プロキシでも HTTP(S)トラフィックを処理できますが、大部分の場合に選択したほうがよい追加機能が HTTP(S)負荷分散には備わっています。

HTTP(S)負荷分散には、次の追加機能が備わっています。

  • HTTP/2 と SPDY/3.1 をネゴシエーションします。
  • 無効な HTTP リクエストまたはレスポンスを拒否します。
  • URL ホストおよびパスに基づいて、別のインスタンス グループにリクエストを転送します。
  • Cloud CDN と統合します。
  • インスタンス間でリクエストの負荷をより均等に分散し、インスタンスをより効率的に使用できます。HTTPS では各リクエストは別個に負荷分散されますが、TCP プロキシでは同じ接続からのすべてのバイトが同じインスタンスに送信されます。

グローバル負荷分散層への接続の元の IP アドレスを表示できますか?

はい。PROXY プロトコル バージョン 1 ヘッダーを先頭に付けて、元の接続情報が維持されるようにロードバランサを設定できます。詳細については、プロキシの PROXY プロトコル ヘッダーの更新を参照してください。

外出先でもリソースをモニタリング

Google Cloud Console アプリを入手して、プロジェクトの管理にお役立てください。

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

Compute Engine ドキュメント