Traffic Director によるアプリケーション ネットワーキングの範囲が Google Cloud の外部まで拡大
Google Cloud Japan Team
※この投稿は米国時間 2020 年 12 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。
アプリケーションのネットワーキングに付随する根本的な課題は、サービスを運用する場所が Google Cloud かオンプレミスか、あるいは他のクラウドか、もしくはこれらすべてであるのかにかかわらず、いずれも変わりません。すなわち、これらのサービスにトラフィックをどのように配信し、これらのサービスが互いにどのように通信するのかということです。
Traffic Director は、サービス メッシュと負荷分散に利用するフルマネージドのコントロール プレーンであり、前述の課題をサービスの運用場所にかかわらず解決できることを基本理念として開発が進められました。そして今回、複数の環境で利用するというニーズにより的確に応えられるよう、この基本理念をさらにもう 1 つの領域に応用しました。
Traffic Director を利用することで、トラフィックを Google Cloud の外部でホストされているサービスとゲートウェイに送信できるようになったのです。Traffic Director で構成したルールに従って、Cloud Interconnect または Cloud VPN を通じて非公開でトラフィックをルーティングします。
この機能を利用すると、VPC ネットワークのサービスを他の環境のサービスとよりシームレスに相互運用することができます。また、非公開のオンプレミス サービスを保護する Cloud Armor など、Google Cloud のネットワーキング サービス ポートフォリオを基盤として、高度なソリューションを構築することも可能になります。Google Cloud のみでワークロードを実行するか、複数の高度な環境が必要であるかを問わず、ネットワーキングのツールキットとして利用できる多用途のツールが Traffic Director なのです。
ハイブリッド接続 NEG の導入
今回の機能が実現したのは、ハイブリッド接続ネットワーク エンドポイント グループ（NEG）に対応したことによるものです。一般公開となったハイブリッド接続 NEG については、クライアントがアプリケーションへのアクセスに使用できる IP アドレスとポート（「エンドポイント」）の集合であると考えてください。
Google Kubernetes Engine（GKE）ベースのサービスについて Traffic Director を構成している場合は、NEG をすでに利用していることでしょう。ハイブリッド接続 NEG は Google Cloud 内部の宛先に解決される必要がないため、特殊な存在となっています。オンプレミスのデータセンターにあるゲートウェイや別のパブリック クラウドにあるアプリケーションなど、VPC ネットワークの外部にある宛先に解決できるのです。
Google Cloud から別の環境にトラフィックを送信する場合、そのトラフィックは Cloud Interconnect や Cloud VPN などのハイブリッド接続で転送されます。この構成では、ワークロードを別の環境に配置したうえで Google Cloud から安全に到達できます。したがって、それらのワークロードに公共のインターネットを通じてアクセスできるようにしておく必要がなくなります。
以下に、Traffic Director でハイブリッド接続 NEG を使用する方法の簡単な例を示します。
オンプレミスで運用されている仮想マシン（VM）があり、その VM に Cloud の VPN 相互接続を介して VPC ネットワークから到達できるとします（IP アドレスは 10.0.0.1、ポートは 80）。
Traffic Director で「on-prem-service」という名前のサービスを作成し、IP アドレス 10.0.0.1、ポート 80 のエンドポイントが含まれているハイブリッド接続 NEG を追加します。
Traffic Director が、アプリケーションとともに運用されている Envoy サイドカー プロキシなどの Traffic Director クライアントにこの情報を送信します。アプリケーションがリクエストを「on-prem-service」に送信すると、Traffic Director クライアントがリクエストを検査し、「10.0.0.1:80」に誘導します。
この機能で実現できる構成
この機能を利用すると、Cloud Load Balancing のグローバル ネットワーク エッジ サービスに加えて、既存の Traffic Director の能力も兼ね備えたソリューションを構築できます。いくつか例を挙げましょう。
オンプレミスまたは別のクラウドにメッシュ トラフィックをルーティングする
この機能の最も単純なユースケースは、従来型のトラフィック ルーティングです。例:
ある環境から別の環境にトラフィックをルーティングするとします。上の例では、アプリケーションが「on-prem」サービスにリクエストを送信すると、Traffic Director クライアントが発信リクエストを検査し、宛先を更新します。宛先は、「on-prem」サービスに関連付けられているエンドポイントに設定されます（この場合は「10.2.0.1」）。リクエストは、VPN または Interconnect を経由して目的の宛先に転送されます。
エンドポイントをさらに追加する必要が生じた場合は、Traffic Director を更新してサービスに追加するだけでよく、アプリケーションのコードに変更を加える必要はありません。
別の環境にサービスを移行する
Google Cloud の外部にあるエンドポイントにトラフィックを非公開で送信できることから、今回の機能は単独でもきわめて有用です。さらに、重みに基づくトラフィック分割をはじめとする Traffic Director の機能と併用することによって、いっそう興味深いメリットを得られます。
上の例は前述のパターンを膨らませたものですが、すべてのトラフィックを「on-prem」サービスに送信するように Traffic Director を構成するのではなく、重みに基づくトラフィック分割を使用して、トラフィックを 2 つのサービスに割り振るように構成しています。
トラフィック分割では、トラフィックの 0% を「cloud」サービス宛て、100% を「on-prem」サービス宛てとする状態から構成に着手できます。次に、「cloud」サービス宛てのトラフィックの割合を徐々に増やしていきます。最終的に、トラフィックの 100% が「cloud」サービスに送信されるようにすると、「on-prem」サービスを廃止できます。
Google Cloud のエッジサービスを他の環境のワークロードに使用する
最後に紹介するのは、この機能を Cloud Load Balancing と組み合わせて、VPC ネットワークの外部にあるワークロードにグローバル エッジ機能を使用する方法です。Cloud Load Balancing では、グローバルに分散した内向きのパス、DDoS 対策のための Cloud Armor、Cloud CDN など、多種多様なネットワーク エッジ サービスが提供されています。
これらの機能を Traffic Director と併用して、公共のインターネットに公開されていないワークロードに対応できるようになりました。Google Cloud と別の環境の間に Cloud VPN または Cloud Interconnect を配置している場合、その非公開ルート経由でトラフィックが転送されます。公共のインターネット経由で到達できるオンプレミスとクラウドのワークロードに Cloud Armor を使用する方法については、以前に記事を投稿しています。下に図解したアプローチの場合、他の環境にあるワークロードに公共のインターネットから到達可能である必要はありません。
この例では、クライアントから発信されるトラフィックは公共のインターネットで転送され、Google のグローバル外部 HTTP(S) ロードバランサなどの Cloud ロードバランサ経由で Google Cloud のネットワークに着信します。トラフィックがロードバランサに到達すると、DDoS 対策のための Cloud Armor や Identity-Aware Proxy ユーザー認証などのネットワーク エッジ サービスを使用できます。
内向きのパスの保護が完了すると、トラフィックは Google Cloud で短時間保留され、アプリケーションまたはスタンドアロン プロキシ（Traffic Director で構成）によって、Cloud VPN または Cloud Interconnect 経由でオンプレミスのサービスに転送されます。
使ってみる
Traffic Director は当初から企業のニーズに主眼を置いたものであり、Google Cloud Platform（GCP）の外部で環境を運用している場合に生じる問題がハイブリッド接続 NEG によって解決される点は、新たな魅力の一つになります。
Traffic Director、Google Cloud Load Balancing、Cloud Armor を今すぐ導入して、複数の環境にまたがる非公開のワークロードに対応した、安全かつグローバルな内向きソリューションを設定しましょう。今回の機能は、本当の意味で普遍的なアプリケーション ネットワーキング ソリューションという Traffic Director の使命を果たすための第一歩にすぎません。今後さらに多くの機能拡張を予定しています。
-Traffic Director 担当プロダクト マネージャー Stewart Reichling
-Traffic Director 担当ソフトウェア エンジニア Chao Xin
