Exploration and Practice of Proxyless Mesh Mode in Spring Cloud Application

Service Mesh の概要

Service Mesh はもはや新しい概念ではありません。現在、Service Mesh に関する多くの探求と実践が行われています。

2016 年は Service Mesh の元年と言えます。Buoyant の CEO である William Morgan が率先して Linkerd をリリースし、業界初の Service Mesh プロジェクトとなりました。同年、Lyft が Envoy をリリースし、2 番目の Service Mesh プロジェクトが誕生しました。

2017 年、Google、IBM、Lyft が共同で Istio をリリースしました。Linkerd や Envoy などのプロジェクトと比較して、Istio はコントロールプレーンの概念を初めて導入し、強力なトラフィック制御機能を提供しました。長年の開発を経て、Istio はコントロールプレーンのデファクトスタンダードとして徐々に確立されてきました。

バージョン 1.0 のリリースにより、Istio は本番環境での利用可能な時代に入り、ますます多くの企業が Service Mesh を本番環境に適用しています。

バージョン 1.5 からは、複数のコンポーネントが単一の構造に統合され始めました。同時に、長年課題とされてきた Mixer コンポーネントが廃止され、Istiod サービスに統合されたことで、デプロイと運用保守が容易になりました。

現在、Istio は最も人気のあるオープンソースの Service Mesh であり、コントロールプレーンとデータプレーンで構成されています。

Istio Mesh アーキテクチャでは、コントロールプレーンは Istiod という名前のプロセスであり、ネットワークプロキシは Envoy です。Istiod はコントロールプレーンの統合コンポーネントとして、サービスの登録と検出、ルーティングルール管理、証明書管理などの機能との連携を担っています。Envoy はデータプレーンとして、Sidecar を通じてビジネストラフィックをプロキシします。Istio と Envoy は xDS プロトコルインターフェースを通じて、サービス検出、ルーティングルール、その他のデータの転送を完了します。Istiod は Service や Endpoint などの K8S リソースをリッスンしてサービス情報を取得し、xDS プロトコルを通じてこれらのリソースをデータプレーンのネットワークプロキシに配布します。Envoy はアプリケーションから独立したプロセスです。Sidecar モード (通常はコンテナモード) でビジネスアプリケーション Pod と一緒に実行され、アプリケーションプロセスと同じホストネットワークを共有し、ルーティングテーブルを変更してビジネストラフィックをインターセプトします。

xDS プロトコルインターフェースの詳細については、xDS REST および gRPC プロトコルドキュメント [1] を参照してください。

クラスタ規模の拡大とビジネスの複雑化に伴い、ネイティブ K8S ベースのコンテナオーケストレーションでは対応が困難になり、開発者は大きなサービスガバナンスの課題に直面せざるを得ません。Service Mesh はこの問題を適切に解決できます。サービスガバナンス機能をコントロールプレーンとプロキシにカプセル化することで、ビジネス開発者はビジネスロジックそのものに集中できます。アプリケーションのデプロイ後、運用作業者が設定を変更するだけで、障害復旧、負荷分散、グレースケールリリースなど、多くのサービスガバナンス機能を実現でき、開発とイテレーションの効率を大幅に向上させます。

Istio の Sidecar は、コンテナインジェクションの形でビジネスアプリケーションプロセスの全ライフサイクルに寄り添います。ビジネスアプリケーションに対して非侵襲型であるため、アプリケーション移行、マルチ言語対応、インフラストラクチャの結合などの問題を解決します。ただし、リソース消費の増大やリクエスト遅延の増加といった問題ももたらします。Sidecar の欠点を考慮すると、データプレーンのサポートに SDK を使用することを検討できます。そこで Proxyless Mesh アーキテクチャが登場します。

Proxyless Service Mesh

Proxyless Service Mesh とは何か。これは近年提唱された新しい概念です。Istio、gRPC、brpc などのオープンソースコミュニティがこの方向で探求と実践を行ってきました。SDK の形でビジネスアプリケーションに導入されるエージェントレスサービスメッシュフレームワークにより、サービス間の通信とガバナンスを担います。

gRPC Proxyless アーキテクチャ

現在、gRPC プロジェクトは xDS API プロトコルを部分的にサポートしています。つまり、Istio を通じて gRPC サービスを管理でき、Envoy Sidecar をデプロイする必要がありません。

上図に示すように、gRPC Proxyless モードでは Istio Agent の初期化とコントロールプレーンとの通信が必要です。まず、Istio Agent は起動時にブートストラップファイルを生成します。これは Envoy 用にブートストラップファイルを生成するのと同じ方法です。gRPC ライブラリに対して、コントロールプレーンへの接続方法、データプレーン通信の証明書の場所、コントロールプレーンに送信するメタデータを指示します。次に、Istio Agent は xDS プロキシとして、アプリケーションに代わってコントロールプレーンへの接続と認証を行います。最後に、Istio Agent はデータプレーン通信で使用する証明書の取得とローテーションを行います。

詳細については、gRPC Proxyless Mesh ドキュメント [2] を参照してください。

Proxyless アーキテクチャの長所と短所

Proxyless Mesh アーキテクチャの長所と短所を簡単に整理します。

Proxyless Mesh の長所：

パフォーマンス：エージェントレスモードでのネットワーク呼び出しはポイントツーポイントの直接通信であり、ネットワーク遅延はプロキシモードよりもはるかに小さくなります。

安定性：Proxyless は単一プロセスモデルでシンプルなトポロジーであり、デバッグが容易で安定性が高いです。

コスト：Sidecar が不要なため、リソース消費が低く抑えられます。

フレームワーク統合：市場には SDK ベースのサービスフレームワークが多数存在し、Mesh への移行後もフレームワークの既存機能を引き続き活用できます。

Proxyless Mesh の短所：

フレームワークと言語へのバインディング：複数の言語とフレームワークの SDK を開発して Proxyless Mesh をサポートする必要があります。現時点では、多くのフレームワークが Proxyless Mesh をサポートしていません。

移植性の低さ：Sidecar の切り替えによるインフラストラクチャの非侵襲型アップグレードが不可能であり、コードの修正が必要です。

Proxyless アーキテクチャの長所は明らかです。特に大規模なビジネスシナリオでは、多くのマシンリソースと追加のメンテナンスコストを節約できます。ただし、短所も同様に明確です。Proxyless SDK のアップグレードが必要になった場合、SDK の更新、コードの修正、フレームワークバージョンのアップグレードが必要になります。

MSE による Proxyless Mesh の課題解決

MSE は JavaAgent を通じて xDS プロトコルを実装する戦略を採用しました。これにより、Spring Cloud は JavaAgent に接続するだけで Mesh エコシステムにアクセスでき、Istio で設定されたルーティングルールをサポートできます。JavaAgent は xDS プロトコルを通じて Istiod から他のサービスのアドレスリストを取得し、Spring Cloud の負荷分散 Ribbon の ServerList に変換して、アドレスリストの収集と統合を行います。これにより、ネイティブな Spring Cloud アプリケーションはコードを 1 行も修正せずに Proxyless Mesh モードをサポートでき、既存の Nacos のサービス検出とも互換性があります。

一方で、Envoy と比較して、JavaAgent は Java アプリケーションに対してさらに豊富なガバナンス機能を提供できます。たとえば、サービスコントラクト、インターフェース情報、データベーストラフィックガバナンス、JVM 監視とガバナンスなどがあります。

Spring Cloud アプリケーションの非侵襲型 Proxyless Mesh アーキテクチャへのアップグレード

実際のシンプルな例を使って、Spring Cloud アプリケーションを非侵襲型で Proxyless Mesh アーキテクチャにアップグレードする方法を体験してみましょう。

デモ：Spring Cloud アプリケーションと Service Mesh アーキテクチャのマルチ言語マイクロサービスとの相互運用を実現するには？

前提条件

MSE サービスガバナンス機能を有効化し、現在の K8S クラスタに Alibaba Cloud ASM の Istio インスタンスを作成します。

ステップ 1：Spring Cloud サービスとマルチ言語サービスをデプロイする

Spring Cloud アプリケーションとマルチ言語の Go アプリケーションをデプロイする必要があります。

デモアプリケーションのサンプルは以下のドキュメント [3] から取得できます。

Spring Cloud アプリケーションからマルチ言語サービスの呼び出しは、他の Spring Cloud アプリケーション間の呼び出しと同じ方法で行います。たとえば、restTemplate を使用して Spring Cloud サービス (アプリケーション名：go-sc-a) の A インターフェースを呼び出す場合、以下のようになります。

restTemplate.getForObject("http://go-sc-a/A", String.class)

他の方法で呼び出すこともできます。対応サービスのポート番号を指定せずに直接アクセスできます。

ステップ 2：環境変数を設定して MSE Agent の xDS プロトコルサポートを有効化する

以下の環境変数を追加して、MSE Agent の xDS プロトコルサポートを有効化する必要があります。

ステップ 3：結果の確認

Spring Cloud サービスとサービスメッシュのマルチ言語サービスは相互運用を実現でき、Spring Cloud サービスからマルチ言語サービスを呼び出す方法はコードの修正を必要としません。

Spring Cloud サービスからマルチ言語サービスへのアクセス：

まとめ

この記事では、Spring Cloud アプリケーションが MSE サービスガバナンスに接続後、コードを一切修正せずに Proxyless Mesh 機能を獲得できることをデモを通じて示しました。現在の MSE サービスガバナンスにはいくつかの制限があり、継続的に補完と改善が進められています。現在のプロキシモードでは、基本的なサービス検出機能と DestinationRule のサブセット機能をサポートしており、MSE のトラフィックガバナンスと連携することで、Mesh アーキテクチャでのフルリンクグレースケール、ラベルルーティングなどのガバナンス機能を実現できます。

また、特筆すべき点として、CloudWeGo、Kratos、Spring Cloud Alibaba、Dubbo、ShardingSphere、Database Mesh などのコミュニティと協力して、OpenSergo マイクロサービスガバナンス標準の構築を進めています。企業とコミュニティのマイクロサービスガバナンスシナリオとベストプラクティスを標準仕様に抽出することを目指しています。

OpenSergo マイクロサービスガバナンス標準の共同構築に、より多くのコミュニティと企業の参加を歓迎します。OpenSergo コミュニティは現在急速な発展段階にあり、マイクロサービスガバナンス標準の定義からコントロールプレーンの実装、Java / Go / C++ / Rust などのマルチ言語 SDK とガバナンス機能の実装、そしてさまざまなマイクロサービスエコシステムとの統合と実装まで、まだ多くの進化の余地があります。コミュニティの皆様の標準仕様の改善とコード貢献を歓迎します。