このガイドでは、インターネット ネットワーク エンドポイント グループ(NEG)でカスタムの送信元を使用する場合の基礎知識について説明します。カスタムの送信元は、Google Cloud の外部にあるインターネット エンドポイントです。インターネット NEG を外部 HTTP(S) ロードバランサのバックエンドとして使用し、Cloud CDN キャッシングを使用してパフォーマンスを向上させることができます。
このガイドでは、カスタムの送信元サーバーに backend.example.com
でプロキシする Cloud CDN 対応バックエンド サービスを使用して、グローバル外部 HTTP(S) ロードバランサを構成する方法を説明します。
この例では、ロードバランサはクライアントからの HTTPS リクエストを受け入れ、HTTP/2 としてカスタムの送信元にプロキシします。この例では、カスタムの送信元が HTTP/2 をサポートしていることを前提としています。
他のオプションとしては、HTTP や HTTP/2 のリクエストを受け入れるようにロードバランサを構成し、カスタムの送信元にリクエストをプロキシする場合は HTTPS を使用します。
このガイドでは、すでにロードバランサが設定され、新しいカスタムの送信元のバックエンドを追加していることを前提としています。
アーキテクチャのサンプルを次に示します。
図では、www.example.com
に IP アドレス 120.1.1.1
のロードバランサ フロントエンドがあります。キャッシュミスが発生した場合、/cart/id/1223515
へのユーザー リクエストはカスタムの送信元から HTTP/2 経由で取得されます。その他の受信トラフィックは、Compute Engine VM を使用する Google Cloud バックエンド サービスか、URL マップに基づいてバックエンド バケットに転送されます。
始める前に
このガイドに進む前に、次の内容を理解しておいてください。
権限
このガイドに記載された手順を行う前に、インターネット NEG を作成し、プロジェクト内の外部 HTTP(S) ロードバランサを作成するか、変更しておく必要があります。そのためには、プロジェクトのオーナーまたは編集者であるか、次の両方の Compute Engine IAM ロールを持っている必要があります。
タスク | 必要なロール |
---|---|
ロードバランサ コンポーネントの作成と変更 | ネットワーク管理者 |
NEG の作成と変更 | Compute インスタンス管理者 |
カスタムの送信元を持つロードバランサの構成
このガイドでは、インターネット NEG を構成してテストする方法を説明します。
設定の概要
インターネット NEG の設定には、次の作業を行います。
- インターネット NEG におけるインターネット エンドポイントを定義します。
- インターネット NEG をバックエンドとしてバックエンド サービスに追加します。
- 外部 HTTP(S) ロードバランサの URL マップを構成し、このバックエンド サービスにマッピングするユーザー トラフィックを定義します。
この例では、次のリソースを作成します。
120.1.1.1
IP アドレスの転送ルールで、受信リクエストをターゲット プロキシに転送します。- 転送ルールの
networkTier
は、PREMIUM
である必要があります。 - ターゲット プロキシによって、各リクエストが URL マップと照合され、各リクエストに適したバックエンド サービスが決定されます。
- カスタムの送信元の場合、ターゲット プロキシは
TargetHttpProxy
かTargetHttpsProxy
である必要があります。この例ではTargetHttpsProxy
を使用しています。 - バックエンド サービスで Cloud CDN を有効にすると(省略可)、Cloud CDN キャッシュからのレスポンスをキャッシュして処理できます。
- バックエンド サービス構成により、トラフィックが 1 つのインターネット NEG に転送されます。このインターネット NEG には、Cloud CDN キャッシュミスが発生したときに外部 HTTP(S) ロードバランサがトラフィックを送信するネットワーク エンドポイントが含まれます。
- この例には、ユーザー定義のリクエスト ヘッダーが含まれています。これはカスタムの送信元が HTTP リクエスト
Host
ヘッダーの特定の値を想定している場合に必要です。
設定は次のようになります。
NEG とインターネット エンドポイントの作成
Console
- Google Cloud Console で、[ネットワーク エンドポイント グループ] ページに移動します。
- [ネットワーク エンドポイント グループを作成] をクリックします。
- ネットワーク エンドポイント グループの名前として「
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 Console で、[負荷分散] ページに移動します。
- バックエンド サービスを既存のロードバランサに追加するには、外部 HTTP(S) ロードバランサを選択し、メニュー をクリックして [編集] を選択します。
- [バックエンドの構成] をクリックします。
- [バックエンド サービスとバックエンド バケットの作成または選択] プルダウン メニューで、[バックエンド サービス] > [バックエンド サービスを作成] の順に選択します。
- バックエンド サービスの名前を
images
に設定します。 - [バックエンド タイプ] で [インターネット ネットワーク エンドポイント グループ] を選択します。
- ロードバランサからインターネット NEG へ使用するプロトコルを選択します。この例では、[HTTP/2] を選択します。
- [新しいバックエンド] > [インターネット ネットワーク エンドポイント グループ] で [
example-fqdn-neg
] を選択し、[完了] をクリックします。 - [Cloud CDN を有効にする] を選択します。
- デフォルトのキャッシュ モードと TTL の設定を維持します。
- [詳細構成] の [カスタム リクエスト ヘッダー] で [ヘッダーを追加] をクリックします。
- [ヘッダー名] に「
Host
」と入力します。 - [ヘッダーの値] に「
backend.example.com
」と入力します。
- [ヘッダー名] に「
- [作成] をクリックします。
- ウィンドウを開いたままにして続行します。
バックエンド サービスを既存の URL マップに接続する
- [ホストとパスのルール] をクリックします。
- 先頭行または最初の数行の右側の列には Google Cloud サービスがあり、それらの 1 つに [ホスト] と [パス] へのデフォルト ルール
Any unmatched (default)
がすでに入力されています。 - 右側の列に
images
が選択されている行があることを確認します。存在しない場合は、[ホストとパスのルールを追加] をクリックして、images
を選択します。他のフィールドには次のように入力します。- [ホスト] に「
*
」と入力します。 - [パス] に「
/cart/id/1223515
」と入力します。
- [ホスト] に「
確認と完了
- [確認と完了] をクリックします。
- 現在の設定と作成しようとしている内容を比較します。
- すべて問題なければ、[作成] をクリックして外部 HTTP(S) ロードバランサを作成します。
gcloud
NEG の新しいバックエンド サービスを作成します。
gcloud compute backend-services create images \ --global \ --enable-cdn \ --protocol=HTTP2
バックエンド サービスを構成して、カスタム リクエスト ヘッダー
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 が接続された新しいバックエンド サービスの名前
外部 HTTP(S) ロードバランサのテスト
ロードバランサを構成したので、ロードバランサの IP アドレスにトラフィックを送信できるようになりました。ドメインを構成した場合、ドメイン名にトラフィックを送信することもできます。ただし、DNS の伝播が完了するまでに時間がかかることがあるため、テスト用の IP アドレスで始めることもできます。
- Google Cloud Console の [負荷分散] ページに移動します。
[負荷分散] ページに移動 - 作成したロードバランサをクリックします。
- ロードバランサの 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 'backend.example.com:443' --connect-to test.example.com:443:IP_ADDRESS:443
(省略可)カスタム ドメインを使用する場合は、更新された DNS 設定が反映されるまでに時間がかかる場合があります。次に、ウェブブラウザでドメイン(
backend.example.com
など)をテストします。トラブルシューティングについては、カスタムの送信元とインターネット NEG に関する問題のトラブルシューティングをご覧ください。
キャッシュ モードの使用
Google Cloud の外部の送信元からコンテンツを取得してキャッシュに保存するように Cloud CDN を構成している場合、アプリケーションまたはオブジェクト ストレージ バケットを更新して有効なキャッシュ ヘッダーを送信することが困難になる場合があります。
これは、送信元サーバーが設定するキャッシュ ヘッダーに一貫性がない場合、TTL が短すぎる、または長すぎる場合、レガシー アプリケーションのキャッシュ ディレクティブなど、無効なキャッシュ ディレクティブが設定されている場合にも当てはまります。
以下を行うことで、送信元からすべてのコンテンツがキャッシュに保存され、送信元によって設定された TTL をオーバーライドするように Cloud CDN を構成できます。
- キャッシュ モードを
FORCE_CACHE_ALL
に設定します。 - 送信元からのすべてのレスポンスに TTL を適用するには、デフォルトの TTL を構成します。
送信元からの静的レスポンスを自動的にキャッシュに保存するには、CACHE_ALL_STATIC
キャッシュ モード設定を使用します。
HTTP キャッシュ ディレクティブを使用して、キャッシュへの保存をレスポンスごとに制御するには、元のヘッダー(USE_ORIGIN_HEADERS
)を使用するようにキャッシュ モードを設定します。Cloud CDN が認識するキャッシュ ディレクティブ、および Cloud CDN によってキャッシュに保存されないコンテンツについては、キャッシュ可能なコンテンツとキャッシュに保存できないコンテンツをご覧ください。
送信元がユーザーごとに動的なコンテンツを配信していない場合は、送信元からのすべてのレスポンスをキャッシュに保存することをおすすめします。これを行うには、FORCE_CACHE_ALL
モードを使用します。このモードでは、コンテンツ タイプやキャッシュ ディレクティブに関係なく、すべてのレスポンスがキャッシュに保存されます。
バックエンドで Cloud CDN を有効にする際に明示的にキャッシュ モードを選択しなかった場合は、API と gcloud
コマンドライン ツールがデフォルトで USE_ORIGIN_HEADERS
に設定され、Cloud Console がデフォルトで CACHE_ALL_STATIC
に設定されます。
Cloud CDN を無効にする
Console
単一のバックエンド サービスに対して Cloud CDN を無効にする
- Google Cloud Console で、[Cloud CDN] ページに移動します。
- 送信元の行の右側で [メニュー] をクリックし、[編集] を選択します。
- Cloud CDN の使用を停止するバックエンド サービスのチェックボックスをオフにします。
- [更新] をクリックします。
送信元のすべてのバックエンド サービスに対して Cloud CDN を削除する
- Cloud Console で、[Cloud CDN] ページに移動します。
- 送信元の行の右側で [メニュー] をクリックし、[削除] を選択します。
- 確認のため、もう一度 [削除] をクリックします。
gcloud
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --no-enable-cdn
Cloud CDN を無効にしても、キャッシュの無効化や消去は行われません。Cloud CDN を無効にして再度有効にすると、キャッシュに保存されたコンテンツの大半はキャッシュに残っています。キャッシュのコンテンツを使用しないようにするには、コンテンツの無効化が必要です。
次のステップ
- Cloud CDN がキャッシュからレスポンスを配信しているかどうかを確認するには、ログの表示をご覧ください。
- キャッシュに保存可能なコンテンツと保存できないコンテンツについては、キャッシュの概要をご覧ください。
- GFE の接続拠点を確認するには、キャッシュのロケーションをご覧ください。