内部負荷分散の設定

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

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

概要

Google Cloud Platform(GCP)は、TCP/UDP ベースのトラフィックに対して内部負荷分散を提供します。内部負荷分散により、内部インスタンスのみが利用できるプライベート負荷分散 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 ネットワーク仮想化スタックを基盤とした軽量の負荷分散を採用し、ソフトウェアで定義された負荷分散により、クライアント インスタンスからバックエンド インスタンスにトラフィックを直接配信しています。

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

GCP クライアントの内部負荷分散のデプロイ

クライアントが VPC ネットワーク内にある場合、内部負荷分散はプライベート サービスを実行するバックエンドに内部クライアント トラフィックを分散します。クライアント インスタンス、内部負荷分散 IP アドレス、バックエンド インスタンスはどれも、VPC ネットワーク上で設定されます。

クライアントが VPC ネットワーク内にあるときの内部負荷分散(クリックして拡大)
クライアントが VPC ネットワーク内にあるときの内部負荷分散(クリックして拡大)

この図では、サブネット 1 のクライアント インスタンスが内部負荷分散 IP アドレス(10.240.0.200)に接続しています。そのインスタンスからのトラフィックは、サブネット 2 のバックエンド インスタンス(10.240.0.2)に負荷分散されます。

VPN または相互接続によるクライアントの内部負荷分散のデプロイ

クライアントが VPN または相互接続を介して接続する場合、クライアントは別のクラウド プロバイダのネットワーク、または別の GCP ネットワークなどのオンプレミス ネットワークに配置できます。クライアントからのトラフィックは、クラウド VPN を通じて VPC ネットワーク内の内部ロードバランサに到達します。その後このトラフィックは、転送ルールが指すバックエンド サービスに属する健全なバックエンド インスタンスに内部的に負荷分散されます。

VPN トンネルと内部ロードバランサは同じリージョンになければなりません。

クライアントが VPN を介して接続するときの内部負荷分散(クリックして拡大)
クライアントが VPN を介して接続するときの内部負荷分散(クリックして拡大)

上記のデプロイには、ショッピング カート アプリケーション用のコンテンツを提供するサブネット 2 および 3 のインスタンスが含まれています。これらのインスタンスは、shopnet と呼ばれる GCP ネットワークの一部です。

この図では、IP アドレスが 192.168.1.1 のクライアント インスタンスがオンプレミス ネットワークに存在し、VPN を使用して GCP の内部負荷分散 IP アドレス(10.240.0.200)に接続しています。クライアントからのトラフィックは、サブネット 2 のバックエンド インスタンス(10.240.0.2)に負荷分散されます。

複数の VPN トンネルまたは相互接続

GCP 以外のネットワークと GCP ネットワークの間に複数の VPN トンネルを設定すると、GCP 以外のクライアントはそれらのトンネルを介して以下のように内部負荷分散にアクセスします。

複数の VPN トンネルによる内部負荷分散(クリックして拡大)
複数の VPN トンネルによる内部負荷分散(クリックして拡大)

この図では、IP アドレスが 192.168.1.1 のクライアント インスタンスがオンプレミス ネットワークに存在し、VPN を介して GCP の内部負荷分散 IP アドレス(10.240.0.200)に接続しています。トラフィックは、複数のトンネルで ECMP ハッシュおよび負荷分散されます。

トンネルの数が変更されない限り、ロードバランサは、特定のセッションのすべてのトラフィックを同じバックエンドに送信します。特定のクライアントからすべてのトラフィックを同じバックエンドに送信するには、セッション アフィニティを使用します。

トンネルの数が変更された場合、オンプレミス ネットワークでは同じセッションに対して異なるトンネルを選択することがあります。ロードバランサは同じバックエンドにマッピングしようとしますが、わずかな割合の接続がリセットされる可能性があります。

内部負荷分散のデプロイ

負荷分散によって、プライベート 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 をどれでも使用できます。

    使用中の IP アドレスを確認するには、VPC ネットワーク / サブネットに関連付けられた既存のインスタンス IP アドレスと他の転送ルール IP アドレスのリストを手動で生成する必要があります。

    内部負荷分散 IP アドレスは、エフェメラル内部 IP を指定して選択できます。または静的内部 IP アドレスを予約することができますが、プロジェクトが削除されるまでプロジェクトに予約されたままです。

    転送ルール用の IP アドレスを選択して指定すると、転送ルールが存在している限り、アドレスの割り当てが継続します。転送ルールが削除されると、その IP アドレスは VPC ネットワークで利用可能な IP アドレス プールに戻されてインスタンスや別の転送ルールに割り当てられるか、または静的内部 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 Cloud Platform 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 --subnet-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 Cloud Platform Console で [ファイアウォール ルール] ページに移動します。
    [ファイアウォール ルール] ページに移動
  2. [ファイアウォール ルールの作成] をクリックします。
  3. [名前] に「allow-all-10-128-0-0-20」と入力します。
  4. [ネットワーク] に 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. [ネットワーク] に my-custom-network を設定します。
  3. [ソースフィルタ] に IP ranges を設定します。
  4. [ソース IP 範囲] に 0.0.0.0/0(どのソースからでも許可)を設定します。
  5. [指定したプロトコルとポート] に tcp:22;tcp:3389;icmp を設定します。
  6. [作成] をクリックします。

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 Cloud Platform Console の [VM インスタンス] ページに移動します。
    [VM インスタンス] ページに移動
  2. [インスタンスを作成] をクリックします。
  3. [名前] を ig-us-central1-1 に設定します。
  4. [ゾーン] を us-central1-b に設定します。
  5. [管理、ディスク、ネットワーキング、SSH キー] をクリックすると、拡張設定が表示されます。
  6. [管理] の [ネットワーキング] をクリックし、[タグ] フィールドに「int-lb」と入力します。
  7. [ネットワーキング] の [ネットワーク インターフェース] の下で、ネットワーク インターフェースを編集します。
  8. [ネットワーキング] で [ネットワーク] に my-custom-network を設定し、[サブネットワーク] に my-custom-subnet を設定します。
  9. 残りのフィールドはデフォルト値をそのまま使用します。
  10. [管理] をクリックし、[起動スクリプト] を次のとおりに設定します。
    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
  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-9 \
    --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-9 \
    --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-9 \
    --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-9 \
    --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 Cloud Platform Console の [インスタンス グループ] ページに移動します。
    [インスタンス グループ] ページに移動
  2. [インスタンス グループを作成] をクリックします。
  3. [名前] を us-ig1 に設定します。
  4. [ゾーン] を us-central1-b に設定します。
  5. [グループ タイプ] で、[非マネージド インスタンス グループ] を選択します。
  6. [ネットワーク] に 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 Cloud Platform Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. [ロードバランサを作成] をクリックします。
  3. [TCP 負荷分散] で [設定を開始] をクリックします。
  4. [インターネット接続または内部専用] で Only between my VMs を選択します。
  5. [続行] をクリックします。
  6. [名前] に my-int-lb を設定します。

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

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

フロントエンド サービスの構成

  1. [フロントエンドの設定] をクリックします。
  2. [サブネットワーク] で my-custom-subnet を選択します。
  3. [内部 IP] で Ephemeral (Automatic) を選択します。
  4. [ポート] に 80 を設定します。
  5. Google Cloud Platform 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 Cloud Platform Console で [ファイアウォール ルール] ページに移動します。
    [ファイアウォール ルール] ページに移動
  2. [ファイアウォール ルールの作成] をクリックします。
  3. [名前] を allow-internal-lb に設定します。
  4. [ネットワーク] に my-custom-network を設定します。
  5. [ターゲットタグ] に int-lb を設定します。
  6. [ソースフィルタ] に IP ranges を設定します。
  7. [ソース IP 範囲] に 10.128.0.0/20 を設定します。
  8. [指定したプロトコルとポート] に tcp:80;tcp:443 を設定します。
  9. [作成] をクリックします。
  10. [ファイアウォール ルールの作成] をクリックします。
  11. [名前] を allow-health-check に設定します。
  12. [VPC ネットワーク] に my-custom-network を設定します。
  13. [ターゲットタグ] に int-lb を設定します。
  14. [ソースフィルタ] に IP ranges を設定します。
  15. [ソース IP 範囲] に 130.211.0.0/22 および 35.191.0.0/16 を設定します。
  16. [指定したプロトコルとポート] に tcp を設定します。
  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 Cloud Platform Console の [VM インスタンス] ページに移動します。
    [VM インスタンス] ページに移動
  2. [インスタンスを作成] をクリックします。
  3. [名前] を standalone-instance-1 に設定します。
  4. [ゾーン] に us-central1-b を設定します。
  5. [管理、ディスク、ネットワーキング、SSH 認証鍵] をクリックすると、拡張設定が表示されます。
  6. [ネットワーク] で、[ネットワーク タグ]フィールドに standalone と入力します。
  7. [ネットワーク] で、ネットワーク インターフェースを編集します。[ネットワーク] に my-custom-network を設定し、[サブネットワーク] に my-custom-subnet を設定します。
  8. [作成] をクリックします。

gcloud


gcloud compute instances create standalone-instance-1 \
    --image-family debian-9 \
    --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

インスタンスからの外部 IP アドレスの削除

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

Console


  1. Google Cloud Platform 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 - バックエンドのリージョンを指定する必要があります。これは、内部ロードバランサの他のコンポーネントと同じリージョンにします。
  • --instance-group-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 のアドレスから発生します。これらの IP アドレス範囲は、ロードバランサがバックエンド インスタンスに接続するために使用されます。ファイアウォール ルールで、この接続を許可する必要があります。

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

ある特定の時点での外部 IP アドレスを調べる必要がある場合は、Google Compute Engine のよくある質問の手順に従ってください。

リージョン インスタンス グループによる内部負荷分散

リージョン インスタンス グループによる内部負荷分散を使用できます。使用する gcloud コマンドは次のとおりです。

次のコマンドは、us-central1 に自動スケーリング可能なリージョン インスタンス グループを作成します。

    gcloud compute instance-groups managed create us-central1-ig1 \
        --region us-central1

次に、us-central1 にバックエンド サービスを作成します。これは、リージョン インスタンス グループを含むバックエンドを追加できるようにするためです。

    gcloud compute backend-services create my-int-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks my-tcp-health-check

次に、リージョン インスタンス グループをバックエンド サービスに追加します。

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

次に転送ルールを作成し、その load-balancing-scheme を internal に設定して、このバックエンド サービスを接続します。

    gcloud compute forwarding-rules create internal-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

モニタリング

内部負荷分散は、モニタリング データを Stackdriver にエクスポートします。モニタリング指標は、内部ロードバランサの構成、使用率、およびパフォーマンスを評価したり、問題をトラブルシューティングしたり、リソースの使用率やユーザー エクスペリエンスを向上させるために使用できます。Stackdriver の事前に定義されたダッシュボードに加えて、カスタム ダッシュボードを作成して、アラートをセットアップし、Stackdriver Monitoring API を通して指標を照会することができます。

Stackdriver Monitoring ダッシュボードの表示

  1. Google Cloud Platform Console で Stackdriver にアクセスします。
    Stackdriver に移動
  2. [Resources] > [Google Cloud Load Balancers] を選択します。
  3. ロードバランサの名前をクリックします。

左側のペインでは、この内部ロードバランサのさまざまな詳細を確認できます。右側のペインでは時系列のグラフを表示できます。[Breakdowns] リンクをクリックすると、特定の内訳が表示されます。左側のペインには現在構成されているデータが表示され、右側のペインには、左側のペインに現在反映されていない、過去の構成で配信されたデータを表示できます。

Stackdriver アラートの定義

Stackdriver アラートは、さまざまな内部負荷分散指標に基づいて定義できます。

  1. Google Cloud Platform Console で Stackdriver にアクセスします。
    Stackdriver に移動
  2. [Alerting] > [Create a Policy] を選択します。
  3. [Add Condition] をクリックし、条件タイプを選択します。
  4. 指標とフィルタを選択します。指標の場合は、リソースタイプが [Internal TCP Load Balancer] または [Internal UDP Load Balancer] です。
  5. [条件を保存] をクリックします。
  6. ポリシー名を入力し、[Save Policy] をクリックします。

Stackdriver カスタム ダッシュボードの定義

内部負荷分散指標に基づくカスタム Stackdriver ダッシュボードを作成できます。

  1. Google Cloud Platform Console で Stackdriver にアクセスします。
    Stackdriver に移動
  2. [Dashboards] > [Create Dashboard] を選択します。
  3. [Add Chart] をクリックします。
  4. グラフにタイトルを付けます。
  5. 指標とフィルタを選択します。指標の場合は、リソースタイプが [Google Cloud TCP Load Balancer (Internal) Rule (internal_tcp_lb_rule)] または [Google Cloud UDP Load Balancer (Internal) Rule (internal_udp_lb_rule)] です。
  6. [保存] をクリックします。

内部ロードバランサの指標

内部ロードバランサの次の指標が Stackdriver に報告されます。

指標 説明
受信スループット バックエンドで受信され、内部ロードバランサ転送ルールに送信されたバイト数。
受信パケット バックエンドで受信され、内部ロードバランサ転送ルールに送信されたパケット数。
送信スループット 転送ルール IP にバインドされた接続で内部負荷分散バックエンドによって送信されたバイト数。
送信パケット 転送ルール IP にバインドされた接続で内部負荷分散バックエンドによって送信されたパケット数。
レイテンシ 各内部負荷分散接続でパケットのバンドルに対して測定された、パケット分散での RTT。通常、Stackdriver ビューでは 95 パーセンタイルに縮小されます。

(*)TCP トラフィックに対してのみ使用できます。

内部ロードバランサ指標の分類項目

内部ロードバランサごとに指標が集計されます。指標は、次の項目ごとにさらに詳細に分類できます。

特性 説明
INSTANCE GROUP 接続を受け取ったインスタンス グループの名前。
BACKEND SCOPE 接続を受け取ったインスタンス グループの範囲(リージョンまたはゾーン)。
BACKEND ZONE インスタンス グループがゾーン インスタンス グループの場合、接続を処理したインスタンス グループのゾーン
CLIENT NETWORK 内部負荷分散に接続したインスタンスがトラフィックを送信する元のネットワーク。
CLIENT SUBNETWORK 内部負荷分散に接続したインスタンスがトラフィックを送信する元のサブネットワーク。
CLIENT ZONE 内部負荷分散転送ルールに接続したインスタンスの Google Cloud Platform ゾーン
FORWARDING RULE インスタンスが内部ロードバランサに接続するために使用する転送ルールの名前。

指標報告の頻度と保持

ロードバランサの指標は、1 分単位のバッチで Stackdriver にエクスポートされます。モニタリング データは 6 週間保持されます。ダッシュボードは、1H、6H、1D、1W、および 6W のデフォルト間隔のデータ分析を提供します。6W から 1 分までの任意の間隔で手動で分析をリクエストできます。

VPN と相互接続での内部負荷分散アクセスのトラブルシューティング

VPN と相互接続での内部負荷分散アクセスによって、2 つの GCP プロダクトが組み合わされます。問題を特定するには、最初に VPN トンネルと同じネットワークおよびリージョンにあるクライアント GCP VM インスタンスから内部ロードバランサにアクセスすることをおすすめします。

クライアント VM インスタンスから内部ロードバランサに正常にアクセスできる場合は、直面する可能性のある一般的な問題をこのセクションの残りの部分で確認してください。

VPN の問題

VPN 経由で内部負荷分散にアクセスするときに VPN の問題が発生した場合は、Cloud VPN トラブルシューティング ガイドをご覧ください。

グローバル ルーティングの問題

内部負荷分散はリージョナル プロダクトです。すべてのクライアントとバックエンドの VM インスタンスと VPN トンネルは、同じリージョンに存在する必要があります。

このため、グローバル ルーティングで内部負荷分散リージョン外のトンネルが使用されると、内部負荷分散アクセスが失われます。

グローバル ルーティングは、内部負荷分散リージョンのローカルなトンネルと内部負荷分散リージョン外のトンネルを使用してを設定できるため、アクセスが失われます。ローカル トンネルがより高いプライオリティで設定されているかまたはプライオリティが指定されていない場合、ローカル トンネルが優先され、内部負荷分散へのアクセスが可能になります。ただし、ローカル トンネルに障害が発生すると、すべてのトラフィックがリモート トンネルにルーティングされ、内部負荷分散へのアクセスが失われます。

UDP と MTU

VPN 経由で内部負荷分散にアクセスするときに大きな UDP パケットがドロップされるのは、UDP でパス MTU 探索(PMTUD)がサポートされていないためです。

この問題を解決するには、インターフェース MTU が IPSec オーバーヘッドと GCP VM インスタンスの MTU(1460)を考慮して設定されていることを確認してください。

VPC ピアリングがサポートされていない

オンプレミス クライアントがピアリングされた内部ロードバランサにアクセスできないのは、VPC ピアリングが VPN アクセスをサポートしていないためです。これらの機能を一緒に使用することはできません。

制限

  • 内部ロードバランサ IP は、手動で設定されたルートのネクストホップ IP にはできません。内部ロードバランサの IP をターゲットとするルートを設定していると、そのルートと一致するトラフィックはドロップされます。
  • あるリージョンのクライアントが別のリージョンの内部ロードバランサにアクセスすることはできません。内部負荷分散を構成するインスタンスはすべて同じ VPC ネットワークとリージョンに属している必要がありますが、サブネットは別でもかまいません。

上限

  • 個々のネットワークで使用できる内部ロードバランサ転送ルールの数は最大 50 です。

  • 内部ロードバランサ転送ルールごとに、最大 250 個のバックエンドを使用できます。

料金

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

よくある質問

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

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

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

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

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

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

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

Compute Engine ドキュメント