フルリンクグレースケールリリースについて

1 概要

今日の急速に変化するソフトウェア開発環境では、ユーザーのニーズが絶えず変化し、競争がますます激化しているため、ソフトウェアの更新とリリースの頻度が標準になっています。ただし、同時に、ユーザー エクスペリエンスの安定性と信頼性を確保することも重要です。従来の大規模なソフトウェア リリースでは、オンライン障害のリスクに直面することが多く、ユーザー エクスペリエンスの低下につながり、ビジネスの通常の運用に影響を及ぼす可能性もあります。

この矛盾を解決するために、ソフトウェア開発の分野でグレースケールリリースという概念が生まれました。グレースケール リリースは、新機能や更新を一度にすべてではなく、一部のユーザーに段階的にプッシュできる段階的なソフトウェア リリース方法です。このアプローチにより、オンライン障害のリスクを効果的に軽減し、ユーザー エクスペリエンスを確保できると同時に、開発チームに、完全リリース前に問題を検証して修正するための時間と機会を増やすことができます。

しかし、ソフトウェア アーキテクチャの進化、特にマイクロサービス アーキテクチャの普及により、ソフトウェア システムは複数のマイクロサービスで構成されることが多くなり、異なるサービスのバージョン アップグレードを調整して同期する必要が生じています。このような状況において、単一サービスのグレースケールリリースではニーズを完全に満たすことができず、フルリンクのグレースケールリリースが誕生しました。

フルリンク グレースケール リリースでは、ソフトウェア システム全体の複数のマイクロサービスを考慮し、複数のマイクロサービスを同時にバージョン管理およびアップグレードして、システム全体のスムーズな移行と安定性を確保します。より包括的かつ詳細なグレースケールリリース方法です。フルリンクグレースケールリリースを通じて、開発チームはさまざまなサービスバージョンのリリース比率をより正確に制御し、システムリスクを軽減し、オンラインの安定性を確保し、ユーザーのニーズを最大限に満たすことができます。

写真

図 1 を例にとると、ソフトウェア システムにはゲートウェイと 4 つのマイクロサービスが含まれています。フルリンク グレースケール リリースにより、ServiceB と ServiceD をグレースケールでリリースすることができ、青線で示される通常のアクセス トラフィックに影響を与えることなく、グレー線で示されるトラフィックを通じてグレースケール機能検証が実行されます。

2. フルリンクグレースケールリリースの核心的な問題

図 1 から、フルリンク グレースケール リリースを実装する場合、関連サービスのグレースケール バージョンを展開し、リクエスト呼び出しチェーン全体でゲートウェイとマイクロサービス コンポーネントが公式トラフィックと特定のバージョンのグレースケール トラフィックを正確に識別し、トラフィックの種類に応じてリクエストを上流のマイクロサービスの正しいバージョンに動的にルーティングできるようにする必要があることがわかります。したがって、次の問題を解決する必要があります。

• マイクロサービス インスタンスにはバージョン情報があり、異なるトラフィックの対応するバージョン インスタンスにサービスを提供します。
• リクエスト トラフィックにはトラフィック特性があり、異なるバージョンのマイクロサービスを要求するトラフィックを区別できます。
• 呼び出しチェーン内の各コンポーネントは、トラフィックの特性に基づいて、リクエストをマイクロサービスの正しいバージョンに動的にルーティングできます。現在のマイクロサービス アーキテクチャは、主に 2 つのモードに分かれています。1 つは従来のマイクロサービス フレームワーク (Spring Cloud など) 上に構築されたマイクロサービス システムであり、もう 1 つはクラウド ネイティブ時代の Kubernetes とサービス メッシュ (Istio など) で構築されたマイクロサービス アーキテクチャです。便宜上、これらを従来モードとクラウド ネイティブ モードと呼びます。以下では、上記の問題を解決し、2 つのモードでフルリンク グレースケールのリリースを実行する方法について説明します。

マイクロサービスの識別

マイクロサービス インスタンスに識別子を追加してバージョン情報を持たせ、異なるトラフィックの対応するバージョン インスタンスにサービスを提供します。

伝統的なモデル

従来のモデルでは、一般的に、製品では、使用されるマイクロサービス フレームワークに基づいて、識別を追加する方法を決定する必要があります。 Spring Cloud フレームワーク + Nacos レジストリに基づくマイクロサービスを例に挙げてみましょう。通常、識別子はマイクロサービス メタデータ構成 (spring.cloud.nacos.discovery.metadata) に追加されます。設定例は次のとおりです。

 spring: cloud: nacos: discovery: metadata: version: ${APP-VERSION:v1}

Nacos登録センターのマイクロサービスのサービス情報は次のとおりです。

写真

クラウドネイティブモデル

クラウドネイティブ モードでは、マイクロサービス インスタンスに識別子を追加する方が便利です。マイクロサービス コード構成を変更する必要はありません。通常、Labal 識別子をマイクロサービス デプロイメントの Pod テンプレートに追加できます。例は次のとおりです。

 apiVersion: apps/v1 kind: Deployment metadata: name: demo spec: selector: matchLabels: app: demo version: v1 template: metadata: labels: app: demo version: v1

トラフィックID

マイクロサービスの識別と同様に、トラフィックに異なる識別子を追加することでトラフィックを区別します。業界では、交通識別は交通カラーリングとも呼ばれ、より専門的で鮮明です。

トラフィックの色分けは 2 つのステップに分かれています。最初のステップはトラフィック ソースでの色分け、2 番目のステップは呼び出しチェーン内での色分けです。

最初のステップは比較的簡単です。フロントエンドまたはゲートウェイは、トラフィックの特性 (ブラウザの種類、ユーザー ID、地域 ID など) に応じてトラフィックに識別情報を追加します (HTTP ヘッダーにバージョン タグを追加するなど)。

2 番目のステップは、フルリンク グレースケールの中核であり、最も複雑な部分です。コール チェーン上の各マイクロサービス コンポーネントが識別子に基づいてトラフィックを識別し、動的にルーティングできるようにするには、トラフィック識別子をコール チェーンに渡す必要があります。

従来のマイクロサービス フレームワークは、サービス登録と検出、負荷分散などの基本機能の実装に重点を置いていますが、トラフィック識別の透過的な伝送をコア機能の 1 つとして考慮していないため、実際のアプリケーションでトラフィック識別のシームレスな伝送を実現することは困難です。

クラウドネイティブ時代の Kubernetes + Istio も、マイクロサービスによるトラフィックの識別と透過的な伝送の実現には役立ちません。多くの人は、Istio がマイクロサービス インスタンスの受信トラフィックと送信トラフィックを傍受でき、トラフィック識別透過伝送をネイティブにサポートする必要があると誤解しています。しかし、実際には、Istio 自体にはトラフィック識別を透過的に伝送する機能がありません。

写真

Istio Sidecar は、上の図に示すように、マイクロサービスの入出力トラフィックを傍受します。 Sidecar は、イングレス トラフィック 1 をインターセプトしてマイクロサービス コンテナに転送できます (イングレス トラフィック 2) が、マイクロサービス コンテナの出力トラフィック 3 をインターセプトして Pod の外部に転送することもできます (出力トラフィック 4)。しかし、Sidecar は出力トラフィック 3 と入力トラフィック 2 の対応関係を認識しません。実際の状況では、Sidecar は大量の出力トラフィックと大量の入力トラフィックを傍受しますが、Sidecar は特定の出力トラフィックがどの入力トラフィックに対応するかを認識しません。マイクロサービス アプリケーションはトラフィック自体を処理するため、対応する関係を知っているのはマイクロサービス アプリケーションだけです (入力トラフィック要求 2 を受信した後、マイクロサービス アプリケーションはビジネス ロジック処理を実行し、出力トラフィック 3 を送信して次のレベルのマイクロサービスを要求します)。したがって、Istio はマイクロサービスのイングレス トラフィックとアウトレッジ トラフィックを傍受できますが、イングレス トラフィックとアウトレッジ トラフィックの対応関係を把握しておらず、イングレス トラフィック識別子をエグレス トラフィックに自動的に追加できず、トラフィック識別子を透過的に伝送できません。

トラフィックID透過伝送モード

では、トラフィック識別透過伝送をどのように実行するのでしょうか?通常、次の 3 つの方法があります。

マイクロサービスのソースコード変更方法

マイクロサービス側はビジネス コード変換を実行し、入力トラフィック要求からトラフィック識別子を取得し、出力トラフィックにトラフィック識別子を追加します。コード例は次のとおりです。

 // 从请求中获取流量标识version String versionValue = request.getHeader("version"); // 构造新请求需要的Header,获取到的流量标识添加到新请求的Header 中HttpHeaders headers = new HttpHeaders(); headers.set("version", versionValue); // 发起出口流量请求

基本的なSDKメソッドの使用

入力トラフィック要求からトラフィック ID を取得し、そのトラフィック ID を出力トラフィックに追加するという共通ロジックは、基本 SDK にカプセル化されています。原則として、SDK がリクエストと応答をインターセプトして処理します。この方法の核となるのは、SDK がマイクロサービス内のリクエストをインターセプトし、リクエストからトラフィック識別子を取得し、マイクロサービスが外部リクエストを開始するときにこの識別子をリクエストに追加することで、トラフィック識別子の透過的な送信を実現することです。基本的な SDK の動作メカニズムには、通常、次の主要なステップが含まれます。

• リクエストと応答をインターセプトする: SDK は、何らかの方法 (AOP、インターセプターなど) でマイクロサービスのリクエストと応答をインターセプトします。これにより、SDK は、リクエストがマイクロサービスに入る前、または応答が返された後にリクエストを処理できます。
• トラフィック ID を取得する: リクエストがマイクロサービスによって処理される前に、SDK はリクエストからトラフィック ID を取得します。これには、HTTP ヘッダー、Cookie、リクエスト パラメータなどから特定の識別子を取得することが含まれる場合があります。
• リクエストの外部への送信: マイクロサービスが外部サービスへのリクエストを開始する必要がある場合、SDK は以前に取得したトラフィック ID をリクエストに追加します。つまり、SDK は、識別子が外部サービスに渡されるように、新しいリクエスト ヘッダー、リクエスト ボディ、またはその他の適切な場所に識別子を追加します。
  上記の手順により、基本 SDK はマイクロサービス内のトラフィックを傍受し、トラフィック識別子を取得し、マイクロサービスが外部リクエストを開始したときにその識別子を外部サービスに送信できます。
  一部の大企業では、インフラストラクチャ チームが製品チームが使用するための基本的な SDK を提供します。参考として、関連するオープンソース ソリューションもいくつかあります。たとえば、Alibaba のオープンソース KtEnv は、Java 言語で SDK の例を提供し、Spring フレームワークのアスペクト メカニズムを使用して「環境タグ」の配信を自動化します。ここで、環境タグはトラフィック識別子です。

基本エージェントモードの使用

エージェント テクノロジを使用してトラフィック識別透過伝送を実装することは、比較的暗黙的で、高度に構成可能な方法です。エージェントは、JVM ランタイムに介入し、Java アプリケーションのバイトコードを動的に操作および拡張できるプログラムです。

トラフィック識別子の透過的な伝送を実装する場合、エージェントは動的バイトコード拡張テクノロジを使用して、バイトコード操作ツール (ASM、ByteBuddy など) を通じて特定のクラスまたはメソッドのバイトコードを強化し、マイクロサービス アプリケーションのバイトコードを動的に変更することで、トラフィック識別子がリクエスト処理リンクで自動的に取得され、リクエストが開始されるとこれらの識別子が外部リクエストに追加されます。これらの識別子には、HTTP ヘッダー、コンテキスト情報、またはその他の識別データが含まれる場合があります。

参照できる基本的なエージェント オープン ソース ソリューションがいくつかあります。たとえば、Java Web アプリケーションに感知されないヘッダー転送を提供するオープン ソース ソリューションである Homer や、JavaAgent テクノロジを使用して Java アプリケーションにサービス グリッド機能を提供するオープン ソース ソリューションである Huawei の Sermant などがあります。トラフィック転送プラグイン tag-transmission を提供し、マイクロサービスがトラフィック転送機能を実装するのに役立ちます。

要約する3つの方法

トラフィック識別透過伝送を実装するこれら 3 つの方法には、それぞれ独自の利点と適用可能なシナリオがあります。要約すると:

• ビジネス コードの変更: この方法はシンプルで直接的ですが、特に複数のサービス間で同様のロジックを追加する必要がある大規模なマイクロサービス システムでは、ビジネス コードの複雑さとメンテナンス コストが増加します。柔軟性とインテリジェント性が十分でなく、実用的な用途はほとんどありません。
• 基本 SDK: ビジネス コードの変更と比較して、基本 SDK を使用すると、よりインテリジェントかつ自動化され、ビジネス コードへの侵入が軽減されると同時に、ある程度の構成可能性と拡張性も提供されます。ただし、これは依然としてビジネス コードに侵入し、言語に関連しています。大規模な多言語マイクロサービスシステムでは、多言語 SDK を提供する必要があります。また、SDKのバージョンアップも困難です。
• エージェント方式: エージェント技術に基づいて、ビジネス コードを変更することなくトラフィック識別子の傍受と送信を実現できます。この方法は、ビジネス コードを直接変更したくない、または変更できない場合のシナリオに特に適しています。柔軟性とインテリジェンス性は高いのですが、言語に縛られ、バージョンアップが比較的難しいという問題もあります。
  一般的に、3 つの方法にはそれぞれ長所と短所があります。実際のシナリオでは、特定のニーズと既存のアーキテクチャに基づいて適切な方法を選択する必要があります。

トラフィックルーティング

トラフィック ルーティングは、マイクロサービスの識別に似ています。従来モードとクラウド ネイティブ モードの両方がサポートされているため、トラフィック識別よりもはるかに簡単です。

従来のマイクロサービス フレームワーク (Spring Cloud など) では、通常、動的ルーティングは API ゲートウェイ (Spring Cloud Gateway など) やロード バランサー (Netflix Ribbon など) などのコンポーネントを通じて実現され、特定のポリシーやルールに従ってトラフィックを分散およびルーティングします。たとえば、リクエスト ヘッダー内のトラフィック識別情報に基づいて、負荷分散戦略を使用して、異なるバージョンのマイクロサービス インスタンスにリクエストを分散し、動的ルーティングを実現できます。

クラウドネイティブ アーキテクチャ (Kubernetes + Istio など) では、動的ルーティングがはるかに簡単になります。 Istio のトラフィック管理機能を通じて、Gateway、VirtualService、DestinationRule などのルールと構成を定義し、トラフィックのきめ細かな制御とルーティングを実現します。

3. フルリンクグレースケールリリースの実践

クラウド ネイティブ モードでは、概要セクションの図 1 に示すマイクロサービスのフルリンク グレースケール リリースを実践します。マイクロサービスのバージョンと呼び出しリンクは図 1 と一致しています。マイクロサービス インスタンスのリストは次のとおりです。

写真

ゲートウェイはIstio Ingress Gatewayを使用し、トラフィックマーク透過伝送は基本エージェント方式を採用しています。キー et-mark を持つ HTTP リクエスト ヘッダーは、マイクロサービス呼び出しリンクで透過的に送信できます。トラフィック ルーティングは、Istio トラフィック管理機能を通じて実装されます。主要な Gateway、VirtualService、および DestinationRule ルールは次のとおりです。

 --- apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: ingress-gateway namespace: e2e-canary-release spec: selector: istio: ingressgateway servers: - hosts: - 'www.e2e-canary-release.com' port: name: http number: 80 protocol: HTTP --- apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: service-a namespace: e2e-canary-release spec: gateways: - e2e-canary-release/ingress-gateway hosts: - 'www.e2e-canary-release.com' http: - route: - destination: host: service-a --- apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: service-b namespace: e2e-canary-release spec: hosts: - service-b http: - match: - headers: et-mark: exact: v2 route: - destination: host: service-b subset: v2 - route: - destination: host: service-b subset: v1 --- apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: service-b namespace: e2e-canary-release spec: host: service-b subsets: - labels: version: v1 name: v1 - labels: version: v2 name: v2

実際の効果は以下のとおりです。デフォルトでは、リクエスト トラフィックが流れるマイクロサービス バージョンはすべて公式バージョン v1 であることがわかります。リクエスト ヘッダーにトラフィック識別子が含まれている場合、つまりトラフィックがグレースケール トラフィックである場合、図 1 のグレー パスに沿って流れ、フルリンク グレースケール リリースを実現します。

写真

写真

4 結論

この記事では、まずフルリンク グレースケール リリースの概念と機能、およびフルリンク グレースケール リリースを実装する際に解決する必要がある主要な問題について説明します。それぞれの問題に対して、従来のモードとクラウドネイティブ モードから対応するソリューションが紹介されます。トラフィック識別子透過伝送について詳しく紹介します。次に、クラウドネイティブモードで、マイクロサービスデモ上でフルリンクグレースケールリリースの実践を行い、実践的な効果を実証します。能力と時間が限られているため、一部のコンテンツは簡単にしか紹介されていません。今後もさらに深い研究と共有を続けていきたいと思います。記事に誤りがありましたら、ご指摘いただければ幸いです。

5参考記事と関連リンク

• フルリンクグレースケールテクノロジーインサイダーの詳細な分析
  https://developer.aliyun.com/article/834510#slide-1
• Istio に基づくフルリンク グレースケール ソ​​リューションの探索と実践https://xie.infoq.cn/article/f6a1db8756e8bfa831947ee05
• Spring Cloud のフルリンク グレースケール リリース ソリューションについてお話しましょう～ https://z.itpub.net/article/detail/5D9F94265D666C4607B92CBC32667692
• Spring Cloud Alibaba-フルリンクグレースケールデザインhttps://www.nowcoder.com/discuss/517248839594541056
• タグ透過伝送: マイクロサービス システム用のタグ透過伝送ソリューションを選択するにはどうすればよいでしょうか? https://leeshengis.com/archives/444794
• トラフィック管理の基礎 - バイトコード拡張に基づくフルリンクトラフィックラベル透過伝送 https://juejin.cn/post/7282957826510667816
• か
  https://alibaba.github.io/virtual-environment/#/zh-cn/doc/use-sdk?id=%E4%BD%BF%E7%94%A8sdk
• ホーマー
  https://github.com/kaikeba/homer
• サーマント
  https://sermant.io/ja/ より

著者: Zhang Haiwen、China Mobile Cloud Capability Center のシニア ソフトウェア開発エンジニア、モバイル クラウド サービス グリッドの責任者、QCon や KubeCon などのカンファレンスの講演者、クラウド ネイティブ、マイクロサービス、コンピューティング パワー ネットワークなどに焦点を当てる。