How to seamlessly transition from traditional microservice framework to service grid ASM

背景

ソフトウェア技術の歴史は、個別のアプリケーションから分散型アプリケーションへと発展し、特にマイクロサービスの概念の台頭により、大規模で高コンカレントかつ低レイテンシな分散型アプリケーションが実現可能になりました。クラウドネイティブ時代において、マイクロサービスフレームワーク自体も継続的に進化とイテレーションを重ねています。

マイクロサービスフレームワークには、一般的に以下の知識ポイントが含まれます：

本記事では、以下の 3 つのマイクロサービスフレームワークに焦点を当てます：

• SpringCloud

• Dubbo

• ServiceMesh（次世代）

これら 3 つのフレームワークは、サービスガバナンス領域の機能について、カバーしきれない部分に違いがあります。本記事では、これらのフレームワークの長短を議論するのではなく、従来のマイクロサービスフレームワークである Dubbo および SpringCloud から ServiceMesh アーキテクチャへいかにシームレスに移行するかに焦点を当てます。Istio は現在の ServiceMesh 分野で最も注目を集めているプロジェクトです。

Alibaba Cloud Service Grid ASM は Istio をベースとしており、Istio のクラウドホスティングと適応を提供するとともに、関連機能の追加および大規模サービスグリッドシナリオでのパフォーマンス最適化を行っています。業界初のフルマネージド Istio 互換の Alibaba Cloud サービスグリッドプロダクトとして、ASM は当初からコミュニティおよび業界のトレンドとアーキテクチャ的に一貫性を保っています。コントロールプレーンのコンポーネントは Alibaba Cloud 側でホストされ、データプレーン側のユーザークラスターとは独立しています。ASM プロダクトはコミュニティ版 Istio をベースにカスタマイズ実装されており、マネージドコントロールプレーン側できめ細かなトラフィック管理とセキュリティ管理をサポートするコンポーネント機能を提供しています。マネージドモードにより、Istio コンポーネントのライフサイクル管理とマネージド K8s クラスターがデカップリングされ、アーキテクチャがより柔軟になり、システムのスケーラビリティが向上しています。2022 年 4 月 1 日より、Alibaba Cloud Service Grid ASM は正式に商用版をリリースし、より豊富な機能、大規模なサポート、より完全な技術サポートを提供し、お客様のさまざまなニーズシナリオにより適切に対応しています。詳細については、プロダクト紹介をご覧ください：

https://www.aliyun.com/product/servicemesh

ここでは、従来のマイクロサービスをサービスグリッド技術スタックに移行する際の既知の問題と、Alibaba Cloud Service Grid ASM が Spring Cloud および Dubbo サービスをいかにシームレスにサポートするかを見ていきます。

[Alibaba Cloud Native] 公式アカウントをフォローし、キーワード「0621」を返信して、記事内のコード圧縮パッケージのダウンロード先を取得してください。

従来のマイクロサービスをサービスグリッドに移行する際の既知の問題とシナリオ

一般的な問題

サービスのコンテナ化後、サービスデプロイメントはローリング方式で更新されます。サービスインスタンスの IP アドレスは頻繁に変更され、対応するサービスインスタンスの IP をサービスレジストリに同期する際に遅延が発生します。このプロセスにより、サービスリクエストで 503 エラーが発生する可能性があります。

• Istio コミュニティ版は、HTTP および gRPC 以外の RPC プロトコルに対するサポートが限定的であり、統一されたルーティング管理および関連ガバナンス機能を提供できません。

• Istio 自体が設計したサービスルーティングモデルにより、サービス間リクエストは ServiceName または ClusterIP に依存するため、SpringCloud サービスを直接メッシュ化できません。インターフェースベースのサービス呼び出し設計により、Dubbo サービスのインターフェース情報は Dubbo プロトコルリクエストのコンテキスト内で渡されます。このモードによる制約は受けないものの、Istio コミュニティ版の Dubbo ルーティングサポートには RDS サポートがなく、コミュニティ版の VirtualService で Dubbo ルーティングを直接設定できません。

上記の一般的な問題に加え、ビジネスのクラウド移行プロセスで頻繁に直面する特定のビジネスシナリオもあります。

シナリオ 1：コンテナクラスター内外のサービスの相互連携方法

• ビジネスの一部をコンテナ化し、Kubernetes クラスターに移行

• ECS 仮想マシン上にデプロイする必要があるレガシーサービスが依然として存在

ASM をレジストリと連携させることで、コンテナクラスター内外のサービス相互運用性を実現し、サービスガバナンス機能を維持できます。また、コンテナビジネスサービスを ASM サービスグリッドで管理することで、サービスガバナンス機能を Sidecar に委譲し、ビジネスは Istio がもたらす宣言的設定を素早く取得し、トラフィック管理やカナリアリリースなどのサービスガバナンスおよびオーケストレーション機能を実行でき、Trace、Log、Metrics に連携する 3 つの可観測性機能を自然に取得できます。

シナリオ 2：多言語サービスの相互連携

クラウドコンピューティングの波の到来により、ビジネスは一般的に より複雑で多様になっています。多くの顧客がビジネス開発の必要性から複数の言語、さらには複数の開発フレームワークを採用しています。異なる言語間のサービスをどのように相互接続するか、または統一されたサービスフレームワークでこれら多言語サービスを管理できるでしょうか？

ASM サービスグリッドは Istio コミュニティ版をベースに機能を拡張し、Spring Cloud および Dubbo サービスのサービスグリッドへのシームレスな移行をサポートしています。これにより、ビジネスはコード変更なしでサービスグリッドが提供する機能を自然に享受できます。以下では、Spring Cloud と Dubbo についてそれぞれ具体的に分析・説明します。

Spring Cloud サービスの管理

Spring Cloud サービスの通信は HTTP プロトコルを使用しており、Istio の HTTP プロトコルサポートは非常に優れています。Istio が Spring Cloud サービスをどのように管理するか、すなわち Spring Cloud サービスリクエストを Istio が依存する ServiceName または ClusterIP にどのように適合させるかを解決するだけで済みます。

簡単に言えば、サービスグリッドは Sidecar モードを採用しているため、リクエストが送信するトラフィックのターゲットサービスが誰であるかを知る必要があり、この情報は HTTP リクエストの Host フィールドで宣言する必要があります。

方式 1：EnvoyFilter + Lua 方式を採用

コア実装は、EnvoyFilter の下で Lua ロジックを設定し、サービスサブスクリプションリクエストの戻り値を変更して、サービスサブスクリプションで返されるターゲット IP アドレスを対応するサービス名に変更することです。具体的なデモ例については、ASM ヘルプドキュメントを参照してください：

https://help.aliyun.com/document_detail/383257.html

ただし、特定のサービスサブスクリプションプロトコルを理解する必要があるため、このソリューションは現在 Nacos のみをサポートしており、Nacos 以外のレジストリはサポートしていません。サービスレジストリの移行ソリューションを提供していますが、さまざまな理由からレジストリに適応するためにコードを変更したくないユーザーもいるでしょう。これに基づき、任意のレジストリに適応可能な方式 2 を提供します。

方式 2：Reverse DNS Filter による逆引き参照で ServiceName を取得

方式 1 は現在 Nacos のみをサポートしており、Eureka や ZooKeeper などのサービスレジストリもサポートしてほしいという多くのユーザーからのフィードバックがありました。これに基づき、以下の汎用ソリューションを導入しました：

ところで、Istio は gRPC プロトコルをネイティブにサポートしており、Dubbo3 の新プロトコルである Triple は gRPC ベースです。Dubbo3 サービスは優雅にメッシュに移行できます。

上記の方式は Dubbo3 サービスにも適用可能です。

まとめ：上記 2 つのソリューション（方式 2 を推奨）により、Spring Cloud サービスが Istio ルーティングモデルに適応する問題を解決しました。これにより、Spring Cloud はコード変更なしで Istio の全機能を享受できます。

もちろん、ユーザーがコード変更を希望する場合は、元の Spring Cloud から負荷分散、サーキットブレーカ、レート制限などの関連アノテーションを削除することをお勧めします。メッシュ環境では、これらの機能はもはや不要だからです。

方式 2 の ReverseDNS Filter は ASM バージョン 1.13 に組み込み済みで、6 月末にリリースおよび公開の予定です。

Dubbo サービスの管理

ここで Dubbo サービスと言う場合、Dubbo2 を指します。Dubbo3 は上記と同様のソリューションを採用できます。また、Dubbo3 コミュニティと連携し、Dubbo3 Proxyless Mesh モードのサポートを進めています。現在、Dubbo2 は依然として多くのユーザーを抱えているため、Alibaba Cloud Service Grid は Dubbo2 に対しても深いサポートを提供しています。以下で言及する Dubbo2 バージョンは、Dubbo2 のみを指します。

Dubbo ユーザーの大半は Nacos または ZooKeeper レジストリを使用しており、ASM プロダクトレベルでは現在 MSE Nacos レジストリをサポートしています。

ASM セットアップメニューで MSE Nacos インスタンスを関連付けるだけで、対応する Nacos 下のサービス情報を検出できます。

Dubbo + Nacos サービスの ASM への移行サポート

全体のアーキテクチャ図は以下の通りです：

関連ドキュメント：

• Dubbo サービスのホスティング

• Dubbo サービストラフィックの管理

• Dubbo サービスの仮想サービスパラメータの説明

• 自己構築 Prometheus の統合による Dubbo サービスの可観測性の実現

ASM は Istio コミュニティ版の VirtualService をベースに、Dubbo ルーティングのサポートを拡張しています。より複雑な設定例は以下の通りです：

Dubbo ルーティングの具体的な Spec 定義および例の説明については、上記の Dubbo サービスガバナンスシリーズのドキュメントを参照してください。

Dubbo + ZooKeeper のサポート

Dubbo オープンソースユーザーには、Nacos の他に ZooKeeper レジストリを使用しているユーザーも多くいます。ただし、ZooKeeper は現在、Istio が依存するサービス検出機能である MCP over XDS プロトコルのサポートを公式には提供していません。

MCPBridge コンポーネントがこの問題を解決します。Alibaba Cloud サービスグリッド ASM シナリオでの具体的な実装方式は以下の通りです：

レジストリの多様性を考慮し、今後 MCPBridge はオープンソースコミュニティに公開されます。皆様のメンテナンスへのご参加をお待ちしています。

ユーザーは MCPBridge Helm インストールパッケージをダウンロードし、ビジネスデプロイメントがある ACK クラスターに MCPBridge を手動でインストールできます。

インストール方法は簡単です。ダウンロード後、Helm インストールパッケージを展開し、ディレクトリ内で以下のコマンドを実行します：

helm install -f values.yaml mcp-bridge .

インストール完了後、mcp-bridge は SLB を介して VPC 内部ネットワークアドレスを提供し、Istio の ConfigSource をこのアドレスに関連付ける必要があります。ASM のこの機能は現在ホワイトリストでのみ公開されており、ワークオーダーを起票するか、記事末尾のグループでプロダクト運用保守担当者に連絡する必要があります。

インストール完了後、アップストリームレジストリアドレスを ZooKeeper に設定できます。環境に利用可能な ZooKeeper サーバーがない場合は、Alibaba Cloud MSE ZooKeeper で素早く作成できます。以下の通りです：

MCPBridge コンポーネントとその関連レジストリの設定は簡単で、MCPBridge CR を作成するだけです。具体的な設定形式は以下の通りです：

kubectl apply -f zk-mcpbridge.yaml が有効になった後、MCPBridge コンポーネントは ZooKeeper の dubbo ノード下のサービス情報を自動的に istiod に同期します。

MCPBridge が Dubbo + ZK をサポートする具体例を体験したい場合は、テストサンプルをダウンロードできます。

以下のパッケージには、上記の MCPBridge の YAML 設定と、テスト用の Dubbo デモサービスの例が含まれています。

次に、このデモ例の使い方を簡単に説明します。

dubbo-zk-demo.tar.gz をダウンロードして展開した後、まず YAML 内の ZK アドレス「mse-7e74ff00-zk.mse.aliyuncs.com」を実際の ZK サービスアドレスに変更する必要があります（このアドレスは MCPBridge コンポーネントからアクセスできる必要があります）。アドレス変更後、dubbo-zk-demo ディレクトリ内で以下のコマンドを実行します：

正常に起動した後、Zookeeper に戻ると、サービス登録情報が報告されていることが確認できます：（dubbo ノードの下に）

次に、コンシューマーサービスを ASM ゲートウェイにマッピングしてテストアクセスを行います。ASM コンソールから ASM ゲートウェイを素早く作成できます。CI/CD や GitOps などのソリューションを使用している場合は、IstioGateway YAML を直接作成することもできます。

ゲートウェイエンティティが正常に作成された後（ゲートウェイのデプロイメント、svc など）、論理ゲートウェイを設定する必要があります。必要な手順は 2 つだけです：

• ゲートウェイルール（Istio の Gateway CRD）を作成し、論理ゲートウェイと、この論理ゲートウェイにバインドする具体的なドメイン名、ポート、プロトコルタイプを宣言します（テストゲートウェイ）

• ゲートウェイルーティングを設定し、/sayHello リクエストを dubbo-consumer-zk.dubbo.svc.cluster.local ターゲットサービスに転送します

ゲートウェイルールとルーティングは以下の YAML を参照できます。この YAML をローカルファイルとして保存し、ASM クラスターで kubectl apply するだけです。

ゲートウェイルールとルーティング設定が有効になった後、ブラウザまたはターミナルコマンドで以下を実行できます：

curl http://$INGRESS_ GATEWAY_ IP/sayHello/world で、先にデプロイした Dubbo デモサービスにアクセスします。以下のコマンドを実行すると、関連する結果を確認できます。前後のリクエストの負荷分散が provider の v1 および v2 バージョンに振り分けられています。

トラフィック管理、カナリアリリース、可観測性の詳細な例については、ASM での Istio および Dubbo サービスガバナンスに関するドキュメントを参照して設定してください。

まとめ

SpringCloud や Dubbo などの従来のマイクロサービスフレームワークに対し、Alibaba Cloud Service Grid ASM は Istio をベースに、顧客の一般的なシナリオニーズと問題に対応する拡張サポートを提供しています。SpringCloud および Dubbo サービスをシームレスに管理し、Istio のネイティブなサービスガバナンス機能を提供できます。

Alibaba Cloud Service Grid ASM は、マネージドサービスグリッドの先駆者として、多くのユーザーに支持されており、それがこのプロダクトを作る上での私たちの自信を強めています。サービスグリッドはもはやバズワードの積み上げではなく、実際に本番環境に適用され、サービスガバナンス分野で一つ一つの技術的問題に対処しています。本質に立ち返れば、サービスグリッドは依然として実際のビジネス問題を解決する必要があります。