Proxyless Mesh Practice in Dubbo

関連タグ：1.Alibaba Cloud Service Mesh
2. Service Mesh による運用管理の簡素化

背景

Dubbo 3.1 のリリースに伴い、Dubbo はクラウドネイティブへの道において新たな一歩を踏み出しました。このバージョンでは、Proxyless Mesh という新機能が追加されました。Dubbo Proxyless Mesh は、xDS プロトコルの解決を直接実装し、Dubbo とコントロールプレーンとの直接通信を実現することで、トラフィック制御、サービスガバナンス、可観測性、セキュリティなどの一元的な管理を実現し、Sidecar モードによるパフォーマンスの損失やデプロイメントアーキテクチャの複雑さを回避します。

Service Mesh とは

Service Mesh は「サービスグリッド」とも訳され、サービス間通信のインフラストラクチャ層として使用されます。Buoyant 社の CEO である William Morgan 氏は、記事「WHAT'S A Service Mesh？ AND WHY DO I NEED ONE？」の中で、Service Mesh とは何か、そしてクラウドネイティブアプリケーションに Service Mesh が必要な理由を説明しています。

以下は、William Morgan 氏による Service Mesh の説明です。

Service Mesh は、サービス間の通信を処理するための専用インフラストラクチャ層です。モダンなクラウドネイティブアプリケーションを構成する複雑なサービストポロジーを通じて、リクエストを確実に配信する役割を担います。実際には、Service Mesh はアプリケーションコードの隣にデプロイされる軽量なネットワークプロキシの配列として実装され、アプリケーション側はプロキシの存在を意識する必要はありません。

訳出：

Service Mesh は、サービス間の通信を処理するインフラストラクチャ層です。モダンなクラウドネイティブアプリケーションの複雑なサービストポロジーを構成し、リクエストを確実に配信する役割を担います。実際には、Service Mesh は通常、軽量なネットワークプロキシの配列として実装されます。これらのプロキシはアプリケーションコードと一緒にデプロイされ、アプリケーションはプロキシの存在を意識する必要がありません。

Service Mesh といえば、Sidecar モードは欠かせない存在です。Sidecar コンテナをビジネス Pod に注入することで、ビジネスコンテナの通信トラフィックをインターセプトします。同時に、Sidecar コンテナはメッシュプラットフォームのコントロールプレーンと接続され、コントロールプレーンから発行されるポリシーに基づいて、プロキシがトラフィックの管理と制御を行い、元々サービスフレームワークが持っていたガバナンス機能を Sidecar コンテナに委譲することで、基盤機能の切り出しとビジネスシステムからのデカップリングを実現します。

従来の Sidecar Mesh デプロイメントアーキテクチャには、スムーズなアップグレード、多言語対応、ビジネスへの影響が少ないといった多くの利点がありますが、同時に以下のような問題も伴います。

・プロキシによるパフォーマンスの損失。複雑なトポロジーのネットワーク呼び出しで特に顕著になります

・トラフィック横取りによるアーキテクチャの複雑化

・Sidecar のライフサイクル管理

・デプロイメント環境の制約。すべての環境が Sidecar のトラフィック横取り条件を満たすわけではありません

Sidecar Mesh モードの問題に対し、Dubbo コミュニティは以前からコントロールプレーンへの直接アクセスを構想し、国内オープンソースコミュニティに先駆けて Proxyless Mesh の概念を提唱しました。Proxyless という概念自体は、Google が最初に提唱したものです。

Dubbo Proxyless Mesh

Dubbo の Proxyless モードとは、Dubbo が Istiod と直接通信し、xDS プロトコルを通じてサービスディスカバリとサービスガバナンスを実現する機能を指します。

Proxyless モードは、マイクロサービスを Dubbo 2.x 時代のデプロイメントアーキテクチャに戻すもので、Dubbo の従来のサービスガバナンスモデルに酷似しています。したがって、このモデル自体は新しいものではなく、Dubbo は当初からこの設計モデルを採用していました。これにより、アプリケーションのパフォーマンスを大幅に向上させ、ネットワーク遅延を削減できます。SDK ベースのマイクロサービスモデルへの回帰であると指摘する声もありますが、実際にはそうではありません。Envoy の xDS API を引き続き使用していますが、アプリケーションへの Sidecar プロキシの注入が不要になるため、アプリケーションのパフォーマンス低下を抑えられます。

Tips：ディスカバリサービスとその API は xDS と呼ばれます

ただし、Mesh アーキテクチャと比較すると、Dubbo の従来のサービスガバナンスモデルではコントロールプレーンの一元的な制御が強調されていません。これに対し、Service Mesh はトラフィック、可観測性、証明書などの標準化された管理とガバナンスを強調しており、まさに Mesh コンセプトの先進性を示す部分です。

Dubbo Proxyless アーキテクチャモードでは、Dubbo プロセスはコントロールプレーンと直接通信し、Dubbo プロセス間は直接通信モードを維持します。Proxyless アーキテクチャの利点は以下の通りです。

・追加のプロキシ中継によるオーバーヘッドがないため、パフォーマンスに敏感なアプリケーションに適しています

・レガシーシステムからのスムーズな移行に有利です

・アーキテクチャがシンプルで、運用保守とデプロイメントが容易です

・ほぼすべてのデプロイメント環境に対応可能です

サービスディスカバリ

xDS アクセスはレジストリモードで接続されます。ノードディスカバリは、他のレジストリのサービスイントロスペクションモデルと同様に、xDS の負荷分散とルーティング設定は ServiceInstance の動的ランタイム設定を通じて転送され、設定パラメータは Invoker 構築時に設定アドレスに転送されます。

証明書管理

ゼロトラストアーキテクチャの下では、ワークロードの識別と信頼を厳密に区別する必要があり、X.509 証明書の発行は推奨される認証方式です。Kubernetes クラスター内では、サービスは DNS 名を介して相互にアクセスしますが、ネットワークトラフィックは DNS 偽装、BGP/ルートハイジャック、ARP 偽装などの手段でハイジャックされる可能性があります。サービス名（DNS 名）とサービス ID を強力に関連付けるため、Istio は X.509 証明書に配置されたセキュリティ命名メカニズムを採用しています。SPIFFE は Istio が採用するセキュリティ命名仕様であり、クラウドネイティブ環境で定義された標準化されたポータブルなワークロード ID 仕様でもあります。

Secure Production Identity Framework For Everyone（SPIFFE）は、サービス間の相互識別のための標準セットであり、主に以下の内容を含みます。

・SPIFFE ID 標準：SPIFFE ID はサービスの一意な識別子であり、具体的な実装では URI リソース識別子を使用します

・SPIFFE 検証可能 ID ドキュメント（SVID）標準：SPIFFE ID を暗号化された検証可能なデータ形式にエンコードします

・SVID の発行と失効の API 標準（SVID は SPIFFE ID の識別クレデンシャルです）



SPIFFE ID は URI 形式でワークロードの一意な識別子を指定し、spiffe:/// の形式を使用します。ただし、Istio は独自のエコシステム内でのみ SPIFFE ID をセキュリティ名として使用し、データ形式は自ら実装しています。通信形式は CNCF がサポートする xDS プロトコル仕様に準拠しています（証明書認証通信は、具体的には xDS の SDS です）。

Istio は特定形式の SPIFFE ID をセキュリティ名として使用し、X.509 証明書の subjectAltName 拡張に注入します。trust_domain パラメータは、Istiod の環境変数 TRUST_DOMAIN を通じて注入され、マルチクラスター環境での相互作用に使用されます。

具体的な形式は以下の通りです。

spiffe:///ns//sa/

以下は、Dubbo Proxyless Mesh の証明書発行プロセスです。

・RSA 秘密鍵の作成

・CSR（証明書署名要求）テンプレートの構築

・自己署名 CSR による証明書の生成

・CA 証明書と秘密鍵を格納する Kubernetes Secret リソースの作成（CA Service により処理）

実践例

次に、既存のプロジェクトを Proxyless Mesh モードで素早く動作させるための実践例を紹介します。

環境構築

・Docker のインストール

https://www.docker.com/

・minikube のインストール

強くお勧めします：

https://kubernetes.io/zh-cn/docs/tutorials/hello-minikube/

・Istio のインストール

https://istio.io/latest/docs/setup/getting-started/

注意：Istio のインストール時に、first party JWT サポートを有効化する必要があります（istioctl ツールでインストールする際に --set values.global.jwtPolicy=first-party-jwt パラメータを追加します）。有効化しないと、クライアント認証に失敗します。

イメージのビルド

1. Docker を起動します

2. minikube を起動します

minikube はローカル Kubernetes 環境であるため、起動には仮想エンジンが必要です。ここでは Docker を使用して管理します。以下のコマンドで起動します。

minikube start

Docker 内で minikube が動作していることを確認できます。

3. Istio のステータスを確認します

4. イメージをビルドします

ローカルでコードの場所を見つけ、以下のコマンドを順次実行します。

#プロバイダーのパスに移動

cd ./ dubbo-samples-xds-provider/

#プロバイダーのイメージをビルド

docker build -t apache/dubbo-demo:dubbo-samples-xds-provider_ 0.0.1 .

#コンシューマーのパスに移動

cd ../ dubbo-samples-xds-consumer/

#コンシューマーのイメージをビルド

docker build -t apache/dubbo-demo:dubbo-samples-xds-consumer_ 0.0.1 .

5. ローカルのイメージを確認します

6. 名前空間を作成します

#名前空間を初期化

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/dubbo-samples-xds/deploy/Namespace.yml

#名前空間を切り替え

kubens dubbo-demo

名前空間を作成しないと、以下のエラーが表示されます。

Deployment のデプロイ

#プロバイダーのパスに移動

cd ./ dubbo-samples-xds-provider/src/main/resources/k8s

# dubbo-samples-xds/dubbo-samples-xds-provider/src/main/resources/k8s/Deployment.yml

# dubbo-samples-xds/dubbo-samples-xds-provider/src/main/resources/k8s/Service.yml

#プロバイダーの Deployment と Service をデプロイ

kubectl apply -f Deployment.yml

kubectl apply -f Service.yml

#コンシューマーのパスに移動

cd ../../../../../ dubbo-samples-xds-consumer/src/main/resources/k8s

# dubbo-samples-xds/dubbo-samples-xds-consumer/src/main/resources/k8s/Deployment.yml

#コンシューマーの Deployment をデプロイ

kubectl apply -f Deployment.yml

minikube のダッシュボードで、デプロイされた Pod を確認できます。

コンシューマーの動作確認

kubectl logs xxx

result: hello, xDS Consumer。 from host: 172.17.0.5

result: hello, xDS Consumer。 from host: 172.17.0.5

result: hello, xDS Consumer。 from host: 172.17.0.6

result: hello, xDS Consumer。 from host: 172.17.0.6

まとめと今後の展望

本記事では、Dubbo Proxyless Mesh のアーキテクチャ、サービスディスカバリ、証明書管理などのコアプロセスを分析し、最後に実例を通じて Dubbo Proxyless の使用方法を紹介しました。

Dubbo 3.1 のリリースに伴い、Dubbo はクラウドネイティブへの道において新たな一歩を踏み出しました。今年末、Dubbo Mesh はサービスディスカバリ機能を備えたバージョンをリリースする予定で、これによりすべての Dubbo ユーザーに低バージョンから Mesh アーキテクチャへのスムーズな移行機能を提供します。ガバナンス機能を備えたバージョンは来年早春にリリース予定で、来年末にはホットプラグイン更新機能を備えたバージョンをリリースする予定です。Dubbo のクラウドネイティブへの道に興味のある皆さんは、ぜひコミュニティへの貢献に積極的にご参加ください。