このドキュメントでは、静的コンテンツのリクエストを Cloud Storage バケットに転送するregional internal Application Load Balancer を作成する方法について説明します。
始める前に
設定が次の前提条件を満たしていることを確認します。
Google Cloud CLI をインストールする
このガイドの手順の一部は、gcloud CLI を使用してのみ実行できます。インストールするには、Google Cloud CLI をインストールするをご覧ください。
ロード バランシングに関連するコマンドについては、API と gcloud CLI のリファレンス ドキュメントをご覧ください。
必要なロール
プロジェクト作成者にはオーナーロール(roles/owner)が付与されます。デフォルトでは、オーナーロール(roles/owner)または編集者ロール(roles/editor)には、このドキュメントの手順に沿って操作するために必要な権限が含まれています。
プロジェクト作成者でない場合は、プロジェクトで必要な権限を適切なプリンシパルに付与する必要があります。プリンシパルは、Google アカウント(エンドユーザーの場合)やサービス アカウントになることもあります。
Cloud Storage バケットとネットワーク リソースの作成に必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。
-
ネットワーク、サブネット、ロードバランサ コンポーネントを作成する: Compute ネットワーク管理者 (
roles/compute.networkAdmin) -
ファイアウォール ルールの追加と削除: Compute セキュリティ管理者 (
roles/compute.securityAdmin) -
Cloud Storage バケットを作成する: ストレージ オブジェクト管理者 (
roles/storage.objectAdmin)
ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。
Cloud Load Balancing のロールと権限の詳細については、ロールと権限をご覧ください。条件付き付与で IAM ポリシーを定義する方法については、転送ルールの IAM 条件をご覧ください。
SSL 証明書リソースを設定する
リクエスト レスポンス プロトコルとして HTTPS を使用する regional internal Application Load Balancer の場合は、次のいずれかのドキュメントの説明に沿って Certificate Manager を使用して SSL 証明書リソースを作成します。
- CA Service インスタンスによって発行されたリージョン Google マネージド証明書をデプロイする
- DNS 認証を使用して、リージョン Google マネージド証明書をデプロイする
- リージョン セルフマネージド証明書をデプロイする
Google マネージド証明書を使用することをおすすめします。
制限事項
regional internal Application Load Balancerのバックエンドとして機能する場合、Cloud Storage バケットには次の制限が適用されます。
プライベート バケットへのアクセスはサポートされていないため、バックエンド バケットはインターネット経由で一般公開する必要があります。
署名付き URL はサポートされていません。
regional internal Application Load Balancerのバックエンド バケットを作成するときに、Cloud CDN との統合は使用できません。
regional internal Application Load Balancer を使用してバックエンド バケットにアクセスする場合、HTTP
GETメソッドのみがサポートされます。バケットからコンテンツをダウンロードできますが、regional internal Application Load Balancer を介してバケットにコンテンツをアップロードすることはできません。regional internal Application Load Balancerの場合、Cloud Storage バケットはロードバランサが構成されているリージョンでのみサポートされます。デュアルリージョンまたはマルチリージョン バケットはサポートされていません。
設定の概要
次のアーキテクチャ図に示すように、リージョンで regional internal Application Load Balancer を構成できます。
アーキテクチャ図に示すように、この例では、2 つのバックエンド バケットを持つ Virtual Private Cloud(VPC)ネットワークにregional internal Application Load Balancer を作成します。各バックエンド バケットは Cloud Storage バケットを参照します。Cloud Storage バケットは us-east1 リージョンにあり、各バケット間でトラフィックの負荷を分散できます。
ネットワークとサブネットを構成する
VPC ネットワーク内で、ロードバランサの転送ルールを構成するリージョン us-east1 にサブネットを構成します。また、ロードバランサを構成するリージョン us-east1 にプロキシ専用サブネットを構成します。
この例では、次の VPC ネットワーク、リージョン、サブネットを使用します。
ネットワーク。ネットワークは、
lb-networkという名前のカスタムモード VPC ネットワークです。ロードバランサのサブネット。
us-east1リージョンのsubnet-usという名前のサブネットは、プライマリ IP 範囲として10.1.2.0/24を使用します。Envoy プロキシのサブネット。
us-east1リージョンのproxy-only-subnet-usという名前のサブネット。プライマリ IP 範囲として10.129.0.0/23を使用します。
ロードバランサの転送ルールのサブネットを構成する
ロードバランサの転送ルールを構成するリージョンにサブネットを作成します。
コンソール
Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
[VPC ネットワークを作成] をクリックします。
[名前] に「
lb-network」と入力します。[サブネット] セクションで、[サブネット作成モード] を [カスタム] に設定します。
[新しいサブネット] セクションに、次の情報を入力します。
- 名前:
subnet-us - [リージョン] では、[
us-east1] を選択します。 - IP アドレス範囲:
10.1.2.0/24 - [完了] をクリックします。
- 名前:
[作成] をクリックします。
gcloud
gcloud compute networks createコマンドを使用して、lb-networkというカスタム VPC ネットワークを作成します。gcloud compute networks create lb-network --subnet-mode=custom
gcloud compute networks subnets createコマンドを使用して、us-east1リージョンのlb-networkVPC ネットワークにサブネットを作成します。gcloud compute networks subnets create subnet-us \ --network=lb-network \ --range=10.1.2.0/24 \ --region=us-east1
プロキシ専用サブネットを構成する
プロキシ専用サブネットには、 Google Cloud がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。このプロキシは、クライアントからの接続を終端し、バックエンドへの接続を作成します。
このプロキシ専用サブネットは、VPC ネットワークと同じリージョン内のすべての Envoy ベースのロードバランサで使用されます。特定の目的では、リージョンごと、ネットワークごとにアクティブなプロキシ専用サブネットが 1 つだけの場合があります。この例では、us-east1 リージョンにプロキシ専用サブネットを作成します。
コンソール
Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
作成した VPC ネットワークの名前をクリックします。
[サブネット] タブで [サブネットを追加] をクリックします。
次の情報を入力します。
- [名前] に「
proxy-only-subnet-us」と入力します。 - [リージョン] に「
us-east1」と入力します。 - [目的] で、[Regional Managed Proxy] を選択します。
- [IP アドレス範囲] に「
10.129.0.0/23」と入力します。
- [名前] に「
[追加] をクリックします。
gcloud
gcloud compute networks subnets createコマンドを使用して、us-east1リージョンにプロキシ専用サブネットを作成します。gcloud compute networks subnets create proxy-only-subnet-us \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=us-east1 \ --network=lb-network \ --range=10.129.0.0/23
ファイアウォール ルールを構成する
この例では、クライアント 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 接続を許可する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
Cloud Storage バケットを構成する
Cloud Storage バケットを構成するプロセスは次のとおりです。
- バケットを作成します。
- コンテンツをバケットにコピーします。
- バケットを公開します。
Cloud Storage バケットを作成する
この例では、us-east1 リージョンに 2 つの Cloud Storage バケットを作成します。
コンソール
- Google Cloud コンソールで Cloud Storage の [バケット] ページに移動します。
[作成] をクリックします。
[始める] セクションに、命名ガイドラインに沿ったグローバルに一意の名前を入力します。
[データの保存場所の選択] をクリックします。
[ロケーション タイプ] を [リージョン] に設定します。
リージョンのリストから [us-east1] を選択します。
[作成] をクリックします。
[バケット] をクリックして、Cloud Storage バケットのページに戻ります。上記の手順に沿って、同じリージョン us-east1 に 2 つ目のバケットを作成します。
gcloud
gcloud storage buckets createコマンドを使用して、us-east1リージョンにバケットを作成します。gcloud storage buckets create gs://BUCKET1_NAME \ --default-storage-class=standard \ --location=us-east1 \ --uniform-bucket-level-accessgcloud storage buckets create gs://BUCKET2_NAME \ --default-storage-class=standard \ --location=us-east1 \ --uniform-bucket-level-accessBUCKET1_NAMEとBUCKET2_NAMEは、Cloud Storage バケット名に置き換えます。
グラフィック ファイルを Cloud Storage バケットにコピーする
設定をテストするには、Cloud Storage の公開バケットから独自の 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/
Cloud Storage バケットを公開する
公共のインターネット上のすべてのユーザーがバケット内のすべてのオブジェクトを閲覧できるようにするには、プリンシパル allUsers に Storage オブジェクト閲覧者(roles/storage.objectViewer)のロールを付与します。
コンソール
バケット内のすべてのオブジェクトに対するアクセス権をすべてのユーザーに付与するには、バケットごとに次の手順を繰り返します。
- Google Cloud コンソールで Cloud Storage の [バケット] ページに移動します。
バケットのリストで、公開する各バケットのチェックボックスをオンにします。
[権限] ボタンをクリックします。[権限] ダイアログが表示されます。
[権限] ダイアログで、 [プリンシパルを追加] ボタンをクリックします。[アクセスを許可] ダイアログが表示されます。
[新しいプリンシパル] フィールドに「
allUsers」と入力します。[ロールを選択] フィールドで、フィルタ ボックスに「
Storage Object Viewer」と入力し、フィルタされた結果から [Storage オブジェクト閲覧者] を選択します。[保存] をクリックします。
[一般公開アクセスを許可] をクリックします。
gcloud
バケット内のオブジェクトを表示する権限をすべてのユーザーに付与するには、buckets add-iam-policy-binding コマンドを実行します。
gcloud storage buckets add-iam-policy-binding gs://BUCKET1_NAME \
--member=allUsers \
--role=roles/storage.objectViewergcloud storage buckets add-iam-policy-binding gs://BUCKET2_NAME \
--member=allUsers \
--role=roles/storage.objectViewer静的内部 IP アドレスの予約
ロードバランサの転送ルールに静的内部 IPv4 アドレスを予約します。詳細については、静的内部 IP アドレスを予約するをご覧ください。
コンソール
Google Cloud コンソールで、[内部静的 IP アドレスの予約] ページに移動します。
[名前] フィールドに、新しいアドレスの名前を入力します。
[IP バージョン] リストで、[IPv4] を選択します。
[ネットワーク] リストで、[lb-network] を選択します。
[サブネットワーク] リストで、[subnet-us] を選択します。
[リージョン] で [us-east1] を選択します。
[静的 IP アドレス] リストで、[自動的に割り当てる] を選択します。ロードバランサを作成すると、この IP アドレスがロードバランサの転送ルールに関連付けられます。
[予約] をクリックして IP アドレスを予約します。
gcloud
静的外部 IP アドレスを予約するには、
gcloud compute addresses createコマンドを使用します。gcloud compute addresses create ADDRESS_NAME \ --region=us-east1 \ --subnet=subnet-usADDRESS_NAMEは、新しいアドレスの名前に置き換えます。アドレスに関する情報を表示するには、
gcloud compute addresses describeコマンドを使用します。gcloud compute addresses describe ADDRESS_NAME
返された IP アドレスをコピーして、次のセクションで
RESERVED_IP_ADDRESSとして使用します。
バックエンド バケットを使用してロードバランサを構成する
このセクションでは、regional internal Application Load Balancerに次のリソースを作成する方法について説明します。
- 2 つのバックエンド バケット。バックエンド バケットは、前に作成した Cloud Storage バケットのラッパーとして機能します。
- URL マップ
- ターゲット プロキシ
- リージョン IP アドレスを持つ転送ルール。転送ルールには、ロードバランサの転送ルール用に作成されたサブネットの IP アドレスが割り当てられます。プロキシ専用サブネットから転送ルールに IP アドレスを割り当てると、転送ルールの作成に失敗します。
この例では、クライアントとロードバランサの間のリクエスト レスポンス プロトコルとして HTTP または HTTPS を使用できます。HTTPS ロードバランサを作成するには、ロードバランサのフロントエンドに SSL 証明書リソースを追加する必要があります。
gcloud CLI を使用して前述のロード バランシング コンポーネントを作成するには、次の操作を行います。
gcloud beta compute backend-buckets createコマンドを使用して、us-east1リージョンに 2 つのバックエンド バケットを作成します。バックエンド バケットのロード バランシング スキームはINTERNAL_MANAGEDです。gcloud beta compute backend-buckets create backend-bucket-cats \ --gcs-bucket-name=BUCKET1_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --region=us-east1gcloud beta compute backend-buckets create backend-bucket-dogs \ --gcs-bucket-name=BUCKET2_NAME \ --load-balancing-scheme=INTERNAL_MANAGED \ --region=us-east1gcloud beta compute url-maps createコマンドを使用して、受信リクエストをバックエンド バケットに転送する URL マップを作成します。gcloud beta compute url-maps create lb-map \ --default-backend-bucket=backend-bucket-cats \ --region=us-east1gcloud beta 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 beta 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 \ --region=us-east1gcloud compute target-http-proxies createコマンドを使用して、ターゲット プロキシを作成します。HTTP トラフィックの場合、リクエストを URL マップに転送するターゲット HTTP プロキシを作成します。
gcloud compute target-http-proxies create http-proxy \ --url-map=lb-map \ --region=us-east1HTTPS トラフィックの場合、リクエストを URL マップに転送するターゲット HTTPS プロキシを作成します。プロキシは、HTTPS ロードバランサの SSL 証明書を保持するロードバランサの一部です。証明書を作成したら、証明書を HTTPS ターゲット プロキシに関連付けることができます。
gcloud compute target-https-proxies create https-proxy \ --url-map=lb-map \ --certificate-manager-certificates=CERTIFICATE_NAME \ --region=us-east1CERTIFICATE_NAMEは、Certificate Manager を使用して作成した SSL 証明書の名前に置き換えます。gcloud compute forwarding-rules createコマンドを使用して、us-east1リージョンの IP アドレスを持つ転送ルールを作成します。IP アドレスの予約は HTTP 転送ルールでは省略可能ですが、HTTPS 転送ルールでは IP アドレスを予約する必要があります。
この例では、エフェメラル IP アドレスがロードバランサの HTTP 転送ルールに関連付けられています。転送ルールが存在している間は、エフェメラル IP アドレスは変わりません。転送ルールを削除して再作成する必要がある場合は、転送ルールに新しい IP アドレスが割り当てられることがあります。
HTTP トラフィックの場合、受信リクエストを HTTP ターゲット プロキシに転送する転送ルールを作成します。
gcloud compute forwarding-rules create http-fw-rule-1 \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=subnet-us \ --subnet-region=us-east1 \ --ports=80 \ --target-http-proxy=http-proxy \ --target-http-proxy-region=us-east1 \ --region=us-east1HTTPS トラフィックの場合、受信リクエストを HTTPS ターゲット プロキシに転送するグローバル転送ルールを作成します。
gcloud compute forwarding-rules create https-fw-rule-1 \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=subnet-us \ --subnet-region=us-east1 \ --address=RESERVED_IP_ADDRESS \ --ports=443 \ --target-https-proxy=https-proxy \ --target-http-proxy-region=us-east1 \ --region=us-east1RESERVED_IP_ADDRESSは、静的内部 IP アドレスを予約するセクションでコピーしたアドレスの名前に置き換えます。
ロードバランサに HTTP リクエストを送信する
内部クライアント VM からロードバランサの転送ルールにリクエストを送信します。
ロードバランサの転送ルールの IP アドレスを取得する
us-east1 リージョンにあるロードバランサの転送ルール(http-fw-rule-1)の IP アドレスを取得し、curl を使用してリージョンの仮想 IP アドレス(VIP)に HTTP リクエストを送信します。
gcloud compute forwarding-rules describe http-fw-rule-1 \
--region=us-east1
返された IP アドレスをコピーして、次のステップで FORWARDING_RULE_IP_ADDRESS として使用します。
クライアント VM を作成して接続をテストする
クライアント VM を作成し、VPC ネットワーク内の VIP に HTTP リクエストを送信します。クライアント VM はロードバランサと同じリージョン内の任意のゾーンにあり、同じ VPC ネットワーク内の任意のサブネットを使用できます。この例では、ロードバランサの転送ルールと同じサブネットにクライアント VM を作成します。
us-east1リージョンにクライアント VM を作成します。gcloud compute instances create client-a \ --image-family=debian-12 \ --image-project=debian-cloud \ --network=lb-network \ --subnet=subnet-us \ --zone=us-east1-c \ --tags=allow-sshクライアント VM への SSH 接続を確立します。
gcloud compute ssh client-a --zone=us-east1-c
この例では、 regional internal Application Load Balancer には VPC ネットワークの
us-east1リージョンにフロントエンド VIP があります。curl を使用して、そのリージョンの VIP に HTTP リクエストを送信します。curl http://FORWARDING_RULE_IP_ADDRESS/love-to-purr/three-cats.jpg --output three-cats.jpg
curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
FORWARDING_RULE_IP_ADDRESSは、ロードバランサの転送ルールの IP アドレスを取得するセクションでコピーした IP アドレスに置き換えます。