トラフィック管理の標準化: Service Directory と Traffic Director

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

最新のサービスは、異なる種類のインフラストラクチャのプラットフォームが混在する環境に構築されています。この混在する環境は、サービスがクラウドに移行され、オペレーションが簡素化されていく中で常に変化しています。サービスをクラウドに移行、または、従来の技術から新しい技術に移行する場合、ロード バランシングやトラフィック管理などの主要なコンポーネントの再構成に手間がかかることがあります。このたび、Google は Service Directory と Traffic Director のインテグレーションのプレビュー版をリリースします。これらを利用すると、異種が混在し、進化し続けるインフラストラクチャ全体において、サービスのロード バランシングとトラフィック管理を一貫した方法で設定できるようになります。

シナリオ: サービスをクラウドへ移行する

例として、オンプレミスで決済サービスを行い、トラフィック管理に Traffic Director を使っている企業を仮定します。この企業は、決済サービスを Google Cloud に移行し、段階的にトラフィックを移行させて運用上のオーバーヘッドを削減したいと考えています。

現在、これを実現するためには、まったく異なるインフラストラクチャ固有の構成パスを管理する必要があり、次のような操作が必要です。

• オンプレミスのサービスを Traffic Director で利用できるようにするためにワークフローを 1 つ構成する

• Google Cloud サービスを利用できるようにするための別のワークフローを構成する

• Google Cloud サービスの構築方法（実行されているのは Compute Engine かまたは Kubernetes Engine かなど）によって異なる手順を踏む

Service Directory と Traffic Director のインテグレーションを使用すると、現在構築されているインフラストラクチャに関係なく、すべてのサービスを同じ方法で構成し、このような手順を簡素化できます。サービスが GCE、GKE、オンプレミス、その他のクラウド上に構築されていたとしても、Traffic Director が必要とする情報は、Service Directory のエントリについてだけです。以下のセクションでは、Service Directory と Traffic Director について取り上げ、この 2 つのプロダクトが手順の簡素化を実現するために、どのように連携しているのかを紹介します。

Service Directory: すべてのサービスを一元管理

Service Directory は、サービスがホストされているのが Google Cloud、オンプレミス、その他のクラウドかどうかにかかわらず、すべてのサービスとそのメタデータを一元管理し、追跡を可能にする中央サービス レジストリです。API 呼び出しを介して、あらゆる種類のサービスを Service Directory に登録できます。ロードバランサをはじめとするサービスや、Kubernetes Engine 上で動作するサービスを使用すると、サービス登録に関するオーケストレーションを自分で管理しなくても、自動的に Service Directory に同期されます。

Traffic Director: ルーティング、ロード バランシング、トラフィック管理

Traffic Director は、次世代のマネージド ロードバランサやオープン サービス メッシュに適した Google Cloud のフルマネージド トラフィック コントロール プレーンです。Traffic Director を使用すると、GKE クラスタと VM インスタンスのサービス間の通信の可視性を高め、ゼロトラストのセキュリティ体制を確立できます。Traffic Director では、複数地域におけるグローバルなロード バランシングが可能で、ヘルスチェックとの統合、フォレンジック用のトラフィック ミラーリング、サービス移行のための重み付けに基づくトラフィック分割、カナリア デプロイなど、数多くの高度なトラフィック管理ポリシーがサポートされます。

Service Directory と Traffic Director

このシナリオで見てきたように、Traffic Director を異種混合デプロイで構成するには、各サービスが構築されているインフラストラクチャを理解する必要があります。サービス インフラストラクチャの種類によって、それぞれ独自の構成パスが必要になる場合があります。Traffic Director を使用すると、Service Directory に登録されたサービスを直接操作することが可能になります。このオプションによって、構成パスがすべてのサービスに対して共通になり利便性が向上します。

操作は簡単です。

• サービスをエンドポイントやアノテーションと一緒に Service Directory に登録します。ロードバランサをはじめとするサービスや Kubernetes Engine 上で動作するサービスについては、自動的に登録されます。

• 以下のようなコマンドを使用して、Service Directory のサービスを Traffic Director のバックエンド サービスにバインドするサービス バインディングを作成します。

• これで、Traffic Director で、このサービスをご利用いただけるようになりました。Traffic Director は、このサービスにトラフィックを転送し、トラフィック管理ポリシーを適用します。以下の例では、シナリオの中の Google Cloud とオンプレミス版の決済サービス間でトラフィックを分割しています。

• サービス バインディングのプロセスは、サービスが構築されているテクノロジーに関係なく、まったく同じものになります。必要なのは、Service Directory に登録されているサービスのエントリの指定だけです。

• Service Directory でサービスのエンドポイント情報が変更されると、Traffic Director によって新しいエンドポイントが自動的に認識されるので、手動で再構成する必要がありません。同様に、サービスのインフラストラクチャが変更されても（別のテクノロジーに移行した場合など）、サービス バインディングのプロセスはまったく同じままです。

Service Directory と Traffic Director のメリットには、以下のようなものがあります。

• シンプルな API: Service Directory によって、内部 TCP / UDP や HTTP(S) ロードバランサをはじめとする、GKE 上で動作するサービスや、Private Service Connect など、複数のサービスをサポートしています。Service Directory のインテグレーションにより、これらのサービスはすべて、サービス バインディングと呼ばれるシンプルな API 構成によって Traffic Director で表現され、Traffic Director を構成するプラットフォーム管理者から現状の詳細なバックエンド表現を抽象化できます。Service Directory が統合されていない場合、プラットフォーム管理者は、現在のインフラストラクチャの設定に応じて、ネットワーク エンドポイント グループやインスタンス グループなど、異なる種類のバックエンドを考慮する必要があります。サービス バインディング API は、統一されたユーザー エクスペリエンスを生み出し、サービス メッシュにおけるサービスのプロデューサーとコンシューマ間の明確な境界を確立することができます。

• サービスの自動登録によるオンボーディングの簡略化: 前述のとおり、ロードバランサや GKE 上で動作する多くの Google Cloud サービスは、自動的に Service Directory に同期されます。これにより、Service Directory、そして Traffic Director にすばやくサービスをオンボーディングできます。

• サービス変更時の対応が簡単: Service Directory を使用すると、Traffic Director に対してサービスの変更が自動的に通知されます。たとえば、サービス エンドポイントの IP が変更された場合、Service Directory は Traffic Director に変更後のステータスを伝えます。その際に再構成をする必要はありません。

• より多くのサービスが利用可能なサービス メッシュ: Service Directory のレジストリには、あらゆる環境のサービスを登録できるため、より多くの役立つサービスをサービス メッシュで利用できるようになります。これには、Private Service Connect、Google Cloud マネージド サービス、オンプレミスやハイブリッド サービスによる組織間のサービスやマネージド サードパーティ サービスが含まれます。

Service Directory と Traffic Director のプレビュー版の利用を開始するには、こちらのドキュメントをご覧ください。