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

このドキュメントでは、クロスリージョン内部アプリケーション ロードバランサを作成して、静的コンテンツのリクエストを Cloud Storage バケットに転送する方法について説明します。

始める前に

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

Google Cloud CLI をインストールする

このガイドの手順の一部は、Google Cloud CLI を使用してのみ実行できます。インストールするには、gcloud CLI をインストールするをご覧ください。

ロード バランシングに関連するコマンドについては、API と gcloud CLI のリファレンス ドキュメントをご覧ください。

権限

このガイドを使用する前に、プロジェクトで Cloud Storage バケットとネットワーク リソースを作成する必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、または次の Compute Engine IAM のロールを持っている必要があります。

タスク	必要なロール
ネットワーク、サブネット、ロードバランサ コンポーネントの作成	Compute ネットワーク管理者ロール（roles/compute.networkAdmin）
ファイアウォール ルールの追加と削除	Compute セキュリティ管理者のロール（roles/compute.securityAdmin）
Cloud Storage バケットを作成する	ストレージ オブジェクト管理者ロール（roles/storage.objectAdmin）

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

• アクセス制御
• IAM Conditions

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

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

• CA Service インスタンスによって発行されたクロスリージョン Google マネージド証明書をデプロイする
• DNS 認証を使用して、クロスリージョン Google マネージド証明書をデプロイする
• クロスリージョン セルフマネージド証明書をデプロイする

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

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

制限事項

クロスリージョン内部アプリケーション ロードバランサのバックエンドとして機能する場合、Cloud Storage バケットには次の制限が適用されます。

• プライベート バケットへのアクセスはサポートされていないため、バックエンド バケットはインターネット経由で一般公開する必要があります。

• 署名付き URL はサポートされていません。

• クロスリージョン内部アプリケーション ロードバランサのバックエンド バケットを作成するときに、Cloud CDN との統合は使用できません。

• クロスリージョン内部アプリケーション ロードバランサを使用してバックエンド バケットにアクセスする場合、HTTP GET メソッドのみがサポートされます。バケットからコンテンツをダウンロードできますが、クロスリージョン内部アプリケーション ロードバランサを介してバケットにコンテンツをアップロードすることはできません。

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

設定の概要

次の図に示すように、複数のリージョンにクロスリージョン内部アプリケーション ロードバランサを構成できます。

Cloud Storage へのトラフィックの分散（クリックして拡大）

アーキテクチャ図に示すように、この例では、2 つのバックエンド バケットを持つ Virtual Private Cloud（VPC）ネットワークにクロスリージョン内部アプリケーション ロードバランサを作成します。各バックエンド バケットは Cloud Storage バケットを参照します。Cloud Storage バケットは us-east1 リージョンと asia-east1 リージョンにあります。

このデプロイ アーキテクチャは高可用性を提供します。リージョン内のクロスリージョン内部アプリケーション ロードバランサに障害が発生した場合、DNS ルーティング ポリシーは、別のリージョンのクロスリージョン内部アプリケーション ロードバランサにトラフィックを転送します。

ネットワークとサブネットを構成する

VPC ネットワーク内で、ロードバランサの転送ルールを構成する各リージョンにサブネットを構成します。さらに、ロードバランサを構成する各リージョンに proxy-only-subnet を構成します。

この例では、次の 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 を使用します。

クロスリージョン内部アプリケーション ロードバランサには、VPC 内の任意のリージョンからアクセスできます。これにより、任意のリージョンのクライアントがロードバランサのバックエンドにグローバルにアクセスできるようになります。

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

コンソール

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

   [VPC ネットワーク] に移動

2. [VPC ネットワークを作成] をクリックします。

3. [名前] に「lb-network」と入力します。

4. [サブネット] セクションで、[サブネット作成モード] を [カスタム] に設定します。

5. [新しいサブネット] セクションに、次の情報を入力します。

   • 名前: subnet-us
   • [リージョン] では、[us-east1] を選択します。
   • IP アドレス範囲: 10.1.2.0/24

6. [完了] をクリックします。

7. [サブネットを追加] をクリックします。

8. 別のリージョンに、ロードバランサの転送ルール用の別のサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。

   • 名前: subnet-asia
   • リージョン: asia-east1
   • IP アドレス範囲: 10.1.3.0/24

9. [完了] をクリックします。

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

gcloud

1. gcloud compute networks create コマンドを使用して、lb-network というカスタム VPC ネットワークを作成します。

   gcloud compute networks create lb-network --subnet-mode=custom
   

2. gcloud compute networks subnets create コマンドを使用して、us-east1 リージョンの lb-network VPC ネットワークにサブネットを作成します。

   gcloud compute networks subnets create subnet-us \
       --network=lb-network \
       --range=10.1.2.0/24 \
       --region=us-east1
   

3. gcloud compute networks subnets create コマンドを使用して、asia-east1 リージョンの lb-network VPC ネットワークにサブネットを作成します。

   gcloud compute networks subnets create subnet-asia \
       --network=lb-network \
       --range=10.1.3.0/24 \
       --region=asia-east1
   

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

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

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

重要: プロキシ専用サブネットのアドレスをロードバランサの転送ルールまたはバックエンドに割り当てないでください。転送ルールの IP アドレスとバックエンド インスタンスの IP アドレスは、このサブネット範囲とは異なるサブネット範囲から割り当てます。Google Cloud は、このサブネット範囲を Google Cloudマネージド プロキシ用に予約します。

コンソール

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

   [VPC ネットワーク] に移動

2. 作成した VPC ネットワークの名前をクリックします。

3. [サブネット] タブで [サブネットを追加] をクリックします。

4. 次の情報を入力します。

   • [名前] に「proxy-only-subnet-us」と入力します。
   • [リージョン] に「us-east1」と入力します。
   • [目的] で、[クロスリージョンのマネージド プロキシ] を選択します。
   • [IP アドレス範囲] に「10.129.0.0/23」と入力します。

5. [追加] をクリックします。

6. asia-east1 リージョンに別のプロキシ専用サブネットを作成します。[サブネット] タブで [サブネットを追加] をクリックします。

7. 次の情報を入力します。

   • [名前] に「proxy-only-subnet-asia」と入力します。
   • [リージョン] に「asia-east1」と入力します。
   • [目的] で、[クロスリージョンのマネージド プロキシ] を選択します。
   • [IP アドレス範囲] に「10.130.0.0/23」と入力します。

8. [追加] をクリックします。

gcloud

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

   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
   

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

   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
   

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

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

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

コンソール

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

   [ファイアウォール ポリシー] に移動

2. [ファイアウォール ルールを作成] をクリックして、クライアント VM で受信する SSH 接続を許可するルールを作成します。

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

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

gcloud

1. ネットワーク タグ 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 バケットを作成する

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

コンソール

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

   [バケット] に移動

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

3. [バケットに名前を付ける] ボックスに、命名ガイドラインに沿ったグローバルに一意の名前を入力します。

4. [データの保存場所の選択] をクリックします。

5. [ロケーション タイプ] を [リージョン] に設定します。

6. リージョンのリストから [us-east1] を選択します。

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

8. [バケット] をクリックして Cloud Storage の [バケット] ページに戻ります。次の手順で 2 番目のバケットを作成しますが、[ロケーション] は asia-east1 に設定します。

gcloud

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

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

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

変数 BUCKET1_NAME と BUCKET2_NAME は、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/never-fetch/

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）のロールを付与します。

コンソール

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

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

   [バケット] に移動

2. バケットのリストで、公開するバケットの名前をクリックします。

3. ページ上部にある [権限] タブを選択します。

4. [権限] セクションで、[ アクセスを許可] ボタンをクリックします。[アクセスを許可] ダイアログが表示されます。

5. [新しいプリンシパル] フィールドに「allUsers」と入力します。

6. [ロールを選択] フィールドで、フィルタ ボックスに「Storage Object Viewer」と入力し、フィルタされた結果から [Storage オブジェクト閲覧者] を選択します。

7. [保存] をクリックします。

8. [一般公開アクセスを許可] をクリックします。

gcloud

バケット内のオブジェクトを表示する権限をすべてのユーザーに付与するには、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

バケット名変数は、一意の Cloud Storage バケット名に置き換えます。

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

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

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

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

注: バックエンド バケットを使用してクロスリージョン内部アプリケーション ロードバランサを構成できるのは、gcloud CLI のみです。

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

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

   gcloud compute backend-buckets create backend-bucket-cats \
       --gcs-bucket-name=BUCKET1_NAME \
       --load-balancing-scheme=INTERNAL_MANAGED
   

   gcloud compute backend-buckets create backend-bucket-dogs \
       --gcs-bucket-name=BUCKET2_NAME \
       --load-balancing-scheme=INTERNAL_MANAGED
   

   注: クロスリージョン内部アプリケーション ロードバランサのバックエンド バケットを作成するときに、Cloud CDN を有効にすることはできません。つまり、--load-balancing-scheme=INTERNAL_MANAGED の場合、Cloud CDN との統合は使用できません。

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

   gcloud compute url-maps create lb-map \
       --default-backend-bucket=backend-bucket-cats \
       --global
   

3. 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
   

4. gcloud compute target-http-proxies create コマンドを使用して、ターゲット プロキシを作成します。

   HTTP トラフィックの場合、リクエストを URL マップに転送するターゲット HTTP プロキシを作成します。

   gcloud compute target-http-proxies create http-proxy \
       --url-map=lb-map \
       --global
   

   HTTPS トラフィックの場合、リクエストを URL マップに転送するターゲット HTTPS プロキシを作成します。プロキシは、HTTPS ロードバランサの SSL 証明書を保持するロードバランサの一部です。証明書を作成したら、証明書を HTTPS ターゲット プロキシに関連付けることができます。

   gcloud compute target-https-proxies create https-proxy \
       --url-map=lb-map \
       --certificate-manager-certificates=CERTIFICATE_NAME \
       --global
   

   CERTIFICATE_NAME は、Certificate Manager を使用して作成した SSL 証明書の名前に置き換えます。

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

   ロードバランサの転送ルールに静的内部 IP アドレスを予約する場合は、静的内部 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 \
       --global-target-http-proxy \
       --global
   

   gcloud compute forwarding-rules create http-fw-rule-2 \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=subnet-asia \
       --subnet-region=asia-east1 \
       --ports=80 \
       --target-http-proxy=http-proxy \
       --global-target-http-proxy \
       --global
   

   HTTPS トラフィックの場合、受信リクエストを 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 \
       --global-target-https-proxy \
       --global
   

   gcloud compute forwarding-rules create https-fw-rule-2 \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=subnet-asia \
       --subnet-region=asia-east1 \
       --address=RESERVED_IP_ADDRESS \
       --ports=443 \
       --target-https-proxy=https-proxy \
       --global-target-https-proxy \
       --global
   

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

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

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

1. us-east1 リージョンにあるロードバランサの転送ルール（http-fw-rule-1）の IP アドレスを取得します。

   gcloud compute forwarding-rules describe http-fw-rule-1 \
       --global
   

2. asia-east1 リージョンにあるロードバランサの転送ルール（http-fw-rule-2）の IP アドレスを取得します。

   gcloud compute forwarding-rules describe http-fw-rule-2 \
       --global
   

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

1. 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
   

2. クライアント VM への SSH 接続を確立します。

   gcloud compute ssh client-a --zone=us-east1-c
   

3. この例では、クロスリージョン内部アプリケーション ロードバランサには、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/never-fetch/three-cats.jpg --output three-cats.jpg
   

高可用性をテストする

1. us-east1 リージョンの転送ルール（http-fw-rule-1）を削除してリージョンの停止をシミュレートし、us-east リージョンのクライアントがバックエンド バケットからデータにまだアクセスできるかどうかを確認します。

   gcloud compute forwarding-rules delete http-fw-rule-1 \
       --global
   

2. 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/never-fetch/three-cats.jpg --output three-cats.jpg
   

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

次のステップ

• 内部アプリケーション ロードバランサの概要
• Envoy ベースのロードバランサ向けプロキシ専用サブネット
• 証明書を管理する
• ロード バランシングの設定をクリーンアップする