コンテンツがオンプレミスまたは別のクラウドでホストされている場合は、外部バックエンドを使用できます。外部バックエンドを使用すると、Google の Cloud CDN からコンテンツを配信できます。
このドキュメントでは、Cloud CDN の外部バックエンドとして、Amazon Simple Storage Service(Amazon S3)や Azure Blob Storage などのサードパーティのオブジェクト ストレージを設定する手順について説明します。外部バックエンドと Cloud CDN は、外部アプリケーション ロードバランサと連携して機能します。
アーキテクチャ
外部バックエンドを作成するには、サードパーティのストレージ サービスをロードバランサのバックエンドとしてポイントするインターネット ネットワーク エンドポイント グループ(NEG)を作成します。インターネット NEG は外部バックエンドに使用されます。
サードパーティのストレージ バケットをバックエンドとして設定するには、次のことを行う必要があります。
- コンテンツを配信するサードパーティのストレージ バケットを準備します。
- バケットの FQDN を使用するインターネット NEG を作成します。
- インターネット NEG をバックエンドとして使用するように外部アプリケーション ロードバランサを構成します。
- セットアップをテストします。
コンテンツを配信するためのバケットの準備
Google Cloud でのセットアップを開始する前に、バケットが正しく構成されていることを確認してください。以下の手順では Amazon S3 のバケットを使用します。このため、Amazon S3 のバケットとオブジェクトに変更を行うための権限が付与されていることを前提としています。
Amazon S3 バケットとバケット内のオブジェクトが一般公開されていること、または Amazon S3 バケットに対して非公開送信元の認証が構成されていることを確認してください。
コンテンツが、キャッシュに保存可能なコンテンツに記載されている要件を満たしていることを確認します。オブジェクトのメタデータを追加する必要がある場合は、AWS のナレッジベース(オブジェクトのメタデータの編集など)をご覧ください。
インターネット NEG を設定する際に Amazon S3 バケットのエンドポイント(FQDN)が必要になります。エンドポイントの情報を取得するには、AWS のナレッジベース(バケットへのアクセスなど)の手順に沿って操作してください。オブジェクトの概要ページから Amazon S3 エンドポイント URL を取得することもできます。
バケットのホスト名を使用するインターネット NEG を作成する
わかりやすくするために、この例では FQDN backend.example.com
を使用します。これは、サードパーティのストレージ バケットの FQDN(http://unique-name-bucket.s3-us-west-1.amazonaws.com/
など)に置き換えてください。
このガイドでは、外部アプリケーション ロードバランサで外部バックエンド(カスタム送信元とも呼ばれます)を使用する基本的な方法について説明します。外部バックエンドは Google Cloud の外部にあるエンドポイントです。外部アプリケーション ロードバランサで外部バックエンドを使用する場合は、Cloud CDN キャッシュを使用してパフォーマンスを向上させることができます。
このガイドでは、外部バックエンド サーバーに backend.example.com
でプロキシする Cloud CDN 対応バックエンド サービスを使用して、グローバル外部アプリケーション ロードバランサを構成する方法を説明します。
この例では、ロードバランサはクライアントからの HTTPS リクエストを受け入れ、HTTPS として外部バックエンドにプロキシします。この例では、外部バックエンドが HTTPS をサポートしていることを前提としています。
他のオプションとしては、HTTP や HTTPS のリクエストを受け入れるようにロードバランサを構成し、外部バックエンドにリクエストをプロキシする場合は HTTPS を使用します。
このガイドでは、すでにロードバランサが設定され、新しい外部バックエンドを追加していることを前提としています。詳細については、マネージド インスタンス グループのバックエンドを使用して従来のアプリケーション ロードバランサを設定するをご覧ください。
図 1 にサンプル アーキテクチャを示します。
図では、www.example.com
に IP アドレス 120.1.1.1
のロードバランサ フロントエンドがあります。キャッシュミスが発生した場合、/cart/id/1223515
へのユーザー リクエストは外部バックエンドから HTTPS 経由で取得されます。その他の受信トラフィックは、Compute Engine VM を使用する Google Cloud バックエンド サービスか、URL マップに基づいてバックエンド バケットに転送されます。
始める前に
このガイドに進む前に、次の内容を理解しておいてください。
インターネット ネットワーク エンドポイント グループの概要をご覧ください。ここには、制限事項も記載されています。
権限
このガイドの説明に従って操作するには、インターネット ネットワーク エンドポイント グループ(NEG)を作成し、プロジェクトで外部アプリケーション ロードバランサを作成または変更する必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、次の Compute Engine IAM のロールがすべて必要です。
タスク | 必要なロール |
---|---|
ロードバランサ コンポーネントの作成と変更 | ネットワーク管理者 |
NEG の作成と変更 | Compute インスタンス管理者 |
外部バックエンドを使用するようにロードバランサを構成する
このセクションでは、インターネット NEG を構成してテストする方法を説明します。
設定の概要
インターネット NEG の設定には、次の作業を行います。
- インターネット NEG におけるインターネット エンドポイントを定義します。
- インターネット NEG をバックエンドとしてバックエンド サービスに追加します。
- 外部アプリケーション ロードバランサの URL マップを構成し、このバックエンド サービスにマッピングするユーザー トラフィックを定義します。
- 必要な IP 範囲を許可リストに登録します。
この例では、次のリソースを作成します。
120.1.1.1
IP アドレスの転送ルールで、受信リクエストをターゲット プロキシに転送します。- 転送ルールの
networkTier
は、PREMIUM
である必要があります。 - ターゲット プロキシによって、各リクエストが URL マップと照合され、各リクエストに適したバックエンド サービスが決定されます。
- 外部バックエンドの場合、ターゲット プロキシは
TargetHttpProxy
かTargetHttpsProxy
である必要があります。この例ではTargetHttpsProxy
を使用しています。 - バックエンド サービスで Cloud CDN を有効にすると(省略可)、Cloud CDN キャッシュからのレスポンスをキャッシュして処理できます。
- この例には、カスタム ヘッダーが含まれています。これは外部バックエンドが HTTP リクエスト
Host
ヘッダーの特定の値を想定している場合に必要です。
設定は次のようになります。
NEG とインターネット エンドポイントを作成する
コンソール
- Google Cloud コンソールの [ネットワーク エンドポイント グループ] ページに移動します。
- [ネットワーク エンドポイント グループを作成] をクリックします。
- ネットワーク エンドポイント グループの名前として「
example-fqdn-neg
」を入力します。 - [ネットワーク エンドポイント グループの種類] で、[ネットワーク エンドポイント グループ(インターネット)] を選択します。
- [デフォルト ポート] に「
443
」と入力します。 - [新しいネットワーク エンドポイント] で [完全修飾ドメイン名とポート] を選択します。
- FQDN の場合は、「
backend.example.com
」と入力します。 - [ポートタイプ] で [デフォルト] を選択し、[ポート番号] が
443
であることを確認します。 - [作成] をクリックします。
gcloud
インターネット NEG を作成し、
--network-endpoint-type
をinternet-fqdn-port
(外部バックエンドに到達可能なホスト名とポート)に設定します。gcloud compute network-endpoint-groups create example-fqdn-neg \ --network-endpoint-type="internet-fqdn-port" --global
エンドポイントを NEG に追加します。ポートが指定されていない場合、バックエンド サービスで構成されるプロトコルによって、デフォルトのポート選択はポート
80
(HTTP)または、443
(HTTPS、HTTP/2)になります。--global
フラグが含まれていることを確認してください。gcloud compute network-endpoint-groups update example-fqdn-neg \ --add-endpoint="fqdn=backend.example.com,port=443" \ --global
作成されたインターネット NEG を一覧表示します。
gcloud compute network-endpoint-groups list --global
出力:
NAME LOCATION ENDPOINT_TYPE SIZE example-fqdn-neg global INTERNET_FQDN_PORT 1
その NEG 内のエンドポイントを一覧表示します。
gcloud compute network-endpoint-groups list-network-endpoints example-fqdn-neg \ --global
出力:
INSTANCE IP_ADDRESS PORT FQDN backend.example.com
ロードバランサに外部バックエンドを追加する
次の例では、既存のロードバランサを更新します。
既存のロードバランサのデフォルトのサービスは、Google Cloud サービスです。この例では、cart/id/1223515
へのすべてのリクエストを、インターネット NEG に関連付けられた images
バックエンド サービスに送信するパスマッチャーの追加により、既存の URL マップを変更します。
Console
バックエンド サービスの作成とインターネット NEG の追加
- Google Cloud コンソールの [ロード バランシング] ページに移動します。
- バックエンド サービスを既存のロードバランサに追加するには、従来のアプリケーション ロードバランサを選択し、 「メニュー」をクリックして [編集] を選択します。
- [バックエンドの構成] をクリックします。
- [バックエンド サービスとバックエンド バケット] メニューで、[バックエンド サービスを作成] を選択します。
- バックエンド サービスの名前を
images
に設定します。 - [バックエンド タイプ] で [インターネット ネットワーク エンドポイント グループ] を選択します。
- ロードバランサからインターネット NEG へ使用するプロトコルを選択します。この例では [HTTPS] を選択します。
- [新しいバックエンド] > [インターネット ネットワーク エンドポイント グループ] で [
example-fqdn-neg
] を選択し、[完了] をクリックします。 - [Cloud CDN を有効にする] を選択します。
- (省略可)キャッシュ モードと TTL の設定を変更します。
- [詳細構成] の [カスタム リクエスト ヘッダー] で [ヘッダーを追加] をクリックします。
- [ヘッダー名] に「
Host
」と入力します。 - [ヘッダーの値] に「
backend.example.com
」と入力します。
- [ヘッダー名] に「
- [作成] をクリックします。
- ウィンドウを開いたままにして続行します。
バックエンド サービスを既存の URL マップに接続する
- [ホストとパスのルール] をクリックします。
- 先頭行または最初の数行の右側の列には Google Cloud サービスがあり、それらの 1 つに [ホスト] と [パス] へのデフォルト ルール
Any unmatched (default)
がすでに入力されています。 - 右側の列に
images
が選択されている行があることを確認します。存在しない場合は、[ホストとパスのルールを追加] をクリックして、images
を選択します。他のフィールドには次のように入力します。- [ホスト] に「
*
」と入力します。 - [パス] に「
/cart/id/1223515
」と入力します。
- [ホスト] に「
確認と完了
- [確認と完了] をクリックします。
- 現在の設定と作成しようとしている内容を比較します。
- すべて問題なければ、[更新] をクリックします。
gcloud
NEG の新しいバックエンド サービスを作成します。
gcloud compute backend-services create images \ --global \ --enable-cdn \ --cache-mode=CACHE_MODE \ --protocol=HTTP2
CACHE_MODE を次のいずれかに置き換えて、キャッシュ モードを設定します。
CACHE_ALL_STATIC
: 静的コンテンツを自動的にキャッシュに保存します。USE_ORIGIN_HEADERS
(デフォルト): コンテンツをキャッシュに保存するには、送信元で有効なキャッシュ ヘッダーを設定する必要があります。FORCE_CACHE_ALL
:Cache-Control
レスポンス ヘッダー内のprivate
、no-store
、またはno-cache
のディレクティブを無視して、すべてのコンテンツをキャッシュに保存します。
バックエンド サービスを構成して、カスタム リクエスト ヘッダー
Host: backend.example.com
をリクエストに追加します。gcloud compute backend-services update images \ --custom-request-header "Host: backend.example.com" --global
backend-services add-backend
コマンドを使用して、インターネット NEG をバックエンド サービスに追加します。gcloud compute backend-services add-backend images \ --network-endpoint-group "example-fqdn-neg" \ --global-network-endpoint-group \ --global
新しいマッチング ルールを作成して、新しいバックエンド サービスをロードバランサの URL マップに接続し、バックエンドにリクエストを転送します。
gcloud compute url-maps add-path-matcher EXAMPLE_URL_MAP \ --default-service=GCP_SERVICE_EXAMPLE \ --path-matcher-name=CUSTOM_ORIGIN_PATH_MATCHER_EXAMPLE \ --backend-service-path-rules=/CART/ID/1223515=IMAGES
次のように置き換えます。
EXAMPLE_URL_MAP
: 既存の URL マップの名前GCP_SERVICE_EXAMPLE
: 既存のデフォルトのバックエンド サービスの名前CUSTOM_ORIGIN_PATH_MATCHER_EXAMPLE
: この新しいパスルールの名前/CART/ID/1223515
パスIMAGES
: インターネット NEG が接続された新しいバックエンド サービスの名前
必要な IP 範囲を許可リストに登録する
外部アプリケーション ロードバランサからインターネット NEG へのリクエストの送信を許可するには、dig
や nslookup
などのツールを使用して、_cloud-eoips.googleusercontent.com
DNS TXT レコードをクエリする必要があります。
たとえば、次の dig
コマンドを実行します。
dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2
出力には、次のように 2 つの IP 範囲が含まれます。
34.96.0.0/20
34.127.192.0/18
IP 範囲を書き留め、ファイアウォールまたはクラウドのアクセス制御リスト(ACL)でこれらの範囲が許可されていることを確認します。
詳細については、リクエストの認証をご覧ください。
ドメインをロードバランサに接続する
ロードバランサが作成されたら、ロードバランサに関連付けられた IP アドレスをメモします(例: 30.90.80.100
)。ドメイン登録サービスを使用して A
レコードを作成し、ドメインがロードバランサを参照するようにします。SSL 証明書に複数のドメインを追加する場合は、それぞれについて A
レコードを追加して、すべてがロードバランサの IP アドレスを指すようにする必要があります。たとえば、www.example.com
と example.com
に A
レコードを作成するには、次のようにします。
NAME TYPE DATA www A 30.90.80.100 @ A 30.90.80.100
DNS プロバイダとして Cloud DNS を使用する場合は、レコードの追加、変更、削除をご覧ください。
外部アプリケーション ロードバランサをテストする
ロードバランサを構成したので、ロードバランサの IP アドレスにトラフィックを送信できるようになりました。ドメインを構成した場合、ドメイン名にトラフィックを送信することもできます。ただし、DNS の伝播が完了するまでに時間がかかることがあるため、テスト用の IP アドレスで始めることもできます。
Google Cloud コンソールの [ロード バランシング] ページに移動します。
作成したロードバランサをクリックします。
ロードバランサの IP アドレスをメモします。
HTTP ロードバランサを作成した場合は、ウェブブラウザで
http://IP_ADDRESS
を使用してロードバランサをテストできます。IP_ADDRESS
をロードバランサの IP アドレスに置き換えます。helloworld
サービスのホームページが表示されることを確認します。HTTPS ロードバランサを作成した場合は、ウェブブラウザ(
https://IP_ADDRESS
)を使用してロードバランサをテストできます。IP_ADDRESS
をロードバランサの IP アドレスに置き換えます。helloworld
サービスのホームページが表示されます。結果に問題があり、Google マネージド証明書を使用している場合は、証明書リソースのステータスが ACTIVE であることを確認します。詳しくは、Google マネージド SSL 証明書リソースのステータスをご覧ください。
あるいは、ローカルマシンのコマンドラインから
curl
を使用することもできます。IP_ADDRESS
は、ロードバランサの IPv4 アドレスに置き換えます。Google マネージド証明書を使用している場合は、ロードバランサの IP アドレスを指すドメインをテストします。次に例を示します。
curl -s 'https://www.example.com:443' --resolve www.example.com:443:IP_ADDRESS
省略可: カスタム ドメインを使用する場合は、更新された DNS 設定が反映されるまでに時間がかかる場合があります。次に、ウェブブラウザでドメイン(
backend.example.com
など)をテストします。トラブルシューティングについては、外部バックエンドとインターネット NEG に関する問題のトラブルシューティングをご覧ください。
Cloud CDN をテストする
テスト 1: バケットのエンドポイントに直接ヒットする
このテストでは、VM から time
コマンドと wget
コマンドを使用します。この例では、バケット backend.example.com
から /cart/id/1223515/image.jpg
をダウンロードします。
出力から、リクエスト全体で 780 ミリ秒を要することがわかります。今回は、Amazon S3 から 3.3 MB のイメージを直接取得します。
time wget backend.example.com/cart/id/1223515/image.jpg
--2020-06-26 18:22:46-- backend.example.com/cart/id/1223515/image.jpg Resolving backend.example.com (backend.example.com)... 52.219.120.233 Connecting to backend.example.com (backend.example.com)|52.219.120.233|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3447106 (3.3M) [image/jpeg] Saving to: '/cart/id/1223515/image.jpg.47' /cart/id/1223515/image.jpg.47 100%[==============================================================================================================================================>] 3.29M 6.25MB/s in 0.5s 2020-06-26 18:22:47 (6.25 MB/s) - '/cart/id/1223515/image.jpg.47' saved [3447106/3447106] real 0m0.780s user 0m0.003s sys 0m0.012s
テスト 2: Cloud CDN を使用して最初のリクエストを行う
このテストでは、ロードバランサの IP アドレスを使用して /cart/id/1223515/image.jpg
ファイルを取得します。これは最初のリクエストであるため、ミスとなり、Cloud CDN は送信元(Amazon S3)からイメージを取得します。出力から、リクエストに 844 ミリ秒かかったことがわかります。
time wget http://LOAD_BALANCER_IP_ADDRESS/cart/id/1223515/image.jpg
--2020-06-26 18:19:27-- http://LOAD_BALANCER_IP_ADDRESS/cart/id/1223515/image.jpg Connecting to LOAD_BALANCER_IP_ADDRESS:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3447106 (3.3M) [image/jpeg] Saving to: '/cart/id/1223515/image.jpg.44' /cart/id/1223515/image.jpg.44 100%[==============================================================================================================================================>] 3.29M 8.23MB/s in 0.4s 2020-06-26 18:19:28 (8.23 MB/s) - '/cart/id/1223515/image.jpg.44' saved [3447106/3447106] real 0m0.844s user 0m0.003s sys 0m0.012s
テスト 3: CDN から 2 回目のリクエストを行う
このロードバランサの IP を使用して、さらにリクエストを送信します。今回は、キャッシュに保存されたレスポンスが取得されるため、前の 2 つのテストよりも処理時間が短くなるはずです。
同じ LB IP LOAD_BALANCER_IP_ADDRESS を再度使用します。出力から、リクエストの処理時間がわずか 18 ミリ秒であったことがわかります。
time wget http://LOAD_BALANCER_IP_ADDRESS/cart/id/1223515/image.jpg
--2020-06-26 18:19:29-- http://LOAD_BALANCER_IP_ADDRESS/cart/id/1223515/image.jpg Connecting to LOAD_BALANCER_IP_ADDRESS:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3447106 (3.3M) [image/jpeg] Saving to: '/cart/id/1223515/image.jpg.45' /cart/id/1223515/image.jpg.45 100%[==============================================================================================================================================>] 3.29M --.-KB/s in 0.008s 2020-06-26 18:19:29 (423 MB/s) - '/cart/id/1223515/image.jpg.45' saved [3447106/3447106] real 0m0.018s user 0m0.001s sys 0m0.010s
ログを使用した確認
Cloud CDN のログは、Cloud CDN 対応バックエンドが接続されている外部アプリケーション ロードバランサに関連付けられます。ログを使用すると、リクエストがヒットまたはミスのいずれであるかを確認できます。Cloud CDN ログの詳細については、ログの表示をご覧ください。
制限事項
サードパーティのバケットとオブジェクトが公開されている必要があります。また、非公開送信元の認証を構成した場合は、バケットとオブジェクトを非公開にしておくこともできます。外部バックエンドは、署名付き URL や署名付き Cookie など、コンテンツ認証のための他の方法をサポートしていません。
HTTP リクエストの
Host
ヘッダーに特定の値を必要とする外部のバックエンド サービス使用する場合、Host
ヘッダーをその値に設定するようにバックエンド サービスを構成する必要があります。カスタム リクエスト ヘッダーを構成しない場合、バックエンド サービスは、クライアントが Google Cloud の外部アプリケーション ロードバランサへの接続に使用したHost
ヘッダーを保持します。カスタム ヘッダーの概要については、カスタム リクエスト ヘッダーを構成するをご覧ください。具体的な例については、外部バックエンドでロードバランサの構成をご覧ください。
次のステップ
- Cloud CDN がキャッシュからレスポンスを提供しているかどうかを確認するには、キャッシュのログと指標をご覧ください。
- キャッシュに保存可能なコンテンツと保存できないコンテンツについては、キャッシュの概要をご覧ください。
- GFE の接続拠点を確認するには、キャッシュのロケーションをご覧ください。