内部不可分散の設定

内部負荷分散によって、Virtual Private Cloud(VPC)の内部インスタンスのみが利用できるプライベート負荷分散 IP アドレスの背後でサービスを実行し、スケールすることができるようになります。

内部負荷分散の概要については、5 分でわかる内部負荷分散をご覧ください。

概要

Google Cloud Platform(GCP)で、TCP/UDP トラフィックの内部負荷分散を行うようになりました。内部負荷分散により、内部インスタンスのみが利用できるプライベート負荷分散 IP アドレスの背後でサービスを実行し、拡張することが可能になります。

内部負荷分散の導入以前は、次の 2 つの方法で負荷分散を行っていました。

  • 方法 1: 外部 IP アドレスを設定し、仮想マシンへのアクセスを制限して、自分のインスタンスのみが設定した外部 IP アドレスにアクセスできるようにします。この方法では、設定が複雑でした。
  • 方法 2: 内部 IP を使用してプロキシ インスタンスを設定し、バックエンドへのリクエストを仲介します。この方法では設定と管理が複雑でした。さらに、プロキシ インスタンスの帯域幅と容量によってスループットが制限されていました。この回避策には、マネージド負荷分散サービスのすべての利点が欠けていました。

内部負荷分散を使用すると、プライベート バックエンド インスタンスをフロントエンドとして機能するように、内部負荷分散 IP を設定できます。負荷分散サービスにパブリック IP は不要となりました。内部クライアント リクエストは、VPC ネットワークとリージョンの内部に留まり、レイテンシが抑えられる可能性があります。これは、負荷が分散されたトラフィックが Google のネットワーク内に留まるためです。全体として、設定が単純になります。

内部負荷分散は、自動モードの VPC ネットワーク、カスタムモードの VPC ネットワーク、レガシー ネットワークで機能します。

このユーザーガイドの残りの部分では、TCP/UDP 向けの内部負荷分散の機能と設定について説明します。

内部負荷分散について

内部負荷分散によって、従来の 3 層ウェブサービスのようなユースケースをサポートできるようになりました。このウェブ階層では、外部 HTTP(S) 負荷分散または外部 TCP/UDP 負荷分散が使用され、アプリケーション階層またはバックエンド データベースを実行しているインスタンスが内部負荷分散の背後にデプロイされています。

HTTP(S) 負荷分散と内部負荷分散を使用した 3 層のウェブアプリ(クリックして拡大)
HTTP(S) 負荷分散と内部負荷分散を使用した 3 層のウェブアプリ(クリックして拡大)

内部負荷分散を使用すると、次の操作が可能になります。

  • プライベート フロントエンド IP を使用した TCP/UDP トラフィックの負荷分散
    • VPC ネットワーク内から内部負荷分散 IP を設定できます。
  • リージョン内のインスタンスにまたがる負荷分散
    • 同じリージョン内にある利用可能な複数のゾーンで、インスタンスをインスタンス化できます。
  • バックエンド用ヘルスチェックの設定
    • バックエンド インスタンスのヘルスチェックは GCP ヘルスチェック システムによって実施されます。
    • TCP、SSL(TLS)、HTTP、HTTPS のいずれかのヘルスチェックを設定できます。
  • クライアント トラフィックを処理するために必要に応じてスケールするフルマネージド負荷分散サービスのあらゆるメリットを活用します。
    • ロードバランサが利用できるかどうか、またはロードバランサが問題となるかどうかを気にする必要がなくなります。

アーキテクチャ

内部負荷分散は、プロキシなど、さまざまな方法で実装できます。

下記の図の左側で示す内部負荷分散の従来のプロキシモデルでは、負荷分散デバイスまたはインスタンスに内部 IP を設定し、この IP にクライアント インスタンスが接続します。この IP が受信するトラフィックはロードバランサで終了します。ロードバランサはバックエンドを選択し、ここに新たな接続を確立します。これで、クライアント <-> ロードバランサと、ロードバランサ <-> バックエンドという 2 つの接続が設定されます。

TCP/UDP アーキテクチャ用の内部負荷分散(クリックして拡大)
TCP/UDP アーキテクチャ用の内部負荷分散(クリックして拡大)

GCP 内部負荷分散は、右のように、異なる方法でクライアント インスタンス リクエストをバックエンドに分散します。これは Andromeda ネットワーク仮想化スタックを基盤とした軽量の負荷分散を採用し、ソフトウェアで定義された負荷分散により、クライアント インスタンスからバックエンド インスタンスにトラフィックを直接配信しています。

内部負荷分散は、デバイスまたはインスタンス ベースのソリューションではなく、ソフトウェアで定義された完全分散型の負荷分散です。

内部負荷分散のデプロイ

内部負荷分散によって、プライベート RFC1918 アドレスを負荷分散 IP に設定し、この負荷分散 IP に対してクライアント インスタンスから発生するリクエストを処理するように、バックエンド インスタンス グループを設定します。

バックエンド インスタンス グループはゾーンの範囲内にあり、可用性の要件を満たす複数のゾーンにインスタンス グループを設定できます。すべてのインスタンスは同じネットワークとリージョンに属している必要がありますが、サブネットは別でもかまいません。内部負荷分散 IP にトラフィックを送信するクライアント インスタンスは、負荷分散 IP やバックエンドと同じ VPC ネットワークとリージョンに存在する必要がありますが、サブネットは異なっていてもかまいません。

内部負荷分散のデプロイの例を下に示します。

内部負荷分散のデプロイ(クリックして拡大)
内部負荷分散のデプロイ(クリックして拡大)

上の例では、us-central リージョンに単一サブネット A(10.10.0.0/16)で my-internal-app という VPC ネットワークを構成しています。2 つのバックエンド インスタンスで 2 つのゾーンにまたがる可用性を提供しています。同じ VPC ネットワークの負荷分散 IP(転送ルール IP)の 10.10.10.1 が選択されています。my-internal-app ネットワーク内の 10.10.100.2 インスタンスから、負荷分散 IP 10.10.10.1 にリクエストが送信されます。このリクエストにより、インスタンス グループ IG1 と IG2 のいずれかに含まれるインスタンスに負荷が分散されます。

以下では、上のデプロイの設定について詳しく説明します。

負荷分散の IP アドレス

内部負荷分散を使用すると、負荷分散 IP は RFC1918 プライベート アドレスになります。

内部ロードバランサの IP アドレス(転送ルール IP)は次のいずれかの方法で割り当てられます。

  • 内部負荷分散 IP を選択する

    転送ルールが負荷分散 IP に関連付けられているリージョンから、割り当てられていない IP アドレスを指定できます。この IP アドレスは、VPC ネットワーク全体の一部であるリージョンのどのサブネットからも取得できます。レガシー ネットワークに内部負荷分散を設定している場合は、そのネットワーク内の未使用の IP が割り当てられます。

    内部負荷分散のベータ版では、VPC ネットワーク / サブネットのすべての既存 IP アドレスと他の転送ルール IP アドレスをリストすることで、使用中の IP を手動で判別する必要があります。

    転送ルール用の IP アドレスを選択して指定すると、転送ルールが存在している限り、アドレスの割り当てが継続します。転送ルールが削除されると、この IP アドレスは VPC ネットワークで利用可能な IP のプールに戻され、インスタンスや別の転送ルールに割り当てることができます。

  • 負荷分散によってフロントエンド IP を自動的に割り当てる

    IP アドレスを指定せずに転送ルールを作成して、IP を自動的に割り当てることができます。この場合、GCP に関連付けられている VPC ネットワーク / サブネットから、割り当てられていない内部 IP アドレスを転送ルールに割り当てます。転送ルールが存在している限り、IP アドレスが割り当てられたままとなります。

内部負荷分散の選択アルゴリズム

クライアントのバックエンド インスタンスは、インスタンスの正常性を考慮したハッシュ アルゴリズムを使用して選択されます。

デフォルトでは、ロードバランサは、次の 5 つのハッシュ用パラメータを使用する 5 タプルハッシュによって、クライアントからの接続をバックエンド インスタンスに送信します。

  • クライアント送信元 IP
  • クライアント ポート
  • 宛先 IP(負荷分散 IP)
  • 宛先ポート
  • プロトコル(TCP または UDP)

ロードバランサでクライアントからのすべてのトラフィックが特定のバックエンド インスタンスに送信されるようにする場合には、セッション アフィニティに次のいずれかのオプションを使用してください。

  • 3 タプル(クライアント IP、宛先 IP、プロトコル)に基づくハッシュ
  • 2 タプル(クライアント IP、宛先 IP)基づくハッシュ

これらのオプションの詳細は、セッション アフィニティ セクションで説明します。

セッション アフィニティ

選択アルゴリズムのセクションで説明したように、クライアントからの接続は、デフォルトでは 5 タプルハッシュを使用してすべてのバックエンド インスタンスにまたがって負荷分散されます。5 タプルハッシュは、クライアント送信元 IP、クライアント ポート、宛先 IP(負荷分散 IP)、宛先ポート、プロトコル(TCP または UDP)を使用します。

ただし、ウェブ アプリケーションがインスタンスでローカルに状態を保存し、クライアントからのすべてのトラフィックの負荷を同じバックエンド インスタンスに分散する必要がある場合などでは、クライアント インスタンスからのすべてのトラフィックの負荷を同じバックエンド インスタンスに分散できます。この機能が用意されていないと、トラフィックが失敗するか、サービスが最適化されないことがあります。

内部負荷分散では、アフィニティ機能を有効にすることでクライアントのすべてのトラフィックを特定のバックエンド インスタンスに所属させることができます。

次のタイプのアフィニティを有効にできます。

  • 3 タプル(client_ip_proto)(クライアント IP、宛先 IP、プロトコル)に基づくハッシュ
    • 上記の 3 つのパラメータのハッシュに基づいて、クライアントのすべてのトラフィックを同じバックエンド インスタンスに振り向ける場合は、このアフィニティを使用します。
  • 2 タプル(client_ip)(クライアント IP、宛先 IP)基づくハッシュ
    • 上記の 2 つのパラメータのハッシュに基づいて、クライアントのすべてのトラフィックを同じバックエンド インスタンスに振り向ける場合は、このアフィニティを使用します。

一般的に、3 タプル アフィニティまたは 2 タプル アフィニティを有効にすると、クライアント トラフィックの負荷は同じバックエンドに分散されますが、トラフィック全体はデフォルトの 5 タプルハッシュと同じように均等に分散されない可能性があります。通常、正常な状態が維持されている限り、特定の接続は同じバックエンド インスタンス上で維持されます。

ヘルスチェック

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

内部負荷分散は次の 4 種類のヘルスチェックをサポートします。

  • TCP ヘルスチェック
  • SSL(TLS)ヘルスチェック
  • HTTP ヘルスチェック
  • HTTPS ヘルスチェック

トラフィックが HTTP(S) の場合、HTTP(S) ヘルスチェックによって、インスタンスが正常であることを確認するだけでなく、ウェブサーバーが稼働中でトラフィックを提供していることも確認されるため、最高のフィデリティ チェックが実現します。トラフィックが HTTPS ではなく、SSL(TLS)を経由して暗号化される場合、SSL ヘルスチェックを設定します。HTTP(S) または SSL(TLS)以外のすべてのトラフィックでは、TCP ヘルスチェックを設定できます。

ヘルスチェックが合格とみなされるためには、インスタンスがコード 200 の有効な HTTP レスポンスを返し、設定時間以内に接続を正常に閉じる必要があります。ヘルスチェックが指定された回数続けてこれを実行すると、そのインスタンスに対してステータス HEALTHY が戻されます。インスタンスが指定された回数のヘルスチェックに失敗した場合、そのインスタンスには UNHEALTHY のマークが付けられ、通知が送信されることはありません。UNHEALTHY インスタンスは新しい接続を受信しませんが、既存の接続は継続されます。その後、インスタンスがヘルスチェックに合格する(指定された回数のヘルスチェックのプローブに正常に応答する)と、インスタンスは通知なしに新しい接続の受信を開始します。

ヘルスチェックのタイプを SSL に設定すると、各インスタンスで SSL 接続が開始します。ヘルスチェックのタイプを TCP に設定すると、TCP 接続が開始します。どちらの場合も、ハンドシェークに成功すると、ヘルスチェックによるプローブは成功したとみなされます。指定された回数のプローブに成功すると、ヘルスチェックに合格し、指定された回数のハンドシェークに続けて失敗すると、ヘルスチェックに失敗します。ヘルスチェックに失敗したインスタンス上でも既存の接続は継続されます。TCP または SSL のヘルスチェックによるプローブでは、次のチェックのいずれかを使用します。

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

高可用性

内部負荷分散は完全に管理された Google Cloud Platform サービスです。ロードバランサ自体の高可用性を維持するために、特別な設定を行う必要はありません。これは、クライアント トラフィックの処理で必要に応じてスケールする完全分散型のサービスです。制限については、制限のセクションに説明されています。

複数のインスタンス グループを設定してサービスの高可用性を実現します。インスタンス グループはゾーンの範囲内にあるため、単一のゾーン内でのインスタンス障害を防ぐため、インスタンス グループを複数のゾーンに設定できます。

複数のインスタンス グループを設定すると、これらのすべてのインスタンス グループ内のインスタンスは 1 つのプールのインスタンスとして処理されます。内部負荷分散は、内部負荷分散の選択アルゴリズムに記載されているハッシュ アルゴリズムを使用して、このグループの正常なインスタンスにまたがるユーザー リクエストを分散します。

HA の複数のゾーン内のインスタンス グループ(クリックして拡大)
HA の複数のゾーン内のインスタンス グループ(クリックして拡大)

実質的には、負荷分散をデプロイしたリージョンの 1 つ以上のゾーンにまたがる 1 つのラージプールで論理構成されるものとしてデプロイを捉えることができます。

上の図では、すべてのインスタンスが正常で、クライアント インスタンスの負荷がインスタンス 1、2、3、4 で構成されるプールに分散されています。

内部負荷分散の設定

内部負荷分散の設定(クリックして拡大)
内部負荷分散の設定(クリックして拡大)

内部負荷分散の設定は複数のコンポーネントで構成されています。これらのコンポーネントはすべて、同じ VPC ネットワークとリージョンに属している必要があります。トラフィックを起点とするクライアント インスタンスは、負荷分散転送ルール IP、バックエンド サービス、インスタンス グループと同じこれらのコンポーネントはすべて、同じ VPC ネットワークとリージョンに属している必要があります。ネットワークとリージョンに属している必要があります。これらのクライアント インスタンスは、負荷分散インスタンスと同じサブネットに属している必要がありません。

上の例では、テスト用に内部負荷分散を設定しています。

以下を設定します。

  1. 同じリージョンの 2 つのゾーンに分散している 4 つのインスタンス
  2. インスタンスを保持するインスタンス グループ
  3. バックエンド コンポーネント。次のものが含まれます。
    • ヘルスチェック - インスタンスの正常性をモニタリングします。
    • バックエンド サービス - インスタンス グループをモニタリングし、設定の超過を防止します。
    • バックエンド - インスタンス グループを保持します。
  4. ユーザー トラフィックをプロキシに送信する転送ルールと内部 IP アドレス
  5. ロードバランサの IP アドレス範囲からのトラフィックを許可するファイアウォール ルール
  6. ロードバランサのテストに使用するスタンドアロンのクライアント インスタンス

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

テスト環境の設定

次のセクションでは、テスト環境のコンポーネントを作成する方法について説明します。

VPC ネットワークとサブネットの設定

内部負荷分散は、自動モードの VPC ネットワーク、カスタムモードの VPC ネットワーク、レガシー ネットワークで機能します。この例では、カスタムモードの VPC ネットワークを使用します。

Console


  1. Google API Console で [VPC ネットワーク] ページに移動します。
    [VPC ネットワーク] ページに移動
  2. [VPC ネットワークを作成] をクリックします。
  3. [名前] に「my-custom-network」と入力します。
  4. [サブネット] の [名前] に「my-custom-subnet」と入力します。
  5. [リージョン] に us-central1 を設定します。
  6. [IP アドレス範囲] に「10.128.0.0/20」と入力します。
  7. [作成] をクリックします。

gcloud


カスタム VPC ネットワークの作成

gcloud compute networks create my-custom-network --mode custom

Created     [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/my-custom-network].
NAME               MODE    IPV4_RANGE  GATEWAY_IPV4
my-custom-network  custom

カスタム VPC ネットワークでの新しいサブネットの作成

gcloud compute networks subnets create my-custom-subnet \
    --network my-custom-network \
    --range 10.128.0.0/20 \
    --region us-central1

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/subnetworks/my-custom-subnet].
NAME              REGION       NETWORK            RANGE
my-custom-subnet  us-central1  my-custom-network  10.128.0.0/20

  • my-custom-network - VPC 作成するネットワークの名前。
  • my-custom-subnet - 作成するサブネットの名前。
  • 10.128.0.0/20 - 範囲には、同じネットワークで他の範囲と重ならない有効な RFC1918 範囲を指定する必要があります。既存の VPC ネットワークにサブネットを作成している場合は、別の範囲の選択が必要になることがあります。

ファイアウォール ルールの設定

ファイアウォール ルールを作成するまで、この VPC ネットワークのインスタンスには接続できません。たとえば、インスタンス間のすべての内部トラフィックを許可し、送信元に関係なく、SSH、RDP、ICMP トラフィックを許可できます。

Console


サブネット内のすべてのトラフィックを許可するファイアウォール ルールの作成

  1. Google API Console で [ファイアウォール ルール] ページに移動します。
    [ファイアウォール ルール] ページに移動
  2. [ファイアウォール ルールの作成] をクリックします。
  3. [名前] に「allow-all-10-128-0-0-20」と入力します。
  4. [VPC ネットワーク] に my-custom-network を設定します。
  5. [ソースフィルタ] に IP ranges を設定します。
  6. [ソース IP 範囲] に 10.128.0.0/20 を設定します。
  7. [許可対象プロトコルとポート] に tcp;udp;icmp を設定します。
  8. [作成] をクリックします。

任意の場所からの SSH、RDP、ICMP を許可するファイアウォール ルールの作成

  1. [名前] に「allow-tcp22-tcp3389-icmp」と入力して、2 つめのファイアウォール ルールを作成します。
  2. [VPC ネットワーク] に my-custom-network を設定します。
  3. [ソースフィルタ] に Allow from any source (0.0.0.0/0) を設定します。
  4. [許可対象プロトコルとポート] に tcp:22;tcp:3389;icmp を設定します。
  5. [作成] をクリックします。

gcloud


サブネット内のすべてのトラフィックを許可するファイアウォール ルールの作成

gcloud compute firewall-rules create allow-all-10-128-0-0-20 \
    --network my-custom-network \
    --allow tcp,udp,icmp \
    --source-ranges 10.128.0.0/20

任意の場所からの SSH、RDP、ICMP を許可するファイアウォール ルールの作成

gcloud compute firewall-rules create allow-tcp22-tcp3389-icmp \
    --network my-custom-network \
    --allow tcp:22,tcp:3389,icmp

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

通常、本番環境システムではインスタンス テンプレートに基づいてマネージド インスタンス グループが使用されますが、初期テストを行う場合にはこの設定を使用した方が簡単です。

各ゾーンでの 2 つのインスタンスの作成

テスト用に、各インスタンスに Apache をインストールします。これらのインスタンスはすべて int-lb のタグで作成されます。このタグは後でファイアウォール ルールによって使用されます。

4 つのインスタンスの名前は ig-us-central1-1 から ig-us-central1-4 になります。

Console


インスタンスの作成

  1. Google API Console で [VM インスタンス] ページに移動します。
    [VM インスタンス] ページに移動
  2. [インスタンスを作成] をクリックします。
  3. [名前] に ig-us-central1-1 を設定します。
  4. [ゾーン] に us-central1-b を設定します。
  5. [管理、ディスク、ネットワーキング、SSH 認証鍵] をクリックすると、拡張設定が表示されます。
  6. [管理] で、[タグ] フィールドに「int-lb」と入力します。
  7. [起動スクリプト] を次のように設定します。
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-1</h1></body></html>' | sudo tee /var/www/html/index.html
  8. [ネットワーキング] で、[VPC ネットワーク] に my-custom-network を設定し、[サブネット] に my-custom-subnet を設定します。
  9. 残りのフィールドはデフォルト値をそのまま使用します。
  10. [作成] をクリックします。
  11. 同じ設定で ig-us-central1-2 を作成します。ただし、[起動スクリプト] は次のように設定します。
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-2</h1></body></html>' | sudo tee /var/www/html/index.html
  12. 同じ設定で ig-us-central1-3 を作成します。ただし、[ゾーン] には us-central1-c を設定し、[起動スクリプト] は次のように設定します。
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-3</h1></body></html>' | sudo tee /var/www/html/index.html
  13. 同じ設定で ig-us-central1-4 を作成します。ただし、[ゾーン] には us-central1-c を設定し、[起動スクリプト] は次のように設定します。
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-4</h1></body></html>' | sudo tee /var/www/html/index.html

gcloud


gcloud compute instances create ig-us-central1-1 \
    --image-family debian-8 \
    --image-project debian-cloud \
    --tags int-lb \
    --zone us-central1-b \
    --subnet my-custom-subnet \
    --metadata startup-script="#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      service apache2 restart
      echo '<!doctype html><html><body><h1>ig-us-central1-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.128.0.3  23.251.150.133 RUNNING

gcloud compute instances create ig-us-central1-2 \
    --image-family debian-8 \
    --image-project debian-cloud \
    --tags int-lb \
    --zone us-central1-b \
    --subnet my-custom-subnet \
    --metadata startup-script="#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      service apache2 restart
      echo '<!doctype html><html><body><h1>ig-us-central1-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.128.0.11 23.251.148.160 RUNNING

gcloud compute instances create ig-us-central1-3 \
    --image-family debian-8 \
    --image-project debian-cloud \
    --tags int-lb \
    --zone us-central1-c \
    --subnet my-custom-subnet \
    --metadata startup-script="#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      service apache2 restart
      echo '<!doctype html><html><body><h1>ig-us-central1-3</h1></body></html>' | tee /var/www/html/index.html
      EOF"

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

gcloud compute instances create ig-us-central1-4 \
    --image-family debian-8 \
    --image-project debian-cloud \
    --tags int-lb \
    --zone us-central1-c \
    --subnet my-custom-subnet \
    --metadata startup-script="#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      service apache2 restart
      echo '<!doctype html><html><body><h1>ig-us-central1-4</h1></body></html>' | tee /var/www/html/index.html
      EOF"

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

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

Console


  1. Google API Console で [インスタンス グループ] ページに移動します。
    [インスタンス グループ] ページに移動
  2. [インスタンス グループを作成] をクリックします。
  3. [名前] に us-ig1 を設定します。
  4. [ゾーン] に us-central1-b を設定します。
  5. [インスタンスの定義] で [既存のインスタンスを選択] をクリックします。
  6. [VPC ネットワーク] に my-custom-network を設定します。
  7. [サブネット] に my-custom-subnet を設定します。
  8. [VM インスタンス] から ig-us-central1-1ig-us-central1-2 を選択します。
  9. その他の設定はそのまま使用します。
  10. [作成] をクリックします。
  11. 上記のステップを繰り返します(次のように設定します)。
    • 名前: us-ig2
    • ゾーン: us-central1-c
    • インスタンス: ig-us-central1-3ig-us-central1-4
  12. 2 つのインスタンスにそれぞれ 2 つのインスタンス グループが作成されたことを確認してください。

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   ZONE          NETWORK MANAGED INSTANCES
    us-ig1 us-central1-b                 0

  2. 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].

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

    gcloud compute instance-groups unmanaged create us-ig2 \
        --zone us-central1-c
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-c/instanceGroups/us-ig2].
    NAME   ZONE          NETWORK MANAGED INSTANCES
    us-ig2 us-central1-c                  0

  4. ig-us-central1-3ig-us-central1-4us-ig2 に追加します。

    gcloud compute instance-groups unmanaged add-instances us-ig2 \
        --instances ig-us-central1-3,ig-us-central1-4 \
        --zone us-central1-c
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/ig-us-central1-c/instanceGroups/us-ig2].

ロードバランサの設定

Console


ロードバランサの作成とバックエンド サービスの設定

  1. Google API Console で [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. [ロードバランサを作成] をクリックします。
  3. [TCP 負荷分散] で [設定を開始] をクリックします。
  4. [インターネット接続または内部専用] で Only between my VMs を選択します。
  5. [続行] をクリックします。
  6. [名前] に my-int-lb を設定します。

バックエンド サービスの設定

  1. [バックエンドの設定] をクリックします。
  2. バックエンド サービスの [名前] に my-int-lb と表示されます。
  3. [リージョン] に us-central1 を設定します。
  4. [VPC ネットワーク] に my-custom-network を設定します。
  5. [バックエンド] で、インスタンス グループ us-ig1 を選択します。
  6. [バックエンドを追加] をクリックします。
  7. インスタンス グループ us-ig2 を選択します。
  8. [ヘルスチェック] で [ヘルスチェックを作成] を選択します。
    1. ヘルスチェックの [名前] に my-tcp-health-check を設定します。
    2. [プロトコル] に TCP を設定します。
    3. 他の設定はそのままにします。
    4. [保存して次へ] をクリックします。
  9. Google API Console で、[バックエンドの設定] の横に緑色のチェックマークが表示されていることを確認します。表示されていない場合には、上のすべてのステップが完了していることを再度確認してください。

フロントエンド サービスの設定

  1. [フロントエンドの設定] をクリックします。
  2. [サブネット] で、my-custom-subnet を選択します。
  3. [IP アドレス] で Automatic を選択します。
  4. [ポート] に '80' を設定します。
  5. Google API Console で、[フロントエンドの設定] の横に緑色のチェックマークが表示されていることを確認します。表示されていない場合には、上のすべてのステップが完了していることを再度確認してください。

確認と完了

  1. [確認と完了] をクリックします。
  2. 設定を再度確認します。
  3. [作成] をクリックします。

gcloud


ヘルスチェックの作成

gcloud compute health-checks create tcp my-tcp-health-check \
    --port 80

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-int-lb \
    --load-balancing-scheme internal \
    --region us-central1 \
    --health-checks my-tcp-health-check \
    --protocol tcp

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/backendServices/my-int-lb].
NAME               BACKENDS PROTOCOL
my-int-lb          TCP

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

内部負荷分散はセッション アフィニティ設定に基づき、受信接続を展開します。セッション アフィニティが設定されていないと、ロードバランサは、現在の負荷に関係なく、できるだけ均等に使用可能なすべてのインスタンスにまたがって接続を展開します。

gcloud compute backend-services add-backend my-int-lb \
    --instance-group us-ig1 \
    --instance-group-zone us-central1-b \
    --region us-central1

Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/backendServices/my-int-lb].

gcloud compute backend-services add-backend my-int-lb \
    --instance-group us-ig2 \
    --instance-group-zone us-central1-c \
    --region us-central1

Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]//regions/us-central1/backendServices/my-int-lb].

転送ルールの作成

内部ロードバランサにトラフィックを転送するための転送ルールを作成します。このコマンドはロードバランサの IP アドレスを指定しないため、アドレスは自動的に割り当てられます。アドレスを指定する場合は、リージョンと VPC ネットワークから未使用のアドレスを選択して --address フラグを使用して指定します。

gcloud compute forwarding-rules create my-int-lb-forwarding-rule \
    --load-balancing-scheme internal \
    --ports 80 \
    --network my-custom-network \
    --subnet my-custom-subnet \
    --region us-central1 \
    --backend-service my-int-lb

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/forwardingRules/my-int-lb-forwarding-rule].

IPAddress: 10.128.0.6 IPProtocol: TCP backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/backendServices/my-int-lb creationTimestamp: '2016-06-17T12:56:44.843-07:00' description: '' id: '6922319202683054867' kind: compute#forwardingRule loadBalancingScheme: INTERNAL name: my-int-lb-forwarding-rule network: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/my-custom-network ports: - '80' region: us-central1 selfLink: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/forwardingRules/my-int-lb-forwarding-rule subnetwork: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/subnetworks/my-custom-subnet

内部負荷分散を許可するファイアウォール ルールの設定

ロードバランサへのトラフィックと、ロードバランサからインスタンスへのトラフィックを許可するように 1 つのファイアウォール ルールを設定します。ヘルス チェッカーからヘルスチェックのプローブを許可する別のファイアウォール ルールを設定します。

Console


  1. Google API Console で [ファイアウォール ルール] ページに移動します。
    [ファイアウォール ルール] ページに移動
  2. [ファイアウォール ルールの作成] をクリックします。
  3. [名前] に allow-internal-lb を設定します。
  4. [VPC ネットワーク] に my-custom-network を設定します。
  5. [ソースフィルタ] に IP ranges を設定します。
  6. [ソース IP 範囲] に 10.128.0.0/20 を設定します。
  7. [許可対象プロトコルとポート] に tcp:80;tcp:443 を設定します。
  8. [ターゲットタグ] に int-lb を設定します。
  9. [作成] をクリックします。
  10. [ファイアウォール ルールの作成] をクリックします。
  11. [名前] に allow-health-check を設定します。
  12. [VPC ネットワーク] に my-custom-network を設定します。
  13. [ソースフィルタ] に IP ranges を設定します。
  14. [ソース IP 範囲] に 130.211.0.0/2235.191.0.0/16 を設定します。
  15. [許可対象プロトコルとポート] に tcp を設定します。
  16. [ターゲットタグ] に int-lb を設定します。
  17. [作成] をクリックします。

gcloud


gcloud compute firewall-rules create allow-internal-lb \
    --network my-custom-network \
    --source-ranges 10.128.0.0/20 \
    --target-tags int-lb \
    --allow tcp:80,tcp:443

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-internal-lb].
NAME               NETWORK            SRC_RANGES     RULES           SRC_TAGS  TARGET_TAGS
allow-internal-lb  my-custom-network  10.128.0.0/20  tcp:80,tcp:443            int-lb

gcloud compute firewall-rules create allow-health-check \
    --network my-custom-network \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --target-tags int-lb \
    --allow tcp

NAME                NETWORK            SRC_RANGES                    RULES  SRC_TAGS  TARGET_TAGS
allow-health-check  my-custom-network  130.211.0.0/22,35.191.0.0/16  tcp              int-lb

スタンドアロンのクライアント インスタンスの作成

テスト用に、ロードバランサと同じリージョンにスタンドアロンのクライアント インスタンスを作成します。

Console


  1. Google API Console で [VM インスタンス] ページに移動します。
    [VM インスタンス] ページに移動
  2. [インスタンスを作成] をクリックします。
  3. [名前] に standalone-instance-1 を設定します。
  4. [ゾーン] に us-central1-b を設定します。
  5. [管理、ディスク、ネットワーキング、SSH 認証鍵] をクリックすると、拡張設定が表示されます。
  6. [管理] で、[タグ] フィールドに「standalone」と入力します。
  7. [ネットワーキング] で、[VPC ネットワーク] に my-custom-network を設定し、[サブネット] に my-custom-subnet を設定します。
  8. [作成] をクリックします。

gcloud


gcloud compute instances create standalone-instance-1 \
    --image-family debian-8 \
    --image-project debian-cloud \
    --zone us-central1-b \
    --tags standalone \
    --subnet my-custom-subnet

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

スタンドアロンのクライアント インスタンスへの SSH 接続を許可するファイアウォール ルールの作成

Console


  1. Google API Console で [ファイアウォール ルール] ページに移動します。
    [ファイアウォール ルール] ページに移動
  2. [ファイアウォール ルールの作成] をクリックします。
  3. [名前] に「allow-ssh-to-standalone」と入力します。
  4. [VPC ネットワーク] に my-custom-network を設定します。
  5. [ソースフィルタ] に Allow from any source (0.0.0.0/0) を設定します。
  6. [許可対象プロトコルとポート] に tcp:22 を設定します。
  7. [ターゲットタグ] に standalone を設定します。
  8. [作成] をクリックします。

gcloud


gcloud compute firewall-rules create allow-ssh-to-standalone \
    --network my-custom-network \
    --target-tags standalone \
    --allow tcp:22

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-ssh-to-standalone].
NAME                     NETWORK            SRC_RANGES  RULES   SRC_TAGS  TARGET_TAGS
allow-ssh-to-standalone  my-custom-network  0.0.0.0/0   tcp:22            standalone

インスタンスからの外部 IP の設定

インスタンス グループにインスタンスを作成したときに、Apache をダウンロードしてインストールするため、インスタンスに外部 IP を設定する必要がありました。Apache がインストールされ、これらのインスタンスが内部ロードバランサとして機能するので、インターネットにアクセスする必要はなく、インスタンスから外部 IP を削除できます。

Console


  1. Google API Console で [VM インスタンス] ページに移動します。
    [VM インスタンス] ページに移動
  2. ig-us-central1-1 をクリックして、このインスタンスのコンソールに移動します。
  3. [編集] をクリックします。
  4. [外部 IP] に None を設定します。
  5. [保存] をクリックします。
  6. ig-us-central1-2 に同じ操作を繰り返します。
  7. ig-us-central1-3 に同じ操作を繰り返します。
  8. ig-us-central1-4 に同じ操作を繰り返します。

gcloud


gcloud compute instances delete-access-config ig-us-central1-1 \
    --access-config-name external-nat --zone us-central1-b
gcloud compute instances delete-access-config ig-us-central1-2 \
    --access-config-name external-nat --zone us-central1-b
gcloud compute instances delete-access-config ig-us-central1-3 \
    --access-config-name external-nat --zone us-central1-c
gcloud compute instances delete-access-config ig-us-central1-4 \
    --access-config-name external-nat --zone us-central1-c

ロードバランサのテスト

ローカルマシンから、スタンドアロンのクライアント インスタンスに接続します。

gcloud compute --project [PROJECT_ID] ssh --zone us-central1-b standalone-instance-1

curl を使用してロードバランサの内部 IP アドレスにアクセスします。他のインスタンスのレスポンスを確認するまで、このステップを数回繰り返します。

$ curl 10.128.0.6
<!doctype html><html><body><h1>ig-us-central1-2</h1></body></html>
$ curl 10.128.0.6
<!doctype html><html><body><h1>ig-us-central1-1</h1></body></html>
$ curl 10.128.0.6
<!doctype html><html><body><h1>ig-us-central1-4</h1></body></html>
$ curl 10.128.0.6
<!doctype html><html><body><h1>ig-us-central1-4</h1></body></html>

内部負荷分散向けの新しい gcloud コマンド パラメータ

内部負荷分散は、HTTP(S)負荷分散と同じ転送ルール、バックエンド サービス、ヘルスチェックのリソースを使用しますが、新しいコマンド パラメータもいくつか使用されます。このセクションではこの新しいパラメータについてのみ説明します。既存のパラメータについては、gcloud コマンドライン ツールのリファレンスに説明があります。

転送ルール

内部負荷分散では、転送ルールはこのルールと同じリージョンのバックエンド サービスを直接示します。このセクションでは、create コマンドのコンテキスト内の新しいパラメータについて説明します。getlistdescribedelete の各コマンドに変化はありません。他のパラメータの説明については、forwarding-rules gcloud コマンドをご覧ください。

forwarding-rules create の新しいパラメータ

gcloud compute forwarding-rules create NAME \
    --load-balancing-scheme internal \
    [--address] \
    --region \
    [--protocol]
    --ports PORT,[PORT,…] \
    --backend-service NAME \
    [--subnetwork] \
    [--network]
  • --load-balancing-scheme - 内部負荷分散では、このパラメータに internal を指定する必要があります。当初、このパラメータは内部負荷分散でのみサポートされます。
  • --address - 内部ロードバランサのターゲット IP アドレス。負荷分散方式が internal の場合は、転送ルール向けに設定されたサブネットに属する RFC1918 の IP アドレスのみを指定できます。この場合、外部アドレスは使用できません。このパラメータが指定されておらず、負荷分散方式が internal の場合、転送ルール向けの IP アドレスは、転送ルール向けに設定されたサブネットまたはネットワークの内部 IP 範囲から自動的に割り当てられます。
  • --region - 転送ルールが作成されるリージョン。グローバル転送ルールは内部負荷分散ではサポートされていません。
  • --protocol(デフォルト: tcp) - 内部負荷分散が処理するプロトコル(tcp または udp)。
  • --ports - カンマ区切りリストで 1~5 つのポートを指定するパラメータ。これを指定すると、リストされたポートを宛先とするパケットのみが転送されます。
  • --backend-service - 転送ルールに振り向けられたすべてのトラフィックを受信するバックエンド サービス。
  • --subnetwork - この転送ルールが適用されるサブネット。内部負荷分散用に設定する場合、転送ルールの内部 IP アドレスがこのサブネットから割り当てられます。自動サブネットモードのネットワークの場合、サブネットはリージョンから判別できるため、指定を省略できます。カスタム サブネットモードのネットワークの場合は、サブネットを指定する必要があります。内部ロードバランサ用のバックエンドとして設定されたインスタンスは、同じリージョン内の異なるサブネットに属していてもかまいません。
  • --network - この転送ルールが適用されるネットワーク。内部負荷分散用に設定する場合、転送ルールの内部 IP アドレスがこのネットワークから割り当てられます。このフィールドを指定しなかった場合は、デフォルトのネットワークが使用されます。デフォルトのネットワークがない場合には、このフィールドを指定する必要があります。

転送ルールのターゲットの設定

forwarding-rules set-target コマンドによって、転送ルールが振り向けられるバックエンド サービスを変更できます。内部負荷分散では、バックエンド サービスが常に転送ルールのターゲットであり、--backend-service パラメータと --region パラメータを必ず指定する必要があります。

Console


このステップでは、gcloud コマンドライン ツールを使用します。

gcloud


gcloud compute forwarding-rules set-target \
    --region REGION \
    --backend-service NAME

バックエンド サービス

転送ルールはクライアント リクエストをバックエンド サービスに振り向けます。バックエンド サービスはこのクライアント リクエストをバックエンドで正常なインスタンスに送信します。インスタンスを正常であるとみなすには、インスタンスのヘルスチェックに合格している必要があります。

backend-services create の新しいパラメータ

他のパラメータの説明については、backend-services gcloud コマンドをご覧ください。

gcloud compute backend-services create NAME \
    --load-balancing-scheme internal \
    --region \
    --health-checks \
    --protocol \
    [--session-affinity] \
    [--timeout]
  • --load-balancing-scheme internal(必須) - ロードバランサが内部負荷分散または外部負荷分散を実行しているかどうかを指定します。このリリースでサポートされるのは、内部負荷分散のみです。internal の値は必ず指定します。
  • --region(必須) - バックエンド サービスが存在するリージョン。内部負荷分散では、インスタンス、インスタンス グループ、バックエンド サービス、ロードバランサ サービス、クライアント インスタンスは、互いに同じネットワークの同じリージョンに含まれている必要があります。互いに同じゾーンまたはサブネットに含まれている必要はありません。
  • --health-checks(必須) - バックエンド サービスにおいてインスタンスのモニタリングに使用されるヘルスチェックの名前。--health-checks パラメータは必ず指定します。--http-health-checks パラメータと --https-health-checks パラメータはサポート対象外です。
  • --protocol(デフォルト: http) - ロードバランサが処理するプロトコル(tcp または udp)。このパラメータは、転送ルールに指定した --protocol パラメータと一致している必要があります。バックエンド サービスの場合、プロトコルは必須です。デフォルト値は http で、内部負荷分散でサポートされているのは tcpudp だけです。
  • --session-affinity - 指定しなかった場合、同じインスタンスからロードバランサへの新しい接続はバックエンド インスタンスにまたがって均等に分散されます。同じクライアント インスタンスからの接続を、同じバックエンド インスタンス上に設定するには、セッション アフィニティ client_ip または client_ip_proto を指定します。詳しくはセッション アフィニティをご覧ください。
  • --timeout(デフォルト = 30s) - バックエンド インスタンス グループからのレスポンスを待機する秒数を指定します。この秒数を過ぎると、リクエストは失敗とみなされます。

backend-services add-backend コマンドの新しいパラメータ

その他のパラメータの説明については、backend-services add-backend コマンドをご覧ください。

gcloud compute backend-services add-backend [INSTANCE_GROUP] \
    --balancing-mode connection \
    --instance-group-zone \
    --region
  • --balancing-mode - 内部負荷分散にサポートされているのは、CONNECTION の負荷モードのみです。未解決の接続数の合計に基づいて分散されます。インスタンスの使用率およびインスタンスへの現在の接続は考慮されません。受信接続は、現在の負荷に関係なく、できるだけ均等に使用可能なすべてのインスタンスにまたがって展開されます。確立済みの接続は、新しい受信接続に関係なく、同じインスタンスに留まります。--max-rate パラメータと --max-rate-per-instance パラメータは内部負荷分散でサポートされません。
  • --instance-group-zone - バックエンドに関連付けるインスタンス グループのゾーン。
  • --region - バックエンドのリージョンを指定する必要があります。これは、内部ロードバランサ コンポーネントの他の部分と同じリージョンにします。
  • 次のパラメータは、内部負荷分散で使用できません。
    • --capacity-scaler
    • --max-rate
    • --max-rate-per-instance
    • --max-utilization

注: getlistdescriberemove-backenddelete の各コマンドは対応するリージョンのバックエンド サービスに対して使用されるときに追加の --regions フラグを設定します。

バックエンド サービスの接続ドレイン

バックエンド サービスで接続ドレインを有効にすると、インスタンス グループからインスタンスが手動で削除されたり、オートスケーラーによって削除されたりした場合に、ユーザーに対する中断を最小限に抑えることができます。接続ドレインを使用できるのは、TCP 接続に限られます。接続ドレインは UDP トラフィックではサポートされていません。接続ドレインの詳細については、接続ドレインの有効化を参照してください。

ヘルスチェック

ヘルスチェックでは、どのインスタンスが新しい接続を受け取れるかが判別されます。ヘルス チェッカーは指定された間隔でインスタンスをプローブします。指定された回数続けてプローブに対するレスポンスに失敗したインスタンスには UNHEALTHY のマークが付けられます。ヘルスチェックのタイプは、TCP、SSL、HTTP、HTTPS のいずれかとなります。

インスタンスの正常性を判別するために、TCP、SSL、HTTP、HTTP ヘルスチェックを設定できます。

  • バックエンド インスタンスで実行されているサービスが HTTP に基づく場合は、HTTP ヘルスチェックを使用します
  • バックエンド インスタンスで実行されているサービスが HTTPS に基づく場合は、HTTPS ヘルスチェックを使用します
  • バックエンド インスタンスで実行されているサービスが SSL を使用している場合は、SSL ヘルスチェックを使用します
  • 別の種類のヘルスチェックを使用する明白な理由がない限り、TCP ヘルスチェックを使用します

設定が完了すると、設定されたインスタンス グループ内のすべてのインスタンスに対して指定されたポートに、定期的にヘルスチェックのプローブが送信されます。

ヘルスチェックの仕組みについて詳しくは、ヘルスチェックをご覧ください。

Health-checks create パラメータ

gcloud compute health-checks create [tcp | ssl | http | https] my-health-check \
    ...options

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

  • --check-interval(デフォルト = 5s) - インスタンスにヘルスチェックのプローブを送信する頻度。たとえば、10s に設定すると、プローブは 10 秒ごとに送信されます。このフラグには、秒には s、分には m の単位を使用できます。
  • --healthy-threshold(デフォルト = 2) - ヘルスチェックのプローブが連続して成功する必要がある回数。この回数を満たさなければ、異常なインスタンスに HEALTHY のマークが付けられます。
  • --port(デフォルト = 80(TCP と HTTP の場合)、443(SSL と HTTPS の場合)) - このヘルスチェックがモニタリングする TCP ポート番号。
  • --request - TCP ヘルスチェックと SSL ヘルスチェックでのみ有効です。ヘルス チェッカーがインスタンスに送信できる、最大で 1024 文字の任意の文字列。ヘルス チェッカーは、--response フィールドに指定されたストリングのインスタンスからレスポンスを探します。--response が設定されていない場合、ヘルス チェッカーはレスポンスを待機せず、TCP または SSL ハンドシェークが成功すると、プローブは成功したとみなします。
  • --response - TCP ヘルスチェックと SSL ヘルスチェックでのみ有効です。ヘルス チェッカーがインスタンスから受け取ることを期待する、最大で 1024 文字の任意の文字列。レスポンスが正確に受信されなかった場合、ヘルスチェックのプローブは失敗します。--response は設定されているが --request は設定されていない場合、ヘルス チェッカーはレスポンスを待機します。ハンドシェークが成功した場合のレスポンスとして、システムによって自動的になんらかのメッセージが送信される場合以外は、必ず --response--request と明確に一致するように設定します。
  • --timeout(デフォルト = 5s) - この期間内にヘルス チェッカーがインスタンスから有効なレスポンスを受け取らなければ、プローブは失敗したとみなされます。たとえば、10s に指定すると、チェッカーは 10 秒間待ってからプローブが失敗したとみなします。このフラグには、秒には s、分には m の単位を使用できます。
  • --unhealthy-threshold(デフォルト = 2) - ヘルスチェックのプローブが連続して失敗する回数。この値に達すると、正常なインスタンスに UNHEALTHY のマークが付けられます。

ヘルスチェックのソース IP とファイアウォール ルール

内部負荷分散では、負荷が分散されたインスタンスへのヘルスチェックのプローブは、範囲 130.211.0.0/2235.191.0.0/16 のアドレスから発生します。ファイアウォール ルールで、この接続を許可する必要があります。

このステップの説明は、内部負荷分散を許可するファイアウォール ルールの設定のセクションにあります。

制限事項

  • クライアント インスタンスとバックエンド インスタンスは Google Cloud Platform 上に存在します。オンプレミス(GCP の外部)クライアントから GCP 内の内部ロードバランサへのトラフィックの送信は、このリリースではサポート対象外です。この機能は今後のリリースでサポートされます。
  • 内部ロードバランサ IP は、手動で設定されたルートのネクストホップ IP にはできません。内部ロードバランサの IP をターゲットとするルートを設定していると、そのルートと一致するトラフィックはドロップされます。
  • リージョン マネージド インスタンス グループはサポートされていません。
  • VPN トンネル経由のトラフィックをロードバランサ IP に送信することはできません。

制限事項

個々のネットワークで使用できるロードバランサ転送ルールの数は最大 50 です。* 1 つのロードバランサ転送ルールに使用できるバックエンドの数は最大 250 です。

料金

通常の負荷分散の料金が適用されます。

よくある質問

質問: 内部負荷分散でサポートされているプロトコルについて教えてください。

  • 内部負荷分散は、TCP トラフィックと UDP トラフィックでサポートされています。

質問: サービス ディスカバリは内部負荷分散でサポートされていますか。

  • サービス名の登録とディスカバリはサポートされていません。内部負荷分散のフロントエンド IP から直接内部負荷分散にアクセスできるようにクライアント インスタンスを設定する必要があります。

質問: 内部負荷分散でターゲット プールを使用できますか。

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

Compute Engine ドキュメント