Traffic Director についての説明

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

御社のアプリケーションがマイクロサービス アーキテクチャにデプロイされていれば、アーキテクチャに付随するネットワーキングの課題についてよく理解されていると思われます。Traffic Director は、グローバル サービス メッシュでマイクロサービスを実行する際に有用です。このメッシュによってマイクロサービスのネットワーキングが処理されるため、ビジネス ロジックとアプリケーション コードに注力することができ、基盤となるネットワークの複雑性を認識する必要がありません。アプリケーション ロジックをネットワーキング ロジックから分離することで、開発速度を向上させ、サービスの可用性を高め、組織に最新の DevOps プラクティスを導入できます。

Kubernetes 上での一般的なサービス メッシュの動作

一般的なサービス メッシュでは、Kubernetes クラスタにサービスをデプロイします。

• 各サービスの Pod には、アプリケーション コンテナと一緒に、サイドカー プロキシとして実行される専用のプロキシ（通常は Envoy）があります。

• 各サイドカー プロキシは、クラスタにインストールされているネットワーキング インフラストラクチャ（コントロール プレーン）と通信します。コントロール プレーンは、サービス メッシュ内のサービス、エンドポイント、ポリシーについて、サイドカー プロキシに通知します。

• Pod がリクエストを送信または受信すると、Pod のサイドカー プロキシによってリクエストが傍受されます。サイドカー プロキシは、そのリクエストを目的の宛先に送信するなどの処理を行います。

コントロール プレーンは各プロキシに接続され、プロキシがリクエストの処理に必要とする情報を提供します。A というサービスのアプリケーション コードがリクエストを送信すると、プロキシがそのリクエストを処理して B というサービスに転送するというフローです。このモデルによって、ネットワーキングのロジックをアプリケーション コードの外に出すことができます。アプリケーション ネットワーキングの処理をサービス メッシュ インフラストラクチャに任せて、ビジネス価値の提供に専念することが可能です。

Traffic Director の特徴

Traffic Director は一般的なサービス メッシュ モデルと似た動作をしますが、非常に重大な相違点がいくつかあります。Traffic Director が提供するものは以下のとおりです。

• フルマネージドの高可用性コントロール プレーン。インストールが不要で、クラスタ内で実行されないため、メンテナンスの必要がありません。本番環境レベルの SLO で、Google Cloud がすべてのプレーンを管理します。

• 容量と健全性を意識したグローバルなロード バランシング、およびフェイルオーバー。

• ゼロトラストのセキュリティ対策を実現するための統合型セキュリティ機能。

• コントロール プレーンとデータプレーンのオブザーバビリティに関する豊富な機能。

• マルチクラスタの Kubernetes、ハイブリッド クラウド、VM、gRPC サービスなどにまたがるマルチ環境サービス メッシュに対するサポート。

Traffic Director は、プロキシがリクエストを転送するために必要な情報を提供します。たとえば、A というサービスに属する Pod 上のアプリケーション コードがリクエストを送信するとします。この Pod とともに稼働するサイドカー プロキシがリクエストを処理して、B というサービスに属する Pod に転送します。

マルチクラスタ Kubernetes: Traffic Director では、複数の Kubernetes クラスタにまたがるアプリケーション ネットワーキングをサポートします。この例では、米国とヨーロッパの Kubernetes クラスタに対して、マネージド プレーンとグローバル コントロール プレーンを提供しています。クラスタ内のサービスが、別のクラスタ内のサービスと通信できます。さらに、複数のクラスタの Pod で構成されるサービスを使用することもできます。Traffic Director の近接ベースのグローバルなロード バランシングを使用すると、B というサービス宛のリクエストは、そのリクエストを処理可能な距離的に最も近い Pod に送られます。また、フェイルオーバーはシームレスに行われます。Pod がダウンすると、その Pod が別の Kubernetes クラスタ内にある場合でも、リクエストに対応可能な別の Pod へ自動的にリクエストがフェイルオーバーされます。

ハイブリッド環境とマルチクラウド環境をまたぐ Traffic Director の動作

Google Cloud、オンプレミス、その他のクラウドのいずれのサービスにおいても、またはそのすべてにサービスがある場合でも、アプリケーション ネットワーキングにおける基本的な課題は変わりません。どのようにして、トラフィックをこうしたサービスへ向かわせるかという課題です。また、どのようにして、こうしたサービスを互いに通信させるかという課題です。

Traffic Director は、Google Cloud で実行されているサービスから、別のパブリック クラウドで実行されているサービスとオンプレミスのデータセンターで実行されているサービスに、トラフィックを転送します。サービスでは、サイドカー プロキシまたはプロキシレス gRPC サービスとして、Envoy を使用できます。Traffic Director を使用すると、Google Cloud 外部の宛先にリクエストを送信できます。これにより、Cloud Interconnect または Cloud VPN を使用して、Google Cloud 内のサービスから他の環境のサービスまたはゲートウェイにプライベート トラフィックをルーティングできます。公開インターネット上で利用可能な外部サービスにリクエストをルーティングすることもできます。

Traffic Director によるプロキシレス gRPC および VM へのサポート方法

仮想マシン: Traffic Director は、VM ベースのワークロードと Kubernetes ベースのワークロードを並行する形で、アプリケーション ネットワーキングを解決します。Compute Engine VM インスタンス テンプレートにフラグを追加するだけで、アプリケーション ネットワーキング機能を提供するプロキシのインストールと構成を含めたインフラストラクチャのセットアップを、Google がシームレスに処理します。

たとえば、ある地域の Kubernetes クラスタ内のサービスへの外部 HTTP(S) ロード バランシングを介してトラフィックがデプロイメントに入ってくると、そのトラフィックがまったく異なる地域の VM 上の別のサービスへルーティングされる場合があります。

gRPC: Traffic Director を使用すると、サービス ディスカバリ、ロード バランシング、トラフィック管理といったアプリケーション ネットワーキング機能を gRPC アプリケーションへ直接簡単に持ち込むことができます。これは、始めから gRPC に備わっている機能のため、サービス プロキシは必要ありません。そのため、プロキシレス gRPC アプリケーションと呼ばれます。詳細については、Traffic Director と gRPC - サービス メッシュ用のプロキシレス サービスをご覧ください。

Traffic Director の詳細については、こちらの投稿とドキュメントをご確認ください。

#GCPSketchnote の詳細については、GitHub リポジトリをフォローしてください。同様のクラウド コンテンツについては、Twitter @pvergadia で発信しています。thecloudgirl.dev もぜひご覧ください。

-Google デベロッパー アドボケイト Priyanka Vergadia