サードパーティのオブジェクト ストレージの設定

コンテンツがオンプレミスまたは別のクラウドでホストされている場合は、外部バックエンドを使用できます。外部バックエンドを使用すると、Google の Cloud CDN からコンテンツを配信できます。

このドキュメントでは、Cloud CDN の外部バックエンドとして、Amazon Simple Storage Service(Amazon S3)や Azure Blob Storage などのサードパーティのオブジェクト ストレージを設定する手順について説明します。外部バックエンドと Cloud CDN は、外部アプリケーション ロードバランサと連携して機能します。

アーキテクチャ

外部バックエンドを作成するには、サードパーティのストレージ サービスをロードバランサのバックエンドとしてポイントするインターネット ネットワーク エンドポイント グループ(NEG)を作成します。インターネット NEG は外部バックエンドに使用されます。

サードパーティのストレージ バケットをバックエンドとして設定するには、次のことを行う必要があります。

  1. コンテンツを配信するサードパーティのストレージ バケットを準備します。
  2. バケットの FQDN を使用するインターネット NEG を作成します。
  3. インターネット NEG をバックエンドとして使用するように外部アプリケーション ロードバランサを構成します。
  4. セットアップをテストします。

コンテンツを配信するためのバケットの準備

Google Cloud でのセットアップを開始する前に、バケットが正しく構成されていることを確認してください。以下の手順では Amazon S3 バケットを使用します。このため、Amazon S3 バケットとオブジェクトに変更を行うための権限が付与されていることを前提としています。

  1. Amazon S3 バケットとバケット内のオブジェクトが一般公開されていること、または Amazon S3 バケットに対して非公開送信元の認証が構成されていることを確認してください。

  2. コンテンツが、キャッシュに保存可能なコンテンツに記載されている要件を満たしていることを確認してください。オブジェクトのメタデータを追加する必要がある場合は、AWS のナレッジベース(オブジェクトのメタデータの編集など)をご覧ください。

  3. インターネット 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 にサンプル アーキテクチャを示します。

図 1. 外部バックエンドに S3 バケットを使用する例。
図 1. 外部バックエンドに S3 バケットを使用する例。

図では、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 マップと照合され、各リクエストに適したバックエンド サービスが決定されます。
    • 外部バックエンドの場合、ターゲット プロキシは TargetHttpProxyTargetHttpsProxy である必要があります。この例では TargetHttpsProxy を使用しています。
  • バックエンド サービスで Cloud CDN を有効にすると(省略可)、Cloud CDN キャッシュからのレスポンスをキャッシュに保存して処理できます。
  • この例には、カスタム ヘッダーが含まれています。これは外部バックエンドが HTTP リクエスト Host ヘッダーの特定の値を想定している場合に必要です。

設定は次のようになります。

図 2. バックエンドとして Amazon S3 バケットを使用する Cloud CDN。
図 2. バックエンドとして Amazon S3 バケットを使用する Cloud CDN。

NEG とインターネット エンドポイントを作成する

コンソール

  1. Google Cloud コンソールの [ネットワーク エンドポイント グループ] ページに移動します。

    [ネットワーク エンドポイント グループ] に移動

  2. [ネットワーク エンドポイント グループを作成] をクリックします。
  3. ネットワーク エンドポイント グループの名前として「example-fqdn-neg」を入力します。
  4. [ネットワーク エンドポイント グループの種類] で、[ネットワーク エンドポイント グループ(インターネット)] を選択します。
  5. [デフォルト ポート] に「443」と入力します。
  6. [新しいネットワーク エンドポイント] で [完全修飾ドメイン名とポート] を選択します。
  7. FQDN の場合は、「backend.example.com」と入力します。
  8. [ポートタイプ] で [デフォルト] を選択し、[ポート番号] が 443 であることを確認します。
  9. [作成] をクリックします。

gcloud

  1. インターネット NEG を作成し、--network-endpoint-typeinternet-fqdn-port(外部バックエンドに到達可能なホスト名とポート)に設定します。

    gcloud compute network-endpoint-groups create example-fqdn-neg \
        --network-endpoint-type="internet-fqdn-port" --global
    
  2. エンドポイントを 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
    
  3. 作成されたインターネット NEG を一覧表示します。

    gcloud compute network-endpoint-groups list --global
    

    出力:

    NAME                LOCATION   ENDPOINT_TYPE        SIZE
    example-fqdn-neg    global     INTERNET_FQDN_PORT   1
    

  4. その 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 の追加

  1. Google Cloud コンソールの [ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. バックエンド サービスを既存のロードバランサに追加するには、従来のアプリケーション ロードバランサを選択し、メニュー」をクリックして [編集] を選択します。
  3. [バックエンドの構成] をクリックします。
  4. [バックエンド サービスとバックエンド バケット] メニューで、[バックエンド サービスを作成] を選択します。
  5. バックエンド サービスの名前を images に設定します。
  6. [バックエンド タイプ] で [インターネット ネットワーク エンドポイント グループ] を選択します。
  7. ロードバランサからインターネット NEG への通信で使用するプロトコルを選択します。この例では [HTTPS] を選択します。
  8. [新しいバックエンド] > [インターネット ネットワーク エンドポイント グループ] で [example-fqdn-neg] を選択し、[完了] をクリックします。
  9. [Cloud CDN を有効にする] を選択します。
  10. (省略可)キャッシュ モードTTL の設定を変更します。
  11. [詳細構成] の [カスタム リクエスト ヘッダー] で [ヘッダーを追加] をクリックします。
    1. [ヘッダー名] に「Host」と入力します。
    2. [ヘッダーの値] に「backend.example.com」と入力します。
  12. [作成] をクリックします。
  13. ウィンドウを開いたままにして続行します。

バックエンド サービスを既存の URL マップに接続する

  1. [ホストとパスのルール] をクリックします。
  2. 先頭行または最初の数行の右側の列には Google Cloud サービスがあり、それらの 1 つに [ホスト] と [パス] へのデフォルト ルール Any unmatched (default) がすでに入力されています。
  3. 右側の列に images が選択されている行があることを確認します。存在しない場合は、[ホストとパスのルールを追加] をクリックして、images を選択します。他のフィールドには次のように入力します。
    1. [ホスト] に「*」と入力します。
    2. [パス] に「/cart/id/1223515」と入力します。

確認と完了

  1. [確認と完了] をクリックします。
  2. 現在の設定と作成しようとしている内容を比較します。
  3. すべて問題なければ、[更新] をクリックします。

gcloud

  1. 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 レスポンス ヘッダー内の privateno-store、または no-cache のディレクティブを無視して、すべてのコンテンツをキャッシュに保存します。

  2. バックエンド サービスを構成して、カスタム リクエスト ヘッダー Host: backend.example.com をリクエストに追加します。

    gcloud compute backend-services update images \
       --custom-request-header "Host: backend.example.com" --global
    
  3. backend-services add-backend コマンドを使用して、インターネット NEG をバックエンド サービスに追加します。

    gcloud compute backend-services add-backend images \
      --network-endpoint-group "example-fqdn-neg" \
      --global-network-endpoint-group \
      --global
    
  4. 新しいマッチング ルールを作成して、新しいバックエンド サービスをロードバランサの 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 へのリクエストの送信を許可するには、dignslookup などのツールを使用して、_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.comexample.comA レコードを作成するには、次のようにします。

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

DNS プロバイダとして Cloud DNS を使用する場合は、レコードの追加、変更、削除をご覧ください。

外部アプリケーション ロードバランサをテストする

ロードバランサを構成したので、ロードバランサの IP アドレスにトラフィックを送信できるようになりました。ドメインを構成した場合、ドメイン名にトラフィックを送信することもできます。ただし、DNS の伝播が完了するまでに時間がかかることがあるため、テスト用の IP アドレスで始めることもできます。

  1. Google Cloud コンソールの [ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. 作成したロードバランサをクリックします。

  3. ロードバランサの IP アドレスをメモします。

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

  5. (省略可)カスタム ドメインを使用する場合は、更新された 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 ヘッダーを保持します。カスタム リクエスト ヘッダーの概要については、カスタム リクエスト ヘッダーを構成するをご覧ください。具体的な例については、外部バックエンドでロードバランサの構成をご覧ください。

次のステップ