URL マップの概要

Google Cloud HTTP(S) ロードバランサと Traffic Director は、URL マップと呼ばれる Google Cloud 構成リソースを使用して、バックエンド サービスまたはバックエンド バケットにリクエストをルーティングします。

たとえば、外部 HTTP(S) ロードバランサでは、1 つの URL マップを使用して、URL マップで構成されたルールに基づいてリクエストを異なる宛先にルーティングできます。

  • https://example.com/video のリクエストは 1 つのバックエンド サービスに送信されます。
  • https://example.com/audio のリクエストは別のバックエンド サービスに送信されます。
  • https://example.com/images のリクエストは Cloud Storage バックエンド バケットに送信されます。
  • 他のホストとパスの組み合わせに対するリクエストは、デフォルトのバックエンド サービスに送信されます。

URL マップは、次の Google Cloud サービスで使用されます。

URL マップリソースには、グローバルとリージョンの 2 種類があります。使用するリソースのタイプは、プロダクトの負荷分散スキームによって異なります。

プロダクト 負荷分散スキーム URL マップのリソースタイプ 選択できる宛先
外部 HTTP(S) ロードバランサ EXTERNAL グローバル、外部 バックエンド サービス、バックエンド バケット
内部 HTTP(S) ロードバランサ INTERNAL_MANAGED リージョン、内部 バックエンド サービス
Traffic Director INTERNAL_SELF_MANAGED グローバル、内部 バックエンド サービス

すべてのプロダクトで、すべての URL マップ機能が利用できるわけではありません。内部 HTTP(S) 負荷分散や Traffic Director で使用される URL マップは、いくつかの高度なトラフィック管理機能もサポートしています。これらの違いの詳細については、高度なトラフィック管理をご覧ください。

URL マップの仕組み

リクエストを受信すると、ロードバランサは URL マップで定義されたルールに基づいて特定のバックエンド サービスまたはバックエンド バケットにリクエストをルーティングします。

バックエンド サービスは、アプリケーションまたはマイクロサービスのインスタンスであるバックエンドのコレクションを表します。バックエンド バケットは、Cloud Storage バケットであり、通常、画像などの静的コンテンツをホストするために使用されます。

外部 HTTP(S) ロードバランサ、内部 HTTP(S) ロードバランサ、Traffic Director の場合、宛先は次のようになります。

さらに、外部 HTTP(S) ロードバランサは次の対象もサポートします。

たとえば、次のような設定があるとします。

  • 1 つの IP アドレス
    • 組織へのリクエストはすべて同じ IP アドレスと同じロードバランサに転送されます。
    • トラフィックは、リクエストの URL に基づいてさまざまなバックエンド サービスに転送されます。
  • 2 つのドメイン
    • example.net(トレーニング動画をホスト)
    • example.org(組織のウェブサイトをホスト)
  • 4 つのサーバーセット
    • 組織のウェブサイトをホスト(バックエンド サービス: org-site
    • トレーニング動画のウェブサイト全体をホスト(バックエンド サービス: video-site
    • 高画質(HD)のトレーニング動画をホスト(バックエンド サービス: video-hd
    • 標準画質(SD)のトレーニング動画をホスト(バックエンド サービス: video-sd

次の処理を行うとしています。

  • example.org(または、example.net 以外のドメイン)へのリクエストが org-site バックエンド サービスに送信される。
  • より具体的なパスと一致しない example.net へのリクエストが video-site バックエンド サービスに送信される。
  • example.net/video/hd/* へのリクエストが video-hd バックエンド サービスに送信される。
  • example.net/video/sd/* へのリクエストが video-sd バックエンド サービスに送信される。

--path-rule/video/* の場合、これは /video/test1/video/test2 などの URI と一致しますが、パス /video とは一致しません。

URL に /../ が含まれるリクエストをロードバランサが受信すると、ロードバランサは 302 リダイレクトで応答します。たとえば、http://example.net/video/../abc に対するリクエストが送信されると、ロードバランサはこのリクエストを http://example.net/abc に変換し、URL マップの構成に従って処理します。この 302 リダイレクトは Cloud Logging には記録されません。

URL マップでは、このタイプのホストとパスベースのルーティングを設定できます。

バックエンド サービス設定の例(クリックして拡大)
バックエンド サービス設定の例(クリックして拡大)

命名

各 URL マップには名前があります。Google Cloud Console を使用して HTTP(S) ベースのロードバランサを作成すると、URL マップに名前が割り当てられます。この名前は、ロードバランサの名前と同じです。gcloud コマンドライン ツールまたは API を使用する場合は、URL マップのカスタム名を定義できます。

URL マップのコンポーネント

URL マップは、URL のリクエストをバックエンド サービスまたはバックエンド バケットに転送する 一連の Google Cloud 構成リソースです。URL マップは、処理する URL ごとにホスト名とパスの部分を使用します。

  • ホスト名は URL のうちのドメイン名の部分です。たとえば、http://example.net/video/hd という URL のホスト名の部分は example.net です。
  • パスは、ホスト名とポート番号(省略可能)に続く URL の一部です。たとえば、http://example.net/video/hd という URL のパス部分は /video/hd です。
基本的な URL マップによるロードバランサ構成(クリックして拡大)。
基本的な URL マップによるロードバランサ構成(クリックして拡大)

この図は、負荷分散構成オブジェクト同士の関係を示しています。

受信リクエストを転送するバックエンド サービスまたはバックエンド バケットは、次の URL マップ構成パラメータで制御します。

  • デフォルトのバックエンド サービスまたはデフォルトのバックエンド バケット。URL マップを作成する場合は、デフォルトのバックエンド サービスまたはデフォルトのバックエンド バケットのどちらか一方のみを指定する必要があります。適用可能なホストルールがない限り、Google Cloud はホスト名を含む URL へのリクエストをこのデフォルトのバックエンド サービスまたはバックエンド バケットに送信します。

  • ホストルール(hostRules。ホストルールは、1 つ以上の関連付けられたホスト名に送信されたリクエストを単一のパスマッチャーpathMatchers)に送信します。URL のホスト名の部分は、ホストルールの構成済みホスト名のセットと完全に一致します。URL マップのホストとパスのルールでは、ホストを省略すると、ルールはリクエストされたすべてのホストと一致します。http://example.net/video/hd へのリクエストをパスマッチャーに送信するには、少なくとも example.net というホスト名を含むホストルールが必要です。このホストルールでは、他のホスト名へのリクエストも処理できますが、それらを同じパスマッチャーに送信します。

    リクエストを別のパスマッチャーに送信する場合は、別のホストルールを使用する必要があります。URL マップ内の 2 つのホストルールに同じホスト名を含めることはできません。

    ホストルールでワイルドカード文字 * を指定すると、すべてのホスト名と一致するようにできます。たとえば、http://example.orghttp://example.net/video/hdhttp://example.com/audio という URL の場合は、ホストルールに * を指定すると、example.orgexample.netexample.com の 3 つのホスト名すべてに一致します。ワイルドカード文字 * を使用して、ホスト名との部分的な一致を検出することもできます。たとえば、ホストルール *.example.netfoo.example.netbar.example.net の両方のホスト名に一致します。

    • ポート番号ホストルール パラメータを使用してポート番号を指定することもできます。たとえば、ポート 8080 の example.net リクエストを送信するには、ホストルールを example.net:8080 に設定します。
  • パスマッチャー(pathMatchers。パスマッチャーは、ホストルールで参照される構成パラメータです。URL のパス部分と、リクエストを処理するバックエンド サービスまたはバックエンド バケットとの関係を定義します。パスマッチャーは、次の 2 つの要素で構成されます。

    • パスマッチャーのデフォルト バックエンド サービスまたはパスマッチャーのデフォルト バックエンド バケット。それぞれのパスマッチャーには、デフォルトのバックエンド サービスまたはデフォルトのバックエンド バケットのどちらか一方のみを指定する必要があります。Google Cloud は、パスマッチャーで関連付けられたホストルールに一致し、かつ、URL パスがパスマッチャーの任意のパスルールに一致しない URL へのリクエストをこのデフォルトのバックエンド サービスまたはバックエンド バケットに送信します。

    • パスのルール。パスマッチャーごとに、1 つ以上のパスルールを指定できます。これは、URL パスを 1 つのバックエンド サービスまたはバックエンド バケットにマッピングする Key-Value ペアです。次のセクションでは、パスルールの機能を詳しく説明します。

オペレーションの順序

リクエストされた URL の特定のホスト名とパスに対して、Google Cloud は次の手順に沿って、URL マップに構成された正しいバックエンド サービスまたはバックエンド バケットにリクエストを送信します。

  • URL マップに URL のホスト名のホストルールが含まれていない場合、Google Cloud は、URL マップのデフォルト バックエンド サービスまたはデフォルト バックエンド バケットにリクエストを送信します。送信先は定義によって異なります。

  • URL マップに、URL のホスト名を含むホストルールが含まれている場合、そのホストルールで参照されるパスマッチャーが使用されます。

    • パスマッチャーに URL パスと完全に一致するパスルールが含まれている場合、Google Cloud は、そのパスルールのバックエンド サービスまたはバックエンド バケットにリクエストを送信します。

    • パスマッチャーに、URL のパスに完全に一致するパスルールが含まれず、/* で終わるパスルールが含まれていて、プリフィックスが URL のパスの最長部分と一致する場合、Google Cloud はそのパスルールのバックエンド サービスまたはバックエンド バケットにリクエストを送信します。たとえば、2 つのパスマッチャー ルール /video/hd/movie1/video/hd/* を含む URL マップの場合、URL に正確なパス /video/hd/movie1 が含まれている場合、そのパスルールと照合されます。

    • 前の条件のどちらも true でない場合、Google Cloud は、パスマッチャーのデフォルトのバックエンド サービスまたはデフォルトのバックエンド バケットにリクエストを送信します。送信先は定義によって異なります。

パスマッチャーの制約

パスマッチャーとパスルールには、次のような制約があります。

  • パスルールでは、スラッシュ文字(/)の後にのみワイルドカード文字(*)を使用できます。たとえば、/videos/*/videos/hd/* は有効なパスルールですが、/videos*/videos/hd* は無効です。

  • パスルールでは、正規表現や部分文字列の一致は使用されません。たとえば、/videos/hd または /videos/hd/* パスルールは、パスが /video/hd-abcd の URL には適用されません。ただし、そのパスには /video/* のパスルールが適用されます。

  • パスマッチャーと一般的な URL マップには、Apache LocationMatch ディレクティブのような機能はありません。共通のプリフィックスを持つ動的 URL パス(たとえば /videos/hd-abcd/videos/hd-pqrs)を生成するアプリケーションで、これらのパスに対するリクエストを別のバックエンド サービスに送信する必要がある場合、URL マップではその目的を実行できません。動的 URL の非常に少ないシンプルなケースでは、限定的なパスルールのセットを使用してパスマッチャーの作成が可能な場合もあります。より複雑なケースでは、バックエンドで正規表現を使用してパスの照合を行います。

ホスト名は 1 つのホストルールのみを参照し、ホストルールは 1 つのパスマッチャーのみを参照します。ただし、1 つのホストルールは複数のホスト名を処理し、複数のホストルールは 1 つのパスマッチャーのみを参照します。そのため、各 URL は 1 つのバックエンド サービスまたはバックエンド バケットにのみ転送されます。

  • Google Cloud は、URL のホスト名部分を使用して、1 つのホストルールと関連するパスマッチャーを選択できます。

  • パスマッチャーでは、同じパスに複数のパスルールを作成することはできません。たとえば、/videos/hd リクエストを複数のバックエンド サービスやバックエンド バケットに転送することはできません。バックエンド サービスは、異なるゾーンやリージョンにバックエンド インスタンス グループまたはバックエンド ネットワーク エンドポイント グループ(NEG)を持つことができます。また、マルチ リージョン ストレージ クラスを使用するバックエンド バケットを作成できます。

URL マップとプロトコル

ターゲット HTTP プロキシとターゲット HTTPS プロキシの両方が URL マップを参照する場合、同じ URL マップ、ホストルール、パスマッチャー ツールを使用して、クライアントから送信された HTTP リクエストと HTTPS リクエストを処理できます。

次のガイドに示すように、URL マップを使用してリダイレクトを構成できます。

最も簡単な URL マップ

最も単純な URL マップは、デフォルトのバックエンド サービスまたはデフォルトのバックエンド バケットだけで構成されています。ホストルールもパスマッチャーもありません。リクエストされた URL は、デフォルトのバックエンド サービスまたはデフォルトのバックエンド バケットのうち、定義されたいずれかで処理されます。

デフォルトのバックエンド サービスを定義すると、Google Cloud はバックエンド サービスの構成に従ってバックエンド インスタンス グループまたはバックエンド NEG にリクエストを送ります。

デフォルト以外のルールがない URL マップ(クリックして拡大)
デフォルト以外のルールがない URL マップ(クリックして拡大)

外部 HTTP(S) ロードバランサを使用した URL マップ ワークフローの例

次の例は、URL マップのオペレーションの順序を示しています。この例では、外部 HTTP(S) ロードバランサの URL マップを構成します。説明を簡単にするため、ここでは、バックエンド サービスのみを使用します。バックエンド バケットを代用することも可能です。外部 HTTP(S) ロードバランサの他のコンポーネントを作成する方法については、外部 HTTP(S) ロードバランサの作成をご覧ください。

内部 HTTP(S) ロードバランサの URL マップおよびその他のコンポーネントを作成する方法については、内部 HTTP(S) ロードバランサの設定準備をご覧ください。

次の例で説明するバックエンド サービスは外部のスキームを持ち、HTTP、HTTPS、または HTTP/2 プロトコルを使用します。

  1. ロードバランサの URL マップを作成し、デフォルトのバックエンド サービスを指定します。この例では、org-site という既存のバックエンド サービスを参照する video-org-url-map という URL マップを作成します。

    gcloud compute url-maps create video-org-url-map \
        --default-service=org-site
    
  2. 次の特性を持つ video-matcher という名前のパスマッチャーを作成します。

    • デフォルトのバックエンド サービスは、video-site という既存のバックエンド サービスになります。
    • 正確な URL パス /video/hd または URL パスのプリフィックス /video/hd/* のリクエストを video-hd という名前の既存のバックエンド サービスに転送するパスルールを追加します。
    • 正確な URL パス /video/sd または URL パスのプレフィックス /video/sd/* のリクエストを video-sd という名前の既存のバックエンド サービスに転送するパスルールを追加します。
    gcloud compute url-maps add-path-matcher video-org-url-map \
        --path-matcher-name=video-matcher \
        --default-service=video-site \
        --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd
    
  3. video-matcher パスマッチャーを参照する example.net というホスト名のホストルールを作成します。

    gcloud compute url-maps add-host-rule video-org-url-map \
        --hosts=example.net \
        --path-matcher-name=video-matcher
    

video-org-url-map URL マップは次のようになります。

gcloud compute url-maps describe video-org-url-map
creationTimestamp: '2021-03-05T13:34:15.833-08:00'
defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site
fingerprint: mfyJIT7Zurs=
hostRules:
- hosts:
  - '*'
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
id: '8886405179645041976'
kind: compute#urlMap
name: video-org-url-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site
  name: video-matcher
  pathRules:
  - paths:
    - /video/hd
    - /video/hd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd
  - paths:
    - /video/sd
    - /video/sd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map

video-org-url-map URL マップは、リクエストされた URL を次の方法でバックエンドに送信します。

パスルール、パスマッチャー、ホストルールを含む URL マップ(クリックして拡大)
パスルール、パスマッチャー、ホストルールを含む URL マップ(クリックして拡大)

次のテーブルに、前の図で表示されたリクエスト処理を示します。

ホスト名 URL パス 選択されたバックエンド サービス 選択の理由
ホスト名:
example.org。また、example.net と異なるその他のホスト名。
すべてのパス org-site ホスト名が URL マップのホストルールにないため、リクエストは URL マップのデフォルトのバックエンド サービスに転送されます。
ホスト名:
example.net
/video
/video/examples
video-site /video/ または /video/* のパスルールがないため、リクエストはデフォルトのバックエンド サービスに移動します。example.net のホストルールはパスマッチャーを参照しますが、これらのパスに適用されるパスルールはありません。
ホスト名:
example.net
/video/hd
/video/hd/movie1
/video/hd/movies/movie2
先頭が /video/hd/* のその他の URL
video-hd example.net のホストルールはパスルールのパスマッチャーを参照しています。このパスルールにより、/video/hd と完全に一致する URL パスか、/video/hd/* で始まる URL パスへのリクエストを video-hd バックエンド サービスに送信します。
ホスト名:
example.net
/video/sd
/video/sd/show1
/video/sd/shows/show2
先頭が /video/sd/* のその他の URL
video-sd example.net のホストルールはパスルールのパスマッチャーを参照しています。このパスルールにより、/video/sd と完全に一致する URL パスか、/video/sd/* で始まる URL パスへのリクエストを video-sd バックエンド サービスに送信します。

URL リダイレクト

URL リダイレクトは、同じ URL から別の URL にドメインの訪問者をリダイレクトします。

受信リクエスト内の特定のパターンに一致する場合も、デフォルトの URL リダイレクトは条件付けされません。たとえば、デフォルトの URL リダイレクトを使用して、任意のホスト名を任意のホスト名にリダイレクトできます。

次の表に示すように、URL リダイレクトを作成するにはいくつかの方法があります。

メソッド 構成
URL マップのデフォルトの URL リダイレクト 最上位 defaultUrlRedirect
パスマッチャーのデフォルトの URL リダイレクト pathMatchers[].defaultUrlRedirect[]
パスマッチャーのパスルールの URL リダイレクト pathMatchers[].pathRules[].urlRedirect
パスマッチャーのルートルールの URL リダイレクト pathMatchers[].routeRules[].urlRedirect

defaultUrlRedirect または urlRedirect 内では、pathRedirect は常に次のように動作します。

  • リクエストパス全体が、指定したパスで置き換えられます。

defaultUrlRedirect または urlRedirect 内での prefixRedirect の動作は使用方法によって異なります。

  • defaultUrlRedirect を使用する場合、一致するパスは常に / であるため、prefixRedirect は事実上プレフィックスの先頭になります。
  • パスマッチャーのルートルールまたはパスルール内で urlRedirect を使用する場合、prefixRedirect は、パスルールまたはルートルールで定義されているように、リクエストされたパスがどのように一致したかに基づくプレフィックス置換になります。

リダイレクトの例

次の表は、リダイレクト構成の例を示しています。右側の列は、デフォルトの URL リダイレクトの API 構成を示しています。

目的 デフォルトの URL リダイレクトを使用した結果
HTTP から HTTPS へのリダイレクト

リダイレクト
http://host.name/path
から
https://host.name/path

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
           
HTTP から HTTPS + ホスト リダイレクト

リダイレクト
http://any-host-name/path
から
https://www.example.com/path

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
          
HTTP から HTTPS + ホスト リダイレクト + フルパス リダイレクト

リダイレクト
http://any-host-name/path
から
https://www.example.com/newPath

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              pathRedirect: "/newPath"
           
HTTP から HTTPS + ホスト リダイレクト + プレフィックス リダイレクト

リダイレクト
http://any-host-name/originalPath
から
https://www.example.com/newPrefix/originalPath

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              prefixRedirect: "/newPrefix"
            

次の例では、各 API リソースにアノテーションを追加します。

kind: compute#urlMap
name: web-map-http
defaultUrlRedirect:
   redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
   httpsRedirect: True # True if you want https://, false if you want http://
   hostRedirect: "new-host-name.com" # Omit to keep the requested host
   pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
   prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
   stripQuery: False # True to omit everything in the URL after ?
  },
  "defaultUrlRedirect": {
    "redirectResponseCode": enum,
  }

完全なエンドツーエンドの例については、次のページをご覧ください。

高度なトラフィック管理

すべてのプロダクトで、すべての URL マップ機能が利用できるわけではありません。URL マップは内部 HTTP(S) 負荷分散と Traffic Director とともに使用され、複数の高度なトラフィック管理機能をサポートします。ただし、これらの機能がすべての外部 HTTP(S) 負荷分散でサポートされているわけではありません。

次の表で、各プロダクトで使用できる URL マップの機能を確認してください。各プロダクトには、トラフィック管理の仕組みを説明する専用のトピックが用意されており、各ユースケースのサンプル URL マップが記載されています。

プロダクト URL マップの機能とトラフィック管理ガイド
外部 HTTP(S) 負荷分散 ロードバランサの機能: ルーティングとトラフィック管理

外部 HTTP(S) ロードバランサのトラフィック管理の概要

外部 HTTP(S) ロードバランサのトラフィック管理の設定

内部 HTTP(S) 負荷分散 ロードバランサの機能: ルーティングとトラフィック管理

内部 HTTP(S) ロードバランサのトラフィック管理の概要

内部 HTTP(S) ロードバランサのトラフィック管理の設定

Traffic Director Traffic Director の機能: ルーティングとトラフィック管理

高度なトラフィック管理の概要

高度なトラフィック管理の構成

API と Cloud SDK リファレンス

Cloud Console に加えて、API と Cloud SDK を使用して URL マップを作成できます。

API

REST API で URL マップを操作するときに使用できるプロパティとメソッドについては、以下をご覧ください。

プロダクト API ドキュメント
外部 HTTP(S) 負荷分散 urlMaps
内部 HTTP(S) 負荷分散 regionUrlMaps
Traffic Director urlMaps

Cloud SDK

Cloud SDK の gcloud コマンドライン ツールについては、以下をご覧ください。

高度なトラフィック管理を行うには、YAML ファイルを使用し、gcloud compute url-maps import コマンドを使用してインポートします。

次のステップ