コンテンツに移動
ネットワーキング

Traffic Director と gRPC - サービス メッシュ用プロキシレス サービス

2020年8月12日
Google Cloud Japan Team

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

多くの組織がサービス メッシュを利用しています。それは特にマイクロサービスを多用する環境において、面倒で複雑なネットワーキングの問題が解決されるからです。また、サービス メッシュを利用することで、負荷分散ポリシーやトラフィック マネジメント ポリシーなどのアプリケーション ネットワーキング ポリシーを一元化して管理できます。ただし、サービス メッシュの導入とは従来、(1)インフラストラクチャの管理(コントロール プレーン)、および(2)アプリケーションに代わってネットワーキングを処理するサイドカー プロキシの実行(データプレーン)を意味していました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_Illustrative_service_mesh_with_sidecar_pro.max-700x700.jpg
コントロール プレーンにより構成されるサイドカー プロキシを使ったサービス メッシュの例

Traffic Director は、Google Cloud が管理するコントロール プレーンで、前述したサービス メッシュ導入時の 1 つ目の障壁を解決するように設計されており、追加のインフラストラクチャ(コントロール プレーン)を管理する必要はありません。今回は 2 つ目の問題を解決する新しいアプローチとして、サイドカー プロキシを管理する必要はない、ということをお知らせします。Traffic Director がプロキシレスの gRPC サービスをサポートすることで、プロキシベースのサービス メッシュでプロキシレスの gRPC アプリケーションを利用することも、さらには完全にプロキシレスのサービス メッシュにすることもできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_service_mesh_with_proxyless_gRPC_applicati.max-700x700.jpg
Traffic Director により構成されるプロキシレスの gRPC アプリケーションを使ったサービス メッシュ

Traffic Director によるプロキシレスの gRPC サービスのサポート

Traffic Director のプロキシレス gRPC サービスのサポートは、シンプルな考えをベースに設計されています。Traffic Director はサイドカー プロキシが gRPC クライアントに代わって負荷分散を行うように構成できるのだから、Traffic Director が直接 gRPC クライアントを構成すればよいのではないかという考えです。

gRPC は、ご存じのとおり、高パフォーマンスかつ豊富な機能を備えたオープンソースの RPC フレームワークで、日常的に利用される Google Cloud Platform(GCP)の多くのサービスの基盤となっています。GCP では gRPC を Google Cloud クライアント ライブラリで利用しており、Cloud Storage、Cloud Pub/Sub、その他多くのサービスにアクセスするのに使われています。gRPC は接続の管理、双方向ストリーミング、その他の重要なネットワーキング機能を処理します。つまり、gRPC はマイクロサービス ベースのアプリケーションを構築するためのすぐれたフレームワークと言えます。

しかし、追加設定なしの gRPC では、DNS ベースの名前解決と簡単な負荷分散しか行いません。サービスに対するバックエンドの動的な検出や距離ベースでのグローバルな負荷分散など、サービス メッシュの機能を求めて、従来はサイドカー プロキシが利用されていました。このサイドカー プロキシは、強力なサービス メッシュ能力を提供できますが、ここもインフラストラクチャの追加部分として管理が必要です。

gRPC + xDS

プロキシレスの gRPC を実現するため、xDS API サポートを最新バージョンの gRPC に追加しました。xDS API は一般的な Envoy プロキシで利用されているオープンソース API と同じものです。xDS API を利用することにより、Traffic Director などの xDS コントロール プレーンがサービスの情報を使って gRPC クライアントを構成できます。このサービス情報にはエンドポイントのアドレス、ヘルス ステータス、(距離および容量に応じた)優先度、サービスを呼び出す際に利用するポリシーなどが含まれます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_Traffic_Director.max-1000x1000.jpg
Traffic Director はマルチリージョンのサービス向けにエンドポイント情報を提供します。トラフィックは容量のある最も近くの正常なインスタンスへと優先され、他のリージョンへ自動的にフェイルオーバーできます。

さらに、gRPC アプリケーション向けに、GCP が管理する ネイティブ gRPC ヘルスチェックのサポートを追加しました。Traffic Director はこのヘルスチェックからデータを収集し、上記画像のように収集したデータを利用してサービスのエンドポイントの正常性を決定します。

このサポートの追加により、gRPC アプリケーションにサイドカー プロキシをデプロイすることなくサービス メッシュを活用できるようになります。

プロキシレス gRPC のスタートガイド

サービス メッシュの利点をできる限り簡単に活用できるようにしたいと願っています。そのために重要なことは追加のインフラストラクチャの必要性を減らすことです。プロキシレスの gRPC をスタートする手順も次のとおり簡単です。

 1. gRPC アプリケーションを最新バージョンに更新する

 2. 新しい「xds」gRPC 名前解決機能を利用する

 3. 小規模なブートストラップ ファイルを追加する

 4. Traffic Director でのサービスとポリシーを構成する

さらに広い意味で、プロキシレスの gRPC サービスを、サイドカー プロキシ ベースのサービスと同様に、サービス メッシュにサービスをデプロイするもう 1 つの方法として考えることもできます。Traffic Director を利用すると、プロキシベースとプロキシレスの gRPC サービス両方を、1 つのサービス メッシュでデプロイできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_Traffic_Director_supports_service_mesh_dep.max-900x900.jpg
Traffic Director はプロキシレスおよびプロキシベースの gRPC アプリケーションを含んだサービス メッシュのデプロイをサポートしています。

両方のデプロイメント モデルを含んだサービス メッシュをお客様が実行することを想定しています。さらに単一の gRPC クライアントがあるサービスの呼び出しをプロキシレスのルートで行い、別のサービスの呼び出しをサイドカー プロキシを通じて行えるようにしました。

プロキシレス gRPC サービスを使った Traffic Director デプロイメントを行うタイミング

プロキシレスの gRPC を使ったアプローチとして、3 つのユースケースを紹介します。(マネージド ネットワーキングの経験に基づく)簡単な gRPC 導入、サービス メッシュでの高パフォーマンス サービス、サイドカー プロキシを追加できない環境へのサービス メッシュの導入の 3 つです。

gRPC を簡単に導入するためのマネージド ネットワーキング

Google はアプリケーション スタックをモダナイズする取り組みの一環として gRPC の導入を検討しているお客様との対話を常に心がけています。gRPC のメリットは明らかですが、クライアント サイドの負荷分散やサービス ディスカバリ、グローバルなフェイルオーバーといった問題を gRPC 自体が解決するわけではありません。Traffic Director によるプロキシレス gRPC サービスのサポートは、このニーズに対処するよう設計されました。したがってより簡単に gRPC をモダナイズされたデプロイメントの一部として導入できるのです。

リソースの効率性とパフォーマンス

プロキシはリソースを消費しますし、数百、数千単位のプロキシにスケーリングするにしたがって消費は増えていきます。加えて、高パフォーマンスのアプリケーションは、リクエストやレスポンスのやり取りでクライアント サイドカー プロキシ、サーバー サイドカー プロキシといった複数のサイドカー プロキシを通じてリクエストを送信する際、パフォーマンス目標の達成が困難になる場合があります。

Google でテストした結果、プロキシレス gRPC を使うことで、サイドカー プロキシに比べてネットワーキングに関連する CPU のコストを節約できることがわかりました。ベンチマークでは、サイドカー プロキシがネットワーク ホップを追加するため、レイテンシの増加を引き起こすことが示されています。プロキシレスのアプローチにより、この両方の面で節約が可能です。

最後に、こういったパフォーマンスの向上は、通信会社のネットワーク機能や 5G / エッジ コンピューティング向けのサービス メッシュのデプロイメントといった新たなユースケースにとって重要になります。

サイドカー プロキシを追加できない環境向けサービス メッシュ

デプロイに必ずしもサイドカー プロキシを追加できるとは限らないお客様とも話をしてきました。マネージド型のコンピューティング環境によっては、複数のプロセスの起動(1 つはアプリケーション、もう 1 つはプロキシの)またはインスタンスのネットワーク スタックへの変更(たとえば、iptables を利用して)を行えません。このような場合、プロキシレス gRPC アプリケーションを利用することでサービス メッシュを活用できます。

次のステップ

企業のネットワークは多種多様です。Traffic Director は、ニーズに合ったデプロイ オプションをサポートできるように柔軟性を持たせて設計されています。サポートされているデプロイ オプションには、Envoy サイドカー プロキシ、Envoy ミドル / ゲートウェイ プロキシ(内部的に Traffic Director を利用している内部 HTTP(S) ロードバランサなど)、そしてプロキシレスの gRPC アプリケーションがあります。

この初回リリースではサービス ディスカバリと負荷分散に焦点を当てています。サービス メッシュではそれ以上のこと、たとえばレイヤ 7 ベースのトラフィック管理とセキュリティなどが可能であることを把握していますが、この最初の一歩を重視しています。今回 GCP が管理する新しい gRPC ヘルスチェックと併せてご紹介したトラフィック管理機能は、お使いの gRPC アプリケーションにサービス メッシュを簡単に導入できるようにする第一歩にすぎません。

この機会に、ぜひTraffic Director の設定ガイドをご覧いただき、Compute EngineGoogle Kubernetes Engine でプロキシレス gRPC サービスをご利用ください。プロキシレス gRPC サービスに対する Traffic Director のサポートの実際のところについて詳しくは、2020 年 7 月 28 日に公開している NET206 on NextOnAir をご覧ください。

-Cloud Functions プロダクト マネージャー Stewart Reichling / プロキシレス gRPC エンジニアリング リード Srini Polavarapu

投稿先