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

このドキュメントでは、静的コンテンツのリクエストを 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 ロールを付与するよう管理者に依頼してください。

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

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

Cloud Load Balancing のロールと権限の詳細については、ロールと権限をご覧ください。条件付き付与で IAM ポリシーを定義する方法については、転送ルールの IAM 条件をご覧ください。

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

リクエスト レスポンス プロトコルとして HTTPS を使用する regional internal Application Load Balancer の場合は、次のいずれかのドキュメントの説明に沿って Certificate Manager を使用して SSL 証明書リソースを作成します。

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

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 を構成できます。

 regional internal Application Load Balancer は、Cloud Storage バックエンドにトラフィックを送信します。
Cloud Storage へのトラフィックの分散(クリックして拡大)

アーキテクチャ図に示すように、この例では、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 を使用します。

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

ロードバランサの転送ルールを構成するリージョンにサブネットを作成します。

コンソール

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

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

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

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

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

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

    1. 名前: subnet-us
    2. [リージョン] では、[us-east1] を選択します。
    3. IP アドレス範囲: 10.1.2.0/24
    4. [完了] をクリックします。
  6. [作成] をクリックします。

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
    

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

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

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

コンソール

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

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

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

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

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

    1. [名前] に「proxy-only-subnet-us」と入力します。
    2. [リージョン] に「us-east1」と入力します。
    3. [目的] で、[Regional Managed Proxy] を選択します。
    4. [IP アドレス範囲] に「10.129.0.0/23」と入力します。
  5. [追加] をクリックします。

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 を使用します。

コンソール

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

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

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

  3. [ファイアウォール ルールの作成] ページで、次の情報を入力します。

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

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 バケットを構成するプロセスは次のとおりです。

  1. バケットを作成します。
  2. コンテンツをバケットにコピーします。
  3. バケットを公開します。

Cloud Storage バケットを作成する

この例では、us-east1 リージョンに 2 つの Cloud Storage バケットを作成します。

コンソール

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

    [バケット] に移動

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

  3. [始める] セクションに、命名ガイドラインに沿ったグローバルに一意の名前を入力します。

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

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

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

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

  8. [バケット] をクリックして、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-access
    
    gcloud storage buckets create gs://BUCKET2_NAME \
        --default-storage-class=standard \
        --location=us-east1 \
        --uniform-bucket-level-access
    

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

コンソール

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

  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

静的内部 IP アドレスの予約

ロードバランサの転送ルールに静的内部 IPv4 アドレスを予約します。詳細については、静的内部 IP アドレスを予約するをご覧ください。

コンソール

  1. Google Cloud コンソールで、[内部静的 IP アドレスの予約] ページに移動します。

    [内部静的 IP アドレスの予約] に移動

  2. [名前] フィールドに、新しいアドレスの名前を入力します。

  3. [IP バージョン] リストで、[IPv4] を選択します。

  4. [ネットワーク] リストで、[lb-network] を選択します。

  5. [サブネットワーク] リストで、[subnet-us] を選択します。

  6. [リージョン] で [us-east1] を選択します。

  7. [静的 IP アドレス] リストで、[自動的に割り当てる] を選択します。ロードバランサを作成すると、この IP アドレスがロードバランサの転送ルールに関連付けられます。

  8. [予約] をクリックして IP アドレスを予約します。

gcloud

  1. 静的外部 IP アドレスを予約するには、gcloud compute addresses create コマンドを使用します。

     gcloud compute addresses create ADDRESS_NAME \
         --region=us-east1 \
         --subnet=subnet-us
    

    ADDRESS_NAME は、新しいアドレスの名前に置き換えます。

  2. アドレスに関する情報を表示するには、gcloud compute addresses describe コマンドを使用します。

    gcloud compute addresses describe ADDRESS_NAME
    

    返された IP アドレスをコピーして、次のセクションで RESERVED_IP_ADDRESS として使用します。

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

このセクションでは、regional internal Application Load Balancerに次のリソースを作成する方法について説明します。

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

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

  1. 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-east1
    
    gcloud beta compute backend-buckets create backend-bucket-dogs \
        --gcs-bucket-name=BUCKET2_NAME \
        --load-balancing-scheme=INTERNAL_MANAGED \
        --region=us-east1
    
  2. gcloud beta compute url-maps create コマンドを使用して、受信リクエストをバックエンド バケットに転送する URL マップを作成します。

    gcloud beta compute url-maps create lb-map \
        --default-backend-bucket=backend-bucket-cats \
        --region=us-east1
    
  3. gcloud 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-east1
    
  4. gcloud compute target-http-proxies create コマンドを使用して、ターゲット プロキシを作成します。

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

    gcloud compute target-http-proxies create http-proxy \
        --url-map=lb-map \
        --region=us-east1
    

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

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

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

  5. 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-east1
    

    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 \
        --target-http-proxy-region=us-east1 \
        --region=us-east1
    

    RESERVED_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 を作成します。

  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. この例では、 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 アドレスに置き換えます。

次のステップ