Microservice Full Link Grayscale New Capabilities

背景

マイクロサービスアーキテクチャでは、サービス間の依存関係が複雑です。場合によっては、ある機能のリリースに複数のサービスの同時アップグレードが必要になることがあります。このようなサービスの新バージョンを、少量のトラフィックによるグレースケールで同時に検証したい場合があります。これが、マイクロサービスアーキテクチャ固有のフルリンクグレースケールシナリオです。ゲートウェイからバックエンドサービス全体に至るまで環境隔離を構築することで、複数の異なるバージョンのサービスのグレースケールを検証できます。リリースプロセスでは、グレースケールバージョンのサービスのみをデプロイすれば済みます。トラフィックがコールリンク上を流れる際、ゲートウェイ、各ミドルウェア、および通過する各マイクロサービスがグレースケールトラフィックを識別し、ガバナンスルールに従って対応するバージョンのサービスに動的にフォワードします。下図に示す通りです。

上の図は、本スキームの効果をよく示しています。異なる色で異なるバージョンのグレースケールトラフィックを表現しています。マイクロサービスゲートウェイとマイクロサービス自体の両方が、トラフィックを識別し、ガバナンスルールに従って動的な判断を行う必要があることがわかります。サービスのバージョンが変化すると、このコールリンクのフォワードもリアルタイムに変化します。マシンによって構築されたグレースケール環境と比較して、本スキームは大量のマシンコストと運用負荷を節約できるだけでなく、開発者がオンライントラフィックをリアルタイムかつ迅速にきめ細かくフルリンク制御することもできます。

フルリンクグレースケール機能は、マイクロサービスアーキテクチャがもたらす迅速な反復と安定性検証の利点を強化し、本番環境のシステムに実際の価値をもたらします。本記事では、拡張されたフルリンクグレースケール機能を備えた MSE サービスガバナンスの適用シナリオと課題に焦点を当てます。

フルリンクランタイムホワイトスクリーン機能

本番環境でフルリンクグレースケールを使用する過程で、以下のような課題に直面することがあります。

• フルリンクグレースケールトラフィックの流れが期待通りに設定できているか、またトラフィックが設定したグレースケールルールに従ってマッチングされているか。

• グレースケールトラフィックに大量の低速呼び出しや例外が発生している場合、それが新バージョンコードのビジネス上の問題なのか、グレースケールプロセスでの考慮不足によるシステム問題なのかをどのように判断し、迅速に問題を特定して効率的な反復を実現するか。

• グレースケールシステムの設計過程で、グレースケールトラフィックにどのようにタグを付けるかを考慮する必要があります。エントリーアプリケーションやマイクロサービスインターフェースで、適切なトラフィック特性（パラメータ、ヘッダー、ビジネスセマンティクスを持つその他の識別子）を見つけることが難しい場合があります。このようなシナリオで、トラフィックに効率的にタグを付ける方法。

前述の課題に基づき、クラウドのお客様のフルリンクグレースケール導入を支援する過程でも同様の問題に直面しています。ランタイムでのホワイトスクリーン機能は、この過程で抽象化して設計した機能です。

ホワイトスクリーン操作の目的は、フルリンクのトラフィックマッチングと実行動作を可視化することです。

トラフィックルーティングルールに基づいて、ランタイムのホワイトスクリーンルールを以下のように抽象化します。

WhiteScreenRule = Target + Action

Target：

• ResourceTarget：ターゲットインターフェース。Web、RPC、カスタムメソッドをサポート

• WorkloadTarget：ターゲットインスタンス。全マシンを選択、またはマシン IP を指定可能

• TrafficCondition：例外、低速呼び出し、フルリンクグレースケールラベル専用

Action：

• 関連するコンテキスト診断情報の収集

• トラフィックの後続リンクへの色付け

• 後続リンクのログ出力の可否

では、ランタイムのホワイトスクリーン機能を使用して、フルリンクグレースケールプロセスで直面する課題をどのように解決するかを詳しく見ていきます。

グレースケールフローのマッチングとトラフィック方向の確認

前述のシナリオでは、Zuul アプリケーションエントリーのホワイトスクリーンマッチングルールを設定するだけで済みます。

フルリンク内のグレースケールトラフィックのパラメータ、戻り値、ヘッダーなどの特性属性を迅速に確認できます。また、フルリンクが期待通りかどうかを迅速に判断し、期待通りでない理由を特定できます。

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

マイクロサービスインスタンスとトラフィックのグレースケールに加えて、マイクロサービスアプリケーション内の設定項目にも、対応するグレースケール機能が必要です。特殊な設定値に対するグレースケールアプリケーションの要求を満たすためです。

マイクロサービスアプリケーションは通常、設定センターを導入して設定管理を行います。設定センターは動的設定プッシュ機能を提供し、アプリケーションを再起動せずに実行ロジックを動的に変更できます。しかし、設定センターの管理対象は設定項目自体のみであり、設定を取得するサービスインスタンスの環境情報を感知できません。つまり、設定を要求するインスタンスが本番環境のインスタンスなのかグレースケール環境のインスタンスなのかを区別できないということです。このような状況で、ある設定が本番環境とグレースケール環境で異なる値を使用する必要がある場合、設定センターで別々の設定項目として管理する必要があります。以下のようなコードを記述する必要があるかもしれません。

このシナリオは A/B テストで非常に一般的です。設定項目とグレースケール環境が増えるにつれ、このコードは繰り返し出現します。さらに、グレースケール環境には複数のサービスが存在することが多く、各サービスが同様のコードのセットを独立して維持する必要があります。最終的なソリューションは図に示す通りです。同じ設定項目が異なる環境で使用する設定値を、ユーザーアプリケーション内で積極的に区別する必要があります。

原因は、設定センターがサービスインスタンスの環境情報を感知できないことにあり、このタスクをコード内で設定センターではなく私たちが処理する必要があり、その結果、環境情報がビジネスコードに侵入することになります。

この問題を解決するために、MSE の設定タグプッシュ機能は、設定管理シナリオにおける環境情報の識別をプラットフォーム側に引き下げ、エージェントが処理します。ユーザーは MSE に接続するだけで、フルリンクグレースケールシナリオで設定プッシュ機能を簡単に利用でき、ビジネスコード内の煩雑な環境情報判定ロジックは不要になります。図に示す通りです。

具体的な手順については、マイクロサービスガバナンス実践者を参照してください：https://help.aliyun.com/practice_detail/447313

ステップ 1：オンラインシーンの復元

spring-cloud-zuul、spring-cloud-a、spring-cloud-b、spring-cloud-c の 4 つのビジネスアプリケーションとレジストリセンターをデプロイします。コールリンクは以下の通りです。

これらは最もシンプルな Spring Cloud および Dubbo アプリケーションです。以下のリンクでプロジェクトのソースコードを取得できます。

https://github.com/aliyun/alibabacloud-microservice-demo/tree/master/mse-simple-demo

MSE ガバナンスセンターコンソールにログインし、左側のナビゲーションバーでアプリケーションガバナンスをクリックし、cfg-spring-cloud-a を入力して検索アイコンをクリックします。cfg-spring-cloud-a アプリケーションカードを選択して、アプリケーション詳細ページに入ります。

次に、左側のナビゲーションバーでアプリケーション設定 > 設定リストを選択し、configValue スイッチの前の + をクリックすると、A アプリケーションのベースラインバージョンとグレースケールバージョンの設定値が同じであることが確認できます。どちらもアプリケーション内の初期値です。

ステップ 2：spring-cloud-a のグレースケールルールを設定

cfg-spring-cloud-a のアプリケーション詳細ページで、左側のナビゲーションバーのトラフィックガバナンスを選択し、ラベルルートをクリックします。図に示す通りです。

次に、グレースケールインスタンスのグレースケールルールを設定します。ラベルグレー > トラフィックルール > 追加をクリックし、以下のグレースケールルールを設定して OK をクリックします。

ステップ 3：設定グレースケールの検証

次に、設定グレースケールを検証します。

1. グレースケールインスタンスのタグプッシュを実行

cfg-spring-cloud-a のアプリケーション詳細ページで、アプリケーション設定 > 設定リストに戻り、configValue スイッチの後のタグ別プッシュを選択します。ポップアップウィンドウでラベルグレーを選択し、グレースケール環境の設定値を設定します。

次に「次へ：値の比較」をクリックし、「タグプッシュ」をクリックしてプッシュを完了します。この時、コンソール上でグレースケールインスタンスの設定値が先に設定した値に変化したことが確認できます。

2. 設定グレースケールの有効化を確認

コンテナサービスコンソールにログインし、左側のナビゲーションバーでクラスターをクリックし、アプリケーションがデプロイされているクラスターに入ります。クラスター詳細ページでネットワーク > サービスを選択し、zuul-slb を見つけて外部エンドポイントをクリックし、サービス呼び出しページにアクセスします。

App A のベースラインバージョンにアクセスできます。設定値がまだ初期値であることがわかります。

先に設定したグレースケールルールを通じて、App A のグレースケールバージョンにアクセスできます。設定値が先にプッシュした値に変化したことがわかります。

3. グレースケール設定値の永続性を検証

タグプッシュの設定値は永続化されます。つまり、グレースケール環境のアプリケーションが再起動されても、MSE エージェントから以前プッシュされた設定値を自動的に取得できます。

コンテナサービスコンソールにログインし、左側のナビゲーションバーでクラスターをクリックし、アプリケーションがデプロイされているクラスターに入ります。クラスター詳細ページでワークロード > ステートレスを選択します。spring-cloud-a-gray ロードをチェックし、一括再デプロイをクリックします。kubectl ツールを使用してロードを再デプロイし、グレースケールアプリケーションの再起動プロセスをシミュレートすることもできます。

アプリケーションの再起動後、前のステップのグレースケールアプリケーションにアクセスするプロセスを再実行します。設定値が以前プッシュされた設定値のままであることがわかります。

まとめ

本記事では、フルリンクグレースケール拡張に基づくランタイムのホワイトスクリーン機能とグレースケール設定機能を紹介し、フルリンクグレースケールのシナリオを補完し、フルリンクグレースケールの可用性をさらに向上させました。フルリンクグレースケールはマイクロサービスガバナンスの重要なシナリオです。MSE のフルリンクグレースケール機能は、顧客シナリオの深化に伴い引き続き拡張と反復を進めています。継続的に投資し、この重要なシナリオをより深掘りし、使いやすくしていく必要があります。フルリンクグレースケール機能を継続的に磨き上げていく道は、まだ多く残っていると言えます。現在、フルリンクグレースケールは約 100 社の企業に使用されています。私たちは常に、顧客によって継続的に磨かれたプロダクトこそが、ますます長く愛されると信じています。ご興味のある方は、ぜひご利用・体験ください