Traffic Director による Google Cloud VMware Engine のロード バランシング

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

以下のソリューションの概要では、GCVE + Traffic Director の実装について説明します。この説明は、ウェブサービスを簡単にスケールアウトし、Google Cloud へのアプリケーションの移行を行う方法をお客様に提供することを目的としています。このソリューションは、Google Cloud Platform のユニークな機能を例証する、柔軟かつオープンなアーキテクチャに構築されています。では詳しくご説明しましょう。

簡単: 完全な構成は数分で実装できます。スクリプトや IaC（Infrastructure-as-Code）による定義によって、迅速な消費が可能になり、最小限のエラーに抑えることができます。

柔軟かつオープン: このソリューションは、ネットワークやアプリケーションのコミュニティで絶大な人気を誇るオープンソースのプラットフォーム「Envoy」を利用しています。

Google Cloud VMware Engine（GCVE）の提供により、GCP のお客様は、Google が管理、サポート、保守する認定 VMware スタック上にクラウド アプリケーションをデプロイできるようになりました。また、これらのお客様の多くは、GCVE 上で動作するアプリケーションと、Google Kubernetes Engine（GKE）や Cloud Functions、App Engine、Cloud Run などのサーバーレス フレームワークなど、当社のプラットフォームがネイティブで提供する、さまざまなインフラストラクチャ サービスとのシームレスな統合を望んでいます。ネットワーク サービスはその筆頭です。

このブログでは、サービス メッシュのフルマネージド コントロール プレーンである Traffic Director を、当社のロードバランサのポートフォリオや ハイブリッド ネットワーク エンドポイント グループ （ハイブリッド NEG）と組み合わせて、VMware Engine でホストされるウェブサービスにハイパフォーマンスのフロントエンドを提供できることを説明します。

Traffic Director は、GCP のネイティブ ロードバランサと GCVE のバックエンドをつなぐ役割も果たしており、これらの技術的なメリットを実現することを目的としています。

• 認証局との統合により、SSL 証明書のライフサイクルを完全に管理することが可能。

• Cloud Armor による DDoS 対策は、サービス拒否攻撃やウェブ攻撃からアプリケーションやウェブサイトを保護するのに役立つ。

• Cloud CDN を使用したキャッシュによるコンテンツ配信。

• 単一の IP と世界中に配信するインテリジェントなエニーキャストにより、フェイルオーバー、復元性、可用性を向上させることが可能。

• お客様所有 IP アドレスの使用（BYOIP）を、Google Cloud のリソースに独自のパブリック IP アドレスをプロビジョニングするために使用。

• GCVE に加え、GCE、GKE、Cloud Storage、サーバーレスなど、多様なバックエンド タイプの統合が可能。

シナリオ #1 - 外部ロードバランサ

以下の図には、このアーキテクチャに関わる GCP コンポーネントの概要が示されています。

このシナリオでは、Envoy プロキシ フリートとして実装された Traffic Director のデータプレーン コンポーネントにトラフィックを転送するために、外部の HTTP(S) ロードバランサが使用されています。ユーザーは、ルーティング可能な NSX セグメントを作成し、Traffic Director ですべてのトラフィック ポリシーを一元的に定義できます。GCVE VM の IP とポートのペアはハイブリッド NEG で直接指定されます。そのため、すべてのネットワーク操作は Google Cloud のコントロール プレーンでフルマネージドになります。

または、GCVE VM を階層 1 レベルで構成された NSX L4 ロードバランサの背後にあるルーティングできない NSX セグメントにデプロイし、VPC ピアリング接続の経路のインポートとエクスポートを介してロードバランサ VIP をお客様の VPC にエクスポートすることも可能です。GCVE では、NSX-T ロードバランサを階層 0 のゲートウェイではなく、階層 1 のゲートウェイと関連付けることが強く推奨されていることに留意することが重要です。

NSX-T でロードバランサを構成する手順（サーバープール、ヘルスチェック、仮想サーバー、分散アルゴリズムなど）は、VMware が文書化しているため、ここでは扱いません。

NSX ロードバランサでウェブ アプリケーションをフロントにすると、次のようなことが可能になります。

• VIP ルートのみが知らされるため、ウェブ層のプライベート IP アドレスの使用や、マルチテナントをデプロイした場合の IP アドレスの重複が可能。

• 内部クライアント（GCP または GCVE 内のアプリケーション）は NSX ロードバランサの VIP をさす場合がある。また、外部クライアントはネイティブ、GCP 外部ロードバランサの前にあるパブリック VIP を指す場合もある。

L7 NSX ロードバランサは、Cookie セッションの永続化や URL マッピングなどの高度なアプリケーション層サービスにも使用可能です（この例では説明しません）。

このシナリオでは、外部の HTTP(S) ロードバランサを使用する実装を示しました。しかし、HTTP(S) 以外のプロトコルに対応するために、外部の TCP/UDP ネットワーク ロードバランサや TCP プロキシを使用できることに留意してください。Traffic Director を L4 モードで使用する場合、ターゲット プロキシごとに単一のバックエンド サービスを使用するなどの制約があり、アーキテクチャの実装時に考慮する必要があります。

シナリオ #2 - 内部ロードバランサ

このシナリオでは、Traffic Director が管理する Envoy プロキシにリクエストをルーティングするためのロード バランシング プラットフォームが変更される点のみ異なります。このユースケースは、ここで文書化されているように、ユーザーが Traffic Director なしではサポートされていない高度なトラフィック管理機能を利用したい場合など、特定の状況において適切な場合があります。

Traffic Director によって制御される Envoy 管理下のプロキシは、GCVE ワークロードに直接トラフィックを送信できます。

別の方法として、シナリオ #1 で説明したことと同様に、明示的な GCVE VM IP の代わりに、NSX LB VIP を使用できます。これにより追加のロード バランシング レイヤが導入されます。

ここでは、L7 内部ロードバランサを使用した場合に考えられる構成を説明しました。しかし、HTTP(S) 以外のプロトコルに対応するために、L4 内部ロードバランサを使用することも可能です。Traffic Director と組み合わせて L4 と L7 のロードバランサを使用する場合、ここで文書化されているように、いくつかの考慮点があるので注意してください。

結論

お客様は、複数の GCP プロダクトを組み合わせることで、グローバルなロード バランシングなど Google が提供するさまざまな分散ネットワーク サービスを利用しながら、可用性や信頼性、パフォーマンスを犠牲にすることなく、運用に継続性をもたらす Google Cloud VMware Engine 環境でアプリケーションをホスティングすることが可能になります。

こちらの詳細については、GCVE ネットワーク ホワイトペーパーを確認してください。VMware Engine の詳細については、VMware Engine のランディング ページにアクセスし、インタラクティブ チュートリアルをご覧ください。また、VMware Engine と他の GCP コア インフラストラクチャおよびデータサービスを統合する方法について説明する予定ですので、今後の記事にご注目ください。