Alibaba Cloud 上で実行中の Spring Cloud クラスターを、ライブトラフィックを中断することなく Serverless App Engine (SAE) に移行します。本トピックでは、デュアル登録およびデュアルサブスクリプション方式について説明します。この方式では、カットオーバーが完了するまで、移行済みアプリケーションと未移行アプリケーションが同じサービスメッシュ内で共存します。アプリケーションは移行プロセス全体を通じて 1 回のみ再起動されます。
動作可能なデモは、sc-migration-examples.zip から入手できます。
事前準備
移行を開始する前に、以下のチェックリストを確認してください。障害要因を早期に特定することで、ロールバックが必要な不完全な移行を回避できます。
| チェック項目 | 条件を満たさない場合の対応 |
|---|---|
| すべてのアプリケーションが Spring Cloud サービス検出 (Eureka または Consul) を使用していること | サービス検出をバイパスして IP アドレスまたはホスト名で直接サービスを呼び出すアプリケーションは、本方式を使用できません。移行前に該当クライアントを更新してください。 |
| ECS インスタンスのポートが使用可能であること(他のプロセスによって占有されていないこと) | ポートが占有されている場合は、代わりにトラフィック分割ソリューションをご利用ください。 |
| アプリケーションがステートレスであること | ステートフルなアプリケーションの場合は、状態の移行に関する追加の計画が必要です。 |
| ストレージおよびメッセージングに Alibaba Cloud サービス (ApsaraDB RDS、メッセージキュー) を使用していること | Alibaba Cloud 外部のストレージおよびメッセージングを使用している場合は、別途調整が必要です。テクニカルサポートについては、DingTalk グループ 32874633 にご参加ください。 |
移行の概要

移行は以下の 3 つのフェーズで構成されます。
| フェーズ | 手順 | 必須 |
|---|---|---|
| 移行 | ステップ 1:アプリケーションの移行 | 必須 |
| 移行後 | ステップ 2:SLB の移行または DNS の更新 | 任意 |
| 移行後 | ステップ 3:ストレージおよびメッセージキューの移行 | 任意 |
移行ソリューションの選択
ゼロダウンタイム移行を実現するためのソリューションは以下の 2 つがあります。
| ソリューション | 仕組み | 適用条件 |
|---|---|---|
| デュアル登録およびデュアルサブスクリプション(本トピック) | アプリケーションを元のレジストリと Nacos の両方に同時に登録します。移行済みアプリケーションと未移行アプリケーションは、移行プロセス全体を通じて相互に検出可能です。 | ECS ポートが使用可能な場合にご利用ください。アプリケーションの再起動は 1 回のみ必要です。 |
| トラフィック分割 | Spring Cloud Alibaba を介してレジストリを Nacos に切り替え、SAE 上に新しいアプリケーションセットをデプロイした後、Server Load Balancer (SLB) およびドメイン名を使用してトラフィックをリダイレクトします。 | ECS ポートが占有されており、インスタンスを再利用できない場合にご利用ください。 |
トラフィック分割ソリューションについては、「アプリケーションのサービス登録および検出を Nacos に変更する」をご参照ください。
デュアル登録およびデュアルサブスクリプションの仕組み
以下の図は、各移行ステージにおけるシステムの状態を示しています。
初期状態
ステージ 1
ステージ 2
ステージ 3
ステージ 4
主な特徴:
移行済みアプリケーションと未移行アプリケーションが相互に検出し、呼び出すことで、業務継続性を確保します。
必要なコード変更は、依存関係を 2 つ追加し、メインクラスにアノテーションを 1 つ付与するだけです。
コンシューマーサービスの呼び出しをモニタリングし、SAE で移行の進捗をリアルタイムに追跡できます。
SAE の構成管理機能により、登録およびサブスクリプションポリシーを動的に制御できます。アプリケーションの再起動は不要で、移行プロセス全体で 1 回のみ再起動されます。
ステップ 1:最初のアプリケーションを移行する
1. アプリケーションの選定
上流の依存関係を持たない基盤となるプロバイダーサービスから開始します。呼び出しトレースが複雑でマッピングが困難な場合は、任意のアプリケーションから開始してもかまいません。
2. 依存関係の追加と構成の更新
a. Nacos 検出依存関係の追加
pom.xml に spring-cloud-starter-alibaba-nacos-discovery を追加します。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
<version>{Version}</version>
</dependency>b. Nacos サーバーアドレスの構成
application.properties に以下の内容を追加します。
spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848c. マルチレジストリ移行依存関係の追加
デフォルトでは、Spring Cloud は 1 つのレジストリしか許可しません。2 番目のレジストリを追加するとエラーが発生します。edas-sc-migration-starter 依存関係を追加することで、この制限が解除され、複数のレジストリへの同時登録が可能になります。
pom.xml に以下を追加します。
<dependency>
<groupId>com.alibaba.edas</groupId>
<artifactId>edas-sc-migration-starter</artifactId>
<version>1.0.2</version>
</dependency>3. RibbonClients 構成の更新
複数のレジストリからサービスをサブスクライブするには、メインクラスで @RibbonClients を設定し、MigrationRibbonConfiguration を使用するようにします。
変更前:
@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);
}
}これらの変更をデプロイした後(オンプレミスまたは SAE 上)は、アプリケーションの再起動を行わずに、Spring Cloud Config または Nacos Config を使用して、アプリケーションが登録またはサブスクライブするレジストリを制御できます。詳細については、「サービス登録およびサブスクリプションポリシーの動的調整」および「アプリケーション構成の管理」をご参照ください。
4. SAE 上へのアプリケーションデプロイ
要件に応じてアプリケーションをデプロイします。詳細については、「アプリケーションのデプロイ」をご参照ください。
5. 移行の検証
以下のいずれかの方法を使用します。
オプション 1:ビジネス動作の確認
デプロイ後にビジネスが期待通りに動作することを確認します。
オプション 2:サービスサブスクリプションモニタリングの確認
Spring Boot Actuator が有効になっている場合、以下のエンドポイントにアクセスして、各サブスクライブされたサービスの RibbonServerList を確認できます。metaInfo 内の serverGroup フィールドに、ノードが属するレジストリが表示されます。
| Spring Boot バージョン | エンドポイント |
|---|---|
| 1.x | http://ip:port/dubboRegistry |
| 2.x | http://ip:port/actuator/dubboRegistry |

ステップ 2:他のアプリケーションを移行する
ステップ 1 と同じ手順に従い、残りのすべてのアプリケーションを順次 SAE に移行します。
移行後:クリーンアップと完了処理
移行用依存関係の削除
すべてのアプリケーションが SAE 上に移行されたら、元のレジストリ構成および edas-sc-migration-starter 依存関係を削除します。
edas-sc-migration-starter は移行専用の依存関係です。そのまま残してもサービスの安定性には影響しませんが、Ribbon の負荷分散効果が制限されます。移行完了後は依存関係を削除し、オフピーク時間帯にバッチ単位でアプリケーションを再起動してください。
SLB の移行または DNS 設定の更新
アプリケーションの移行後、SLB インスタンスおよびドメイン名の構成を処理します。
SLB インスタンス
| シナリオ | アクション |
|---|---|
| 移行前に SLB が存在していました | 再利用します。バインドの詳細については、「CLB インスタンスをアプリケーションにバインドし、パブリックまたはプライベート IP アドレスを生成する」をご参照ください。 |
| 移行前に SLB が存在しなかった場合 | SLB インスタンスを作成し、イングレスアプリケーション(例:API ゲートウェイ)にバインドします。 |
| ECS ポートが占有されている場合 | トラフィック分割ソリューションをご利用ください。新しい ECS インスタンスを追加し、既存の SLB を再利用するか、新しい SLB を作成します。 |
ドメイン名
| シナリオ | アクション |
|---|---|
| SLB を再利用する場合 | ドメイン名の変更は不要です。 |
| 新規 SLB 作成 | 新しい SLB をドメイン名設定に追加し、古いエントリを削除します。「DNS サーバの更新」をご参照ください。 |
ストレージおよびメッセージキューの移行
アプリケーションが ApsaraDB RDS やメッセージキューなどの Alibaba Cloud サービスを使用している場合、ストレージおよびメッセージキューの移行は不要です。アプリケーションが Alibaba Cloud 上にデプロイされていない場合は、テクニカルサポートのために DingTalk グループ 32874633 にご参加ください。
サービス登録およびサブスクリプションポリシーを動的に調整する
SAE の構成管理機能を使用して、移行中の任意のタイミングで登録およびサブスクリプションポリシーを調整できます。アプリケーションの再起動は不要です。
サブスクリプションポリシーの調整
デフォルトでは、SAE は関連するすべてのレジストリからサービスデータをサブスクライブおよび集約します。
特定のレジストリからのみサブスクライブするには、spring.cloud.edas.migration.subscribes プロパティを設定します。
# Eureka および Nacos の両方からサービスをサブスクライブ
spring.cloud.edas.migration.subscribes=nacos,eureka
# Nacos のみからサービスをサブスクライブ
spring.cloud.edas.migration.subscribes=nacos登録ポリシーの調整
デフォルトでは、SAE は関連するすべてのレジストリに登録します。
特定のレジストリへの登録を除外するには、spring.cloud.edas.migration.registry.excludes プロパティを設定します。
# すべてのレジストリに登録(デフォルト — 空欄のまま)
spring.cloud.edas.migration.registry.excludes=
# Eureka への登録のみ無効化
spring.cloud.edas.migration.registry.excludes=eureka
# Nacos および Eureka への登録を無効化
spring.cloud.edas.migration.registry.excludes=nacos,eurekaSAE の構成管理機能を使用して、アプリケーションを再起動せずにランタイムでこのプロパティを更新できます。