すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:Apr 10, 2025

    マイクロサービスフレームワークの選択は、クラウドネイティブテクノロジーの発展とともに進化しています。クラウド時代において、Kubernetes は O&M システムを再構築します。Zuul ゲートウェイはコンテナサービスディスカバリをサポートしておらず、NGINX Ingress ゲートウェイと比較してパフォーマンスが劣ります。可観測性とセキュリティの面では、Zuul ゲートウェイはカスタム開発と統合が必要です。これらの欠点は、Zuul ゲートウェイの技術開発を制限します。クラウドネイティブゲートウェイは、従来のトラフィックゲートウェイとマイクロサービスゲートウェイを統合することで開発されています。クラウドネイティブゲートウェイは、サービスコストの削減に役立ち、高パフォーマンス、高統合、そしてすぐに使えるという利点があります。このトピックでは、Zuul ゲートウェイからクラウドネイティブゲートウェイにサービスを移行する方法について説明します。

    前提条件

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

    次のいずれかの条件が満たされている場合は、手順 2：Zuul ゲートウェイの構成の移行に直接進んでください。

    • 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：Zuul ゲートウェイの構成の移行

    Zuul ゲートウェイの構成例：

    • 関連付けられたレジストリの構成

      spring:
  application:
    name: zuul-demo
  cloud:
    nacos:
      discovery:
        server-addr: nacos-server:8848
      config:
        enabled: false

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

      zuul:
  routes:
    demo:
      path: /test/a
      serviceId: service-a
    pre:
      path: /auth/validation/**
      serviceId: service-a
    header:
      path: /auth/test
      requestHeadersToAdd:
      - key: debug_tag
        value: true
    retry:
      path: /app/try/**
      stripPrefix: false
      retryable: true
      serviceId: service-a
  retryable: true
  ignoredPatterns:
  - /login/api/a/v3/a
  - /auth/api/b
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 コンソールで Zuul ゲートウェイの構成を移行するには、次の操作を実行します。

    • レジストリ関連の操作

      クラウドネイティブゲートウェイは、サービスソースを使用してレジストリを関連付けます。MSE コンソールを使用してサービスソースを追加し、サービスソースをサービスに関連付けることができます。構成はリアルタイムで有効になります。サービスソースを追加する方法の詳細については、サービスソースの追加をご参照ください。

    • サービスの関連付け操作

      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：トラフィックの移行

    呼び出し元側でのトラフィック移行の手順:

    • 呼び出し元側またはクライアント側での反復移行: いくつかのサービスのアクセス URL を変更して、移行結果を確認できます。

    • プロキシ側での段階的移行: サービスの種類に基づいて、元のプロキシ側に移行ステップを作成できます。たとえば、コアサービスと非コアサービスに対して個別に移行ステップを作成できます。その後、アクセス URL に基づいてサービスを段階的に移行できます。

    • DNS ベースの完全移行: 段階的移行が完了したら、元のドメイン名をクラウドネイティブゲートウェイのアクセス URL に関連付けることができます。

    • (推奨) 手順による移行:

      1. テストとしていくつかのサービスを移行し、移行結果を確認します。

      2. コアサービスを順番に移行します。

      3. ストレステストが完了したら、DNS ベースの完全移行を実行します。

    移行ソリューション

    コスト

    リスク

    反復移行

    高

    低

    プロキシ側での段階的移行

    中

    中

    DNS ベースの完全移行

    低

    高

    手順による移行

    比較的低

    比較的低

    リファレンス

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