Google Cloud グローバル外部 HTTP(S) ロードバランサ - 詳細

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

クラウドでワークロードをプロビジョニングしてアプリケーションを提供する場合、ロードバランサ（LB）をそのアプリケーションまたはサービスのフロントエンドに配置することを強くおすすめします。ロードバランサは、リクエストを処理できる容量を備えたさまざまなバックエンド（インスタンス グループ、ネットワーク エンドポイント グループ、Cloud Storage など）に、ユーザー アプリケーションのリクエストをリダイレクトします。

Google Cloud のロード バランシングは、最大限のスケーラビリティを備えた分散型の冗長化されたマネージド サービスです。グローバル外部、リージョン外部、リージョン内部など、さまざまな種類があります。Cloud Load Balancing については、こちらのブログ投稿をご覧ください。

ここでは、グローバル外部 HTTP(S) ロード バランシングを中心に取り上げます。この LB には以下の 2 つのモードがあります。

• グローバル外部 HTTP(S) ロードバランサ。このマネージド サービスは、Google Front End（GFE）を基盤として構築されています。HTTP(S) 外部ロードバランサの最新バージョンであり、オープンソースの Envoy プロキシを使用して、高度なトラフィック管理機能（トラフィックのミラーリング、重み付けに基づくトラフィック分割、リクエストやレスポンスに基づくヘッダー変換など）をサポートします。詳細については、高度なトラフィック管理（Envoy）を使用した外部 HTTP(S) ロードバランサの Codelab をご確認ください。

• グローバル外部 HTTP(S) ロードバランサ（従来型）。このマネージド サービスは、Google Front End（GFE）を基盤として構築されています。これは、プレミアム ネットワーク サービス ティアではグローバルで、スタンダード ネットワーク サービス ティアではリージョンになります（プレミアムとスタンダードの違いについては、このブログ記事でさらに詳しく説明します）。

前述のとおり、グローバル外部 HTTP(S) ロードバランサは、HTTP(S) 外部ロードバランサの新しいバージョンであり、高度なトラフィック管理機能を備えています。ただし設計上、対象とするユースケースと必要な機能を特定してからオプションを選択することをおすすめします。サポートされるロード バランシング機能の詳細については、「ロードバランサの機能」や「外部 HTTP(S) ロード バランシングのユースケース」のドキュメントを参照してください。このブログ記事では、Google Cloud グローバル外部 HTTP(S) ロード バランシングの 2 つのモードについて説明します。

最初に、アーキテクチャの観点から考慮するべき次の主要な要素について分析してみましょう。下の図 1 は、グローバル外部 HTTP(S) ロードバランサと従来のグローバル外部 HTTP(S) ロードバランサのアーキテクチャの概要を示しています。

注: 次のアーキテクチャは、プレミアム ネットワーク サービス ティアでデプロイするとグローバル外部 HTTP(S) ロードバランサ（従来）にも適用できます。詳細については、このブログ投稿の後半で紹介します。  

パフォーマンスの向上: Google Cloud グローバル ロードバランサの背後でホストされているアプリケーションにトラフィックを追加して、クライアントやエンドユーザーに最も近いポイントから Google の信頼性の高いグローバル ネットワーク インフラストラクチャに入れる機能（プレミアム ネットワーク サービス ティアで有効）を提供し、クライアントとバックエンド サーバー間のレイテンシを低減します。また、事前定義されたポリシーとヘルスチェックの指標に基づいてバックエンド インスタンスに負荷を分散して、リクエストを処理するのに十分な容量のあるインスタンスにリダイレクトすることで、最終的に全体のパフォーマンスを最適化できます。さらに、コンテンツ配信の機能を有効にすると、画像や動画などの静的コンテンツを Google のエッジ ロケーション（ユーザーの近くでキャッシュおよび配信）にキャッシュ保存して、パフォーマンスをさらに最適化できます。

セキュリティの最適化: アプリケーションやサービスへの最初のエントリ ポイントとして機能し、Google のエッジ ロケーションでクライアント接続を終了します。トラフィックは、バックエンドに転送される前に、ネットワーク レイヤの DDoS 攻撃やアプリケーション レイヤ攻撃について検査されます。これは、バックエンド システムに到達する前にこうした攻撃を軽減できる最適なアプローチです。また、Google Cloud Armor を使用してアプリケーション レイヤのセキュリティを確立し、Identity-Aware Proxy で HTTPS によってアクセスされるアプリケーションの一元的な認可レイヤを確立することで、セキュリティをさらに強化できます。これらの機能は、クラウド環境を保護する多層防御を可能にする重要な要素です。  

復元性: ヘルスチェック指標に合格しなかったインスタンスを再起動するための自動修復、障害シナリオが発生した場合にバックエンド インスタンス（同一または別のリージョン）にトラフィックをリダイレクトする機能によって、全体的なソリューションの復元性が向上します。  

柔軟性: 柔軟なハイブリッド アーキテクチャを提供して、オンプレミスまたは他のクラウドに存在するバックエンドにクラウドのロード バランシング機能を拡張します。これは、さまざまなハイブリッド戦略を可能にする重要な要素です。このようなアーキテクチャは、従来（オンプレミス）のソリューションから最新のクラウドベース ソリューションへの短期的な移行によって推進される場合もあれば、特定の機能を有効化したり特定のコンプライアンス要件を充足したりするために、アーキテクチャ決定が長期にわたって行われる場合もあります。

運用の簡素化: マネージド サービスという性質上、インフラストラクチャの構築やピーク時間におけるスケーリングについて心配する必要がなく、サーバーレス機能をグローバル レベルで利用できます。また、Google のグローバル外部 HTTP(S) ロードバランサ（プレミアム ティア）を使用すると、単一のエニーキャスト IP がフロントエンドで使用され、グローバルに分散できます。これにより、リージョンごとにロードバランサをデプロイしたり、DNS ソリューションとポリシーのレイヤを使用してグローバルおよびリージョン レベルでトラフィックをリダイレクトしたりする必要がなくなります。

Google Cloud のグローバル HTTP(S) ロードバランサは、どのようにしてこうしたアーキテクチャ上の利点をもたらすのでしょうか？

その答えを簡単にするために、下の図 2 に示す Google Cloud グローバル HTTP(S) ロードバランサのアーキテクチャ コンポーネントを分析する必要があります。このアーキテクチャの概要は、どちらのモードにも当てはまりますが、スタンダード ティアをグローバル外部 HTTP(S) ロードバランサ（従来型）と併せて使用する場合は除きます。これについては、後ほどこのブログで説明します。

• ソフトウェア定義されたロード バランシング: Google Cloud のグローバル ロード バランシングはハードウェア ベースではありません。マネージド サービスとして提供される、ソフトウェア定義の完全分散型ソリューションです。外部ロードバランサは、Google Front End（GFE）に存在します。GFE は世界中に分散され、Google のポイント オブ プレゼンス（POP）に配置されています。GFE は他のシステムやコントロール プレーンと連携してグローバル ロード バランシングを実行します。適切な証明書を使用し、前方秘匿性に対応するなどのベスト プラクティスに沿ってすべての安全な HTTP 接続を（可能な限りクライアントの近くで）終了するため、GFE 機能はこのようなアーキテクチャでは重要な要素となります。さらに、GFE は、Google グローバル ネットワークのエッジレイヤ（POP）での DoS 攻撃に対する保護も適用します。

• Google グローバル ネットワーク: 高度にプロビジョニングされた、低レイテンシのネットワークです。Gmail、Google 検索、YouTube などの高度にスケーラブルなサービスを支えているネットワークと同じものです。Google Cloud グローバル ロード バランシングは、これと同じフロントエンド インフラストラクチャ（GFE）上に構築されています。さらに、Google の海底ケーブルは、100 を超えるネットワーク エッジ ロケーション（POP）を含むクラウド インフラストラクチャを相互接続しているため、このグローバル ネットワークで重要な役割を果たしています。このネットワークにより、トラフィック リクエストの送信元にできるだけ近い場所で Google バックボーンにユーザー トラフィックを取り込めるようになり、ユーザー エクスペリエンスの向上につながっています。

このような接続性は プレミアム ネットワーク サービス ティア と呼ばれ、図 3 に示すように、Google の高速で信頼性の高いプライベート グローバル ネットワークを介して移動距離を最大化する「コールドポテト ルーティング」アプローチを採用しています。この方法は、公共のインターネットを経由してトラフィックをエンド ツー エンドでルーティングするよりも効率的です。通常、公共のインターネットでは、ローカル ISP はトラフィックを別の ISP に渡します（ほとんどの場合、宛先に到達するまでにトラフィックは複数の ISP を経由します）。その結果、複数の ISP とネットワーキング ホップを通過するトラフィックには、パス全体でより高いレイテンシと帯域幅の制約が生じます。

Google Cloud グローバル外部ロードバランサ（従来型）では、単一のエニーキャスト仮想 IP アドレス（VIP）で上記のように動作するプレミアム ティアを選択するオプションがあります。なお、スタンダード ティアも選択できます。この場合、図 4 に示すように、グローバル外部ロードバランサ（従来型）がリージョン レベルで動作し、リージョンごとに IP および転送ルールが存在し、バックエンドはそのリージョン IP と転送ルールと同じリージョンに存在する必要があります。

• グローバル（外部）転送ルール: グローバル転送ルールは、Google Front End（GFE）で配布されて適用されます。グローバル転送ルールにより、単一のグローバル エニーキャスト IP が提供されます。グローバル外部 HTTP(S) ロードバランサとグローバル外部 HTTP(S) ロードバランサ（従来型）をプレミアム ティアで使用している場合、この IP は、IPv4 または IPv6 にできます。これらは GFE に登録され、サイト、アプリケーション、バックエンド バケットの DNS レコードで使用できます。グローバルに分散されたソリューションに関して、各リージョンの IP と DNS に悩まされることはありません。ただし、スタンダード ティアでグローバル外部 HTTP(S) ロード バランシング（従来型）を使用している場合、転送ルールはリージョン レベルで動作し、バックエンドが転送ルールを含む同じリージョンに存在する必要があります（図 4 を参照）。

• URL マップ: HTTP(S) リクエストが特定のエニーキャストまたはリージョン VIP 宛てに送信された後、リクエストは Google エッジ フロントエンドに到達し、ロードバランサがリクエストのルーティング先を（特定のバックエンド サービスまたはバックエンド バケットに）決定する必要があります。この決定は、転送ルールと HTTP(S) プロキシによってリクエストが転送された後に、URL マップで定義されたルールに基づいて行われます。このアプローチにより、グローバル HTTP(S) ロードバランサは URL マップレベルで事前に構成されたルールに基づいて、リクエストを異なる宛先にルーティングするために単一の URL マップを使用できます。図 5 は、URL マップのアーキテクチャ コンポーネントと、それが全体的なグローバル外部 HTTP(S) ロードバランサ アーキテクチャに適合する場所を示しています。また、URL マップでは、追加の一致条件を使用できる高度なトラフィック管理を構成できます。

このアプローチを使用すると、ロード バランシング ソリューションをフレキシブルに設計して、さまざまな要件に基づいてトラフィックを動作および分散させることができます。要件には以下が含まれます（ただしこれらに限定されません）。

• GFE レベルのロードバランサが、トラフィックを処理できる容量を持つトラフィック ソースに最も近いインスタンスのグループへとトラフィックをリダイレクトできる近接性ベースのルーティング（プレミアム ティアのクラウド グローバル ロードバランサまたは従来のグローバル ロードバランサを使用している場合はクロス リージョン ロード バランシング）。

• アプリケーションの特定の部分に対するリクエストなど、URL コンテンツに基づくトラフィックのルーティング。たとえば、マルチメディアを容量の大きいインスタンス グループにリダイレクトし、静的コンテンツへと膨張したトラフィックをCloud CDN から提供することで、ユーザー エクスペリエンスを向上させ、レイテンシを短縮できます。URL マップは、処理する URL ごとにホスト名とパスの部分を使用して、この動作を実行します。このような処理により、ロードバランサが HTTP ヘッダーと URL クエリ パラメータに基づいてトラフィック ルーティングを決定する、ヘッダーベースおよびパラメータ ベースのルーティングが提供されます。これにより、追加のティアをデプロイする必要がないため、最終的にクラウド アーキテクチャを簡素化するのに役立ちます。その結果として、Google Cloud グローバル HTTP(S) をさまざまなユースケースで使用できます。特に、次のような高度なトラフィック管理が使用されている場合に有効です。

• A/B テスト

• バックエンドで実行されているさまざまなサービスにユーザーのトラフィックをリダイレクトする

• デバイスのさまざまなカテゴリやリクエスト送信元の地理的位置情報に基づいて、多様なページとエクスペリエンスを提供することで、地理情報関連のコンテンツまたはデバイスタイプに基づいたコンテンツを提供する

• バックエンド サービス: 実際のアプリケーション インスタンス、関連するヘルスチェックとバックエンドサービス、分散モードを論理的にグループ化したものです。正常なインスタンスはどれか、過剰に使用されているインスタンスはどれか（CPU の使用率、インスタンスごとの 1 秒あたりのリクエストから）、自動スケーリングをトリガーするタイミングを判断するのに役立ちます。構成の観点から、リクエストをバックエンド サービスにルーティングするようにロード バランシング サービスを構成する必要があります。詳細については、バックエンド サービスの概要のドキュメントを参照してください。

• バックエンド: Google Cloud ロードバランサからトラフィックを受信するエンドポイントを指します。バックエンドは、自動スケーリングの有無にかかわらず、マネージド インスタンス グループを使用して仮想マシンを追加および管理するインスタンス グループになることも、非マネージド インスタンス グループになることもできます。または、ネットワーク エンドポイント グループ（NEG）を基盤にすることも可能です。この場合、コンテナ ネイティブのロード バランシングを提供するコンテナ化アプリケーション、トラフィックをオンプレミスまたは他のクラウドに送信するハイブリッド アーキテクチャ、Cloud Run、App Engine、Cloud Functions、API ゲートウェイ サービスを使用したサーバーレス アプリケーションなど、複数のユースケースに対応します。

注: 可能な場合、ロードバランサでHTTP/3を有効にして、高レイテンシ接続でのウェブページの読み込み時間とスループットを改善できます。

まとめ

Google Cloud には、さまざまなユースケースの設計を簡素化するためのロード バランシングのオプションが複数用意されています。グローバル外部 HTTP(S) ロード バランシングには、このロード バランシングが提供する 2 つのタイプまたはモードがあります。したがって、アーキテクトやデザイナーは、対象となるソリューションとアプリケーションの要件を最初に理解したうえで、どのタイプのロードバランサを選択すれば最適な設計になるかを決定する必要があります。また、Google Cloud が提供するロード バランシングは、シンプルなものから非常に高度で洗練された設計やユースケースにまでおよびます。設計上の一般的な推奨事項として、常にシンプルで具体的なユースケースから取り組むことをおすすめします。その後、高度なルールとポリシーを定義することでさらに機能を追加して強化していくことができます。

- Google Cloud（ドバイ）パートナー担当カスタマー エンジニア Marwan Al shawi
- デベロッパー リレーションズ エンジニア Ammett Williams