Spring Cloud Gateway から MSE クラウドネイティブゲートウェイへのシームレスな移行 - MSE

Kubernetes 上の Spring Cloud Gateway は、コンテナサービスをネイティブに検出できず、NGINX Ingress ゲートウェイと比較してパフォーマンスが劣り、可観測性およびセキュリティのためのカスタム開発を必要とします。クラウド移行およびハイブリッドクラウドのシナリオでは、この制約により、Ingress と Spring Cloud Gateway の 2 レイヤー構成が生じ、ネットワークホップ数、リソース消費量、運用・保守（O&M）コストが増加します。

Microservices Engine (MSE) クラウドネイティブゲートウェイは、トラフィックゲートウェイとマイクロサービスゲートウェイを単一レイヤーに統合し、高いパフォーマンス、高度な統合性、すぐに使える機能を提供することで、サービスコストを大幅に削減できます。本ガイドでは、Spring Cloud Gateway のルーティングルール、サービスソース、認証、およびトラフィックを MSE クラウドネイティブゲートウェイへ移行するための 5 つのステップを順に説明します。

Spring Cloud Gateway とクラウドネイティブゲートウェイの対応関係

移行を開始する前に、Spring Cloud Gateway の主要な概念がクラウドネイティブゲートウェイにおいてどのように対応付けられるかを確認してください。

Spring Cloud Gateway	クラウドネイティブゲートウェイ	補足説明
Nacos レジストリ	サービスソース	クラウドネイティブゲートウェイは、設定済みのサービスソース（Nacos、ACK、EDAS、または SAE）からサービス一覧をプルします。
`spring.cloud.gateway.routes`	ルーティングルール	YAML ファイルではなく、MSE コンソールでルートを定義します。各ルーティングルールは、パス条件をバックエンドサービスにマップします。
ルート条件（`Path=`）	ルート一致条件	パス一致をサポートします。
`uri: lb://service-a`	バックエンドサービス＋バージョン	サービスソースからインポートしたサービスを選択し、対象バージョンを設定します。
Ribbon 負荷分散ルール	負荷分散ポリシー	MSE コンソールのサービス設定から設定します。
Hystrix サーキットブレーカー	ルートレベルポリシー	クラウドネイティブゲートウェイは、各ルートに対してスロットリング、タイムアウトなどのポリシーを提供します。
`AddResponseHeader` フィルター	ヘッダー設定ポリシー	MSE コンソールでルートレベルポリシーとして設定します。
カスタム認証フィルター	JWT / OIDC / IDaaS / カスタム認証	認証プラグインがカスタムフィルターコードを置き換えます。

前提条件

移行を開始する前に、以下の条件を満たしていることを確認してください。

MSE コンソールでクラウドネイティブゲートウェイが作成済みであること。詳細については、「クラウドネイティブゲートウェイの作成」をご参照ください。
クラウドネイティブゲートウェイの基本概念に慣れていること。詳細については、「クラウドネイティブゲートウェイの詳細情報」をご参照ください。
現在の Spring Cloud Gateway 構成ファイル（application.yml、bootstrap.yml、および Nacos や Git に外部化された構成）のバックアップが取得済みであること。

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

クラウドネイティブゲートウェイは、バックエンドサービスを検出するためにサービスソースを必要とします。環境に応じて、既に互換性のあるソースが利用可能である場合や、新たに設定が必要な場合があります。

このステップをスキップする場合

以下のいずれかに該当する場合は、ステップ 2 に進んでください。

Container Service for Kubernetes (ACK) を使用しており、Kubernetes のサービス検出機能が有効になっている場合
MSE Nacos インスタンスを使用しており、Mesh Configuration Protocol（MCP）をサポートするバージョンへアップグレード済みの場合
サービス検出メカニズムを一切使用せず、ドメイン名または固定 IP アドレスに依存している場合

レジストリタイプ別にサービスソースを設定

現在使用中のレジストリに該当するオプションを選択してください。

MSE Nacos インスタンス

MSE Nacos インスタンスを購入します。詳細については、「Nacos エンジンの作成」をご参照ください。
アプリケーションの構成またはコードを更新して、サービスを MSE Nacos インスタンスに登録します。詳細については、「Nacos Java SDK ドキュメント」をご参照ください。
（任意）Java アプリケーションの場合、MSE のマイクロサービスガバナンスエージェントを使用して、登録移行を自動化できます。詳細については、「MSE Sync を活用した移行ソリューション」をご参照ください。

Enterprise Distributed Application Service (EDAS) レジストリ

EDAS レジストリを直接サービスソースとして追加します。詳細については、「サービスソースの追加」をご参照ください。

Serverless App Engine (SAE) レジストリ

SAE レジストリを直接サービスソースとして追加します。詳細については、「サービスソースの追加」をご参照ください。

サービスソースの検証

サービスソースを追加した後、MSE コンソールを開き、クラウドネイティブゲートウェイに移動します。サービスソースがサービスソース一覧に表示され、正常に動作していることを確認してください。

ステップ 2：ルーティングおよびサービス構成の移行

Spring Cloud Gateway の YAML 構成を、MSE コンソール上のクラウドネイティブゲートウェイ設定に変換します。以下に、代表的な構成例と、各セクションがコンソール上でどのように対応するかを示します。

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

各構成セクションの移行手順

以下の操作を MSE コンソールで実行します。

1. レジストリ連携設定をサービスソースに置き換え

spring.cloud.nacos.discovery ブロックは、ステップ 1 で設定したサービスソースに置き換えられます。追加の操作は不要です。

2. バックエンドサービスのインポート

ルートで参照されている各バックエンドサービス（例： service-a）をインポートします。

MSE コンソールで、クラウドネイティブゲートウェイに移動し、サービスソースからサービスをインポートします。詳細については、「サービスの追加」をご参照ください。
各インポート済みサービスに対して適切なバージョンを設定します。詳細については、「サービスバージョンの管理」をご参照ください。

Ribbon 負荷分散設定および Hystrix サーキットブレーカー設定（WeightedResponseTimeRule、ConnectTimeout、ReadTimeout、リトライおよび同時実行数制限など）は、クラウドネイティブゲートウェイのサービスおよびルートポリシーに対応します。これらの設定はコンソールから行います。

3. ルーティングルールの作成

各ルートエントリをクラウドネイティブゲートウェイのルーティングルールに変換します。詳細については、「ルーティングルールの作成」をご参照ください。

上記の例では、以下の 2 つのルーティングルールを作成します。

Spring Cloud Gateway のルート	クラウドネイティブゲートウェイのルート
`websocket_test`：パス `/echo` → `ws://localhost:9000`	パスマッチ: `/echo`、バックエンド: `localhost:9000`
`default_path_to_service-a`：パス `/sleep` → `lb://service-a`	パス一致：`/sleep`、バックエンド：`service-a`（サービスソースからインポート済み）

4. ルートレベルポリシーの設定

Spring Cloud Gateway の default-filters（例：AddResponseHeader）は、クラウドネイティブゲートウェイのルートレベルポリシーに対応します。必要に応じて、以下のポリシーを設定します。

ルーティング構成の検証

ルーティングルールを作成した後、各移行済みルートについて、クラウドネイティブゲートウェイのエンドポイントに対してテストリクエストを送信します。リクエストが正しいバックエンドサービスに到達し、期待される応答が返されることを確認してください。

# /echo WebSocket ルートのテスト
curl -v http://<cloud-native-gateway-endpoint>/echo

# /sleep ルートのテスト
curl -v http://<cloud-native-gateway-endpoint>/sleep

ステップ 3：認証の設定

Spring Cloud Gateway でカスタム認証フィルターを使用している場合、クラウドネイティブゲートウェイの認証方式に置き換えます。ID プロバイダーに応じて、適切な方法を選択してください。

認証の検証

認証を設定した後、有効な認証情報を含まないリクエストを送信し、ゲートウェイが 401 Unauthorized 応答を返すことを確認します。次に、有効な認証情報を含むリクエストを送信し、バックエンドサービスに到達することを確認します。

# 401 Unauthorized が返されることを期待
curl -v http://<cloud-native-gateway-endpoint>/sleep

# 有効なトークン付きで 200 OK が返されることを期待
curl -v -H "Authorization: Bearer <valid-token>" http://<cloud-native-gateway-endpoint>/sleep

ステップ 4：可観測性の設定

クラウドネイティブゲートウェイは、モニタリング、アラート機能、ログ配布、トレーシング分析を提供し、Spring Cloud Gateway で通常必要となるカスタム統合を代替します。要件に応じて、必要な機能を有効化してください。

可観測性の検証

モニタリングおよびログ配布を有効化した後、テストトラフィックを生成します。ゲートウェイのダッシュボードにメトリックが表示され、ログが指定の送信先に届いていることを確認してください。

ステップ 5：トラフィックの移行

ルーティングルール、認証、および可観測性の設定が完了したら、Spring Cloud Gateway からクラウドネイティブゲートウェイへ本番トラフィックを移行します。コストとリスクのバランスに応じて、以下の 4 つの移行戦略から選択できます。

戦略	コスト	リスク	説明
反復的移行	高	低	呼び出し元またはクライアント側で、少数のサービスのアクセス URL を段階的に変更します。各バッチの検証を完了してから次のバッチに進みます。
プロキシ側での段階的移行	中	中	元のプロキシでサービスをコア／非コアに分類し、非コアサービスを先に移行し、その後コアサービスを移行します。
DNS を使用した完全移行	低	高	元のドメイン名を直接クラウドネイティブゲートウェイのアクセス URL に指向させます。すべてのトラフィックが一度に切り替わります。
手順型移行（推奨）	比較的低	比較的低い	上記戦略を構造的に組み合わせたもの。以下の推奨手順をご参照ください。

推奨手順

構成のバックアップを取得します。 Spring Cloud Gateway のすべての構成ファイル（application.yml、bootstrap.yml、および外部化された構成）のコピーが存在することを確認します。このバックアップはロールバック時のベースラインとなります。
小規模なバッチでテストします。 重要度の低い少数のサービスをクラウドネイティブゲートウェイに移行し、ルーティング、認証、応答動作を検証します。
コアサービスを逐次移行します。 テストバッチの検証が完了したら、コアサービスを 1 つずつ順次移行します。各サービスの移行後に、ゲートウェイのダッシュボードでエラー率およびレイテンシーを監視します。
負荷テストを実施します。 全トラフィックの切り替え前に、クラウドネイティブゲートウェイに対して負荷テストを実行し、想定スループットを処理できることを確認します。
DNS を使用した完全移行を実施します。 元のドメイン名をクラウドネイティブゲートウェイのアクセス URL に関連付けて、残りのすべてのトラフィックを切り替えます。
元のゲートウェイを稼働状態に維持します。 ロールバック期間中、Spring Cloud Gateway のデプロイメントを維持します。問題が発生した場合は、DNS レコードを元のゲートウェイに戻すことでロールバックできます。

ロールバック

トラフィックの切り替え後に問題が発生した場合は、DNS レコードを Spring Cloud Gateway に戻すことでロールバックできます。移行中は元の構成およびサービス登録がそのまま維持されるため、ロールバックには DNS 変更のみが必要です。

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