すべてのプロダクト
Search

このプロダクト

    Microservices Engine:MSE クラウドネイティブゲートウェイを使用したブルーグリーンデプロイ、A/B テスト、カナリアリリースの実装

    ドキュメントセンター

    Microservices Engine:MSE クラウドネイティブゲートウェイを使用したブルーグリーンデプロイ、A/B テスト、カナリアリリースの実装

    最終更新日:Feb 13, 2025

    マイクロサービスエンジン（MSE）のクラウドネイティブゲートウェイは、イングレスとして機能し、膨大なトラフィック管理機能を提供するマネージドサービスです。クラウドネイティブゲートウェイは、コンテナサービス Kubernetes 版（ACK）、MSE Nacos、MSE ZooKeeper、エンタープライズ分散型アプリケーションサービス（EDAS）レジストリ、サーバーレスアプリケーションエンジン（SAE）レジストリ、固定アドレス、ドメインネームシステム（DNS）など、さまざまなサービスソースをサポートしています。クラウドネイティブゲートウェイは、サービスバージョンをサポートし、カナリアリリースを実装するための統一ソリューションを提供します。このトピックでは、サービスディスカバリに ACK クラスタと Nacos インスタンスを使用して、さまざまなサービスリリース戦略を実装する方法について説明します。

    前提条件

    ACK

    この例では、サービスディスカバリに ACK クラスタを使用します。バックエンドサービスは、アノテーションベースのサービス API を使用して CoreDNS に登録されます。バックエンドサービスは、使用中のバージョンを照会するために使用される API 操作を提供します。リクエストパスは /version で、使用中のバージョンは v1 です。クラウドネイティブゲートウェイは ACK クラスタと統合されており、ACK クラスタからサービス情報をリアルタイムで取得できます。このようにして、クラウドネイティブゲートウェイはバックエンドサービスを外部ユーザーに公開できます。

    基于容器服务K8s服务发现方式的业务架构图

    アプリケーションのデプロイ

    1. ACK コンソール にログインします。 次の YAML コードを使用して、バージョン v1 のアプリケーションをデプロイします。

      アプリケーションのデプロイ方法の詳細については、「Deployment を使用してステートレスアプリケーションを作成する」をご参照ください。

      apiVersion: v1
kind: Service
metadata:
  name: httpbin
spec:
  ports:
  - port: 8080
    protocol: TCP
  selector:
    app: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpbin
      version: v1  // バージョン v1 を指定
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      containers:
      - image: specialyang/spring-cloud-httpbin-k8s:v1
        imagePullPolicy: Always
        name: spring-cloud-httpbin-k8s
        ports:
        - containerPort: 8080

    2. MSE コンソール にログインします。 目的のゲートウェイの [概要] ページで、左側のナビゲーションペインの [ルート] をクリックします。次に、[ソース] タブをクリックします。[ソースの追加] をクリックして、コンテナサービスをサービスソースとして追加します。

      image

    3. 左側のナビゲーションペインで、[ルート] をクリックします。[サービス] タブを選択します。[サービスの追加] をクリックします。[サービスの追加] パネルで、クラウドネイティブゲートウェイに公開する httpbin サービスを追加します。

    4. httpbin サービスに v1 バージョンを追加します。

      クラウドネイティブゲートウェイにサービスバージョンを追加する方法の詳細については、「サービスバージョンの管理」をご参照ください。

      説明

      v1 タグに基づいて v1 ノードをフィルタリングする必要があります。現在、v1 のみがデプロイされています。したがって、v1 ノードはインスタンスノードの 100% を占めます。

      image

    5. [ルート設定] ページで、サービスのルートを作成して、サービスを外部ユーザーに公開します。 httpbin サービスを公開するために使用される API 操作のルートは /version です。リクエストは httpbin サービスの v1 バージョンに転送されます。

    6. 次のコマンドを実行して、テストリクエストを送信します。

      for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done

      コマンド出力:

      version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1

    ブルーグリーンデプロイメントを実行する

    ブルーグリーンデプロイメントでは、サービスの新しいバージョンは、現在のバージョンと同じ量のリソースを使用する必要があります。ブルーグリーンデプロイメントが完了すると、すべてのトラフィックが新しいバージョンに切り替えられます。

    基于容器服务K8s服务发现机制的蓝绿发布

    1. ACK のアノテーションベースの API リソースを使用して、httpbin サービスの v2 バージョンをデプロイします。レプリカの数は 3 です。

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin-v2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpbin
      version: v2
  template:
    metadata:
      labels:
        app: httpbin
        version: v2
    spec:
      containers:
      - image: specialyang/spring-cloud-httpbin-k8s:v2
        imagePullPolicy: Always
        name: spring-cloud-httpbin-k8s
        ports:
        - containerPort: 8080

    2. httpbin サービスに v2 バージョンを追加します。

      クラウドネイティブゲートウェイへのサービスバージョンの追加方法の詳細については、「サービスバージョンの管理」をご参照ください。

      説明

      v2 タグに基づいて v2 ノードをフィルタリングする必要があります。現在、インスタンス内の v1 ノードの数は v2 ノードの数と同じです。したがって、v1 ノードと v2 ノードはそれぞれインスタンスノードの 50% を占めます。

      image

    3. 作成したルートのサービスを変更して、ブルーグリーンデプロイメントでトラフィックを v1 から v2 に切り替えます。

      クラウドネイティブゲートウェイのルーティング規則の変更方法の詳細については、「ルーティング規則の変更」をご参照ください。

      image

    4. 次のコマンドを実行して、テストリクエストを送信します。

      for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done

      コマンド出力:

      version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2

    /version リクエストパスを使用して API リソースにアクセスするトラフィックは、v1 から v2 に切り替えられました。

    A/B テストを実行する

    A/B テストでは、ユーザーリクエストのメタデータに基づいて、トラフィックをサービスの新しいバージョンにルーティングします。A/B テストでは、リクエストの内容に基づいてトラフィックを動的にルーティングします。この例では、User-Agent 値が Android のリクエストのみが新しいバージョンにアクセスでき、他のリクエストは元のバージョンに送信されます。

    基于容器服务K8s服务发现机制的A/B测试

    1. httpbin サービスの v1 バージョンと v2 バージョンが引き続き使用されます。さらに、2 つのルーティングルールを作成する必要があります。

      • /version パスに一致するリクエストは、v1 バージョンにルーティングされます。

      • /version パスに一致し、User-Agent ヘッダーに Android が含まれるリクエストは、v2 バージョンにルーティングされます。

      説明

      version-v2 ルートは、一致に使用されるリクエストヘッダーとともに追加する必要があります。

    2. User-Agent ヘッダーに Android が含まれていないテストリクエストを送信するには、次のコマンドを実行します。

      curl ${GATEWAY_EXTERNAL_IP}/version

      コマンド出力:

      version: v1

    3. User-Agent ヘッダーに Android が含まれているテストリクエストを送信するには、次のコマンドを実行します。

      curl -H "User-Agent: Mozilla/5.0 (Linux; Android 4.0.3)" ${GATEWAY_EXTERNAL_IP}/version

      コマンド出力:

      version: v2

    リクエストは、リクエストが送信されたオペレーティングシステムに基づいて、異なるサービスバージョンに配信されます。

    カナリアリリースを実行する

    カナリアリリース機能を使用すると、少量のトラフィックをサービスの新しいバージョンにルーティングできます。新しいバージョンが検証された後、すべてのトラフィックが新しいバージョンにルーティングされるまで、より多くのトラフィックが徐々に新しいバージョンにルーティングされます。このプロセスでは、リソース使用率を最大化するために、新しいバージョンがスケールアウトされ、元のバージョンがスケールインされます。

    基于容器服务K8s服务发现机制的金丝雀发布

    1. カナリアリリースでは、新しいバージョンのレプリカの数は、元のバージョンのレプリカの数と一致する必要はありません。唯一の要件は、新しいバージョンのリソースが、そのバージョンへのカナリアトラフィックを処理するのに十分である必要があることです。この場合、新しいバージョンのレプリカの数は 1 に設定されています。 [サービス] ページの [サービスバージョン] セクションで、バージョンのノード分布を表示できます。

      image

    2. ノードの重みに基づいて、サービスの新しいバージョンと元のバージョンにトラフィックを転送するルートを作成します。

      このプロセスでは、httpbin サービスの v1 および v2 バージョンを構成し、トラフィックのルーティング元となる重みを指定する必要があります。たとえば、[送信先サービス] に [ラベルルーティング] を選択し、v1 バージョンの重みを 80%、v2 バージョンの重みを 20% に設定できます。

    3. 次のコマンドを実行して、テストリクエストを送信します。

      for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done

      コマンド出力:

      version: v1
version: v1
version: v1
version: v1
version: v1
version: v2
version: v1
version: v2
version: v1
version: v1

    10 件のリクエストのうち 2 件が v2 バージョンにアクセスします。このトラフィック分散比率は予想される比率です。

    説明

    実際のビジネスシナリオでは、バージョンが検証された後、新しいバージョンのトラフィックの割合を徐々に増やすことができます。トラフィックの割合を増やす場合は、新しいバージョンをスケールアウトし、元のバージョンをスケールインする必要があります。

    Nacos

    この例では、バックエンドサービスは、使用中のバージョンを照会するために使用される API 操作を提供します。リクエストパスは /version で、使用中のバージョンは v1 です。クラウドネイティブゲートウェイは MSE Nacos インスタンスと統合されており、MSE Nacos インスタンスからサービス情報をリアルタイムで取得できます。このようにして、クラウドネイティブゲートウェイはバックエンドサービスを外部ユーザーに公開できます。

    基于Nacos注册中心服务发现方式的业务架构图

    アプリケーションをデプロイする

    1. [ACKコンソール] にログインします。 次の YAML コードを使用して、バージョン v1 のアプリケーションをデプロイします。

      アプリケーションのデプロイ方法の詳細については、「デプロイメントを使用してステートレスアプリケーションを作成する」をご参照ください。

      説明

      • YAML ファイルの ${NACOS_SERVER_ADDRESS} 変数は、MSE Nacos インスタンスのアドレスに置き換える必要があります。MSE Nacos インスタンスがゲートウェイと同じ VPC に存在する場合は、変数をインスタンスの内部エンドポイントに置き換えることができます。それ以外の場合は、変数をインスタンスのパブリックエンドポイントに置き換えます。

      • ACK では、ポッドのラベルのデータはノードメタデータと見なすことができます。Nacos では、ノードメタデータはサービスが登録されるときに伝送されるデータによって決定されます。Spring Cloud フレームワークでは、spring.cloud.nacos.discovery.metadata.xxx 環境変数を使用して、ノードのメタデータを追加できます。この例では、version を使用して、異なるバージョンを持つノードを区別します。この場合、アプリケーションの spring.cloud.nacos.discovery.metadata.version を v1 に設定します。

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpbin
  template:
    metadata:
      labels:
        app: httpbin
    spec:
      containers:
      - image: specialyang/spring-cloud-httpbin-nacos:v1
        imagePullPolicy: Always
        name: spring-cloud-httpbin-nacos
        ports:
        - containerPort: 8080
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: ${NACOS_SERVER_ADDRESS} 
        - name: spring.cloud.nacos.discovery.metadata.version
          value: v1

    2. [MSEコンソール] にログインします。 目的のゲートウェイの [概要] ページで、左側のナビゲーションペインの [ルート] をクリックします。次に、[ソース] タブをクリックして、MSE Nacos インスタンスをサービスソースとして追加します。

    3. 左側のナビゲーションペインで、[ルート] をクリックします。次に、[サービス] タブをクリックして、クラウドネイティブゲートウェイに公開する httpbin サービスをインポートし、サービスソースとして MSE Nacos を選択します。

    4. httpbin サービスに v1 バージョンを追加します。

      説明

      v1 のタグに基づいて v1 ノードをフィルタリングする必要があります。現在、v1 のみがデプロイされています。したがって、v1 ノードはインスタンスノードの 100% を占めます。

      image

    5. [ルート設定] ページで、サービスのルートを作成して、サービスを外部ユーザーに公開します。httpbin サービスを公開するために使用される API 操作のルートは /version です。リクエストは httpbin サービスの v1 バージョンに転送されます。

    6. 次のコマンドを実行して、テストリクエストを送信します。

      for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done

      コマンド出力:

      version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1
version: v1

    ブルーグリーンデプロイメントを実行する

    ブルーグリーンデプロイメントでは、サービスの新しいバージョンは、現在のバージョンと同じ量の risorse を使用する必要があります。ブルーグリーンデプロイメントが完了すると、トラフィックは新しいバージョンに切り替えられます。

    1

    1. httpbin サービスの新しいバージョン v2 をデプロイします。

      説明

      Nacos インスタンスにアプリケーションを登録する手順は、ACK クラスタにサービスを登録する手順と同じです。アプリケーションの spring.cloud.nacos.discovery.metadata.version=v2 設定を追加します。アプリケーションが起動すると、アプリケーションは自動的に Nacos インスタンスに登録され、カスタムメタデータを伝送します。クラウドネイティブゲートウェイは、メタデータを使用して異なるバージョンのノードを区別できます。

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin-v2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: httpbin
  template:
    metadata:
      labels:
        app: httpbin
    spec:
      containers:
      - image: specialyang/spring-cloud-httpbin-nacos:v2
        imagePullPolicy: Always
        name: spring-cloud-httpbin-nacos
        ports:
        - containerPort: 8080
        env:
        - name: spring.cloud.nacos.discovery.server-addr
          value: ${NACOS_SERVER_ADDRESS}
        - name: spring.cloud.nacos.discovery.metadata.version
          value: v2

    2. httpbin サービスに v2 バージョンを追加します。

      クラウドネイティブゲートウェイにサービスバージョンを追加する方法の詳細については、「サービスバージョンの管理」をご参照ください。

      説明

      v2 のタグに基づいて v2 ノードをフィルタリングする必要があります。現在、インスタンス内の v1 ノードの数は v2 ノードの数と同じです。したがって、v1 ノードと v2 ノードはそれぞれインスタンスノードの 50% を占めます。

      image

    3. 作成したルートの宛先サービスを変更して、ブルーグリーンデプロイメントでトラフィックを v1 から v2 に切り替えます。

      クラウドネイティブゲートウェイのルーティングルールを変更する方法の詳細については、「ルーティングルールの変更」をご参照ください。

    4. 次のコマンドを実行して、テストリクエストを送信します。

      for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done

      コマンド出力:

      version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2
version: v2

    /version リクエストパスを使用して API リソースにアクセスするトラフィックは、v1 から v2 に切り替えられました。

    A/B テストを実行する

    A/B テストは、ユーザーリクエストのメタデータに基づいて、トラフィックをサービスの新しいバージョンにルーティングします。A/B テストは、リクエストの内容に基づいてトラフィックを動的にルーティングします。この例では、User-Agent 値が Android のリクエストのみが新しいバージョンにアクセスでき、他のリクエストは元のバージョンに送信されます。

    2

    1. httpbin サービスの v1 バージョンと v2 バージョンは引き続き使用されます。さらに、2 つのルーティングルールを作成する必要があります。

      • /version パスに一致するリクエストは v1 バージョンにルーティングされます。

      • /version パスに一致し、User-Agent ヘッダーに Android が含まれるリクエストは v2 バージョンにルーティングされます。

      説明

      version-v2 ルートには、一致に使用されるリクエストヘッダーを追加する必要があります。

    2. 次のコマンドを実行して、User-Agent ヘッダーに Android が含まれていないテストリクエストを送信します。

      curl ${GATEWAY_EXTERNAL_IP}/version

      コマンド出力:

      version: v1

    3. 次のコマンドを実行して、User-Agent ヘッダーに Android が含まれているテストリクエストを送信します。

      curl -H "User-Agent: Mozilla/5.0 (Linux; Android 4.0.3)" ${GATEWAY_EXTERNAL_IP}/version

      コマンド出力:

      version: v2

    リクエストは、リクエストが送信されたオペレーティングシステムに基づいて、異なるサービスバージョンに配信されます。

    カナリアリリースを実行する

    カナリアリリース機能を使用すると、少量のトラフィックをサービスの新しいバージョンにルーティングできます。新しいバージョンが検証された後、すべてのトラフィックが新しいバージョンにルーティングされるまで、徐々に多くのトラフィックが新しいバージョンにルーティングされます。このプロセスでは、新しいバージョンはスケールアウトされ、元のバージョンはスケールインされて、リソース使用率が最大化されます。

    3

    1. カナリアリリースでは、新しいバージョンのレプリカの数は、元のバージョンのレプリカの数と一致する必要はありません。唯一の要件は、新しいバージョンのリソースが、そのバージョンへのカナリアトラフィックを処理するのに十分である必要があることです。この場合、新しいバージョンのレプリカの数は 1 に設定されています。[サービス] ページの [サービスバージョン] セクションで、バージョンのノード分布を表示できます。

      image

    2. ノードの重み付けに基づいて、サービスの新しいバージョンと元のバージョンにトラフィックを転送するルートを作成します。

      このプロセスでは、httpbin サービスの v1 バージョンと v2 バージョンを設定し、トラフィックのルーティングに基づいて重みを指定する必要があります。たとえば、宛先サービスに [ラベルルーティング] を選択し、v1 バージョンの重みを 80%、v2 バージョンの重みを 20% に設定できます。

    3. 次のコマンドを実行して、テストリクエストを送信します。

      for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done

      コマンド出力:

      version: v1
version: v1
version: v1
version: v1
version: v1
version: v2
version: v1
version: v2
version: v1
version: v1

    10 件のリクエストのうち 2 件が v2 バージョンにアクセスします。このトラフィック分散比率は予想される比率です。

    説明

    実際のビジネスシナリオでは、バージョンが検証された後、新しいバージョンのトラフィックの割合を徐々に増やすことができます。トラフィックの割合を増やすときは、新しいバージョンをスケールアウトし、元のバージョンをスケールインする必要があります。