すべてのプロダクト
Search

このプロダクト

    Alibaba Cloud Service Mesh:エンドツーエンドのカナリアリリースを実装するためのトラフィックラベルの使用

    ドキュメントセンター

    Alibaba Cloud Service Mesh:エンドツーエンドのカナリアリリースを実装するためのトラフィックラベルの使用

    最終更新日:Jan 13, 2025

    複数のサービスに対してエンドツーエンドのカナリアリリースを実装する必要がある場合は、トラフィックラベルを設定してトラフィック特性を識別し、ゲートウェイのイングレストラフィックを通常のトラフィックとカナリアトラフィックに分割できます。 カナリアトラフィックの特性は、ユーザーリクエストの処理に使用されるサービス間で渡されます。 この方法で、エンドツーエンドのカナリアリリースが実装されます。 このトピックでは、トラフィックラベルを使用してマイクロサービスのエンドツーエンドのカナリアリリースを実装する方法について説明します。

    前提条件

    機能の説明

    カナリアリリースはさまざまな方法で実装できます。 たとえば、ASM を使用して、ブルーグリーンリリースモードと段階的リリースモードでアプリケーションをデプロイできます。 サンプルモードは、単一サービスのリリースに適用できます。 このモードでは、オープンソース Istio の VirtualService を使用して、サービスの各バージョンのトラフィックの重みを指定します。 このモードは、複数のサービスのカナリアリリースタイミングの要件を満たすことができません。

    ASM は、トラフィックのラベル付けとラベルベースのルーティング機能に基づいて、エンドツーエンドのカナリアリリース機能を提供します。 これにより、複数のサービスのカナリアリリースを同時に実装できます。 ビジネスのカナリアテスト中に、システムはイングレストラフィックを通常のトラフィックとカナリアトラフィックに分割し、トラフィックの特性を識別します。 リクエストのトラフィックがカナリアトラフィックとして識別されると、リクエストはカナリアリリースサービスにルーティングされます。 このようにして、システムは単に特定のトラフィック比率で異なるバージョンのバックエンドサービスにトラフィックを分散するのではなく、カナリアトラフィックの特性がユーザーリクエストの処理に使用されるすべてのサービス間で渡されます。 詳細については、トラフィックのラベル付けをご参照ください。

    構成の説明

    ここをクリックして、サンプル構成ファイルをダウンロードできます。 次の図は、例に示すサービスの呼び出しチェーンを示しています。

    应用服务调用链路

    この例では、サービス A がサービス B を呼び出すとき、サービス A には HTTP ヘッダー my-trace-id を渡すためのコード実装ロジックが含まれています。 詳細については、src/mock-abc/go/main.go パスの main.go 構成ファイルをご参照ください。

    説明

    他のアプリケーションを使用する場合は、アプリケーションに HTTP ヘッダーを渡すロジックが含まれていることを確認してください。 後続の関数は HTTP ヘッダーに依存します。

    ベースバージョンのアプリケーションデプロイメントファイル: application-base.yaml

    apiVersion: v1
kind: Service
metadata:
  name: mocka
  labels:
    app: mocka
    service: mocka
spec:
  ports:
  - port: 8000
    name: http
  selector:
    app: mocka
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mocka-base
  labels:
    app: mocka
    version: base
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mocka
      version: base
  template:
    metadata:
      labels:
        app: mocka
        version: base
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: Always
        env:
        - name: version  // バージョン
          value: base
        - name: app    // アプリケーション
          value: mocka
        - name: upstream_url // アップストリーム URL
          value: "http://mockb:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: mockb
  labels:
    app: mockb
    service: mockb
spec:
  ports:
  - port: 8000
    name: http
  selector:
    app: mockb
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockb-base
  labels:
    app: mockb
    version: base
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockb
      version: base
  template:
    metadata:
      labels:
        app: mockb
        version: base
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: Always
        env:
        - name: version   // バージョン
          value: base
        - name: app     // アプリケーション
          value: mockb
        ports:
        - containerPort: 8000

    カナリアリリースバージョンのアプリケーションデプロイメントファイル: application-canary.yaml

    apiVersion: v1
kind: Service
metadata:
  name: mocka
  labels:
    app: mocka
    service: mocka
spec:
  ports:
  - port: 8000
    name: http
  selector:
    app: mocka
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mocka-canary
  labels:
    app: mocka
    version: canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mocka
      version: canary
  template:
    metadata:
      labels:
        app: mocka
        version: canary
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: Always
        env:
        - name: version    // バージョン
          value: canary
        - name: app      // アプリケーション
          value: mocka
        - name: upstream_url  // アップストリーム URL
          value: "http://mockb:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: mockb
  labels:
    app: mockb
    service: mockb
spec:
  ports:
  - port: 8000
    name: http
  selector:
    app: mockb
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockb-canary
  labels:
    app: mockb
    version: canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockb
      version: canary
  template:
    metadata:
      labels:
        app: mockb
        version: canary
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: Always
        env:
        - name: version   // バージョン
          value: canary
        - name: app     // アプリケーション
          value: mockb
        ports:
        - containerPort: 8000

    手順 1: ACK クラスターにサンプルサービスをデプロイする

    1. 目的のネームスペース（この例ではデフォルトのネームスペース）に対して、サイドカープロキシの自動インジェクションを有効にします。 詳細については、サイドカープロキシの自動インジェクションの有効化をご参照ください。

    2. kubeconfig ファイルの情報に基づいて kubectl を使用して ACK クラスターに接続し、次のコマンドを実行してサンプルサービスをデプロイします。

      YAML ファイルの詳細については、構成の説明をご参照ください。

      kubectl apply -n default -f application-base.yaml
kubectl apply -n default -f application-canary.yaml

    手順 2: 初期ルーティングルールを設定する

    1. routing.yaml という名前のファイルを作成し、次の内容をファイルにコピーします。

      routing.yaml の内容

      apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: simple-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - "*"
      port:
        name: http
        number: 80
        protocol: HTTP
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: dr-mocka
spec:
  host: mocka
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
  subsets:
    - labels:
        version: base
      name: version-base
    - labels:
        version: canary
      name: version-canary
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: dr-mockb
spec:
  host: mockb
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
  subsets:
    - labels:
        version: base
      name: version-base
    - labels:
        version: canary
      name: version-canary
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: vs-gateway-mocka
spec:
  gateways:
  - simple-gateway
  hosts:
    - "*"
  http:
  - route:
      - destination:
          host: mocka
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: vs-mockb
spec:
  hosts:
    - mockb
  http:
    - route:
        - destination:
            host: mockb

    2. kubeconfig ファイルの情報に基づいて kubectl を使用して ASM インスタンスに接続し、次のコマンドを実行してルーティングルールを設定します。

      kubectl apply -n default -f routing.yaml

    3. 異なるバージョンのサービスにアクセスできるかどうかを確認します。

      1. ASM コンソールでイングレスゲートウェイのパブリック IP アドレスを取得します。 詳細については、手順 2: ASM イングレスゲートウェイの IP アドレスを取得するをご参照ください。

      2. 次のコマンドを実行して環境変数を設定します。

        xxxx は、サブステップ a で取得した IP アドレスです。

        export ASM_GATEWAY_IP=xxxx

      3. 次のコマンドを実行して、異なるバージョンのサービスにアクセスできるかどうかを確認します。

        for i in {1..200};  do curl   -H'my-asm-prefer-tag: version-base'  -H'my-trace-id: x000'$i  http://${ASM_GATEWAY_IP}/; echo; sleep 1; done;

        期待される出力:

        -> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: base, ip: 172.17.0.70)
-> mocka(version: base, ip: 172.17.0.132)-> mockb(version: base, ip: 172.17.0.70)
-> mocka(version: base, ip: 172.17.0.132)-> mockb(version: canary, ip: 172.17.0.54)
-> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: canary, ip: 172.17.0.54)
-> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: base, ip: 172.17.0.70)
-> mocka(version: base, ip: 172.17.0.132)-> mockb(version: base, ip: 172.17.0.70)
-> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: canary, ip: 172.17.0.54)

        出力は、イングレスゲートウェイからサービス A へ、およびサービス A からサービス B へのトラフィックフローにランダムロードバランシングのルーティングポリシーが採用されていることを示しています。 my-asm-prefer-tag ヘッダーまたは curl コマンドを使用して指定された他のリクエストヘッダーは、ランダムルーティングポリシーを変更しません。

    手順 3: サンプルサービスのトラフィックラベルを設定する

    ASM では、TrafficLabel CustomResourceDefinition（CRD）を使用してトラフィックラベルを設定し、トラフィックラベルに基づいてトラフィックを異なるワークロードにルーティングできます。 詳細については、トラフィックのラベル付けをご参照ください。

    1. trafficlabel.yaml という名前のファイルを作成し、次の内容をファイルにコピーします。

      trafficlabel.yaml の内容

      apiVersion: istio.alibabacloud.com/v1
kind: TrafficLabel
metadata:
  name: trafficlabel-ns
  namespace: default
spec:
  rules:
  - labels:
    - name: asm-labels-sample
      valueFrom:
      - $getExternalInboundRequestHeader(my-asm-prefer-tag, my-trace-id) // 外部からの受信リクエストヘッダーを取得
---
apiVersion: istio.alibabacloud.com/v1
kind: TrafficLabel
metadata:
  name: ingressgateway
  namespace: istio-system
spec:
  rules:
  - labels:
    - name: asm-labels-sample
      valueFrom:
      - $getInboundRequestHeader(my-asm-prefer-tag) // 受信リクエストヘッダーを取得
  workloadSelector:
    labels:
      istio: ingressgateway

      構成の説明:

      • trafficlabel-ns トラフィックラベルは、この例でデプロイされた mocka サービスや mockb サービスなど、デフォルトのネームスペースのすべてのサービスに有効です。 ingressgateway トラフィックラベルは、ingressgateway ゲートウェイのみに有効です。

      • この例では、my-asm-prefer-tag リクエストヘッダーを使用してバージョンを区別します。 したがって、getExternalInboundRequestHeader の最初のパラメーターを my-asm-prefer-tag に設定します。 ビジネス要件に基づいて構成を変更してください。

      • この例では、my-trace-id は渡す必要がある HTTP ヘッダーです。 したがって、getExternalInboundRequestHeader の 2 番目のパラメーターを my-trace-id に設定します。 ビジネス要件に基づいて構成を変更してください。

    2. kubeconfig ファイルの情報に基づいて kubectl を使用して ASM インスタンスに接続し、次のコマンドを実行してトラフィックラベルを設定します。

      kubectl apply -f trafficlabel.yaml

    手順 4: ラベルベースのルーティングルールを設定する

    ラベルベースのルーティングルールを設定して、トラフィックフローを制御できます。

    1. サービスプロバイダー側でカナリアリリースを確認する

    サービス A からサービス B へのトラフィックルーティングが期待どおりであるかどうかを確認します。 具体的には、サービス A に流れ込むカナリアトラフィックがサービス B のカナリアリリースバージョンに転送されるかどうか、およびサービス A に流れ込むベーストラフィックがサービス B のベースバージョンに転送されるかどうかを確認します。

    次の図は、サービス B にトラフィックラベルベースのルーティングルールを設定した後のトラフィックフローを示しています: 验证服务提供侧的灰度

    1. vs-tf-mockb.yaml という名前のファイルを作成し、次の内容をファイルにコピーします。

      apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: vs-mockb
spec:
  hosts:
    - mockb
  http:
    - route:
        - destination:
            host: mockb
            subset: $asm-labels-sample

    2. 次のコマンドを実行して、サービス A にルーティングルールを有効にします。

      kubectl apply -n default -f vs-tf-mockb.yaml

    3. 次のコマンドを実行して、サービス A に流れ込むカナリアトラフィックがサービス B のカナリアリリースバージョンに転送されるかどうかを確認します。

      for i in {1..200};  do curl -H'my-asm-prefer-tag: version-canary'  -H'my-trace-id: x000'$i  http://${ASM_GATEWAY_IP}/; echo; sleep 1; done;

      期待される出力:

      -> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: canary, ip: 172.17.0.54)
-> mocka(version: base, ip: 172.17.0.132)-> mockb(version: canary, ip: 172.17.0.54)
-> mocka(version: base, ip: 172.17.0.132)-> mockb(version: canary, ip: 172.17.0.54)
-> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: canary, ip: 172.17.0.54)
-> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: canary, ip: 172.17.0.54)
-> mocka(version: base, ip: 172.17.0.132)-> mockb(version: canary, ip: 172.17.0.54)

    4. 次のコマンドを実行して、サービス A に流れ込むベーストラフィックがサービス B のベースバージョンに転送されるかどうかを確認します。

      for i in {1..200};  do curl -H'my-asm-prefer-tag: version-base'  -H'my-trace-id: x000'$i  http://${ASM_GATEWAY_IP}/; echo; sleep 1; done;

      期待される出力:

      -> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: base, ip: 172.17.0.70)
-> mocka(version: base, ip: 172.17.0.132)-> mockb(version: base, ip: 172.17.0.70)
-> mocka(version: base, ip: 172.17.0.132)-> mockb(version: base, ip: 172.17.0.70)
-> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: base, ip: 172.17.0.70)
-> mocka(version: base, ip: 172.17.0.132)-> mockb(version: base, ip: 172.17.0.70)
-> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: base, ip: 172.17.0.70)
-> mocka(version: canary, ip: 172.17.0.129)-> mockb(version: base, ip: 172.17.0.70)
-> mocka(version: base, ip: 172.17.0.132)-> mockb(version: base, ip: 172.17.0.70)

      結果は、サービス A に流れ込むイングレスカナリアトラフィックとイングレスベーストラフィックが、サービス B の予期されるバージョンにルーティングされていないことを示しています。 サービス A のトラフィックラベルベースのルーティングルールを設定する必要があります。 詳細については、次の手順に進みます。

    2. エンドツーエンドのカナリアリリース機能を確認する

    サービス A の a-vs-tf.yaml という名前のトラフィックラベルベースのルーティングルールファイルを設定し、イングレスゲートウェイに対してファイルを有効にします。 期待される結果は、イングレスリクエストのカナリアトラフィックが最初にサービス A のカナリアリリースバージョンに転送され、次にサービス B のカナリアリリースバージョンに転送され、ベーストラフィックが最初にサービス A のベースバージョンに転送され、次にサービス B のベースバージョンに転送されることです。

    次の図は、サービス A にトラフィックラベルベースのルーティングルールを設定した後のトラフィックフローを示しています: 验证全链路灰度

    1. vs-tf-mocka.yaml という名前のファイルを作成し、次の内容をファイルにコピーします。

      apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: vs-gateway-mocka
spec:
  gateways:
  - simple-gateway
  hosts:
    - "*"
  http:
  - route:
      - destination:          host: mocka
          subset: $asm-labels-sample

    2. 次のコマンドを実行して、イングレスゲートウェイにルーティングルールを有効にします。

      kubectl apply -n default -f vs-tf-mocka.yaml

    3. 次のコマンドを実行して、イングレスリクエストのカナリアトラフィックが最初にサービス A のカナリアリリースバージョンに転送され、次にサービス B のカナリアリリースバージョンに転送されるかどうかを確認します。

      for i in {1..200};  do curl -H'my-asm-prefer-tag: version-canary'  -H'my-trace-id: x000'$i  http://${ASM_GATEWAY_IP}/; echo; sleep 1; done;

      期待される出力:

      -> mocka(version: canary, ip: 172.17.0.69)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: canary, ip: 172.17.0.69)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: canary, ip: 172.17.0.69)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: canary, ip: 172.17.0.69)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: canary, ip: 172.17.0.69)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: canary, ip: 172.17.0.69)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: canary, ip: 172.17.0.69)-> mockb(version: canary, ip: 172.17.0.130)

    4. 次のコマンドを実行して、イングレスリクエストのベーストラフィックが最初にサービス A のベースバージョンに転送され、次にサービス B のベースバージョンに転送されるかどうかを確認します。

      for i in {1..200};  do curl -H'my-asm-prefer-tag: version-base'  -H'my-trace-id: x000'$i  http://${ASM_GATEWAY_IP}/; echo; sleep 1; done;

      期待される出力:

      -> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)

    3. トラフィックラベルベースのルーティングに対応する重みベースのトラフィック分散が要件を満たしているかどうかを確認する

    次の図は、サービス A に重みベースおよびトラフィックラベルベースのルーティングルールを設定した後のトラフィックフローを示しています: 验证路由权重

    1. vs-tf-mocka-90-10.yaml という名前のファイルを作成し、次の内容をファイルにコピーします。

      apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: vs-gateway-mocka
spec:
  gateways:
  - simple-gateway
  hosts:
    - "*"
  http:
  - route:
      - destination:
          host: mocka
          subset: version-base
        weight: 90
      - destination:
          host: mocka
          subset: $asm-labels-sample
        weight: 10

    2. 次のコマンドを実行して、イングレスゲートウェイにルーティングルールを有効にします。

      kubectl apply -n default -f vs-tf-mocka-90-10.yaml

    3. 次のコマンドを実行して、イングレスリクエストのカナリアトラフィックがサービス A のカナリアリリースバージョンとベースバージョンに転送されるかどうかを確認します。

      for i in {1..200};  do curl -H'my-asm-prefer-tag: version-canary'  -H'my-trace-id: x000'$i  http://${ASM_GATEWAY_IP}/; echo; sleep 1; done;

      期待される出力:

      -> mocka(version: base, ip: 172.17.0.90)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: canary, ip: 172.17.0.130)
-> mocka(version: canary, ip: 172.17.0.69)-> mockb(version: canary, ip: 172.17.0.130)

      結果は、イングレスリクエストのカナリアトラフィックの約 90% がサービス A のベースバージョンに転送され、約 10% がサービス A のカナリアリリースバージョンに転送されることを示しています。上記のルーティングルールに従って、リクエストトラフィックの約 90% がサービス A のベースバージョンに転送され、残りの 10% は my-asm-prefer-tag ヘッダーの値に基づいて転送されます。 リクエストコマンドは、my-asm-prefer-tag の値を version-canary に設定します。 したがって、リクエストトラフィックの 10% がサービス A のカナリアリリースバージョンに転送されます。

    4. 次のコマンドを実行して、イングレスリクエストのすべてのベーストラフィックがサービス A のベースバージョンに転送されるかどうかを確認します。

      for i in {1..200};  do curl -H'my-asm-prefer-tag: version-base'  -H'my-trace-id: x000'$i  http://${ASM_GATEWAY_IP}/; echo; sleep 1; done;

      期待される出力:

      -> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)
-> mocka(version: base, ip: 172.17.0.90)-> mockb(version: base, ip: 172.17.0.93)

      上記のルーティングルールに従って、リクエストトラフィックの約 90% がサービス A のベースバージョンに転送され、残りの 10% は my-asm-prefer-tag ヘッダーの値に基づいて転送されます。 リクエストコマンドは my-asm-prefer-tag の値を version-base に設定します。 したがって、リクエストトラフィックの 10% がサービス A のベースバージョンに転送されます。