Enterprise Distributed Application Service:複数アプリケーションを含む Spring Cloud クラスターを EDAS へスムーズに移行

EDAS への移行理由

EDAS は、自社管理型の Spring Cloud インフラストラクチャーに伴う運用負荷を、マネージドプラットフォームへ置き換えます。移行後には以下のメリットがあります。

• 柔軟なデプロイメント — スタートアップパラメーターの設定、デプロイメント進捗の視覚的追跡、およびリクエストの切断を回避するグレースフルなサービス接続・切断機能を活用できます。

• 組み込みのサービス検出 — EDAS の商用リリースには、サービス検出および構成管理機能が標準搭載されており、自社管理の Eureka、ZooKeeper、Consul を置き換えます。

• 集中型サービス管理 — EDAS コンソールから、公開済みおよび消費済みのサービスを照会できます。インスタンス情報の照会に加え、マイクロサービスのトレース、システムコールトポロジー、スロークエリ分析も利用可能です。

• 自動スケーリング — トラフィック量に応じて、アプリケーションインスタンスを動的に増減できます。

• 段階的リリース — 全インスタンスへの更新適用前に、小規模な検証を目的としたエンドツーエンドの段階的リリースを実行できます。

• 速度制限およびサービス低下 — 高負荷時におけるアプリケーションの安定性を維持するために、速度制限およびサービス低下を適用できます。

移行方法の選択

EDAS では、サービス継続性を保ったまま移行できる 2 種類の方法をサポートしています。

レジストリ切り替え を選択する場合は、「サービス登録およびサービス検出の実装」の標準セットアップに従ってください。本ガイドの残りの部分では、デュアル登録およびデュアルサブスクリプション について説明します。

移行の概要

移行は、以下の 3 つのフェーズで構成されます。

1. アプリケーションの移行（必須） — ステートレスアプリケーションを最初に、1 つずつ移行します。

2. Server Load Balancer (SLB) インスタンスの移行または DNS の更新（任意） — トラフィックを新しいデプロイ先へ向けるための設定です。

3. ストレージおよびメッセージキューの移行（任意） — アプリケーションが既に ApsaraDB RDS や Message Queue などの Alibaba Cloud サービスを利用している場合は、このステップは不要です。

本ガイドでは、フェーズ 1 に焦点を当てます。

フェーズ 1：アプリケーションの移行

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    <version>{Version}</version>
</dependency>

spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
ribbon.nacos.enabled=false

<dependency>
    <groupId>com.alibaba.edas</groupId>
    <artifactId>edas-sc-migration-starter</artifactId>
    <version>1.0.5</version>
</dependency>

@SpringBootApplication
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
}

@SpringBootApplication
@RibbonClients(defaultConfiguration = MigrationRibbonConfiguration.class)
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
}

フェーズ 2：SLB インスタンスの移行または DNS の更新（任意）

すべてのアプリケーションの移行が完了したら、ネットワークルーティングを更新します。

• 移行前に SLB インスタンスを使用していた場合、再利用します」をご参照ください。

• SLB インスタンスを使用していなかった場合、新規に作成し、エントリーポイントアプリケーション（例：API Gateway）にバインドします。

• ドメイン名の設定：

  • SLB インスタンスを再利用する場合は、DNS の変更は不要です。

  • 新規 SLB インスタンスを作成する場合は、DNS を更新して新規 SLB インスタンスを指すようにし、旧インスタンスを削除します。「ドメイン名の DNS サーバーの変更」をご参照ください。

フェーズ 3：ストレージおよびメッセージキューの移行（任意）

アプリケーションが既に ApsaraDB RDS や Message Queue などの Alibaba Cloud サービスを利用している場合は、ストレージおよびメッセージキューの移行は不要です。

アプリケーションが Alibaba Cloud 上にない場合は、EDAS テクニカルサポートまでお問い合わせください。完全な移行計画をご提供いたします。

登録およびサブスクリプションポリシーの動的調整

移行中、アプリケーションが登録またはサブスクライブするレジストリを、再起動せずに動的に調整できます。EDAS の構成管理機能、Spring Cloud Config、または Nacos Config を使用して、以下のプロパティをランタイムで更新します。

# Eureka および Nacos の両方をサブスクライブ
spring.cloud.edas.migration.subscribes=nacos,eureka

# Nacos のみをサブスクライブ
spring.cloud.edas.migration.subscribes=nacos

# すべてのレジストリに登録（デフォルト）
spring.cloud.edas.migration.registry.excludes=

# Eureka への登録を停止
spring.cloud.edas.migration.registry.excludes=eureka

# Nacos および Eureka の両方への登録を停止
spring.cloud.edas.migration.registry.excludes=nacos,eureka

移行後のクリーンアップ

すべてのアプリケーションが EDAS 上で正常に稼働している状態になったら、移行専用の構成を削除します。

1. 各アプリケーションの pom.xml（または build.gradle）から edas-sc-migration-starter 依存関係を削除します。

2. メインクラスから @RibbonClients(defaultConfiguration = MigrationRibbonConfiguration.class) アノテーションを削除します。

3. 元のサービスレジストリの依存関係および構成（例：Eureka や Consul クライアント設定）を削除します。

4. ribbon.nacos.enabled=false を application.properties から削除します。

5. 非ピーク時間帯に、アプリケーションをバッチ単位で再起動します。

デモプロジェクト

EDAS では、デュアル登録およびデュアルサブスクリプションを実証するサンプルプロジェクトを提供しています。プロジェクトをダウンロードし、付属の README を参照してローカルで実行してください。