すべてのプロダクト
Search
ドキュメントセンター

Serverless App Engine:アプリケーション移行

最終更新日:Sep 28, 2025

アプリケーションが本番環境にデプロイされ、期待どおりに実行されている場合は、Serverless App Engine (SAE) にスムーズに移行できます。これにより、業務継続性が確保され、データ損失を防ぐことができます。

SAE にアプリケーションを移行する理由

  • SAE は、柔軟な起動パラメーター構成、視覚化されたデプロイプロセス、グレースフルなリリースとシャットダウン、段階的リリースなど、アプリケーションのリリースプロセスの構成、クエリ、および管理に使用できる複数の機能を提供します。

  • 商用リリース後、SAE はサービスディスカバリと構成管理機能を提供します。 Eureka、ZooKeeper、Consul などのミドルウェアを維持する必要はありません。

  • SAE コンソールでサービスを一元的に管理できます。これにより、リリースおよび消費されたサービスの詳細をクエリできます。

  • SAE は自動スケーリング機能を提供します。トラフィックの変動に基づいて、アプリケーションのインスタンスを動的にスケールインおよびスケールアウトできます。

  • SAE は高度な監視機能を提供します。インスタンスの基本情報、マイクロサービストレース、システムコールトポロジ、低速 SQL クエリをクエリできます。

  • SAE は、Spring Cloud アプリケーションの高可用性を確保するために、スロットリングとデグレード機能を提供します。

  • SAE は、エンドツーエンドのカナリアリリース機能を提供します。アプリケーションの反復中に、少数の Spring Cloud アプリケーションでカナリアリリースを実行して新しいバージョンをテストできます。

スムーズな移行とは

たとえば、Spring Cloud クラスタとクラスタ内のアプリケーションが本番環境にデプロイされ、期待どおりに実行されているとします。 すべての SAE 機能にアクセスするためにクラスタを SAE に移行する場合、スムーズな移行方法を使用してビジネスの継続性を確保できます。

説明

Spring Cloud クラスタが本番環境にデプロイされていない場合、またはダウンタイムの移行が許容される場合は、オンプレミス環境でアプリケーションを開発し、SAE にデプロイできます。 詳細については、以下のトピックをご参照ください。

移行プロセス

  1. アプリケーションの移行

    ほとんどの場合、移行されるアプリケーションはステートレスであり、最初に移行する必要があります。

  2. オプション: Server Load Balancer (SLB) インスタンスの移行またはドメイン名設定の変更

    アプリケーションの移行後、アプリケーションにバインドされている SLB インスタンスを移行するか、ドメイン名設定を変更する必要があります。

    • SLB インスタンス

      • 移行前に SLB インスタンスが使用されている場合は、移行後に SLB インスタンスを再利用できます。ビジネス要件に基づいて、SLB インスタンスをアプリケーションにバインドする方法を選択できます。 詳細については、「CLB インスタンスをアプリケーションにバインドし、アプリケーションのパブリックまたはプライベート IP アドレスを生成する」をご参照ください。

      • 移行前に SLB インスタンスが使用されていない場合は、前の図に示すように、移行後に SLB インスタンスを作成し、API ゲートウェイなどのイングレスアプリケーションにバインドすることをお勧めします。

      • アプリケーションを移行する場合は、Elastic Compute Service (ECS) の使用コストを削減するために、デュアル登録とデュアルサブスクリプションを有効にすることをお勧めします。 特定の原因(たとえば、ECS インスタンスに構成されている元のポートが使用されている)により既存の ECS インスタンスを使用できない場合は、トラフィック分割移行ソリューションを使用して新しい ECS インスタンスを追加する必要があります。 アプリケーションの移行後、ビジネス要件に基づいて、既存の SLB インスタンスを再利用するか、SLB インスタンスを作成して移行済みアプリケーションにバインドします。

    • ドメイン名

      • 移行後に SLB インスタンスを再利用できる場合は、ドメイン名を変更する必要はありません。

      • SLB インスタンスを作成して移行済みアプリケーションにバインドする場合は、ドメイン名設定に新しい SLB インスタンスを追加する必要があります。 詳細については、「ドメイン名の DNS サーバを変更する」をご参照ください。 また、不要になった SLB インスタンスを削除する必要があります。

  3. オプション: ストレージとメッセージキューの移行

    • アプリケーションが Alibaba Cloud にデプロイされており、ApsaraDB RDS や Message Queue などの Alibaba Cloud サービスを使用している場合は、ストレージまたはメッセージキューを移行する必要はありません。

    • アプリケーションが Alibaba Cloud にデプロイされていない場合は、DingTalk グループ (ID: 32874633) に参加してテクニカルサポートを受けてください。

移行ソリューション

トラフィック分割、デュアル登録とデュアルサブスクリプションのいずれかのソリューションを使用して、アプリケーションを移行できます。 どちらのソリューションも、ビジネスを中断することなく、スムーズなアプリケーション移行を保証します。 このセクションでは、デュアル登録とデュアルサブスクリプションの移行ソリューションについて説明します。

  • トラフィック分割

    Dubbo を使用して元のサービスレジストリを SAE Config Server に切り替え、新しいアプリケーションセットを開発し、SAE にデプロイします。 次に、SLB を使用してドメイン名を設定し、トラフィックを切り替えます。

    トラフィック分割移行ソリューションのアプリケーション開発については、「マイクロサービスシナリオの概要」をご参照ください。

  • デュアル登録とデュアルサブスクリプション

    デュアル登録とデュアルサブスクリプションソリューションとは、移行中に元のサービスレジストリと SAE サービスレジストリの両方にアクセスすることを指します。 これにより、移行済みアプリケーションと移行されていないアプリケーションが相互に呼び出すことができます。

    次の図は、デュアル登録とデュアルサブスクリプションの移行ソリューションのアーキテクチャを示しています。

    デュアル登録とデュアルサブスクリプションの移行ソリューションには、次の利点があります。

    • 移行済みアプリケーションと移行されていないアプリケーションは、相互に検出して呼び出すことができます。 これにより、ビジネスの継続性が確保されます。

    • 依存関係を追加し、少量のコードを変更するだけで、デュアル登録とデュアルサブスクリプションを実装できます。

    • コンシューマーサービス呼び出しの詳細を表示し、移行の進行状況をリアルタイムで表示できます。

    • アプリケーションを繰り返し再起動することなく、サービスの登録とサブスクリプションのポリシーを動的に変更できます。 移行プロセスでは、アプリケーションを1回だけ再起動する必要があります。

関連情報

さまざまなアーキテクチャのマイクロサービスアプリケーションを移行する方法の詳細については、以下のトピックをご参照ください。