ネットワーキング

外部 HTTP(S) ロードバランサでの新しいトラフィック制御機能の使用

Google Networking 02

※この投稿は米国時間 2020 年 7 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。 

すべての HTTP(S) ロードバランサの中心には、受信リクエストを適切な場所にリダイレクトする永続的な URL マップがあります。Google は 4 月に、URL マップによりサポートされる新しい 2 つのアクションである リダイレクトと書き換えを発表しました。URL リダイレクトを行うと、ロードバランサは受信したリクエストを 1 つの URL から別の URL にリダイレクトできます。書き換えによって、バックエンド サービスで使用される URL とは異なる URL を外部ユーザーに表示できます。また、HTTP ヘッダーと URL のクエリ パラメータで一致させることができる一致条件を追加しました。

こうしたトラフィック制御機能により、自社製のソリューションに依存することなく、ロードバランサへのルーティングの決定をさらにシフトさせることができます。この機能の発表後、いくつかのユースケースが寄せられています。Google Cloud のお客様がこの機能を本番環境で利用する様子をお読みになり、ユースケースを実際にお試しください。

HTTP から HTTPS へのリダイレクトにおける HIPAA 準拠

HIPPA(Health Insurance Portability and Accountability Act of 1996、1996 年の医療保険の相互運用性と説明責任に関する法律)は、個人の医療情報(PHI)を転送する際の暗号化を求めています。ウェブサイトについては、ウェブのリクエストとレスポンスを保護するために HTTPS を使用する必要があることを意味します。暗号化されていない HTTP リクエストでは、HTTPS リクエストの代わりに、ブラウザにリクエストを再送信するよう求めるブラウザへのレスポンスが生じます。これは、リダイレクト レスポンスと呼ばれます。通常は、シームレスなユーザー エクスペリエンスのためにブラウザはリダイレクト レスポンスの提案に暗黙的に従います。
HTTP-to-HTTPS redirect.gif

しかし、バックエンドのウェブサーバーにリダイレクト レスポンスを生成させると、コンピューティング費用、構成の複雑性、レイテンシ、帯域幅消費の増加につながります。このプロセスを省略し、ロードバランサにリダイレクトを直接発行させ、バックエンド サーバーに暗号化されていないリクエストが届くリスクを低減できるようになりました。HTTP から HTTPS へとスキーマを変更することに加えて、ロードバランサによって生成されたリダイレクト レスポンスは、リクエストが別のホストや URL パスに送信されるべきというシグナルを発することもできます。

単に defaultUrlRedirect を構成して、httpsRedirect をすべてのホストに対して true に設定するだけで、HTTP から HTTPS へのリダイレクトを実現できます。
  gcloud compute url-maps import x-url-map --global <<<EOF
kind: compute#urlMap
name: x-url-map
hostRules:
  - pathMatcher: https-redirect-path-matcher
    hosts: [ 'secure.mydomain.com' ]
pathMatchers:
  - name: https-redirect-path-matcher
    defaultUrlRedirect:
      httpsRedirect: true
EOF

URL 書き換えによるバックエンドの再編成

URL リダイレクトは通常、ユーザー(ブラウザ)とロードバランサ間の変換です。しかし、Cloud Load Balancing の新しい URL 書き換え機能は、ロードバランサとバックエンド間の通信のみを対象としています。

URL 書き換えの一般的なユースケースとして、VM ウェブサーバーから Google Cloud Storage への静的なウェブ コンテンツの移行が挙げられます。この場合、静的ウェブ要素の URL パスを、ストレージ バケットとバケット内のパスを識別する URL へとマッピングする必要があります。この変換はクライアント ブラウザには関係がなく、ロードバランサとストレージ システムのバックエンド間のやり取りにのみ影響します。

URL rewrite.gif

これを実現するには、まず、対応するホストとパスがクライアントをロードバランサの URL に一致させる場合に、routeActionurlRewrite として構成します。

  gcloud compute url-maps import static-content-url-map --global <<EOF
name: static-content-url-map
hostRules:
  - pathMatcher: myhost-path-matcher
    hosts: [ mydomain.com' ]
pathMatchers:
  - name: myhost-path-matcher
    defaultService: 'global/backendServices/myhost-web-server'
    pathRules:
    - path: [ ‘/tech-docs ]
      service: ‘backendBuckets/docs-bucket’
      routeAction:
        urlRewrite:
          pathPrefixRewrite: ‘/next-gen-docs’
EOF

クエリ パラメータによるルーティングでの A/B テスト

このような Cloud Load Balancing の新機能により実現するもう 1 つの機能を使用すると、URL のホストとパスだけではなく、HTTP ヘッダーやクエリ パラメータに基づいてルーティングの決定を行えます。

A_B testing.jpg

たとえば、ウェブサイトの新しいバージョンをテストするとします。特定のリクエストをテスト用バックエンドにリダイレクトさせるよう記述したクエリ パラメータを URL へ追加できます。その後、ロードバランサは「テスト用」クエリ パラメータがあるかどうかを確認し、トラフィックをテスト用ウェブサーバーのバックエンド サービスにルーティングします。

  gcloud compute url-maps import ab-testing-url-map --global <<EOF
name: ab-testing-url-map
hostRules:
  - pathMatcher: ab-testing-path-matcher
    hosts: [ mydomain.com' ]
pathMatchers:
  - name: ab-testing-path-matcher
    defaultService: 'global/backendServices/myhost-web-server'
    routeRules:
    - priority: 10
      service: ‘global/backendServices/my-experimental-web-server’
      matchRules:
        - queryParameterMatch:
          name: ‘experimental’
          presentMatch: true
EOF

これらの例がお役に立てば幸いです。外部 HTTP(S) 負荷分散に関連するトラフィック制御の新機能の詳細については、このドキュメントをご覧ください。また、内部 HTTP ロードバランサによってサポートされているトラフィック制御 API については、こちらをご覧ください。トラフィック制御 API をどのようにお使いでしょうか。ぜひフィードバックをお寄せください。

-ソフトウェア エンジニア Jeff Piazza / シニア ソフトウェア エンジニア Gautam Nirodi