Spring Cloud Gateway からクラウドネイティブゲートウェイへのサービスの移行 - Microservices Engine

Kubernetes アーキテクチャでは、Spring Cloud Gateway はコンテナサービスを検出できず、NGINX Ingress ゲートウェイよりもパフォーマンスが低くなります。可観測性とセキュリティの面では、Spring Cloud Gateway にはカスタム開発と統合が必要です。クラウド移行やハイブリッドクラウドデプロイなどのシナリオでは、2 層ネットワークアーキテクチャが存在する場合があります。1 つの層は Ingress ゲートウェイ用で、もう 1 つの層は Spring Cloud Gateway 用です。これにより、ネットワーク層、リソース消費、および O&M コストが増加します。クラウドネイティブゲートウェイは、従来のトラフィックゲートウェイとマイクロサービスゲートウェイを組み合わせたものです。これにより、サービスコストを大幅に削減できます。クラウドネイティブゲートウェイは、高性能、高統合、すぐに使えるという利点を備えています。このトピックでは、Spring Cloud Gateway から Microservices Engine（MSE）クラウドネイティブゲートウェイにサービスを移行する方法について説明します。

前提条件

クラウドネイティブゲートウェイが作成されていること。詳細については、MSE クラウドネイティブゲートウェイの作成をご参照ください。
クラウドネイティブゲートウェイに精通していること。詳細については、クラウドネイティブゲートウェイを使用した MSE Nacos サービスの管理をご参照ください。

手順 1：サービスソースの確認

以下の状況では、手順 2：Spring Cloud Gateway の構成の移行に直接進むことができます。

Container Service for Kubernetes（ACK）が使用されており、Kubernetes サービスディスカバリがサポートされている。
MSE Nacos インスタンスが購入され、レジストリとして使用されている。MSE Nacos インスタンスは、Mesh Configuration Protocol（MCP）をサポートするバージョンにアップグレードされている。
サービスディスカバリメカニズムが使用されておらず、ドメイン名と固定 IP アドレスがサービスの検出に使用されている。

サービスソースのタイプに基づいて、移行操作を実行できます。

MSE Nacos インスタンスを使用する
1. MSE Nacos インスタンスを購入します。詳細については、Nacos エンジンを作成するをご参照ください。
2. 構成またはコードを変更し、サービスを MSE Nacos インスタンスに登録します。詳細については、Java SDKをご参照ください。
3. オプション。アプリケーションが Java アプリケーションの場合は、MSE の Microservices Governance エージェントを使用して移行操作を実行します。詳細については、MSE Sync に基づく移行ソリューションをご参照ください。
Enterprise Distributed Application Service（EDAS）の共有レジストリを使用する
クラウドネイティブゲートウェイは EDAS レジストリをサポートしています。EDAS レジストリをサービスソースとして直接追加できます。詳細については、サービスソースの追加をご参照ください。
Serverless App Engine（SAE）の共有レジストリを使用する
クラウドネイティブゲートウェイは SAE レジストリをサポートしています。SAE レジストリをサービスソースとして直接追加できます。詳細については、サービスソースの追加をご参照ください。

手順 2：Spring Cloud Gateway の構成の移行

Spring Cloud Gateway の構成例：

関連レジストリの構成

spring:
  application:
    name: gateway-demo
  cloud:
    nacos:
      discovery:
        server-addr: nacos-server:8848  // Nacos サーバーのアドレス
      config:
        enabled: false

ルーティングサービスの構成

spring:
  cloud:
    gateway:
      default-filters:
        - AddResponseHeader=X-Response-Default-Foo, Default-Bar // デフォルトのレスポンスヘッダー

      routes:  // ルート設定
        - id: websocket_test
          uri: ws://localhost:9000
          order: 9000
          predicates:
            - Path=/echo
        - id: default_path_to_service-a
          uri: lb://service-a
          order: 10000
          predicates:
            - Path=/sleep
service-a:  // service-a の設定
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.WeightedResponseTimeRule
    ConnectTimeout: 1000
    ReadTimeout: 8000
    MaxAutoRetries: 3
    MaxAutoRetriesNextServer: 2
    MaxTotalConnections: 20000
    MaxConnectionsPerHost: 5000
hystrix:  // hystrix の設定
  command:
    service-a:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 60000
          strategy: SEMAPHORE
          semaphore:
            maxConcurrentRequests: 60000

MSE コンソールで Spring Cloud Gateway の構成を移行するには、次の操作を実行します。

レジストリ関連の操作
クラウドネイティブゲートウェイは、サービスソースを使用してレジストリを関連付けます。MSE コンソールを使用してサービスソースを追加し、サービスソースをサービスに関連付けることができます。構成はリアルタイムで有効になります。サービスソースを追加する方法の詳細については、サービスソースの追加をご参照ください。
サービスの関連付け操作
1. サービスをインポートして、サブスクライブするサービスを追加します。サービスを追加する方法の詳細については、サービスの追加をご参照ください。
2. 追加したサービスに適切なルートバージョンを構成する方法の詳細については、サービスバージョンの管理をご参照ください。
```
service-a: // service-a の設定
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.WeightedResponseTimeRule
    ConnectTimeout: 1000
    ReadTimeout: 8000
    MaxAutoRetries: 3
    MaxAutoRetriesNextServer: 2
    MaxTotalConnections: 20000
    MaxConnectionsPerHost: 5000
```
ルーティング構成操作
ゲートウェイのルーティングポリシーを構成します。詳細については、ルートの作成をご参照ください。
```
spring:
  cloud:
    gateway:
      routes: // ルート設定
        - id: websocket_test
          uri: ws://localhost:9000
          order: 9000
          predicates:
            - Path=/echo
        - id: default_path_to_service-a
          uri: lb://service-a
          order: 10000
          predicates:
            - Path=/sleep
```
クラウドネイティブゲートウェイは複数のルーティングポリシーをサポートしています。詳細については、以下のトピックをご参照ください。

手順 3：クラウドネイティブゲートウェイの認証方式の構成

クラウドネイティブゲートウェイは複数の認証方式をサポートしています。詳細については、以下のトピックをご参照ください。

手順 4：クラウドネイティブゲートウェイのグローバルデータダッシュボードの表示

各クラウドネイティブゲートウェイのグローバルデータダッシュボードを表示できます。詳細については、以下のトピックをご参照ください。

手順 5：トラフィックの移行

呼び出し元側でのトラフィックを移行する手順：

呼び出し元側またはクライアント側での反復移行：いくつかのサービスのアクセス URL を変更して、移行結果を確認できます。
プロキシ側での段階的移行：サービスの種類に基づいて、元のプロキシ側に移行手順を作成できます。たとえば、コサービスと非コサービスの移行手順を個別に作成できます。次に、アクセス URL に基づいてサービスを段階的に移行できます。
DNS ベースの完全移行：段階的移行が完了したら、元のドメイン名をクラウドネイティブゲートウェイのアクセス URL に関連付けることができます。
[推奨] 手順的移行：
1. テストとしていくつかのサービスを移行し、移行結果を確認します。
2. コサービスを順番に移行します。
3. ストレステストが完了したら、DNS ベースの完全移行を実行します。

移行ソリューション	コスト	リスク
反復移行	高	低
プロキシ側での段階的移行	中	中
DNS ベースの完全移行	低	高
手順的移行	比較的低	比較的低

参考資料

クラウドネイティブゲートウェイの詳細については、クラウドネイティブゲートウェイの概要をご参照ください。