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

※この投稿は米国時間 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 準拠

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

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

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

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

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

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

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

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

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

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