このドキュメントでは、外部 HTTP(S) ロードバランサを作成して静的コンテンツのリクエストを Cloud Storage バケットに転送する方法について説明します。バックエンド バケットを使用してロードバランサを構成すると、ユーザーのリージョンに関係なく、/love-to-fetch で始まる URL パスへのリクエストは us-east1 Cloud Storage バケットに送信され、その他のリクエストはすべて europe-north1 Cloud Storage バケットに送信されます。
バックエンドが HTTP(S) で動的コンテンツを配信する場合は、バックエンド バケットの代わりにバックエンド サービスの使用を検討してください。
このタスクを Cloud Console で直接行う際の順を追ったガイダンスについては、[ガイドを表示] をクリックしてください。
以降のセクションでは、[ガイドを表示] をクリックした場合と同じ手順について説明します。
ロードバランサ バックエンドとしての Cloud Storage バケット
外部 HTTP(S) ロードバランサは、URL マップを使用して、指定された URL パスからトラフィックをバックエンドに転送します。
次の図では、ロードバランサが /love-to-fetch/ のパスを含むトラフィックを us-east1 リージョンの Cloud Storage バケットに送信しています。他のすべてのリクエストは、europe-north1 リージョンの Cloud Storage バケットに送信されます。
デフォルトで Cloud Storage では、Cloud CDN が使用するものと同じキャッシュを使用します。バックエンド バケットで Cloud CDN を有効にすると、コンテンツで Cloud CDN コントロールを使用できます。Cloud CDN のコントロールには、キャッシュ モード、署名付き URL、無効化などがあります。Cloud CDN では、サイズの大きいコンテンツ（10 MB 超）をキャッシュに保存することもできます。バックエンド バケットで Cloud CDN を有効にしない場合は、Cloud Storage メタデータで設定されたように、送信元の Cache-Control ヘッダーを使用して、小規模なコンテンツのキャッシュを制御することのみ可能です。
始める前に
設定が次の前提条件を満たしていることを確認します。gcloud または gsutil ユーティリティを使用している場合は、両方をクイックスタート: gsutil ツールの使用の手順でインストールできます。
デフォルト プロジェクトの設定
Console
- Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
-
Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。
-
Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。
-
Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。
gcloud / gsutil
gcloud config set project PROJECT_ID
または
gsutil config set project PROJECT_ID
PROJECT_ID は、このガイドで使用しているプロジェクトに置き換えてください。
権限
このガイドを使用する前に、プロジェクトで Cloud Storage バケットとロードバランサを作成する必要があります。そのためには、プロジェクトのオーナーまたは編集者であるか、次の Compute Engine IAM のロールが必要です。
| タスク | 必要なロール |
|---|---|
| ロードバランサのコンポーネントの作成 | ネットワーク管理者 |
| Cloud Storage バケットを作成する | ストレージ オブジェクト管理者 |
詳細については、次のガイドをご覧ください。
SSL 証明書リソースを設定する
HTTPS ロードバランサの場合、SSL 証明書リソースは、次のドキュメントの説明のように作成します。
Google マネージド証明書を使用することをおすすめします。
この例では、SSL 証明書リソース www-ssl-cert をすでに利用していることを前提としています。
Cloud Storage バケットとコンテンツを準備する
Cloud Storage バケットを準備するプロセスは次のとおりです。
バケットを作成します。
コンテンツをバケットにコピーします。
バケットに公開アクセス権を設定します。
Cloud Storage バケットを作成する
この例では、ロードバランサがアクセスする 2 つの Cloud Storage バケットを作成します。本番環境のデプロイでは、複数の Google Cloud リージョンにオブジェクトを自動的に複製するマルチリージョン バケットを選択することをおすすめします。これにより、コンテンツの可用性が高まり、アプリケーション全体のフォールト トレラントが向上します。
作成する Cloud Storage バケットの名前をメモします。この名前は後で使用します。このガイドでは、これらを BUCKET_1_NAME および BUCKET_2_NAME と呼びます。
Console
Cloud Console で、Cloud Storage の [ブラウザ] に移動します。
[バケットを作成] をクリックします。
[バケットに名前を付ける] ボックスに、命名ガイドラインに沿ったグローバルに一意の名前を入力します。
[データの保存場所の選択] をクリックします。
[ロケーション タイプ] を [リージョン] に設定します。
[ロケーション] を europe-north1 に設定します。このガイドでは BUCKET_1_NAME です。
[作成] をクリックします。
[ブラウザ] をクリックして Cloud Storage ブラウザに戻ります。次の手順で 2 番目のバケットを作成しますが、[ロケーション] は us-east1 に設定します。このガイドでは BUCKET_2_NAME です。
gcloud / gsutil
gsutil mb -p PROJECT_ID -c standard -l europe-north1 -b on gs://BUCKET_1_NAME
gsutil mb -p PROJECT_ID -c standard -l us-east1 -b on gs://BUCKET_2_NAME
BUCKET_1_NAME と BUCKET_2_NAME を作成するバケットの名前に置き換えます。
Cloud Storage バケットにコンテンツを転送する
セットアップを後でテストするために、Cloud Storage の公開バケットから独自の Cloud Storage バケットに次の画像をコピーします。
[Cloud Shell をアクティブにする] をクリックします。
Cloud Shell で次のコマンドを実行します。バケット名の変数は Cloud Storage バケット名に置き換えます。
gsutil cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET_1_NAME/never-fetch/gsutil cp gs://gcp-external-http-lb-with-bucket/two-dogs.jpg gs://BUCKET_2_NAME/love-to-fetch/Cloud Console で、各バケットの詳細ページの [更新] をクリックし、ファイルが正常にコピーされたことを確認します。
Cloud Storage バケットを公開する
Cloud Storage バケットを公開読み取り可能にすると、インターネット上の誰でもオブジェクトの一覧の取得と表示、メタデータ（ACL を除く）の表示を行えるようになります。公開バケットに機密情報を含めないでください。
機密情報が誤って公開される可能性を減らすため、公開オブジェクトと機密データを同じバケットに保存しないでください。詳細については、推奨されるバケット アーキテクチャをご覧ください。
Console
バケット内のすべてのオブジェクトに対するアクセス権をすべてのユーザーに付与するには、バケットごとに次の手順を繰り返します。
Cloud Console で、Cloud Storage の [ブラウザ] に移動します。
バケット名をクリックし、[権限] タブをクリックします。
[追加] をクリックします。
[新しいプリンシパル] ボックスに「
allUsers」と入力します。[ロールを選択] ボックスで、[Cloud Storage] > [Storage オブジェクト閲覧者] を選択します。
[保存] をクリックします。
[一般公開アクセスを許可] をクリックします。
gcloud / gsutil
バケット内のオブジェクトを表示する権限をすべてのユーザーに付与するには、次のコマンドを実行します。
gsutil iam ch allUsers:objectViewer gs://BUCKET_1_NAME
gsutil iam ch allUsers:objectViewer gs://BUCKET_2_NAME
外部 IP アドレスを予約
Cloud Storage バケットを設定したら、オーディエンスがロードバランサにアクセスするために使用するグローバル静的外部 IP アドレスを予約できます。
この手順は省略可能ですが、静的外部 IP アドレスはドメインを指定するための単一アドレスを提供するため、行うことをおすすめします。
Console
Google Cloud Console で [外部 IP アドレス] ページに移動します。
[静的アドレスを予約] をクリックします。
[名前] ボックスに「
example-ip」と入力します。[ネットワーク サービス階層] を [プレミアム] に設定します。
[IP バージョン] で [IPv4] をオンにします。
[タイプ] で [グローバル] をオンにします。
[予約] をクリックします。
gcloud / gsutil
gcloud compute addresses create example-ip \
--network-tier=PREMIUM \
--ip-version=IPV4 \
--global
予約された IPv4 アドレスをメモします。
gcloud compute addresses describe example-ip \
--format="get(address)" \
--global
バックエンド バケットを使用した外部 HTTP(S) ロードバランサの作成
ここでは、HTTP または HTTPS ロードバランサの作成手順について説明します。HTTPS ロードバランサを作成するには、ロードバランサのフロントエンドに SSL 証明書リソースを追加する必要があります。詳細については、SSL 証明書の概要をご覧ください。
Console
構成を開始する
Google Cloud Console の [ロード バランシング] ページに移動します。
- [ロードバランサを作成] をクリックします。
- [HTTP(S) ロード バランシング] カードで [構成を開始] をクリックします。
- [インターネット接続または内部専用] で [インターネットから VM またはサーバーレス サービスへ] を選択します。
- [グローバル / リージョン] で、[グローバル HTTP(S) ロードバランサ（従来型）] を選択します。
- [続行] をクリックします。
バックエンドを構成する
[名前] ボックスに「
http-lb」と入力します。[バックエンドの構成] をクリックします。
[Backend services and backend buckets] ボックスをクリックし、[バックエンド バケットを作成] をクリックします。
[バックエンド バケット名] ボックスに「
cats」と入力します。[Cloud Storage バケット] ボックスで、[参照] をクリックします。
[BUCKET_1_NAME] を選択して、[選択] をクリックします。最初に
catsバックエンド バケットを作成すると、これがデフォルトになります。これにより、一致しないトラフィック リクエストがすべて転送されます。ロードバランサでデフォルトのバックエンド バケットのリダイレクト ルールを変更することはできません。[作成] をクリックします。
同じプロセスを使用して、
dogsという名前のバックエンド バケットを作成し、BUCKET_2_NAME を選択します。[OK] をクリックします。
ホストとパスのルールを構成する
ホストルールとパスマッチャーは、外部 HTTP(S) ロードバランサの URL マップの構成要素です。この例のルールを設定するには:
[ホストとパスのルール] をクリックします。
dogsで、[ホスト] フィールドに「*」、[パス] フィールドに「/love-to-fetch/*」と入力します。
フロントエンドを構成する
[フロントエンドの構成] をクリックします。
以下のオプションが次の値で構成されていることを確認します。
プロパティ 値（値を入力するか、指定されたオプションを選択） プロトコル HTTP ネットワーク サービス階層 プレミアム IP バージョン IPv4 IP アドレス example-ip ポート 80 HTTP ロードバランサの代わりに HTTPS ロードバランサを作成する場合は、SSL 証明書（
gcloud compute ssl-certificates list）が必要です。また、次のようにフィールドに入力する必要があります。プロパティ 値（値を入力するか、指定されたオプションを選択） プロトコル HTTP(S) ネットワーク サービス階層 プレミアム IP バージョン IPv4 IP アドレス example-ip ポート 443 証明書を選択するか、新しい証明書を作成する （省略可）HTTP から HTTPS へのリダイレクトを有効にする このチェックボックスを使用して、ポート 80 からポート 443 へのリダイレクトを有効にします。 このチェックボックスをオンにすると、HTTPS ロードバランサと同じ IP アドレスを使用し、HTTP リクエストをロードバランサの HTTPS フロントエンドにリダイレクトする追加の部分的な HTTP ロードバランサが作成されます。
このチェックボックスは、HTTPS プロトコルが選択されていて、予約済みの IP アドレスが使用されている場合にのみ選択できます。
[完了] をクリックします。
構成を確認する
[確認と完了] をクリックします。
[フロントエンド]、[ホストとパスのルール]、[バックエンド バケット] を確認します。
[作成] をクリックし、ロードバランサが作成されるのを待ちます。
ロードバランサの名前（http-lb）をクリックします。
ロードバランサの IP アドレスをメモします（次のタスクで使用します）。このガイドではこれを IP_ADDRESS と呼びます。
gcloud / gsutil
バックエンドを構成する
gcloud compute backend-buckets create dogs \
--gcs-bucket-name=BUCKET_1_NAME
gcloud compute backend-buckets create cats \
--gcs-bucket-name=BUCKET_2_NAME
URL マップの構成
gcloud compute url-maps create http-lb \
--default-backend-bucket=cats
gcloud compute url-maps add-path-matcher http-lb \
--path-matcher-name=path-matcher-2 \
--new-hosts=* \
--backend-bucket-path-rules="/love-to-fetch/*=dogs" \
--default-backend-bucket=cats
ターゲット プロキシの構成
gcloud compute target-http-proxies create http-lb-proxy \
--url-map=http-lb
転送ルールの構成
gcloud compute forwarding-rules create http-lb-forwarding-rule \
--load-balancing-scheme=EXTERNAL \
--network-tier=PREMIUM \
--address=example-ip \
--global \
--target-http-proxy=http-lb-proxy \
--ports=80
ロードバランサにトラフィックを送信する
ロードバランサの構成から数分後、ロードバランサの IP アドレスへのトラフィックの送信を開始できます。
Console
ウェブブラウザで次のアドレスに移動してロードバランサをテストします。IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。
http://IP_ADDRESS/love-to-fetch/two-dogs.jpg
http://IP_ADDRESS/never-fetch/three-cats.jpg
HTTP ロードバランサを設定した場合は、ブラウザが HTTPS に自動的にリダイレクトしていないことを確認してください。
gcloud / gsutil
curl コマンドを使用して、次の URL からのレスポンスをテストします。IP_ADDRESS は、ロードバランサの IPv4 アドレスに置き換えます。
curl http://IP_ADDRESS/love-to-fetch/two-dogs.jpg
curl http://IP_ADDRESS/never-fetch/three-cats.jpg
制限事項
- バックエンド バケットは、グローバル外部 HTTP(S) ロードバランサとグローバル外部 HTTP(S) ロードバランサ（従来型）でのみサポートされます。リージョン外部 HTTP(S) ロードバランサやその他の種類のロードバランサではサポートされません。
Identity-Aware Proxy ではバックエンド バケットはサポートされていません。
次のステップ