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

Serverless App Engine:アプリケーションのカナリアリリース

最終更新日:Dec 19, 2025

複数のインスタンスを持つアプリケーションをアップグレードする際、カナリアリリースや段階的リリースといった手法を用いて、インスタンスを異なるバージョンに更新できます。このトピックでは、カナリアリリースの手法について説明します。また、アプリケーションのカナリアリリースの実行方法と、アプリケーションのロールバック方法についても説明します。

前提条件

対象アプリケーションのインスタンス数が 1 より大きいこと。

背景情報

カナリアリリースは、元のデプロイバージョンを維持したまま、新しいバージョンのパフォーマンスをテストするためのデプロイ手法です。カナリアリリースは、システムの安定性を確保し、可能な限り早い段階でエラーを特定して修正するのに役立ちます。

アプリケーションの安定性を確保するため、カナリアリリースにおけるアプリケーションインスタンスの数は、アプリケーションインスタンス総数の 50% を超えることはできません。残りのアプリケーションインスタンスは、特定のバッチでリリースされます。最初のバッチのアプリケーションインスタンスがリリースされた後、次のバッチをリリースするかどうかを指定できます。次のバッチを手動でリリースする前に、新バージョンの業務データを収集し、次のバッチをリリースするかどうかを判断できます。

以下の種類のカナリアリリースがサポートされています。

  • トラフィック比率によるカナリアリリース:例えば、トラフィックの 20% を新バージョンに転送し、80% を現在のバージョンに転送できます。

  • リクエスト内容によるカナリアリリース:例えば、特定のユーザー ID から送信されたリクエストによって生成されたトラフィックを新バージョンに転送し、その他のトラフィックを現在のバージョンに転送できます。

カナリアリリース方式は、段階的リリース方式よりもきめ細かいトラフィック制御を提供します。段階的リリース方式の詳細については、「アプリケーションの段階的リリース」をご参照ください。

利用シーン

例えば、あるアプリケーションに V1 のインスタンスが 10 個あり、これらのインスタンスを V2 にアップグレードしたいとします。この例では、2 つのインスタンスに対してカナリアリリースが実行され、残りの 8 つのインスタンスは 3 つのバッチでリリースされます。以下の図は、カナリアリリースのプロセスを示しています。

image

操作手順

警告

アプリケーションを再デプロイすると、アプリケーションは再起動されます。業務中断などの予期せぬエラーを防ぐため、オフピーク時間帯にアプリケーションをデプロイすることを推奨します。

  1. SAE アプリケーションリスト ページの上部でリージョンと名前空間を選択し、対象アプリケーションの ID をクリックしてアプリケーション詳細ページを開きます。

  2. 対象アプリケーションの [基本情報] ページで、[アプリケーションのデプロイ] をクリックします。

  3. デプロイパラメーターを設定します。

    説明

    アプリケーションのデプロイ方法は、最初に選択したデプロイ方法に基づきます。選択した方法に応じてパラメーターを設定してください。

    • WAR パッケージによるデプロイ:別の WAR パッケージをアップロードするか、新しくデプロイする WAR パッケージのパスを入力し、ランタイム環境やその他の設定を行います。

    • JAR パッケージによるデプロイ:別の JAR パッケージをアップロードするか、新しくデプロイする JAR パッケージのパスを入力し、ランタイム環境やその他の設定を行います。

    • ZIP パッケージによるデプロイ:別の ZIP パッケージをアップロードするか、新しくデプロイする ZIP パッケージのパスを入力し、ランタイム環境やその他の設定を行います。

    • イメージ:[イメージの設定] セクションで、[イメージの変更] をクリックします。[イメージの変更] パネルで、別のイメージリポジトリまたはイメージバージョンを選択します。

  4. [リリースポリシー設定] セクションで、カナリアリリースを設定します。

    gE6PL2tWNl

    設定項目

    説明

    リリースポリシー

    [カナリアリリース (段階的)] を選択します。

    カナリアリリースのインスタンス

    カナリアリリースを実行するインスタンスの数。

    カナリア後の残りのバッチ

    カナリアリリースの後、残りのインスタンスをリリースするバッチの数。

    最小利用可能インスタンス数

    ローリングアップグレードごとに確保される最小利用可能インスタンス数。

    • 数値指定:最小利用可能インスタンス数を入力します。[システム推奨値を使用] を選択した場合、最小利用可能インスタンス数は既存インスタンス数の 25% に設定されます。

    • 比率指定:パーセンテージを入力します。

    説明
    • アプリケーションのデプロイおよびロールバック中に、少なくとも 1 つのインスタンスが利用可能であることを確認してください。これにより、業務継続性が確保されます。値を 0 に設定すると、アプリケーションのアップグレード中に業務中断が発生します。

    • パーセンテージを指定した場合、最小利用可能インスタンス数は最も近い整数に切り上げられます。例えば、5 つのインスタンスが利用可能で、25% を指定した場合、最小利用可能インスタンス数は 2 となります。

    レイヤー 7 トラフィックカナリアリリースルールを有効にする (Kubernetes Ingress)

    この機能は、レイヤー 7 トラフィック (Kubernetes Ingress) のカナリアリリースを作成した後にのみ有効になります。

    マイクロサービスのカナリアリリースルールを有効にする (Spring Cloud および Dubbo アプリケーション)

    この機能は、マイクロサービストラフィックのカナリアリリースを作成した後にのみ有効になります。

  5. 設定が完了したら、[OK] をクリックします。

  6. 以下のいずれかの方法で、設定が有効になったかを確認します。

    • 方法 1:[変更履歴] ページで、アプリケーションの変更詳細とリリースステータスを確認します。すべてのバッチが実行されると、アプリケーションはアップグレードされます。

    • 方法 2:[基本情報] ページの [インスタンス] タブをクリックして、インスタンスのステータスを確認します。[ステータス] 列に [実行中] と表示されていれば、アプリケーションはデプロイされています。

アプリケーションのロールバック

カナリアリリースまたは段階的リリース方式を使用してアプリケーションのインスタンスをアップグレードする際に、1 つ以上のインスタンスがアップグレードされていない場合、アプリケーションのアップグレードステータスは [実行中] となります。

例外により最初のリリースバッチのアプリケーションインスタンスから応答がない場合、[変更詳細] ページの [今すぐロールバック] をクリックして、アップグレードされたインスタンスを以前のバージョンにロールバックし、アプリケーション設定をアップグレード前の元の設定に戻します。

アプリケーションの変更プロセス中に、デプロイパッケージが利用できない、ヘルスチェックに失敗するなどの例外が発生してアップグレードに失敗した場合、SAE はアプリケーションを停止し、ロールバックします。

SAE でのアプリケーションのアップグレードプロセスには、約 30 分かかります。アップグレードがタイムアウトした場合、SAE はタイムアウト例外を報告し、変更プロセスを停止します。この場合、[変更詳細] ページでリリースプロセスを手動で終了し、アプリケーションをロールバックする必要があります。

関連ドキュメント

以下の表は、SAE にアプリケーションをデプロイした後に実行できる操作について説明しています。

操作

関連ドキュメント

アプリケーションの更新、開始、停止、削除、インスタンスのスケールインまたはスケールアウトなどのライフサイクル管理操作

アプリケーションのライフサイクル管理

アプリケーションの自動スケーリングポリシーの設定、Server Load Balancer (SLB) インスタンスのアプリケーションへのバインド、アプリケーションのバッチでの開始または停止などのパフォーマンス最適化操作

ログの管理、モニタリング設定、アプリケーションイベントの表示、変更履歴の表示など、アプリケーションのステータスに基づく操作