共有 VPC を使用した内部 HTTP(S) ロードバランシングの設定

このドキュメントでは、共有 VPC 環境で内部 HTTP(S) ロードバランシングを設定するための 2 つのサンプル構成を示します。

最初の例では、サービスプロジェクトにロードバランサのすべてのコンポーネントとバックエンドを作成します。
2 番目の例では、ロードバランサのフロントエンドコンポーネントと URL マップをサービスプロジェクト内に作成し、ロードバランサのバックエンドサービスとバックエンドを別のサービスプロジェクト内に作成します。このタイプのデプロイは、URL マップが別のプロジェクトのバックエンドサービスを参照するため、プロジェクトにまたがるサービスの参照と呼ばれます。

どちらの例でも、ロードバランサの作成を開始する前に、同じ事前構成を使用して権限を付与し、共有 VPC を設定する必要があります。

これ以外にも、内部 HTTP(S) ロードバランシングでサポートされる共有 VPC 構成があります。その他の有効な共有 VPC アーキテクチャについては、共有 VPC アーキテクチャをご覧ください。

共有 VPC ネットワークを使用しない場合は、内部 HTTP(S) ロードバランシングの設定をご覧ください。

始める前に

共有 VPC の概要を確認します。
内部 HTTP(S) ロードバランシングの概要（共有 VPC アーキテクチャセクションを含む）を確認します。

権限

共有 VPC 用に内部 HTTP(S) ロードバランサを設定するには、管理者が事前に設定とプロビジョニングを行う必要があります。最初の設定後、サービスプロジェクトのオーナーは、ロードバランサのすべてのコンポーネントとそのバックエンドをサービスプロジェクトにデプロイするか、別のサービスまたはホストプロジェクトの URL マップから参照可能なサービスプロジェクトに、ロードバランサのバックエンドコンポーネント（バックエンドサービスとバックエンド）をデプロイします。

このセクションでは、このガイドに従って共有 VPC ネットワークに内部 HTTP(S) ロードバランサを設定するために必要な権限について簡単に説明します。

共有 VPC の設定

次のロールが必要です。

共有 VPC の設定やホストプロジェクトの有効化などの 1 回限りの管理タスクを実行する。
新しいサービスプロジェクトをオンボーディングするたびに繰り返す必要がある管理タスクを実行する。これには、サービスプロジェクトの接続、ネットワークリソースのプロビジョニングと構成、サービスプロジェクト管理者へのアクセス権の付与が含まれます。

これらのタスクは、共有 VPC ホストプロジェクトで実行する必要があります。共有 VPC 管理者も共有 VPC ホストプロジェクトのオーナーにすることをおすすめします。これにより、ネットワーク管理者とセキュリティ管理者のロールが自動的に付与されます。

タスク	必要なロール
共有 VPC の設定、ホストプロジェクトの有効化、サービスプロジェクト管理者へのアクセス権の付与	共有 VPC 管理者
共有 VPC でのサブネットの作成とサービスプロジェクト管理者へのアクセス権の付与	ネットワーク管理者
ファイアウォールルールの追加と削除	セキュリティ管理者

サブネットをプロビジョニングしたら、ホストプロジェクトのオーナーは、これらのリソースを使用するすべてのユーザー（通常はサービスプロジェクト管理者またはデベロッパー）にホストプロジェクトでネットワークユーザーロールを付与します。

タスク	必要なロール
ホストプロジェクトに属する VPC とサブネットの使用	ネットワークユーザー

このロールは、プロジェクトレベルまたは個々のサブネットに対して付与できます。Google では個々のサブネットにロールを付与することをおすすめします。プロジェクトにロールを付与すると、ホストプロジェクトの VPC 内の現在および将来のすべてのサブネットに対してアクセスを与えることになります。

内部 HTTP(S) ロードバランサとバックエンドのデプロイと更新

サービスプロジェクト管理者が負荷分散リソースとバックエンドを作成するには、サービスプロジェクトで次のロールが必要です。これらのロールによって付与される権限は、サービスプロジェクトのオーナーまたは編集者には自動的に付与されます。

サービスプロジェクトで付与されるロール

タスク	必要なロール
ロードバランサのコンポーネントの作成	ネットワーク管理者
インスタンスの作成	インスタンス管理者
SSL 証明書の作成と変更	セキュリティ管理者

詳細については、次のガイドをご覧ください。

前提条件

このセクションの手順は、内部 HTTP(S) ロードバランサを作成するたびに実行する必要はありません。ただし、ロードバランサの作成に進む前に、ここで説明するリソースにアクセスできることを確認する必要があります。

ホストプロジェクトとサービスプロジェクトで共有 VPC を設定する

以降の手順では、共有 VPC がすでに設定されていることを前提としています。この設定には、組織の IAM ポリシーの設定と、ホストプロジェクトとサービスプロジェクトの指定が含まれています。

共有 VPC を設定し、ホストプロジェクトとサービスプロジェクトを有効にするまで、先に進まないでください。

ホストプロジェクトでネットワークとサブネットを構成する

2 つのサブネット（ロードバランサのフロントエンドとバックエンド用サブネット、およびロードバランサのプロキシ用サブネット）を持つ共有 VPC ネットワークが必要です。

この例では、次のネットワーク、リージョン、サブネットを使用します。

ネットワーク。ネットワークの名前は lb-network です。
ロードバランサのフロントエンドとバックエンド用のサブネット。us-west1 リージョンの lb-frontend-and-backend-subnet という名前のサブネットは、プライマリ IP 範囲として 10.1.2.0/24 を使用します。
プロキシのサブネット。us-west1 リージョンの proxy-only-subnet という名前のサブネット。プライマリ IP 範囲として 10.129.0.0/23 を使用します。

ロードバランサのフロントエンドとバックエンドのサブネットを構成する

この手順は、内部 HTTP(S) ロードバランサを作成するたびに実行する必要はありません。サービスプロジェクトが、プロキシ専用サブネットだけでなく、共有 VPC ネットワーク内のサブネットにもアクセスできることだけを確認する必要があります。

Cloud コンソール

Google Cloud Console で、[VPC ネットワーク] ページに移動します。
[VPC ネットワーク] ページに移動
[VPC ネットワークを作成] をクリックします。
[名前] に「lb-network」と入力します。
[サブネット] セクションで次の設定を行います。
- [サブネット作成モード] を [カスタム] に設定します。
- [新しいサブネット] セクションに、次の情報を入力します。
  - 名前: lb-frontend-and-backend-subnet
  - リージョン: us-west1
  - IP アドレス範囲: 10.1.2.0/24
- [完了] をクリックします。
[作成] をクリックします。

gcloud

gcloud compute networks create コマンドを使用して、VPC ネットワークを作成します。
```
gcloud compute networks create lb-network --subnet-mode=custom
```

サブネットを us-west1 リージョン内の lb-network ネットワークに作成します。

gcloud compute networks subnets create lb-frontend-and-backend-subnet \
    --network=lb-network \
    --range=10.1.2.0/24 \
    --region=us-west1

プロキシ専用サブネットを構成する

プロキシ専用サブネットは、lb-network VPC ネットワークの us-west1 リージョン内のすべての内部 HTTP(S) ロードバランサで使用されます。リージョンごと、ネットワークごとにアクティブなプロキシ専用サブネットは 1 つだけです。

このネットワークの us-west1 リージョンに内部 HTTP(S) ロードバランサ用に予約されているプロキシ専用サブネットがすでに存在する場合は、この手順を実施しないでください。

Cloud コンソール

コンソールで [VPC ネットワーク] ページに移動します。
[VPC ネットワーク] ページに移動
共有 VPC ネットワークの名前 lb-network をクリックします。
[サブネットを追加] をクリックします。
[名前] に「proxy-only-subnet」と入力します。
[リージョン] で us-west1 を選択します。
[目的] を [リージョンマネージドプロキシ] に設定します。
[IP アドレス範囲] に「10.129.0.0/23」と入力します。
[追加] をクリックします。

gcloud

gcloud compute networks subnets create コマンドを使用して、プロキシ専用サブネットを作成します。

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

サービスプロジェクト管理者にバックエンドサブネットへのアクセス権を付与する

サービスプロジェクト管理者は lb-frontend-and-backend-subnet サブネットにアクセスして、ロードバランサのバックエンドをプロビジョニングする必要があります。

共有 VPC 管理者は、サービスプロジェクト管理者（またはサブネットを使用するリソースとバックエンドをデプロイするデベロッパー）にアクセス権を付与する必要があります。手順については、一部のサブネットのサービスプロジェクト管理者をご覧ください。

ホストプロジェクトでファイアウォールルールを構成する

この手順は、内部 HTTP(S) ロードバランサを作成するたびに実行する必要はありません。これは、ホストプロジェクト管理者がホストプロジェクトで実行する必要がある 1 回限りの手順です。

この例では、次のファイアウォールルールを使用します。

fw-allow-ssh。負荷分散されたインスタンスに適用される内向きルール。任意のアドレスから TCP ポート 22 への SSH 接続を許可します。このルールには、送信元の IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲を指定できます。この例では、ターゲットタグ allow-ssh を使用して、ファイアウォールルールが適用される仮想マシン（VM）を識別します。
fw-allow-health-check。負荷分散されたインスタンスに適用される内向きルール。Google Cloud ヘルスチェックシステム（130.211.0.0/22 と 35.191.0.0/16）からのすべての TCP トラフィックを許可します。この例では、ターゲットタグ load-balanced-backend を使用して、適用するインスタンスを識別します。
fw-allow-proxies。負荷分散されたインスタンスに適用される内向きルール。内部 HTTP(S) ロードバランサが管理するプロキシからポート 80、443、8080 への TCP トラフィックを許可します。この例では、ターゲットタグ load-balanced-backend を使用して、適用するインスタンスを識別します。

これらのファイアウォールルールがない場合は、デフォルトの上り（内向き）拒否ルールによってバックエンドインスタンスへの受信トラフィックがブロックされます。

Cloud コンソール

コンソールで、[ファイアウォールルール] ページに移動します。
[ファイアウォールルール] ページに移動
[ファイアウォールルールを作成] をクリックして、SSH 接続の受信を許可するルールを作成します。
- 名前: fw-allow-ssh
- ネットワーク: lb-network
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: allow-ssh
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 0.0.0.0/0
- プロトコルとポート:
  - 指定されたプロトコルとポートを選択します。
  - tcp にチェックを入れて、ポート番号に「22」と入力します。
[作成] をクリックします。
[ファイアウォールルールを作成] をもう一度クリックして、Google Cloud ヘルスチェックを許可するルールを作成します。
- 名前: fw-allow-health-check
- ネットワーク: lb-network
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: load-balanced-backend
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 130.211.0.0/22 と 35.191.0.0/16
- プロトコルとポート:
  - 指定されたプロトコルとポートを選択します。
  - tcp にチェック入れて、「80」と入力します。
    このルールは、ヘルスチェックに使用されているプロトコルとポートのみに制限することをおすすめします。プロトコルとポートに tcp:80 を使用すると、Google Cloud はポート 80 で HTTP を使用して VM に接続できますが、ポート 443 では HTTPS を使用して VM に接続することはできません。
[作成] をクリックします。
[ファイアウォールルールを作成] をもう一度クリックをして、ロードバランサのプロキシサーバーがバックエンドに接続できるようにするルールを作成します:
- 名前: fw-allow-proxies
- ネットワーク: lb-network
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: load-balanced-backend
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 10.129.0.0/23
- プロトコルとポート:
  - 指定されたプロトコルとポートを選択します。
  - tcp にチェックを入れて、ポート番号に「80, 443, 8080」と入力します。
[作成] をクリックします。

gcloud

ネットワークタグ allow-ssh を使用して、VM との SSH 接続を許可する fw-allow-ssh ファイアウォールルールを作成します。source-ranges を省略すると、Google Cloud は任意の送信元としてルールを解釈します。
```
gcloud compute firewall-rules create fw-allow-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22
```
Google Cloud ヘルスチェックを許可する fw-allow-health-check ルールを作成します。この例では、ヘルスチェックプローブからのすべての TCP トラフィックを許可します。ただし、必要に応じてポートの範囲を狭く構成することもできます。
```
gcloud compute firewall-rules create fw-allow-health-check \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp
```

内部 HTTP(S) ロードバランサのプロキシにバックエンドへの接続を許可する fw-allow-proxies ルールを作成します。

gcloud compute firewall-rules create fw-allow-proxies \
  --network=lb-network \
  --action=allow \
  --direction=ingress \
  --source-ranges=10.129.0.0/23 \
  --target-tags=load-balanced-backend \
  --rules=tcp:80,tcp:443,tcp:8080

サービスプロジェクトで内部 HTTP(S) ロードバランサを構成する

この例では、すべてのロードバランシングコンポーネント（転送ルール、ターゲットプロキシ、URL マップ、バックエンドサービス）とバックエンドがサービスプロジェクト内に作成される内部 HTTP(S) ロードバランサを構成します。

内部 HTTP(S) ロードバランサのネットワークリソース（プロキシ専用サブネットやバックエンドインスタンスのサブネットなど）は、ホストプロジェクトに作成されます。バックエンドインスタンスのファイアウォールルールもホストプロジェクトに作成されます。

このセクションでは、ロードバランサとバックエンドを設定する方法について説明します。これらの手順は、サービスプロジェクト管理者（またはサービスプロジェクト内で操作するデベロッパー）が行う必要があり、ホストプロジェクト管理者の関与は必要ありません。このセクションの手順は、内部 HTTP(S) ロードバランシングを設定する標準の手順とほぼ同じです。

この例では、エフェメラル内部 IP アドレスの割り振りを許可せずに、内部 HTTP(S) ロードバランサの転送ルールに予約済み内部 IP アドレスを明示的に設定しています。転送ルールの IP アドレスは予約しておくことをおすすめします。

マネージドインスタンスグループを作成する

このセクションでは、テンプレートとマネージドインスタンスグループの作成方法を説明します。このマネージドインスタンスグループに VM インスタンスを作成し、内部 HTTP(S) ロードバランサのバックエンドサーバーを実行します。クライアントからのトラフィックは、これらのバックエンドサーバーに負荷分散されます。わかりやすく説明するために、バックエンドサーバーはそれぞれ独自のホスト名を提供します。

Cloud コンソール

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

[インスタンステンプレート] に移動
1. [インスタンステンプレートを作成] をクリックします。
2. [名前] に「l7-ilb-backend-template」と入力します。
3. [ブートディスク] が Debian GNU/Linux 10 (buster) などの Debian イメージに設定されていることを確認します。これらの手順では、apt-get などの Debian でのみ使用できるコマンドを使用します。ブートディスクを変更する必要がある場合は、[変更] をクリックします。
  1. [オペレーティングシステム] で [Debian] を選択します。
  2. [バージョン] で、利用可能な Debian イメージ（Debian GNU/Linux 10 (buster) など）を選択します。
  3. [選択] をクリックします。
4. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] の [管理] タブで、次のスクリプトを [起動スクリプト] フィールドに挿入します。
```
 #! /bin/bash
 sudo apt-get update
 sudo apt-get install apache2 -y
 sudo a2ensite default-ssl
 sudo a2enmod ssl
 sudo vm_hostname="$(curl -H "Metadata-Flavor:Google" 

 http://169.254.169.254/computeMetadata/v1/instance/name)"
 sudo echo "Page served from: $vm_hostname" | 

 tee /var/www/html/index.html
 sudo systemctl restart apache2
 
```
5. [ネットワーキング] で [共有ネットワーク（共有元のホストプロジェクト: HOST_PROJECT_ID）] を選択します。
6. [ネットワーク] で lb-network を選択し、[サブネット] に lb-frontend-and-backend-subnet を選択します。
7. ネットワークタグ allow-ssh と load-balanced-backend を追加します。
8. [作成] をクリックします。
マネージドインスタンスグループを作成します。コンソールで、[インスタンスグループ] ページに移動します。

[インスタンスグループ] に移動
1. [インスタンスグループを作成] をクリックします。
2. [新しいマネージドインスタンスグループ（ステートレス）] を選択します。詳細については、ステートレス MIG とステートフル MIG をご覧ください。
3. [名前] に「l7-ilb-backend-example」と入力します。
4. [ロケーション] で [シングルゾーン] を選択します。
5. [リージョン] で、us-west1 を選択します。
6. [ゾーン] で、[us-west1-a] を選択します。
7. [インスタンステンプレート] で l7-ilb-backend-template を選択します。
8. グループ内に作成するインスタンスの数を指定します。
  
  この例では、[自動スケーリング] で次のオプションを指定します。
  - [自動スケーリングモード] で [Off:do not autoscale] を選択します。
  - [インスタンスの最大数] に「2」と入力します。
  オプションとして、UI の [自動スケーリング] セクションで、インスタンスの CPU 使用率に基づいてインスタンスを自動的に追加または削除するようにインスタンスグループを構成できます。
9. [作成] をクリックします。

gcloud

このガイドの gcloud の手順は、Cloud Shell または bash がインストールされた別の環境を使用していることを前提としています。

gcloud compute instance-templates create コマンドを使用して、HTTP サーバーで VM インスタンステンプレートを作成します。

gcloud compute instance-templates create l7-ilb-backend-template \
--region=us-west1 \
--network=projects/HOST_PROJECT_ID/global/networks/lb-network \
--subnet=projects/HOST_PROJECT_ID/regions/us-west1/subnetworks/lb-frontend-and-backend-subnet \
--tags=allow-ssh,load-balanced-backend \
--image-family=debian-10 \
--image-project=debian-cloud \
--metadata=startup-script='#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
sudo vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
sudo echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
sudo systemctl restart apache2' \
--project SERVICE_PROJECT_ID

gcloud compute instance-groups managed create コマンドを使用して、ゾーンにマネージドインスタンスグループを作成します。

gcloud compute instance-groups managed create l7-ilb-backend-example \
    --zone=us-west1-a \
    --size=2 \
    --template=l7-ilb-backend-template \
    --project SERVICE_PROJECT_ID

ロードバランサを構成する

このセクションでは、次の内部 HTTP(S) ロードバランサのリソースを作成する方法について説明します。

HTTP ヘルスチェック
マネージドインスタンスグループをバックエンドとして使用するバックエンドサービス
URL マップ
SSL 証明書（HTTPS の場合のみ必須）
ターゲットプロキシ
転送ルール

プロキシの可用性

同じ共有 VPC ネットワークを使用しているサービスプロジェクトの数によっては、各 Google Cloud プロジェクトが独自のネットワークをホストするネットワークデプロイモデルよりも、割り当てまたは上限に達するのが早い場合があります。

たとえば、Google Cloud リージョン内で、新しい内部 HTTP(S) ロードバランサに応じるプロキシの容量が足りなくなることがあります。その場合、ロードバランサの作成時にコンソールでプロキシの可用性に関する警告メッセージが表示されます。この問題を解決するには、次のいずれかを行います。

容量の問題が解決するまで待ちます。
この上限を引き上げるには、Google Cloud セールスチームにお問い合わせください。

Cloud コンソール

ロードバランサタイプの選択

コンソールで [ロードバランシング] ページに移動します。
[ロードバランシング] ページに移動
[HTTP(S) ロードバランシング] で [構成を開始] をクリックします。
[インターネット接続または内部専用] で [VM 間のみ] を選択します。この設定は、ロードバランサが内部であることを意味します。
[続行] をクリックします。

ロードバランサの準備

ロードバランサの [名前] に「l7-ilb-shared-vpc」と入力します。
[リージョン] で us-west1 を選択します。
[ネットワーク] で [共有ネットワーク（共有元のホストプロジェクト: HOST_PROJECT_ID）] を選択します。
1. プルダウンから [lb-network] を選択します。
  [共有 VPC ネットワークに必要なプロキシ専用サブネット] という警告が表示されたら、ホストプロジェクト管理者が lb-network 共有 VPC ネットワークの us-west1 リージョンに proxy-only-subnet を作成していることを確認します。このページで、プロキシ専用サブネットを表示する権限がなくても、ロードバランサの作成は成功します。
ウィンドウを開いたままにして続行します。

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

[バックエンドの構成] をクリックします。
[バックエンドサービスの作成または選択] メニューから [バックエンドサービスを作成] を選択します。
バックエンドサービスの [名前] を l7-ilb-backend-service に設定します。
[バックエンドタイプ] をインスタンスグループに設定します。
[新しいバックエンド] セクションで、次の操作を行います。
1. [インスタンスグループ] を l7-ilb-backend-example に設定します。
2. [ポート番号] を 80 に設定します。
3. [分散モード] を [使用率] に設定します。
4. [完了] をクリックします。
[ヘルスチェック] セクションで、[ヘルスチェックを作成] を選択し、次のパラメータを選択します。
1. 名前: l7-ilb-basic-check
2. プロトコル: HTTP
3. ポート: 80
[保存して次へ] をクリックします。
[作成] をクリックします。

URL マップの構成

[ルーティングルール] をクリックします。l7-ilb-backend-service が、ホストとパスが一致しなかった場合に使用される唯一のバックエンドサービスであることを確認します。

トラフィック管理の詳細については、トラフィック管理の設定をご覧ください。

フロントエンドを構成する

HTTP の場合:

[フロントエンドの設定] をクリックします。
[フロントエンド IP とポートの追加] をクリックします。
[名前] を l7-ilb-forwarding-rule に設定します。
[プロトコル] を HTTP に設定します。
[サブネットワーク] を [lb-frontend-and-backend-subnet] に設定します。
プルダウンリストで選択できる場合でも、フロントエンドにプロキシ専用サブネットは選択しないでください。
[内部 IP] で [静的内部 IP アドレスの予約] を選択します。
表示されるパネルで、次の情報を入力します。
1. 名前: l7-ilb-ip
2. [静的 IP アドレス] セクションで、[ユーザー選択] を選択します。
3. [カスタム IP アドレス] セクションに「10.1.2.99」と入力します。
4. [予約] をクリックします。
[ポート] を 80 に設定します。
[完了] をクリックします。

HTTPS の場合:

クライアントとロードバランサ間で HTTPS を使用する場合は、プロキシを構成するために 1 つ以上の SSL 証明書リソースが必要になります。SSL 証明書リソースの作成方法については、SSL 証明書をご覧ください。現在、内部 HTTP(S) ロードバランサでは Google マネージド証明書がサポートされません。

[フロントエンドの設定] をクリックします。
[フロントエンド IP とポートの追加] をクリックします。
[名前] フィールドに「l7-ilb-forwarding-rule」と入力します。
[プロトコル] フィールドで [HTTPS (includes HTTP/2)] を選択します。
[サブネットワーク] を [lb-frontend-and-backend-subnet] に設定します。
プルダウンリストで選択できる場合でも、フロントエンドにプロキシ専用サブネットは選択しないでください。
[内部 IP] で [静的内部 IP アドレスの予約] を選択します。
表示されるパネルで、次の情報を入力します。
1. 名前: l7-ilb-ip
2. [静的 IP アドレス] セクションで、[ユーザー選択] を選択します。
3. [カスタム IP アドレス] セクションに「10.1.2.99」と入力します。
4. [予約] をクリックします。
HTTPS トラフィックを許可するように、ポートが 443 に設定されていることを確認します。
[証明書] プルダウンリストをクリックします。
1. プライマリ SSL 証明書として使用しようとしているセルフマネージド SSL 証明書リソースがすでにある場合は、プルダウンメニューから選択します。
2. そうでない場合は、[新しい証明書を作成] を選択します。
  1. [名前] に「l7-ilb-cert」と入力します。
  2. 該当するフィールドに PEM 形式のファイルをアップロードします。
    - 公開鍵証明書
    - 証明書チェーン
    - 秘密鍵
  3. [作成] をクリックします。
プライマリ SSL 証明書リソースに加えて証明書リソースを追加するには、次の手順に沿って操作します。
1. [証明書を追加] をクリックします。
2. [証明書] リストから証明書を選択するか、[新しい証明書の作成] をクリックし、上記の手順を行います。
[完了] をクリックします。

構成を確認して完了する

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

gcloud

gcloud compute health-checks create http コマンドを使用して HTTP ヘルスチェックを定義します。

gcloud compute health-checks create http l7-ilb-basic-check \
   --region=us-west1 \
   --use-serving-port \
   --project SERVICE_PROJECT_ID

gcloud compute backend-services create コマンドを使用してバックエンドサービスを定義します。

gcloud compute backend-services create l7-ilb-backend-service \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --health-checks=l7-ilb-basic-check \
  --health-checks-region=us-west1 \
  --region=us-west1 \
  --project SERVICE_PROJECT_ID

gcloud compute backend-services add-backend コマンドを使用して、バックエンドサービスにバックエンドを追加します。

gcloud compute backend-services add-backend l7-ilb-backend-service \
  --balancing-mode=UTILIZATION \
  --instance-group=l7-ilb-backend-example \
  --instance-group-zone=us-west1-a \
  --region=us-west1 \
  --project SERVICE_PROJECT_ID

gcloud compute url-maps create コマンドを使用して、URL マップを作成します。

gcloud compute url-maps create l7-ilb-map \
  --default-service=l7-ilb-backend-service \
  --region=us-west1 \
  --project SERVICE_PROJECT_ID

ターゲットプロキシを作成します。

HTTP の場合:

内部 HTTP ロードバランサの場合は、gcloud compute target-http-proxies create コマンドを使用してターゲットプロキシを作成します。
```
gcloud compute target-http-proxies create l7-ilb-proxy \
  --url-map=l7-ilb-map \
  --url-map-region=us-west1 \
  --region=us-west1 \
  --project SERVICE_PROJECT_ID
```
HTTPS の場合:

SSL 証明書リソースの作成方法については、SSL 証明書をご覧ください。現在、内部 HTTP(S) ロードバランサでは Google マネージド証明書がサポートされません。

ファイルパスを変数名に割り当てます。
```
export LB_CERT=path to PEM-formatted file
```
```
export LB_PRIVATE_KEY=path to PEM-formatted file
```
gcloud compute ssl-certificates create コマンドを使用してリージョン SSL 証明書を作成します。
```
gcloud compute ssl-certificates create l7-ilb-cert \
  --certificate=$LB_CERT \
  --private-key=$LB_PRIVATE_KEY \
  --region=us-west1
```
リージョン SSL 証明書を使用して、gcloud compute target-https-proxies create コマンドでターゲットプロキシを作成します。
```
gcloud compute target-https-proxies create l7-ilb-proxy \
  --url-map=l7-ilb-map \
  --region=us-west1 \
  --ssl-certificates=l7-ilb-cert \
  --project SERVICE_PROJECT_ID
```

転送ルールを作成します。

カスタムネットワークでは、転送ルールでサブネットを参照する必要があります。

転送ルールの IP アドレスには、lb-frontend-and-backend-subnet を使用します。プロキシ専用サブネットを使用すると、転送ルールの作成に失敗します。

HTTP の場合:

適切なフラグを設定して gcloud compute forwarding-rules create コマンドを実行します。

gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
  --subnet=projects/HOST_PROJECT_ID/regions/us-west1/subnetworks/lb-frontend-and-backend-subnet \
  --address=10.1.2.99 \
  --ports=80 \
  --region=us-west1 \
  --target-http-proxy=l7-ilb-proxy \
  --target-http-proxy-region=us-west1 \
  --project SERVICE_PROJECT_ID

HTTPS の場合:

適切なフラグを設定して gcloud compute forwarding-rules create コマンドを実行し、転送ルールを作成します。

gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
  --subnet=projects/HOST_PROJECT_ID/regions/us-west1/subnetworks/lb-frontend-and-backend-subnet \
  --address=10.1.2.99 \
  --ports=443 \
  --region=us-west1 \
  --target-https-proxy=l7-ilb-proxy \
  --target-https-proxy-region=us-west1 \
  --project SERVICE_PROJECT_ID

テスト

VM インスタンスを作成して接続をテストする

クライアントは、ホストプロジェクトまたは接続されたサービスプロジェクトのいずれかに配置できます。この例では、サービスプロジェクトにクライアント VM をデプロイして、ロードバランサが動作していることをテストします。クライアントは、同じ共有 VPC ネットワークを使用し、ロードバランサと同じリージョンに存在する必要があります。

gcloud compute instances create l7-ilb-client-us-west1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=projects/HOST_PROJECT_ID/regions/us-west1/subnetworks/lb-frontend-and-backend-subnet \
    --zone=us-west1-a \
    --tags=allow-ssh \
    --project SERVICE_PROJECT_ID

ロードバランサにトラフィックを送信する

作成したインスタンスにログインし、内部 HTTP(S) ロードバランサの転送ルールの IP アドレスを介してバックエンドの HTTP(S) サービスに到達可能であることと、バックエンドインスタンス間でトラフィックのロードバランシングが行われていることをテストします。

SSH を使用してクライアントインスタンスに接続します。
```
gcloud compute ssh l7-ilb-client-us-west1-a \
  --zone=us-west1-a
```
IP アドレスがホスト名を提供していることを確認します。
```
curl 10.1.2.99
```
HTTPS テストの場合、curl は次のものに置き換えます。
```
curl -k -s 'https//:10.1.2.99:443'
```
-k フラグを指定すると、curl は証明書の検証をスキップします。

100 個のリクエストを実行して、ロードバランシングされていることを確認します。

HTTP の場合:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl --silent 10.1.2.99)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.99: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

HTTPS の場合:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl -k -s 'https://:10.1.2.99:443')"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.99: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

プロジェクト間のサービス参照を構成する

このページの前の例では、すべてのロードバランサコンポーネントとそのバックエンドがサービスプロジェクト内に作成される共有 VPC デプロイを設定しました。

内部 HTTP(S) ロードバランシングでは、1 つのホストまたはサービスプロジェクトの URL マップが、共有 VPC 環境の複数のサービスプロジェクトにまたがるバックエンドサービス（とバックエンド）を参照できる共有 VPC デプロイを構成することもできます。これはプロジェクト間のサービス参照と呼ばれます。

このセクションの手順では、サポートされている以下のいずれかの組み合わせを構成できます。

転送ルール、ホストプロジェクトのターゲットプロキシと URL マップ、サービスプロジェクトのバックエンドサービス
サービスプロジェクトの転送ルール、ターゲットプロキシ、URL マップ、別のサービスプロジェクトのバックエンドサービス

要件を設定する

この例では、フロントエンドとバックエンドが別のサービスプロジェクトに存在するサンプルロードバランサを構成します。

共有 VPC を設定して、この例のネットワーク、サブネット、ファイアウォールルールを構成するための前提条件をすべて満たす必要があります。まだ行っていない場合は、必要な手順を完了してください。手順については、以下をご覧ください。

権限
前提条件

ロードバランサのフロントエンドとバックエンドが別のサービスプロジェクトに存在する

サービスプロジェクト B にバックエンドとバックエンドサービスを作成する

このセクションのコマンドはすべて、サービスプロジェクト B で実行する必要があります。

gcloud compute instance-templates create コマンドを使用して、HTTP サーバーで VM インスタンステンプレートを作成します。

gcloud compute instance-templates create BACKEND_IG_TEMPLATE \
    --region=us-west1 \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/us-west1/subnetworks/lb-frontend-and-backend-subnet \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2' \
    --project SERVICE_PROJECT_B_ID

gcloud compute instance-groups managed create コマンドを使用して、ゾーンにマネージドインスタンスグループを作成します。

gcloud compute instance-groups managed create BACKEND_MIG \
    --zone=us-west1-a \
    --size=2 \
    --template=BACKEND_IG_TEMPLATE \
    --project=SERVICE_PROJECT_B_ID

gcloud compute health-checks create http コマンドを使用して HTTP ヘルスチェックを定義します。

gcloud compute health-checks create http HTTP_HEALTH_CHECK_NAME \
   --region=us-west1 \
   --use-serving-port \
   --project=SERVICE_PROJECT_B_ID

gcloud compute backend-services create コマンドを使用してバックエンドサービスを定義します。

gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --health-checks=HTTP_HEALTH_CHECK_NAME \
  --health-checks-region=us-west1 \
  --region=us-west1 \
  --project=SERVICE_PROJECT_B_ID

gcloud compute backend-services add-backend コマンドを使用して、バックエンドサービスにバックエンドを追加します。

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --balancing-mode=UTILIZATION \
  --instance-group=BACKEND_MIG \
  --instance-group-zone=us-west1-a \
  --region=us-west1 \
  --project=SERVICE_PROJECT_B_ID

バックエンドサービスを使用する権限をロードバランサ管理者に付与する

ロードバランサが他のサービスプロジェクトのバックエンドサービスを参照するには、ロードバランサ管理者に compute.backendServices.use 権限が必要です。この権限を付与するには、compute.loadBalancerServiceUser という IAM 事前定義ロールを使用します。このロールは、サービスプロジェクト管理者が付与する必要があり、プロジェクトレベルまたは個々のバックエンドサービスレベルで適用できます。

この例では、プロジェクト B のサービスプロジェクト管理者は、次のいずれかのコマンドを実行して、サービスプロジェクト A のロードバランサ管理者に compute.backendServices.use 権限を付与する必要があります。

プロジェクトレベルのポリシーバインディング:

gcloud projects add-iam-policy-binding SERVICE_PROJECT_B_ID \
    --member="user:LOAD_BALANCER_ADMIN" \
    --role="roles/compute.loadBalancerServiceUser"

バックエンドサービスレベルでは、サービスプロジェクト管理者が次のいずれかのコマンドを使用して loadBalancerServiceUser ロールを付与します。

gcloud projects add-iam-policy-binding SERVICE_PROJECT_B_ID \
    --member="user:LOAD_BALANCER_ADMIN" \
    --role="roles/compute.loadBalancerServiceUser" \
    --condition='expression=resource.name=="projects/SERVICE_PROJECT_B_ID/regions/us-west1/backend-services/BACKEND_SERVICE_NAME",title=Shared VPC condition'

gcloud beta compute backend-services add-iam-policy-binding BACKEND_SERVICE_NAME
    --member="user:LOAD_BALANCER_ADMIN" \
    --role="roles/compute.loadBalancerServiceUser" \
    --project=SERVICE_PROJECT_B_ID \
    --region=us-west1

条件を使用して条件属性を指定することで、リージョンバックエンドサービスのサブセットにのみ適用されるように IAM 権限を構成することもできます。

サービスプロジェクト A にロードバランサのフロントエンドと URL マップを作成する

このセクションのコマンドはすべて、サービスプロジェクト A で実行する必要があります。

URL マップを作成し、サービスプロジェクト B に作成されたバックエンドサービスにデフォルトサービスを設定します。
```
gcloud compute url-maps create URL_MAP_NAME \
    --default-service=projects/SERVICE_PROJECT_B_ID/regions/us-west1/backendServices/BACKEND_SERVICE_NAME \
    --region=us-west1 \
    --project=SERVICE_PROJECT_A_ID
```
ロードバランサ管理者にサービスプロジェクト B のバックエンドサービスに対する compute.backendServices.use 権限がない場合、URL マップの作成は失敗します。

ターゲットプロキシを作成します。

HTTP の場合:

gcloud compute target-http-proxies create HTTP_TARGET_PROXY_NAME \
  --url-map=URL_MAP_NAME \
  --url-map-region=us-west1 \
  --region=us-west1 \
  --project SERVICE_PROJECT_A_ID

HTTPS の場合:

gcloud compute ssl-certificates create コマンドを使用してリージョン SSL 証明書を作成します。

gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
  --certificate=PATH_TO_CERTIFICATE \
  --private-key=PATH_TO_PRIVATE_KEY \
  --region=us-west1 \
  --project=SERVICE_PROJECT_A_ID

リージョン SSL 証明書を使用して、gcloud compute target-https-proxies create コマンドでターゲットプロキシを作成します。

gcloud compute target-https-proxies create HTTPS_TARGET_PROXY_NAME \
  --url-map=URL_MAP_NAME \
  --region=us-west1 \
  --ssl-certificates=SSL_CERTIFICATE_NAME \
  --project=SERVICE_PROJECT_A_ID

転送ルールを作成します。転送ルールの IP アドレスには、lb-frontend-and-backend-subnet を使用します。プロキシ専用サブネットを使用すると、転送ルールの作成に失敗します。

HTTP の場合:

gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
  --subnet=projects/HOST_PROJECT_ID/regions/us-west1/subnetworks/lb-frontend-and-backend-subnet \
  --address=10.1.2.99 \
  --ports=80 \
  --region=us-west1 \
  --target-http-proxy=HTTP_TARGET_PROXY_NAME \
  --target-http-proxy-region=us-west1 \
  --project=SERVICE_PROJECT_A_ID

HTTPS の場合:

gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
  --subnet=projects/HOST_PROJECT_ID/regions/us-west1/subnetworks/lb-frontend-and-backend-subnet \
  --address=10.1.2.99 \
  --ports=443 \
  --region=us-west1 \
  --target-https-proxy=HTTPS_TARGET_PROXY_NAME \
  --target-https-proxy-region=us-west1 \
  --project=SERVICE_PROJECT_A_ID

ロードバランサをテストするには、ロードバランサのテストで説明されている手順を行います。

次のステップ

内部 HTTP(S) 負荷分散に必要なプロキシ専用サブネットのリソースを管理するには、内部 HTTP(S) ロードバランサのプロキシ専用サブネットをご覧ください。
内部 HTTP(S) ロードバランサの問題をトラブルシューティングする方法については、内部 HTTP(S) 負荷分散のトラブルシューティングをご覧ください。
ロードバランサの設定をクリーンアップする。

共有 VPC を使用した内部 HTTP(S) ロード バランシングの設定

始める前に

権限

共有 VPC の設定

内部 HTTP(S) ロードバランサとバックエンドのデプロイと更新

前提条件

ホスト プロジェクトとサービス プロジェクトで共有 VPC を設定する

ホスト プロジェクトでネットワークとサブネットを構成する

ロードバランサのフロントエンドとバックエンドのサブネットを構成する

Cloud コンソール

gcloud

プロキシ専用サブネットを構成する

Cloud コンソール

gcloud

サービス プロジェクト管理者にバックエンド サブネットへのアクセス権を付与する

ホスト プロジェクトでファイアウォール ルールを構成する

Cloud コンソール

gcloud

サービス プロジェクトで内部 HTTP(S) ロードバランサを構成する

マネージド インスタンス グループを作成する

Cloud コンソール

gcloud

ロードバランサを構成する

プロキシの可用性

Cloud コンソール

ロードバランサ タイプの選択

ロードバランサの準備

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

URL マップの構成

フロントエンドを構成する

構成を確認して完了する

gcloud

テスト

VM インスタンスを作成して接続をテストする

ロードバランサにトラフィックを送信する

プロジェクト間のサービス参照を構成する

要件を設定する

サービス プロジェクト B にバックエンドとバックエンド サービスを作成する

バックエンド サービスを使用する権限をロードバランサ管理者に付与する

サービス プロジェクト A にロードバランサのフロントエンドと URL マップを作成する

次のステップ

共有 VPC を使用した内部 HTTP(S) ロードバランシングの設定

ホストプロジェクトとサービスプロジェクトで共有 VPC を設定する

ホストプロジェクトでネットワークとサブネットを構成する

サービスプロジェクト管理者にバックエンドサブネットへのアクセス権を付与する

ホストプロジェクトでファイアウォールルールを構成する

サービスプロジェクトで内部 HTTP(S) ロードバランサを構成する

マネージドインスタンスグループを作成する

ロードバランサタイプの選択

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

サービスプロジェクト B にバックエンドとバックエンドサービスを作成する

バックエンドサービスを使用する権限をロードバランサ管理者に付与する

サービスプロジェクト A にロードバランサのフロントエンドと URL マップを作成する