共有 VPC 環境で Cloud Storage バケットを使用してクロスリージョン内部アプリケーションロードバランサを設定する

このドキュメントでは、Cloud Storage バケットを使用して共有 VPC 環境でクロスリージョン内部アプリケーションロードバランサを設定するための 2 つのサンプル構成を示します。

最初の例では、1 つのサービスプロジェクトにロードバランサのすべてのコンポーネントとバックエンドを作成します。
2 番目の例では、ロードバランサのフロントエンドコンポーネントと URL マップを 1 つのサービスプロジェクト内に作成し、ロードバランサのバックエンドバケットと Cloud Storage バケットを別のサービスプロジェクト内に作成します。

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

このドキュメントで前述した構成例の他に、ロードバランサのフロントエンドと URL マップがホストプロジェクトに作成され、バックエンドバケットと Cloud Storage バケットがサービスプロジェクトに作成される共有 VPC デプロイを設定することもできます。その他の有効な共有 VPC アーキテクチャの詳細については、共有 VPC アーキテクチャをご覧ください。

共有 VPC ネットワークを使用しない場合は、Cloud Storage バケットを使用してクロスリージョン内部アプリケーションロードバランサを設定するをご覧ください。

始める前に

設定が次の前提条件を満たしていることを確認します。

Google Cloud プロジェクトを作成する

1 つのホストプロジェクトと 2 つのサービスプロジェクトの Google Cloud プロジェクトを作成します。

必要なロール

Cloud Storage バケットを含む共有 VPC 環境でリージョン外部アプリケーションロードバランサを設定するために必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。

共有 VPC を設定するには: ホストプロジェクトに対する Compute 共有 VPC 管理者（roles/compute.xpnAdmin）
サービスプロジェクト管理者に共有 VPC ネットワークの使用権限を付与するには: ホストプロジェクトに対する Compute ネットワークユーザー（roles/compute.networkUser）
Cloud Storage バケットを作成するには: サービスプロジェクトに対するストレージオブジェクト管理者（roles/storage.objectAdmin）
ロードバランシングリソースを作成する: サービスプロジェクトに対する Compute ネットワーク管理者（roles/compute.networkAdmin）
Compute Engine インスタンスを作成する: サービスプロジェクトに対する Compute インスタンス管理者（roles/compute.instanceAdmin.v1）
Certificate Manager SSL 証明書を作成して変更する: サービスプロジェクトに対する Certificate Manager オーナー（roles/certificatemanager.owner）
他のサービスプロジェクトのバックエンドバケットを参照するには: サービスプロジェクトに対する Compute ロードバランササービスユーザー（roles/compute.loadBalancerServiceUser）

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

共有 VPC 環境を設定する

共有 VPC 環境を設定するには、ホストプロジェクトで次の手順を完了します。

ロードバランサの転送ルールのサブネットを構成します。
プロキシ専用サブネットを構成します。
ファイアウォールルールを構成する。
ホストプロジェクトで共有 VPC を設定する。

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

ホストプロジェクトでは、次の VPC ネットワーク、リージョン、サブネットを使用します。

ネットワーク。ネットワークは、lb-network という名前のカスタムモード VPC ネットワークです。
ロードバランサのサブネット。us-east1 リージョンの subnet-us という名前のサブネットは、プライマリ IP 範囲として 10.1.2.0/24 を使用します。asia-east1 リージョンの subnet-asia という名前のサブネットは、プライマリ IP 範囲として 10.1.3.0/24 を使用します。
Envoy プロキシのサブネット。us-east1 リージョンの proxy-only-subnet-us-east1 という名前のサブネットは、プライマリ IP 範囲として 10.129.0.0/23 を使用します。asia-east1 リージョンの proxy-only-subnet-asia-east1 という名前のサブネットは、プライマリ IP 範囲として 10.130.0.0/23 を使用します。

ロードバランサの転送ルールのサブネットを構成する

コンソール

Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。

[VPC ネットワーク] に移動
[VPC ネットワークを作成] をクリックします。
[名前] に「lb-network」と入力します。
[サブネット] セクションで、[サブネット作成モード] で [カスタム] を選択します。
[新しいサブネット] セクションに、次の情報を入力します。
- 名前: subnet-us
- [リージョン] では、[us-east1] を選択します。
- IP アドレス範囲: 10.1.2.0/24
[完了] をクリックします。
[サブネットを追加] をクリックします。
別のリージョンに、ロードバランサの転送ルール用の別のサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。
- 名前: subnet-asia
- リージョン: asia-east1
- IP アドレス範囲: 10.1.3.0/24
[完了] をクリックします。
[作成] をクリックします。

gcloud

gcloud compute networks create コマンドを使用して、lb-network というカスタム VPC ネットワークを作成します。
```
gcloud compute networks create lb-network \
    --subnet-mode=custom \
    --project=HOST_PROJECT_ID
```
gcloud compute networks subnets create コマンドを使用して、us-east1 リージョンの lb-network VPC ネットワークに subnet-us という名前のサブネットを作成します。
```
gcloud compute networks subnets create subnet-us \
    --network=lb-network \
    --range=10.1.2.0/24 \
    --region=us-east1 \
    --project=HOST_PROJECT_ID
```
gcloud compute networks subnets create コマンドを使用して、asia-east1 リージョンの lb-network VPC ネットワークに subnet-asia という名前のサブネットを作成します。
```
gcloud compute networks subnets create subnet-asia \
    --network=lb-network \
    --range=10.1.3.0/24 \
    --region=asia-east1 \
    --project=HOST_PROJECT_ID
```
HOST_PROJECT_ID は、共有 VPC 環境でホストプロジェクトとして有効になっているプロジェクトに割り当てられたGoogle Cloud プロジェクト ID に置き換えます。

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

プロキシ専用サブネットには、 Google Cloud がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。このプロキシは、クライアントからの接続を終端し、バックエンドへの新しい接続を作成します。

このプロキシ専用サブネットは、VPC ネットワークと同じリージョン内のすべての Envoy ベースのロードバランサで使用されます。特定の目的では、リージョンごと、ネットワークごとにアクティブなプロキシ専用サブネットが 1 つだけの場合があります。この例では、2 つのプロキシ専用サブネット（1 つは us-east1 リージョン、もう 1 つは asia-east1 リージョン）を作成します。

コンソール

Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。

[VPC ネットワーク] に移動
作成した VPC ネットワークの名前をクリックします。
[サブネット] タブで [サブネットを追加] をクリックします。
次の情報を入力します。
- [名前] に「proxy-only-subnet-us」と入力します。
- [リージョン] に「us-east1」と入力します。
- [目的] で、[クロスリージョンのマネージドプロキシ] を選択します。
- [IP アドレス範囲] に「10.129.0.0/23」と入力します。
[追加] をクリックします。
asia-east1 リージョンに別のプロキシ専用サブネットを作成します。[サブネット] タブで [サブネットを追加] をクリックします。
次の情報を入力します。
- [名前] に「proxy-only-subnet-asia」と入力します。
- [リージョン] に「asia-east1」と入力します。
- [目的] で、[クロスリージョンのマネージドプロキシ] を選択します。
- [IP アドレス範囲] に「10.130.0.0/23」と入力します。
[追加] をクリックします。

gcloud

gcloud compute networks subnets create コマンドを使用して、us-east1 リージョンにプロキシ専用サブネットを作成します。

この例では、プロキシ専用サブネットの名前は proxy-only-subnet-us です。
```
gcloud compute networks subnets create proxy-only-subnet-us \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=us-east1 \
    --network=lb-network \
    --range=10.129.0.0/23 \
    --project=HOST_PROJECT_ID
```
gcloud compute networks subnets create コマンドを使用して、asia-east1 リージョンにプロキシ専用サブネットを作成します。

この例では、プロキシ専用サブネットの名前は proxy-only-subnet-asia です。
```
gcloud compute networks subnets create proxy-only-subnet-asia \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=asia-east1 \
    --network=lb-network \
    --range=10.130.0.0/23 \
    --project=HOST_PROJECT_ID
```
HOST_PROJECT_ID は、ホストプロジェクトに割り当てられたGoogle Cloud プロジェクト ID に置き換えます。

ファイアウォールルールを構成する

この例では、クライアント VM へのポート 22 での SSH アクセスを許可する上り（内向き）ファイアウォールルールを使用します。この例では、このファイアウォールルールの名前は fw-allow-ssh です。

コンソール

Google Cloud コンソールで、[ファイアウォールポリシー] ページに移動します。

[ファイアウォールポリシー] に移動
[ファイアウォールルールを作成] をクリックして、クライアント VM で受信する SSH 接続を許可するルールを作成します。
- 名前: fw-allow-ssh
- ネットワーク: lb-network
- トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: allow-ssh
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 0.0.0.0/0
- プロトコルとポート:
  - 指定されたプロトコルとポートを選択します。
  - [TCP] チェックボックスをオンにして、ポート番号に「22」と入力します。
[作成] をクリックします。

gcloud

ネットワークタグ allow-ssh を使用して、VM との SSH 接続を許可するファイアウォールルールを作成します。--source-ranges を省略すると、Google Cloud は任意の送信元としてルールを解釈します。

この例では、ファイアウォールルールの名前は fw-allow-ssh です。
```
gcloud compute firewall-rules create fw-allow-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22 \
    --project=HOST_PROJECT_ID
```
HOST_PROJECT_ID は、ホストプロジェクトに割り当てられたGoogle Cloud プロジェクト ID に置き換えます。

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

共有 VPC ホストプロジェクトを有効にして、ホストプロジェクトのサブネットを共有し、サービスプロジェクトをホストプロジェクトに接続して、サービスプロジェクトで共有 VPC ネットワークを使用できるようにします。ホストプロジェクトに共有 VPC を設定するには、次のページをご覧ください。

上記の手順を完了すると、次のいずれかの設定を行うことができます。

サービスプロジェクトでロードバランサを構成する
クロスプロジェクト構成を使用してロードバランサを構成する

サービスプロジェクトでロードバランサを構成する

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

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

図 1. Cloud Storage バケットを使用する共有 VPC 環境のクロスリージョン内部アプリケーションロードバランサ — **図 1.** Cloud Storage バケットを使用する共有 VPC 環境のクロスリージョン内部アプリケーションロードバランサ

このセクションでは、ロードバランサとバックエンドを設定する方法について説明します。

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

Cloud Storage バケットを構成する

Cloud Storage バケットを構成するプロセスは次のとおりです。

Cloud Storage バケットを作成します。
コンテンツを Cloud Storage バケットにコピーする。
Cloud Storage バケットを一般公開します。

Cloud Storage バケットを作成する

この例では、2 つの Cloud Storage バケットを作成します。1 つは us-east1 リージョンに、もう 1 つは asia-east1 リージョンに作成します。本番環境のデプロイでは、複数の Google Cloud リージョンにオブジェクトを自動的に複製するマルチリージョンバケットを選択することをおすすめします。これにより、コンテンツの可用性が高まり、アプリケーション全体のフォールトトレラントが向上します。

コンソール

Google Cloud コンソールで Cloud Storage の [バケット] ページに移動します。

[バケット] に移動
[作成] をクリックします。
[始める] セクションに、命名ガイドラインに沿ったグローバルに一意の名前を入力します。
[データの保存場所の選択] をクリックします。
[ロケーションタイプ] を [リージョン] に設定します。
リージョンのリストから [us-east1] を選択します。
[作成] をクリックします。
[バケット] をクリックして Cloud Storage の [バケット] ページに戻ります。次の手順で 2 番目のバケットを作成しますが、[ロケーション] は asia-east1 に設定します。

gcloud

gcloud storage buckets create コマンドを使用して、us-east1 リージョンに最初のバケットを作成します。

gcloud storage buckets create gs://BUCKET1_NAME \
    --default-storage-class=standard \
    --location=us-east1 \
    --uniform-bucket-level-access \
    --project=SERVICE_PROJECT_ID

gcloud storage buckets create コマンドを使用して、asia-east1 リージョンに 2 つ目のバケットを作成します。
```
gcloud storage buckets create gs://BUCKET2_NAME \
    --default-storage-class=standard \
    --location=asia-east1 \
    --uniform-bucket-level-access \
    --project=SERVICE_PROJECT_ID
```
次のように置き換えます。
- BUCKET1_NAME と BUCKET2_NAME: Cloud Storage バケット名
- SERVICE_PROJECT_ID: サービスプロジェクトに割り当てられた Google Cloud プロジェクト ID

Cloud Storage バケットにコンテンツをコピーする

Cloud Storage バケットにデータを入力するには、Cloud Storage の公開バケットから独自の Cloud Storage バケットにグラフィックファイルをコピーします。

Cloud Shell で次のコマンドを実行します。バケット名の変数は一意の Cloud Storage バケット名に置き換えます。

  gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/love-to-purr/

  gcloud storage cp gs://gcp-external-http-lb-with-bucket/two-dogs.jpg gs://BUCKET2_NAME/love-to-fetch/

BUCKET1_NAME と BUCKET2_NAME は、Cloud Storage バケット名に置き換えます。

Cloud Storage バケットを一般公開する

公共のインターネット上のすべてのユーザーがバケット内のすべてのオブジェクトを閲覧できるようにするには、プリンシパル allUsers に Storage オブジェクト閲覧者（roles/storage.objectViewer）のロールを付与します。

コンソール

バケット内のすべてのオブジェクトに対するアクセス権をすべてのユーザーに付与するには、バケットごとに次の手順を繰り返します。

Google Cloud コンソールで Cloud Storage の [バケット] ページに移動します。

[バケット] に移動
バケットのリストで、公開するバケットの名前をクリックします。
[権限] タブを選択します。
[権限] セクションで、[ アクセスを許可] ボタンをクリックします。[アクセスを許可] ダイアログが表示されます。
[新しいプリンシパル] フィールドに「allUsers」と入力します。
[ロールを選択] フィールドで、フィルタボックスに「Storage Object Viewer」と入力し、フィルタされた結果から [Storage オブジェクト閲覧者] を選択します。
[保存] をクリックします。
[一般公開アクセスを許可] をクリックします。

gcloud

バケット内のオブジェクトを表示する権限をすべてのユーザーに付与するには、gcloud storage buckets add-iam-policy-binding コマンドを実行します。

gcloud storage buckets add-iam-policy-binding gs://BUCKET1_NAME --member=allUsers --role=roles/storage.objectViewer

gcloud storage buckets add-iam-policy-binding gs://BUCKET2_NAME --member=allUsers --role=roles/storage.objectViewer

BUCKET1_NAME と BUCKET2_NAME は、Cloud Storage バケット名に置き換えます。

ロードバランサの IP アドレスを予約する

次のものに静的内部 IP アドレスを予約します。

us-east1 リージョンの転送ルール
asia-east1 リージョンの転送ルール

コンソール

Google Cloud コンソールで、[IP アドレス] ページに移動します。

[静的アドレスの予約] に移動
[内部を予約] をクリックします。
[名前] に新しいアドレスの名前を入力します。
[IP バージョン] で [IPv4] を選択します。
[予約] をクリックして IP アドレスを予約します。
上記の手順を繰り返して、asia-east1 リージョンで IP アドレスを予約します。

gcloud

us-east1 リージョンで静的内部 IP アドレスを予約するには、gcloud compute addresses create コマンドを使用します。
```
gcloud compute addresses create ADDRESS1_NAME  \
   --region=us-east1 \
   --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
   --project=SERVICE_PROJECT_ID
```
次のように置き換えます。
- ADDRESS1_NAME: この IP アドレスに割り当てる名前
- HOST_PROJECT_ID: ホストプロジェクトに割り当てられた Google Cloud プロジェクト ID
- SERVICE_PROJECT_ID: サービスプロジェクトに割り当てられた Google Cloud プロジェクト ID
asia-east1 リージョンで静的内部 IP アドレスを予約するには、gcloud compute addresses create コマンドを使用します。
```
gcloud compute addresses create ADDRESS2_NAME  \
   --region=asia-east1 \
   --subnet=projects/HOST_PROJECT_ID/regions/asia-east1/subnetworks/subnet-asia \
   --project=SERVICE_PROJECT_ID
```
次のように置き換えます。
- ADDRESS2_NAME: この IP アドレスに割り当てる名前
- HOST_PROJECT_ID: ホストプロジェクトに割り当てられた Google Cloud プロジェクト ID
- SERVICE_PROJECT_ID: サービスプロジェクトに割り当てられた Google Cloud プロジェクト ID
結果を表示するには、gcloud compute addresses describe コマンドを使用します。
```
gcloud compute addresses describe ADDRESS1_NAME \
   --project=SERVICE_PROJECT_ID
```
```
gcloud compute addresses describe ADDRESS2_NAME \
   --project=SERVICE_PROJECT_ID
```
次のように置き換えます。
- ADDRESS1_NAME と ADDRESS2_NAME: IP アドレスに割り当てた名前
- SERVICE_PROJECT_ID: サービスプロジェクトに割り当てられた Google Cloud プロジェクト ID
返された IP アドレスは、以降のセクションで RESERVED_IP_ADDRESS として参照されます。

SSL 証明書リソースを設定する

リクエストレスポンスプロトコルとして HTTPS を使用するクロスリージョン内部アプリケーションロードバランサの場合は、次のいずれかのドキュメントの説明に沿って Certificate Manager を使用して SSL 証明書リソースを作成します。

証明書を作成したら、証明書を HTTPS ターゲットプロキシに関連付けることができます。

Google マネージド証明書を使用することをおすすめします。

バックエンドバケットを使用してロードバランサを構成する

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

2 つのバックエンドバケット。バックエンドバケットは、前に作成した Cloud Storage バケットのラッパーとして機能します。
URL マップ
ターゲットプロキシ
リージョン IP アドレスを持つ 2 つのグローバル転送ルール。転送ルールには、ロードバランサの転送ルール用に作成されたサブネットの IP アドレスが割り当てられます。プロキシ専用サブネットから転送ルールに IP アドレスを割り当てると、転送ルールの作成に失敗します。

この例では、クライアントとロードバランサの間のリクエストレスポンスプロトコルとして HTTP または HTTPS を使用できます。HTTPS ロードバランサを作成するには、ロードバランサのフロントエンドに SSL 証明書リソースを追加する必要があります。

gcloud CLI を使用して前述のロードバランシングコンポーネントを作成するには、次の操作を行います。

gcloud compute backend-buckets create コマンドを使用して、Cloud Storage バケットごとに 1 つ、合計 2 つのバックエンドバケットを作成します。バックエンドバケットのロードバランシングスキームは INTERNAL_MANAGED です。

この例では、バックエンドバケットの名前は backend-bucket-cats と backend-bucket-dogs です。これは、Cloud Storage バケット内のコンテンツを示しています。
```
gcloud compute backend-buckets create backend-bucket-cats \
    --gcs-bucket-name=BUCKET1_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --project=SERVICE_PROJECT_ID
```
```
gcloud compute backend-buckets create backend-bucket-dogs \
    --gcs-bucket-name=BUCKET2_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --project=SERVICE_PROJECT_ID
```
次のように置き換えます。
- BUCKET1_NAME と BUCKET2_NAME: Cloud Storage バケット名
- SERVICE_PROJECT_ID: サービスプロジェクトに割り当てられた Google Cloud プロジェクト ID
gcloud compute url-maps create コマンドを使用して、受信リクエストをバックエンドバケットに転送する URL マップを作成します。

この例では、URL マップの名前は lb-map です。
```
gcloud compute url-maps create lb-map \
    --default-backend-bucket=backend-bucket-cats \
    --global \
    --project=SERVICE_PROJECT_ID
```
SERVICE_PROJECT_ID は、サービスプロジェクトに割り当てられたGoogle Cloud プロジェクト ID に置き換えます。
gcloud compute url-maps add-path-matcher コマンドを使用して、URL マップのホストルールとパスルールを構成します。

この例では、デフォルトのバックエンドバケットは backend-bucket-cats で、このバケット内に存在するすべてのパスを処理します。ただし、http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg をターゲットとするリクエストは backend-bucket-dogs バックエンドを使用します。たとえば、/love-to-fetch/ フォルダがデフォルトバックエンド（backend-bucket-cats）にも存在する場合、/love-to-fetch/* に特定のパスルールがあるため、ロードバランサは backend-bucket-dogs バックエンドの優先度を上げます。
```
gcloud compute url-maps add-path-matcher lb-map \
    --path-matcher-name=path-matcher-pets \
    --new-hosts=* \
    --backend-bucket-path-rules="/love-to-fetch/*=backend-bucket-dogs" \
    --default-backend-bucket=backend-bucket-cats
    --project=SERVICE_PROJECT_ID
```
SERVICE_PROJECT_ID は、サービスプロジェクトに割り当てられたGoogle Cloud プロジェクト ID に置き換えます。
gcloud compute target-http-proxies create コマンドを使用して、ターゲットプロキシを作成します。

HTTP トラフィックの場合、リクエストを URL マップに転送するターゲット HTTP プロキシ（http-proxy）を作成します。
```
gcloud compute target-http-proxies create http-proxy \
    --url-map=lb-map \
    --global \
    --project=SERVICE_PROJECT_ID
```
SERVICE_PROJECT_ID は、サービスプロジェクトに割り当てられたGoogle Cloud プロジェクト ID に置き換えます。

HTTPS トラフィックの場合、リクエストを URL マップに転送するターゲット HTTPS プロキシ（https-proxy）を作成します。プロキシは、HTTPS ロードバランサの SSL 証明書を保持するロードバランサの一部です。証明書を作成したら、証明書を HTTPS ターゲットプロキシに関連付けることができます。
```
gcloud compute target-https-proxies create https-proxy \
    --url-map=lb-map \
    --certificate-manager-certificates=CERTIFICATE_NAME \
    --global \
    --project=SERVICE_PROJECT_ID
```
次のように置き換えます。
- CERTIFICATE_NAME: Certificate Manager を使用して作成した SSL 証明書の名前
- SERVICE_PROJECT_ID: サービスプロジェクトに割り当てられた Google Cloud プロジェクト ID

gcloud compute forwarding-rules create コマンドを使用して、2 つのグローバル転送ルールを作成します。1 つには us-east1 リージョンの IP アドレスがあり、もう 1 つには asia-east1 リージョンの IP アドレスがあります。

HTTP トラフィックの場合、受信リクエストを HTTP ターゲットプロキシに転送するグローバル転送ルール（http-fw-rule-1 と http-fw-rule-2）を作成します。

gcloud compute forwarding-rules create http-fw-rule-1 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
    --subnet-region=us-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=80 \
    --target-http-proxy=http-proxy \
    --global-target-http-proxy \
    --global \
    --project=SERVICE_PROJECT_ID

gcloud compute forwarding-rules create http-fw-rule-2 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/asia-east1/subnetworks/subnet-asia \
    --subnet-region=asia-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=80 \
    --target-http-proxy=http-proxy \
    --global-target-http-proxy \
    --global \
    --project=SERVICE_PROJECT_ID

次のように置き換えます。

HOST_PROJECT_ID: ホストプロジェクトに割り当てられた Google Cloud プロジェクト ID
RESERVED_IP_ADDRESS: 予約した IP アドレス
SERVICE_PROJECT_ID: サービスプロジェクトに割り当てられた Google Cloud プロジェクト ID

HTTPS トラフィックの場合、受信リクエストを HTTPS ターゲットプロキシに転送するグローバル転送ルール（https-fw-rule-1 と https-fw-rule-2）を作成します。

gcloud compute forwarding-rules create https-fw-rule-1 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
    --subnet-region=us-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=443 \
    --target-https-proxy=https-proxy \
    --global-target-https-proxy \
    --global \
    --project=SERVICE_PROJECT_ID

gcloud compute forwarding-rules create https-fw-rule-2 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/asia-east1/subnetworks/subnet-asia \
    --subnet-region=asia-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=443 \
    --target-https-proxy=https-proxy \
    --global-target-https-proxy \
    --global \
    --project=SERVICE_PROJECT_ID

次のように置き換えます。

HOST_PROJECT_ID: ホストプロジェクトに割り当てられた Google Cloud プロジェクト ID
RESERVED_IP_ADDRESS: 予約した IP アドレス
SERVICE_PROJECT_ID: サービスプロジェクトに割り当てられた Google Cloud プロジェクト ID

ロードバランサに HTTP リクエストを送信する

内部クライアント VM からロードバランサの転送ルールにリクエストを送信します。

ロードバランサの転送ルールの IP アドレスを取得する

ロードバランサの転送ルールの IP アドレスを取得する手順は次のとおりです。

us-east1 リージョンにあるロードバランサの転送ルール（http-fw-rule-1）の IP アドレスを取得します。
```
gcloud compute forwarding-rules describe http-fw-rule-1 \
    --global \
    --project=SERVICE_PROJECT_ID
```
asia-east1 リージョンにあるロードバランサの転送ルール（http-fw-rule-2）の IP アドレスを取得します。
```
gcloud compute forwarding-rules describe http-fw-rule-2 \
    --global \
    --project=SERVICE_PROJECT_ID
```
SERVICE_PROJECT_ID は、サービスプロジェクトに割り当てられたGoogle Cloud プロジェクト ID に置き換えます。

返された IP アドレスをコピーして、以降の手順で FORWARDING_RULE_IP_ADDRESS として使用します。

クライアント VM を作成して接続をテストする

接続をテストするクライアント VM を作成する手順は次のとおりです。

us-east1 リージョンに client-a という名前のクライアント VM を作成します。
```
gcloud compute instances create client-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
    --zone=us-east1-c \
    --tags=allow-ssh \
    --project=SERVICE_PROJECT_ID
```
次のように置き換えます。
- HOST_PROJECT_ID: ホストプロジェクトに割り当てられた Google Cloud プロジェクト ID
- SERVICE_PROJECT_ID: サービスプロジェクトに割り当てられた Google Cloud プロジェクト ID
クライアント VM への SSH 接続を確立します。
```
 gcloud compute ssh client-a \
     --zone=us-east1-c \
     --project=SERVICE_PROJECT_ID
```
SERVICE_PROJECT_ID は、サービスプロジェクトに割り当てられたGoogle Cloud プロジェクト ID に置き換えます。
この例では、クロスリージョン内部アプリケーションロードバランサには、VPC ネットワークの us-east1 リージョンと asia-east1 リージョンの両方にフロントエンド仮想 IP アドレス（VIP）があります。curl を使用して、いずれかのリージョンの VIP に HTTP リクエストを送信します。
```
curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
```
```
curl http://FORWARDING_RULE_IP_ADDRESS/love-to-purr/three-cats.jpg --output three-cats.jpg
```
FORWARDING_RULE_IP_ADDRESS は、ロードバランサの転送ルールの IP アドレスに置き換えます。

高可用性をテストする

高可用性をテストする手順は次のとおりです。

us-east1 リージョンの転送ルール（http-fw-rule-1）を削除してリージョンの停止をシミュレートし、us-east リージョンのクライアントがバックエンドバケットからデータにまだアクセスできるかどうかを確認します。
```
gcloud compute forwarding-rules delete http-fw-rule-1 \
    --global \
    --project=SERVICE_PROJECT_ID
```
SERVICE_PROJECT_ID は、サービスプロジェクトに割り当てられたGoogle Cloud プロジェクト ID に置き換えます。
curl を使用して、いずれかのリージョンの転送ルールの VIP に HTTP リクエストを送信します。
```
curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
```
```
curl http://FORWARDING_RULE_IP_ADDRESS/love-to-purr/three-cats.jpg --output three-cats.jpg
```
FORWARDING_RULE_IP_ADDRESS は、転送ルールの IP アドレスに置き換えます。

us-east1 リージョンの VIP に HTTP リクエストを送信すると、DNS ルーティングポリシーは、この VIP が応答していないことを検出し、次に最適な VIP（この例では asia-east1）をクライアントに返します。この動作により、リージョンの停止中でもアプリケーションを維持できます。

クロスプロジェクト構成を使用してロードバランサを構成する

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

クロスリージョン内部アプリケーションロードバランサでは、1 つのホストまたはサービスプロジェクトの URL マップが、共有 VPC 環境の複数のサービスプロジェクトにまたがるバックエンドバケットを参照できる共有 VPC デプロイを構成することもできます。

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

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

このセクションでは、後者の構成を例として説明します。

設定の概要

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

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

必要なロールを構成する
共有 VPC 環境を設定する

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

サービスプロジェクト B で Cloud Storage バケットとバックエンドバケットを構成する

このセクションの手順はすべて、サービスプロジェクト B で行う必要があります。

バックエンドバケットを作成するには、次の操作を行う必要があります。

Cloud Storage バケットを作成する

コンソール

Google Cloud コンソールで Cloud Storage の [バケット] ページに移動します。

[バケット] に移動
[作成] をクリックします。
[始める] セクションに、命名ガイドラインに沿ったグローバルに一意の名前を入力します。
[データの保存場所の選択] をクリックします。
[ロケーションタイプ] を [リージョン] に設定します。
リージョンのリストから [us-east1] を選択します。
[作成] をクリックします。
[バケット] をクリックして Cloud Storage の [バケット] ページに戻ります。次の手順で 2 番目のバケットを作成しますが、[ロケーション] は asia-east1 に設定します。

gcloud

gcloud storage buckets create コマンドを使用して、us-east1 リージョンに最初のバケットを作成します。

gcloud storage buckets create gs://BUCKET1_NAME \
    --default-storage-class=standard \
    --location=us-east1 \
    --uniform-bucket-level-access \
    --project=SERVICE_PROJECT_B_ID

gcloud storage buckets create コマンドを使用して、asia-east1 リージョンに 2 つ目のバケットを作成します。

gcloud storage buckets create gs://BUCKET2_NAME \
    --default-storage-class=standard \
    --location=asia-east1 \
    --uniform-bucket-level-access \
    --project=SERVICE_PROJECT_B_ID

次のように置き換えます。

BUCKET1_NAME と BUCKET2_NAME: Cloud Storage バケット名。
SERVICE_PROJECT_B_ID: サービスプロジェクト B に割り当てられた Google Cloud プロジェクト ID。

Cloud Storage バケットにコンテンツをコピーする

Cloud Storage バケットにデータを入力するには、Cloud Storage の公開バケットから独自の Cloud Storage バケットにグラフィックファイルをコピーします。

Cloud Shell で次のコマンドを実行します。バケット名の変数は一意の Cloud Storage バケット名に置き換えます。

  gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/love-to-purr/

  gcloud storage cp gs://gcp-external-http-lb-with-bucket/two-dogs.jpg gs://BUCKET2_NAME/love-to-fetch/

BUCKET1_NAME と BUCKET2_NAME は、Cloud Storage バケット名に置き換えます。

Cloud Storage バケットを一般公開する

コンソール

バケット内のすべてのオブジェクトに対するアクセス権をすべてのユーザーに付与するには、バケットごとに次の手順を繰り返します。

Google Cloud コンソールで Cloud Storage の [バケット] ページに移動します。

[バケット] に移動
バケットのリストで、公開するバケットの名前をクリックします。
[権限] タブを選択します。
[権限] セクションで、[ アクセスを許可] ボタンをクリックします。[アクセスを許可] ダイアログが表示されます。
[新しいプリンシパル] フィールドに「allUsers」と入力します。
[ロールを選択] フィールドで、フィルタボックスに「Storage Object Viewer」と入力し、フィルタされた結果から [Storage オブジェクト閲覧者] を選択します。
[保存] をクリックします。
[一般公開アクセスを許可] をクリックします。

gcloud

バケット内のオブジェクトを表示する権限をすべてのユーザーに付与するには、gcloud storage buckets add-iam-policy-binding コマンドを実行します。

gcloud storage buckets add-iam-policy-binding gs://BUCKET1_NAME --member=allUsers --role=roles/storage.objectViewer

gcloud storage buckets add-iam-policy-binding gs://BUCKET2_NAME --member=allUsers --role=roles/storage.objectViewer

BUCKET1_NAME と BUCKET2_NAME は、Cloud Storage バケット名に置き換えます。

バックエンドバケットを使用してロードバランサを構成する

バックエンドバケットを作成する手順は次のとおりです。

gcloud compute backend-buckets create コマンドを使用して、Cloud Storage バケットごとに 1 つ、合計 2 つのバックエンドバケットを作成します。バックエンドバケットのロードバランシングスキームは INTERNAL_MANAGED です。

この例では、バックエンドバケットの名前は backend-bucket-cats と backend-bucket-dogs です。これは、Cloud Storage バケット内のコンテンツを示しています。
```
gcloud compute backend-buckets create backend-bucket-cats \
    --gcs-bucket-name=BUCKET1_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --project=SERVICE_PROJECT_B_ID
```
```
gcloud compute backend-buckets create backend-bucket-dogs \
    --gcs-bucket-name=BUCKET2_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --project=SERVICE_PROJECT_B_ID
```
次のように置き換えます。
- BUCKET1_NAME と BUCKET2_NAME: Cloud Storage バケット名。
- SERVICE_PROJECT_B_ID: サービスプロジェクト B に割り当てられた Google Cloud プロジェクト ID。

サービスプロジェクト A でロードバランサのフロントエンドコンポーネントを構成する

このセクションの手順はすべて、サービスプロジェクト A で行う必要があります。

サービスプロジェクト A で、次のフロントエンドロードバランシングコンポーネントを作成する必要があります。

ターゲットプロキシに接続されている SSL 証明書リソース。SSL 証明書を作成するには、前のセクションで説明した手順に沿って操作します。
ロードバランサの 2 つの転送ルール用の 2 つの IP アドレス。前のセクションで説明した手順に沿って、転送ルールの IP アドレスを作成できます。
サービスプロジェクト B のバックエンドバケットを参照する URL マップ
ターゲットプロキシ
それぞれにリージョン IP アドレスを持つ 2 つの転送ルール。

フロントエンドコンポーネントを作成する手順は次のとおりです。

gcloud compute url-maps create コマンドを使用して、受信リクエストをバックエンドバケットに転送する URL マップを作成します。

この例では、URL マップの名前は lb-map です。
```
gcloud compute url-maps create lb-map \
    --default-backend-bucket=projects/SERVICE_PROJECT_B_ID/global/backendBuckets/backend-bucket-cats \
    --global \
    --project=SERVICE_PROJECT_A_ID
```
次のように置き換えます。
- SERVICE_PROJECT_B_ID: サービスプロジェクト B に割り当てられた Google Cloud プロジェクト ID
- SERVICE_PROJECT_A_ID: サービスプロジェクト A に割り当てられた Google Cloud プロジェクト ID
gcloud compute url-maps add-path-matcher コマンドを使用して、URL マップのホストルールとパスルールを構成します。

この例では、デフォルトのバックエンドバケットは backend-bucket-cats で、このバケット内に存在するすべてのパスを処理します。ただし、http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg をターゲットとするリクエストは backend-bucket-dogs バックエンドを使用します。たとえば、/love-to-fetch/ フォルダがデフォルトバックエンド（backend-bucket-cats）にも存在する場合、/love-to-fetch/* に特定のパスルールがあるため、ロードバランサは backend-bucket-dogs バックエンドの優先度を上げます。
```
gcloud compute url-maps add-path-matcher lb-map \
    --path-matcher-name=path-matcher-pets \
    --new-hosts=* \
    --backend-bucket-path-rules="/love-to-fetch/*=projects/SERVICE_PROJECT_B_ID/global/backendBuckets/backend-bucket-dogs" \
    --default-backend-bucket=projects/SERVICE_PROJECT_B_ID/global/backendBuckets/backend-bucket-cats \
    --project=SERVICE_PROJECT_A_ID
```
次のように置き換えます。
- SERVICE_PROJECT_B_ID: サービスプロジェクト B に割り当てられた Google Cloud プロジェクト ID
- SERVICE_PROJECT_A_ID: サービスプロジェクト A に割り当てられた Google Cloud プロジェクト ID
gcloud compute target-http-proxies create コマンドを使用して、ターゲットプロキシを作成します。

HTTP トラフィックの場合、リクエストを URL マップに転送するターゲット HTTP プロキシ（http-proxy）を作成します。
```
gcloud compute target-http-proxies create http-proxy \
    --url-map=lb-map \
    --global \
    --project=SERVICE_PROJECT_A_ID
```
SERVICE_PROJECT_A_ID は、サービスプロジェクト A に割り当てられたGoogle Cloud プロジェクト ID に置き換えます。

HTTPS トラフィックの場合、リクエストを URL マップに転送するターゲット HTTPS プロキシ（https-proxy）を作成します。プロキシは、HTTPS ロードバランサの SSL 証明書を保持するロードバランサの一部です。証明書を作成したら、証明書を HTTPS ターゲットプロキシに関連付けることができます。
```
gcloud compute target-https-proxies create https-proxy \
    --url-map=lb-map \
    --certificate-manager-certificates=CERTIFICATE_NAME \
    --global \
    --project=SERVICE_PROJECT_A_ID
```
次のように置き換えます。
- CERTIFICATE_NAME: Certificate Manager を使用して作成した SSL 証明書の名前
- SERVICE_PROJECT_A_ID: サービスプロジェクト A に割り当てられた Google Cloud プロジェクト ID

  gcloud compute forwarding-rules create http-fw-rule-1 \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
      --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
      --subnet-region=us-east1 \
      --address=RESERVED_IP_ADDRESS \
      --ports=80 \
      --target-http-proxy=http-proxy \
      --global-target-http-proxy \
      --global \
      --project=SERVICE_PROJECT_A_ID

  gcloud compute forwarding-rules create http-fw-rule-2 \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
      --subnet=projects/HOST_PROJECT_ID/regions/asia-east1/subnetworks/subnet-asia \
      --subnet-region=asia-east1 \
      --address=RESERVED_IP_ADDRESS \
      --ports=80 \
      --target-http-proxy=http-proxy \
      --global-target-http-proxy \
      --global \
      --project=SERVICE_PROJECT_A_ID

次のように置き換えます。

HOST_PROJECT_ID: ホストプロジェクトに割り当てられた Google Cloud プロジェクト ID
RESERVED_IP_ADDRESS: 予約した IP アドレス
SERVICE_PROJECT_A_ID: サービスプロジェクト A に割り当てられた Google Cloud プロジェクト ID

gcloud compute forwarding-rules create https-fw-rule-1 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
    --subnet-region=us-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=443 \
    --target-https-proxy=https-proxy \
    --global-target-https-proxy \
    --global \
    --project=SERVICE_PROJECT_A_ID

gcloud compute forwarding-rules create https-fw-rule-2 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/asia-east1/subnetworks/subnet-asia \
    --subnet-region=asia-east1 \
    --address=RESERVED_IP_ADDRESS \
    --ports=443 \
    --target-https-proxy=https-proxy \
    --global-target-https-proxy \
    --global \
    --project=SERVICE_PROJECT_A_ID

次のように置き換えます。

HOST_PROJECT_ID: ホストプロジェクトに割り当てられた Google Cloud プロジェクト ID
RESERVED_IP_ADDRESS: 予約した IP アドレス
SERVICE_PROJECT_A_ID: サービスプロジェクト A に割り当てられた Google Cloud プロジェクト ID

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

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

この例では、サービスプロジェクト B のサービスプロジェクト管理者は、次のいずれかのコマンドを実行して、サービスプロジェクト A のロードバランサ管理者に compute.backendBuckets.use 権限を付与する必要があります。これは、プロジェクトレベルで（プロジェクト内のすべてのバックエンドバケットの場合）、またはバックエンドバケットごとに行うことができます。

コンソール

プロジェクトレベルの権限

プロジェクト内のすべてのバックエンドバケットに権限を付与するには、次の操作を行います。

この手順を完了するには、compute.backendBuckets.setIamPolicy 権限と resourcemanager.projects.setIamPolicy 権限が必要です。

Google Cloud コンソールで、[IAM] ページに移動します。

[IAM] に移動
プロジェクトを選択します。
[アクセスを許可] をクリックします。
[新しいプリンシパル] フィールドに、プリンシパルのメールアドレスまたはその他の ID を入力します。
[ロールを割り当てる] セクションで、[ロールを追加] をクリックします。
[ロールを選択] ダイアログの [ロールを検索] フィールドに「Compute Load Balancer Services User」と入力します。
[Compute ロードバランササービスユーザー] チェックボックスをオンにします。
[適用] をクリックします。
（省略可）ロールに条件を追加します。
[保存] をクリックします。

個々のバックエンドバケットのリソースレベルの権限

プロジェクト内の個々のバックエンドバケットに権限を付与するには、次の操作を行います。

この手順を完了するには、compute.backendBuckets.setIamPolicy 権限が必要です。

Google Cloud コンソールで、[バックエンド] ページに移動します。

[バックエンド] に移動
バックエンドのリストから、アクセス権を付与するバックエンドバケットを選択し、[権限] をクリックします。
[プリンシパルを追加] をクリックします。
[新しいプリンシパル] フィールドに、プリンシパルのメールアドレスまたはその他の ID を入力します。
[ロールを選択] リストで、[Compute ロードバランササービスユーザー] を選択します。
[保存] をクリックします。

gcloud

プロジェクトレベルの権限

プロジェクト内のすべてのバックエンドバケットに権限を付与するには、次の操作を行います。

この手順を完了するには、compute.backendBuckets.setIamPolicy 権限と resourcemanager.projects.setIamPolicy 権限が必要です。

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

次のように置き換えます。

SERVICE_PROJECT_B_ID: サービスプロジェクト B に割り当てられた Google Cloudプロジェクト ID
LOAD_BALANCER_ADMIN: バインディングを追加するプリンシパル

個々のバックエンドバケットのリソースレベルの権限

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

gcloud projects add-iam-policy-binding コマンドを使用して、Compute ロードバランササービスユーザーのロールを付与します。

この手順を完了するには、compute.backendBuckets.setIamPolicy 権限が必要です。

  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/global/backendBuckets/BACKEND_BUCKET_NAME",title=Shared VPC condition'

次のように置き換えます。

SERVICE_PROJECT_B_ID: サービスプロジェクト B に割り当てられた Google Cloudプロジェクト ID
LOAD_BALANCER_ADMIN: バインディングを追加するプリンシパル
BACKEND_BUCKET_NAME: バックエンドバケットの名前

または、 gcloud compute backend-buckets add-iam-policy-binding コマンドを使用して、Compute ロードバランササービスユーザーのロールを付与します。

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

ロードバランサに HTTP リクエストを送信する

内部クライアント VM からロードバランサの転送ルールにリクエストを送信します。

ロードバランサの転送ルールの IP アドレスを取得する

ロードバランサの転送ルールの IP アドレスを取得する手順は次のとおりです。

us-east1 リージョンにあるロードバランサの転送ルール（http-fw-rule-1）の IP アドレスを取得します。
```
gcloud compute forwarding-rules describe http-fw-rule-1 \
    --global \
    --project=SERVICE_PROJECT_A_ID
```
asia-east1 リージョンにあるロードバランサの転送ルール（http-fw-rule-2）の IP アドレスを取得します。
```
gcloud compute forwarding-rules describe http-fw-rule-2 \
    --global \
    --project=SERVICE_PROJECT_A_ID
```
SERVICE_PROJECT_A_ID は、サービスプロジェクト A に割り当てられたGoogle Cloud プロジェクト ID に置き換えます。

返された IP アドレスをコピーして、以降の手順で FORWARDING_RULE_IP_ADDRESS として使用します。

クライアント VM を作成して接続をテストする

接続をテストするクライアント VM を作成する手順は次のとおりです。

us-east1 リージョンに client-a という名前のクライアント VM を作成します。
```
gcloud compute instances create client-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=projects/HOST_PROJECT_ID/global/networks/lb-network \
    --subnet=projects/HOST_PROJECT_ID/regions/us-east1/subnetworks/subnet-us \
    --zone=us-east1-c \
    --tags=allow-ssh \
    --project=SERVICE_PROJECT_A_ID
```
次のように置き換えます。
- HOST_PROJECT_ID: ホストプロジェクトに割り当てられた Google Cloud プロジェクト ID
- SERVICE_PROJECT_A_ID: サービスプロジェクト A に割り当てられた Google Cloud プロジェクト ID
クライアント VM への SSH 接続を確立します。
```
 gcloud compute ssh client-a \
     --zone=us-east1-c \
     --project=SERVICE_PROJECT_A_ID
```
SERVICE_PROJECT_A_ID は、サービスプロジェクト A に割り当てられたGoogle Cloud プロジェクト ID に置き換えます。
この例では、クロスリージョン内部アプリケーションロードバランサには、VPC ネットワークの us-east1 リージョンと asia-east1 リージョンの両方にフロントエンド仮想 IP アドレス（VIP）があります。curl を使用して、いずれかのリージョンの VIP に HTTP リクエストを送信します。
```
curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
```
```
curl http://FORWARDING_RULE_IP_ADDRESS/love-to-purr/three-cats.jpg --output three-cats.jpg
```
FORWARDING_RULE_IP_ADDRESS は、ロードバランサの転送ルールの IP アドレスに置き換えます。

高可用性をテストするには、このドキュメントの高可用性をテストするをご覧ください。

共有 VPC 環境で Cloud Storage バケットを使用してクロスリージョン内部アプリケーション ロードバランサを設定する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

始める前に

Google Cloud プロジェクトを作成する

必要なロール

共有 VPC 環境を設定する

ロードバランサの転送ルールのサブネットを構成する

コンソール

gcloud

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

コンソール

gcloud

ファイアウォール ルールを構成する

コンソール

gcloud

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

サービス プロジェクトでロードバランサを構成する

Cloud Storage バケットを構成する

Cloud Storage バケットを作成する

コンソール

gcloud

Cloud Storage バケットにコンテンツをコピーする

Cloud Storage バケットを一般公開する

コンソール

gcloud

ロードバランサの IP アドレスを予約する

コンソール

gcloud

SSL 証明書リソースを設定する

バックエンド バケットを使用してロードバランサを構成する

ロードバランサに HTTP リクエストを送信する

ロードバランサの転送ルールの IP アドレスを取得する

クライアント VM を作成して接続をテストする

高可用性をテストする

クロス プロジェクト構成を使用してロードバランサを構成する

設定の概要

サービス プロジェクト B で Cloud Storage バケットとバックエンド バケットを構成する

Cloud Storage バケットを作成する

コンソール

gcloud

Cloud Storage バケットにコンテンツをコピーする

Cloud Storage バケットを一般公開する

コンソール

gcloud

バックエンド バケットを使用してロードバランサを構成する

サービス プロジェクト A でロードバランサのフロントエンド コンポーネントを構成する

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

コンソール

プロジェクト レベルの権限

個々のバックエンド バケットのリソースレベルの権限

gcloud

プロジェクト レベルの権限

個々のバックエンド バケットのリソースレベルの権限

ロードバランサに HTTP リクエストを送信する

ロードバランサの転送ルールの IP アドレスを取得する

クライアント VM を作成して接続をテストする

次のステップ

共有 VPC 環境で Cloud Storage バケットを使用してクロスリージョン内部アプリケーションロードバランサを設定する

ファイアウォールルールを構成する

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

サービスプロジェクトでロードバランサを構成する

バックエンドバケットを使用してロードバランサを構成する

クロスプロジェクト構成を使用してロードバランサを構成する

サービスプロジェクト B で Cloud Storage バケットとバックエンドバケットを構成する

バックエンドバケットを使用してロードバランサを構成する

サービスプロジェクト A でロードバランサのフロントエンドコンポーネントを構成する

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

プロジェクトレベルの権限

個々のバックエンドバケットのリソースレベルの権限

プロジェクトレベルの権限

個々のバックエンドバケットのリソースレベルの権限