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

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 などのカンファレンスの講演者、クラウドネイティブ、マイクロサービス、コンピューティングパワーネットワークなどに焦点を当てる。

<<: AWS、Microsoft、Googleがガートナーのクラウドサービス部門マジッククアドラントをリード

>>: 安全なクラウド構成のベストプラクティス