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

Kubernetes 環境では、Spring Cloud Gateway はコンテナサービスを自動的に検出できず、パフォーマンスは NGINX Ingress ゲートウェイよりも低く、可観測性およびセキュリティ機能を統合するにはカスタム開発が必要です。クラウド移行やハイブリッドクラウドのシナリオでは、Ingress ゲートウェイと Spring Cloud Gateway の 2 層アーキテクチャになってしまうことがあります。この構成では、ネットワークの複雑さ、リソース消費、運用オーバーヘッドが増加します。クラウドネイティブゲートウェイは、従来のトラフィックゲートウェイとマイクロサービスゲートウェイの機能を単一のサービスに統合します。これにより、アーキテクチャが簡素化され、コストが削減され、高性能、緊密な統合、すぐに使える機能が提供されます。このトピックでは、サービスを Spring Cloud Gateway から MSE クラウドネイティブゲートウェイに移行する方法について説明します。

前提条件

ステップ 1：サービスソースの特定

ご利用の構成が次のいずれかの条件を満たす場合は、「ステップ 2：Spring Cloud Gateway 構成の移行」に進むことができます。

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

ご利用の構成が次のいずれかのシナリオに該当する場合は、対応する移行手順を実行してクラウドネイティブゲートウェイに接続してください：

自己管理レジストリ
1. MSE Nacos レジストリを購入します。詳細については、「Nacos エンジンの作成」をご参照ください。
2. 構成またはコードを変更して、サービスを MSE Nacos インスタンスに登録します。詳細については、「Java SDK」をご参照ください。
3. オプション： Java アプリケーションがある場合は、Microservices Engine (MSE) ガバナンスエージェントを使用してレジストリを移行できます。詳細については、「MSE Sync を使用したサービスレジストリの移行」をご参照ください。
Enterprise Distributed Application Service (EDAS) の共有レジストリ

クラウドネイティブゲートウェイは EDAS レジストリをサポートしています。レジストリをサービスソースとして直接追加できます。詳細については、「サービスソースの追加」をご参照ください。
Serverless App Engine (SAE) の共有レジストリ

クラウドネイティブゲートウェイは SAE レジストリをサポートしています。レジストリをサービスソースとして直接追加できます。詳細については、「サービスソースの追加」をご参照ください。

ステップ 2：Spring Cloud Gateway 構成の移行

以下は、Spring Cloud Gateway の構成例です：

関連付けられたレジストリ

spring:
  application:
    name: gateway-demo
  cloud:
    nacos:
      discovery:
        server-addr: nacos-server:8848
      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:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.WeightedResponseTimeRule
    ConnectTimeout: 1000
    ReadTimeout: 8000
    MaxAutoRetries: 3
    MaxAutoRetriesNextServer: 2
    MaxTotalConnections: 20000
    MaxConnectionsPerHost: 5000
hystrix:
  command:
    service-a:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 60000
          strategy: SEMAPHORE
          semaphore:
            maxConcurrentRequests: 60000

以下のセクションでは、Spring Cloud Gateway の設定を MSE コンソールでの操作にマッピングする方法を示します：

レジストリ構成のマッピング

クラウドネイティブゲートウェイでは、レジストリ接続をサービスソースとして管理します。 MSE コンソールでサービスソースを作成し、サービスに関連付けて動的なリアルタイム更新を行うことができます。詳細については、「サービスソースの追加」をご参照ください。 [サービスソースの追加] ダイアログボックスで、[ソースタイプ] を MSE Nacos に設定し、対応する [クラスター名] を選択し、[レジストリタイプ] に NACOS と入力し、[レジストリアドレス] を指定します。前提条件: パラメータ設定で、MCPEnabled を true に設定する必要があります。構成が完了したら、[OK] をクリックします。
サービス関連付けのマッピング
1. サブスクライブしたいサービスをインポートしてサービスを追加します。詳細については、「サービスの追加」をご参照ください。
2. 追加された各サービスに適切なバージョンを設定します。詳細については、「サービスバージョンの管理」をご参照ください。
```
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：トラフィックの移行

以下は、クライアントトラフィックを移行するためのいくつかの戦略です：

反復的なクライアント移行：いくつかのビジネスシナリオを選択し、そのアクセスアドレスを変更してから、移行を検証します。
プロキシレイヤーでの段階的なカナリアリリース：既存のプロキシレイヤーで、段階的な変更計画を作成します。コアサービスと非コアサービスの区分に基づいて、トラフィックを徐々に新しいアドレスに切り替えます。
DNS 解決による完全な切り替え：十分なカナリアテストの後、DNS レコードを新しいクラウドネイティブゲートウェイのエンドポイントアドレスに切り替えます。
(推奨) 段階的な移行：
1. 受け入れテストのためにいくつかのビジネスシナリオを選択します。
2. 反復的なカナリアリリースを通じて、コアシナリオのトラフィックを徐々に移行します。
3. ストレステストが成功した後、DNS レコードを切り替えて完全移行を実行します。

移行戦略	コスト	リスク
反復的なクライアント移行	高	低
プロキシレイヤーでの段階的なカナリアリリース	中	中
DNS 解決による完全な切り替え	低	高
段階的な移行	比較的低い	比較的低い

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