Microservices Engine:MSE Cloud-native Gateway を使用したサービスリリース戦略の実装

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

1. Container Service for Kubernetes (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
     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 Gateway Management コンソールにログインします。ゲートウェイの詳細 ページの左側メニューで、Routes > ソース を選択します。ソースの作成 をクリックし、コンテナサービス からサービスソースを追加します。

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

   ソース リストに、作成したソースレコードが表示されます。ソースタイプは [Container Service] で、Ingress リスニングステータスは [Enabled] です。

3. 左側のナビゲーションペインで、Routes > Service を選択します。クラウドネイティブゲートウェイを介して公開する httpbin サービスをインポートします。

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

4. httpbin サービスのポリシー設定で、v1 という名前のサービスバージョンを追加します。

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

   説明

   v1 バージョンのノードをフィルタリングするために、対応するラベルを選択する必要があります。v1 バージョンのみがデプロイされているため、すべてのインスタンスがこのバージョンになります。

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

ブルーグリーンデプロイメント

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

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 バージョンのノードをフィルタリングするために、対応するラベルを選択する必要があります。クラスターには現在、同数の v1 ノードと v2 ノードがあるため、各バージョンが全体の 50% を占めます。

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

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

   ルート管理リストで、ルート [testtt] のルート条件が [Prefix Match | /version]、宛先サービスタイプが Tag-based Routing、宛先サービスが [httpbin (v2 100%)]、ステータスが [Published] であることを確認します。

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 へのすべてのトラフィックが v2 バージョンにルーティングされるようになりました。

A/B テスト

A/B テストは、ユーザーリクエストのメタデータに基づいてトラフィックを新しいバージョンにルーティングし、リクエストのコンテンツに基づいた動的なルーティングが可能になります。この例では、User-Agent ヘッダーに Android を含むリクエストは新しいバージョンにルーティングされ、その他のすべてのリクエストは古いバージョンにルーティングされます。

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

ご覧のとおり、リクエスト元のオペレーティングシステムに基づいてトラフィックが分割されます。

カナリアリリース

カナリアリリースでは、トラフィックのごく一部を新しいバージョンにルーティングできます。新しいバージョンを検証した後、カットオーバーが完了するまで段階的にトラフィックを増やすことができます。このプロセス中に、新しいバージョンをスケールアウトし、古いバージョンをスケールインして、リソース使用率を最適化できます。

1. カナリアリリース戦略では、新しいバージョンの初期レプリカ数は古いバージョンと一致させる必要はありません。カナリアトラフィックを処理するのに十分なリソースがあれば十分です。新しいバージョンのレプリカ数を 1 に設定します。サービスバージョンの設定で、各バージョンのノードの割合を確認できます。

2. 重みに基づいて新旧バージョン間でトラフィックを分散するルーティングルールを作成します。

   httpbin v1 と v2 の 2 つの宛先サービスを設定し、それらのトラフィックの重みを設定します。たとえば、宛先サービスタイプとして Tag-based Routing を選択し、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 バージョンにルーティングされたことを示しており、期待される 20% のトラフィックの重みと一致します。

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

1. Container Service for Kubernetes (ACK) コンソールにログインします。次の YAML を使用してアプリケーションをデプロイします。アプリケーションの初期バージョンは v1 です：

   アプリケーションのデプロイ方法の詳細については、「ステートレスワークロード (Deployment) の作成」をご参照ください。

   説明

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

   • Kubernetes のサービスディスカバリでは、Pod ラベルがノードメタデータとして機能します。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 Gateway Management コンソールにログインします。ゲートウェイの詳細 ページの左側のナビゲーションペインで、Routes > ソース を選択し、対象の MSE Nacos レジストリのサービスソースを追加します。

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

3. 左側のナビゲーションペインで、Routes > Service を選択し、クラウドネイティブゲートウェイを介して公開する httpbin サービスをインポートし、サービスソースとして MSE Nacos レジストリを選択します。

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

4. httpbin サービスのポリシー設定で、v1 という名前のサービスバージョンを追加します。

   説明

   v1 バージョンのノードをフィルタリングするために、対応するラベルを選択する必要があります。v1 バージョンのみがデプロイされているため、すべてのインスタンスがこのバージョンになります。

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

ブルーグリーンデプロイメント

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

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

   説明

   アプリケーションコンテナに spring.cloud.nacos.discovery.metadata.version=v2 環境変数を追加します。アプリケーションが起動すると、指定された Nacos インスタンスに登録され、このカスタムメタデータが含まれます。MSE Cloud-native Gateway はこのメタデータを使用して、異なるバージョンのノードを区別します。

   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 バージョンのノードをフィルタリングするために、対応するラベルを選択する必要があります。クラスターには現在、同数の v1 ノードと v2 ノードがあるため、各バージョンが全体の 50% を占めます。

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 へのすべてのトラフィックが v2 バージョンにルーティングされるようになりました。

A/B テスト

A/B テストは、ユーザーリクエストのメタデータに基づいてトラフィックを新しいバージョンにルーティングし、リクエストのコンテンツに基づいた動的なルーティングが可能になります。この例では、User-Agent ヘッダーに Android を含むリクエストは新しいバージョンにルーティングされ、その他のすべてのリクエストは古いバージョンにルーティングされます。

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

ご覧のとおり、リクエスト元のオペレーティングシステムに基づいてトラフィックが分割されます。