MSE realizes the full link grayscale based on Apache APISIX

フルリンクグレースケールとは

マイクロサービスアーキテクチャでは、サービス間の依存関係が複雑で、ある機能のリリースが複数のサービスの同時アップグレードに依存することがあります。このようなサービスの新バージョンに対して、同時に小規模なトラフィックでグレースケール検証を行いたいというニーズがあり、これがマイクロサービスアーキテクチャにおけるフルリンクグレースケール特有のシナリオです。ゲートウェイからバックエンドサービス全体にかけて環境隔離を構築することで、複数の異なるバージョンのサービスに対してグレースケール検証を実施できます。

リリースプロセスでは、サービスのグレースケールバージョンのみをデプロイすれば済みます。トラフィックが呼び出しリンクを流れる際、通過するゲートウェイ、ミドルウェア、マイクロサービスがグレースケールトラフィックを識別し、ガバナンスルールに基づいて対応するサービスのグレースケールバージョンに動的に転送します。以下の図の通りです。

上記の図は、このスキームの効果をわかりやすく示しています。異なる色で異なるバージョンのグレースケールトラフィックを表現しています。マイクロサービスゲートウェイとマイクロサービス自体の両方がトラフィックを識別し、ガバナンスルールに基づいて動的な判断を行う必要があることがわかります。サービスバージョンが変更されると、この呼び出しリンクの転送もリアルタイムで変化します。マシンを使用して構築されるグレースケール環境と比較して、このスキームはマシンのコストと運用保守の工数を大幅に削減できるだけでなく、開発者がフルリンク全体のオンライントラフィックを迅速かつ正確に制御できるようになります。

では、フルリンクグレースケールをどのように実現するのでしょうか。上記の議論を通じて、以下の課題に対処する必要があります。

1. リンク上の各コンポーネントとサービスが、リクエストトラフィックの特性に基づいて動的にルーティングできること

2. サービス配下のすべてのノードをグループ化し、バージョンを識別できること

3. トラフィックに対してグレースケール識別とバージョン識別を行えること

4. 異なるバージョンのグレースケールトラフィックを識別できること

以下では、OpenSergo が定義したトラフィックルーティングの v1alpha1 標準について、フルリンクグレースケールを実現するために必要な技術的な詳細を説明します。

Q：OpenSergo とは

A：OpenSergo は、オープンで汎用的な分散型サービスアーキテクチャ向けのサービスガバナンス標準であり、リンク全体にわたるヘテロジニアスなエコシステムをカバーします。業界のサービスガバナンスのシナリオと実践に基づいて、共通のサービスガバナンス標準を形成しています。OpenSergo の最大の特徴は、統一された設定/DSL/プロトコルでサービスガバナンスルールを定義し、多言語のヘテロジニアスアーキテクチャに対してフルリンクのエコシステムカバレッジを実現することです。マイクロサービスの言語が Java、Go、Node.js のいずれであっても、標準的なマイクロサービスであっても Mesh アクセスであっても、ゲートウェイからマイクロサービスまで、データベースからキャッシュまで、サービス登録・検出から設定まで、開発者は同じ OpenSergo CRD 標準設定を通じて各レイヤーで統一されたガバナンスと制御を実現でき、各種フレームワークや言語の差異を意識することなく、ヘテロジニアス環境におけるフルリンクサービスガバナンスの複雑さを軽減できます。

Q：フルリンクグレースケールを理解する前に、なぜ OpenSergo を紹介するのか

A：OpenSergo は、分散アーキテクチャ向けのフルリンクサービスガバナンス仕様を YAML 設定で実装する統一された方法を定義しています。仕様と標準を理解しながら、技術的な詳細の実装も把握できます。同時に、OpenSergo 標準に準拠した新しいコンポーネントを実装することも可能です。

OpenSergo トラフィックルーティング v1alpha1 標準

トラフィックルーティングとは、その名の通り、特定の属性特性を持つトラフィックを指定された宛先にルーティングすることです。トラフィックルーティングはトラフィックガバナンスの重要な構成要素であり、開発者はトラフィックルーティング標準に基づいて、グレースケールリリース、カナリアリリース、ディザスタトレランスルーティング、ラベルルーティングなど、さまざまなシナリオを実現できます。

フルリンクグレースケールの例：

トラフィックルーティングルール（v1alpha1）は、主に以下の 3 つの部分から構成されます。

・Workload LabelRule：ワークロードのグループにラベルを付けます。APISIX の各アップストリームにタグを付けると理解できます。

・Traffic Label Rule：特定の属性特性を持つトラフィックにラベルを付けます。

・Workload タグとトラフィックタグに基づいてマッチングルーティングを実行し、指定されたタグを持つトラフィックを一致する Workload にルーティングします。

タグに異なるセマンティクスを割り当てることで、さまざまなシナリオのルーティング機能を実現できます。

トラフィックのマーク：

特定の属性特性を持つトラフィックに、対応するラベルを付ける必要があります。

たとえば、内部テストユーザーを新しいホームページにグレースケールする場合、テストユーザーの uid=12345 で、UID が X-User-ID ヘッダーに格納されているとします。

上記の設定を通じて、パスが /index で uid ヘッダーが 12345 の HTTP トラフィックに gray フラグを付け、このトラフィックがグレースケールトラフィックであることを識別できます。

Workload のラベル付け：

では、サービスノードに異なるタグを追加するにはどうすればよいでしょうか。現在注目されているクラウドネイティブ技術推动下で、ほとんどのビジネスがコンテナ化の取り組みを進めています。ここでは、コンテナベースのアプリケーションを例に、Kubernetes Service をサービス検出として使用する場合と、人気の Nacos レジストリを使用する場合の 2 つのシナリオで、サービス Workload ノードへのラベル付け方法を紹介します。

Kubernetes Service をサービス検出として使用する業務システムでは、サービスプロバイダーが ApiServer にサービスリソースを送信することでサービスの公開を完了します。サービス利用者は、サービスリソースに関連付けられた Endpoint リソースをリッスンし、Endpoint リソースから関連する Pod リソースを取得し、上記の Labels データを読み取ってノードのメタデータ情報として使用します。したがって、アプリケーション記述リソースである Deployment の Pod テンプレートでノードにラベルを追加するだけで済みます。

Nacos をサービス検出として使用する業務システムでは、一般的に、使用するマイクロサービスフレームワークに応じてマーキング方法を決定する必要があります。Java アプリケーションで Spring Cloud マイクロサービス開発フレームワークを使用している場合、ビジネスコンテナに対応する環境変数を追加することでタグの追加操作を完了できます。たとえば、ノードにバージョン gray のラベルを追加したい場合、ビジネスコンテナに `traffic.opensergo.io/label: gray` を追加すると、フレームワークがノードを Nacos に登録する際に gray ラベルを付与します。

データベースインスタンスやキャッシュインスタンスのタグ付けなど、複雑なワークロードのマーキングシナリオでは、WorkloadLabelRule CRD を使用してマークできます。

トラフィックカラーリング：

リクエストリンク上のコンポーネントは、異なるグレースケールトラフィックをどのように識別するのでしょうか。答えはトラフィックカラーリングです。リクエストトラフィックに異なるグレースケール識別子を付与して区別しやすくします。リクエストの発生源でトラフィックを染色でき、フロントエンドはリクエスト時にユーザー情報やプラットフォーム情報に基づいてトラフィックをマークします。フロントエンドでこれができない場合は、マイクロサービスゲートウェイで特定ルーティングルールに一致するリクエストに動的にトラフィック識別子を付与することもできます。また、トラフィックがリンク上のグレースケールノードを通過する際、リクエスト情報にグレースケール識別子が含まれていない場合は、自動的にカラーリングを行い、後続のフローでトラフィックがグレースケールバージョンのサービスに優先的にアクセスできるようにする必要があります。

現在、トラフィックカラーリングの標準は OpenSergo v1alpha1 で詳細に定義されておらず、コミュニティと協議してトラフィックカラーリング標準を設計できます。Apache APISIX も OpenSergo 標準に適応する予定です。開発者は同じ OpenSergo CRD 標準を使用してトラフィックゲートウェイレイヤーに対する統一ガバナンスと制御を行え、Apache APISIX をベースにしたマイクロサービスアーキテクチャの新たな価値を解放できます。

フルリンクグレースケールはマイクロサービスのコア機能の一つであり、マイクロサービス化が深まる中でクラウドユーザーにとって欠かせない機能です。フルリンクグレースケールには多くの技術とシナリオが関わるため、企業が一つずつ自社実装する場合、拡張とメンテナンスに多大な工数を要します。

Apache APISIX をベースにしたフルリンクグレースケールスキームのプロダクト実践

技術の説明に続いて、Alibaba Cloud 上の Apache APISIX をベースにしたフルリンクグレースケールのプロダクト実践を紹介します。

前提条件

ステップ 1：Ingress-APISIX コンポーネントのインストール

APISIX のアーキテクチャは以下の通りです。APISIX をインストールする必要があります。

1. apisix、apisix-ingress-controller、etcd などのコンポーネントをインストールします。

ingress-apisix 名前空間の下に、ステートレスな apisix、apisix-ingress-controller アプリケーション、およびステートフルな etcd アプリケーションを確認できます。

2. APISIX Admin をインストールします。

インストール後、SLB をバインドできます。

{SLB の IP アドレス}:9000 で APISIX コンソールにアクセスします（デフォルトパスワード：admin/admin）。

ステップ 2：マイクロサービスガバナンスの有効化

このステップでは、MSE マイクロサービスガバナンスを有効化し、MSE サービスガバナンスコンポーネント（ack-one-pilot）をインストールし、アプリケーションに対してマイクロサービスガバナンスを有効にする必要があります。具体的な操作については、Alibaba Cloud の公式チュートリアルを参照してください。

https://help.aliyun.com/product/123350.html

ステップ 3：デモアプリケーションのデプロイ

Alibaba Cloud Container Service にアプリケーション A、B、C の 3 つをデプロイし、各アプリケーションにベースバージョンとグレーバージョンをそれぞれデプロイします。また、サービス検出用の Nacos Server アプリケーションもデプロイします。詳細については、デモアプリケーションのデプロイに関するチュートリアルを参照してアプリケーションのデプロイを完了してください。デプロイ完了後、APISIX Dashboard を通じてアップストリーム設定のアプリケーション設定を行えます。

アプリケーションシナリオ：指定されたリクエストパラメーターに基づくルーティングによるフルリンクグレースケールの実現

一部のクライアントではドメイン名のリライトができず、異なるパラメーターを渡して www.demo.com にアクセスすることでグレースケール環境へルーティングしたいというニーズがあります。たとえば、下図のようにリクエストパラメーター env=gray を使用してグレースケール環境にアクセスします。

呼び出しチェーンは Ingress APISIX → A → B → C で、A は Spring Boot アプリケーションとすることができます。

APISIX ルーティングルールの設定

APISIX Dashboard でルートを選択し、作成をクリックします。マッチング条件で新しい高度なマッチングルールの作成を選択し、リクエストパスに /* を選択して、対応するアップストリームを選択します。以下のルートをそれぞれ設定します。

・ホストが www.demo.com でリクエストパラメーターが env=gray の場合、ルーティングは優先的に ID 401163331936715388 に対応するアップストリーム、つまり spring-cloud-a-gray-svc にマッチします。

・ホストが www.demo.com の場合、ルーティングは ID 401152455435354748 に対応するアップストリーム、つまり spring-cloud-a-svc にマッチします。

グレースケールに対応するルーティングを設定します。

MSE フルリンクグレースケールの設定

MSE のフルリンクリリースの設定を完了する必要があります。具体的な操作については、フルリンクグレースケールの設定に関するチュートリアルを参照してください。

結果の検証

ここで、www.demo.com にアクセスすると、ベースライン環境にルーティングされます。

次に、www.demo.com に env=gray を付けてアクセスすると、グレースケール環境にルーティングされます。

注：47.97.253.177 は APISIX のパブリック IP アドレスです。

まとめ

現在、MSE サービスガバナンスのフルリンクグレースケール機能は、クラウドネイティブゲートウェイ、ALB、APISIX、Apache Dubbo、Spring Cloud、RocketMQ、およびデータベースに対応しています。

Apache APISIX の柔軟なルーティング能力と MSE のフルリンクグレースケール能力を組み合わせることで、エンタープライズレベルのフルリンクグレースケール能力を迅速に実現できます。APISIX はヘッダー、Cookie、パラメーター、ドメイン名など複数の方法でルーティングをサポートしています。必要に応じて、トラフィックをゲートウェイ側で異なるスイムレーン環境にルーティングするだけで、トラフィックは対応するラベルのスイムレーン内を自動的に流れます。呼び出しチェーン内でスイムレーンに依存する他のサービスが存在しない場合は、トラフィックをベースライン環境にロールバックし、必要に応じて再度対応するラベルのスイムレーンにルーティングします。

サービスガバナンスは、マイクロサービス化がある段階に達した後に必ず通る道であり、その過程で新たな問題に直面し続けます。

・フルリンクグレースケール以外に、サービスガバナンスにはどのような能力があるのか。

・サービスガバナンス能力の標準定義はあるのか、どのような内容が含まれるのか。

・多言語シナリオでのフルリンクのベストプラクティスや標準はあるのか。

・ヘテロジニアスなマイクロサービスをどのように統一的にガバナンスできるのか。

サービスガバナンスを探求し、他のマイクロサービスと連携する中で、異なるガバナンス体系がもたらす困難は大きく、2 つ以上のガバナンス体系を接続するコストも膨大であることがわかりました。このため、OpenSergo プロジェクトを提案しました。OpenSergo は、異なるフレームワークや言語におけるマイクロサービスガバナンスの概念の断片化と相互運用性の問題を解決することを目指しています。