注文を変更する - - Alibaba Cloud ドキュメントセンター

Serverless App Engine (SAE) は、さまざまなAPIを提供します。これらのAPIを使用して、名前空間とVPCの管理、アプリケーション情報の照会、自動スケーリングの実装、マイクロサービスの照会など、さまざまなタスクを実行できます。 SAEは、変更命令に基づいてアプリケーションを管理する。このトピックでは、SAE変更注文の基本概念、API呼び出し、およびプロセス設計について説明します。

変更命令とは何ですか?

基本的な概念

SAEは、変更命令に基づいてアプリケーションを管理する。 SAEのアプリケーションでO&Mを実行するには、変更注文に依存する必要があります。 SAEで管理されるアプリケーションの変更命令は、順番に実行されなければならない。 SAEは、アプリケーションに対して一度に1つの変更命令のみを実行する。

なぜ変更注文を並行して実行できないのですか?

自動スケーリング
SAEを使用してアプリケーションをリリースまたはスケーリングする場合、例外を防ぐためにすべてのオートスケーリングルールを無効にする必要があります。複数の変更命令が並行して実行される場合、競合が発生する可能性があります。例えば、オートスケーリングルールは、注文Aに対しては無効にされるが、注文Aがまだ進行中である間に、注文Bに対しては再び有効にされる。自動スケーリングルールが有効になり、アプリケーションをスケーリングしようとすると、アプリケーションが期待どおりにスケーリングされない場合があります。
リリースとロールバック
各リリースおよびロールバック操作は、基になるリソースに関する説明ファイルを生成します。 SAEでは、最大2つのアプリケーションバージョンを同時に存在させることができます。複数の変更命令が並行して実行される場合、制限を超える3つ以上のアプリケーションバージョンがデプロイされる可能性があります。

変更注文に関連するAPI呼び出し

変更注文に関連するAPIを呼び出して、SAEでアプリケーションをデプロイできます。このトピックでは、変更注文が正常に実行されたかどうかを確認する方法について説明します。この例では、アプリケーションリリースシナリオを使用しています。アプリケーションリリースは、変更注文の最も複雑な使用シナリオです。したがって、このシナリオで変更命令が正常に実行されたかどうかを確認するために使用される方法は、他のシナリオにも適用できます。

変更注文に関連するAPIを呼び出すと、Statusパラメーターが返されます。このパラメーターには、次の有効な値があります。

0: 変更注文の準備中です。
1: 変更命令は実行中です。
2: 変更順序は正常に実行されました。
3: 変更命令の実行に失敗しました。
6: 変更命令の実行が停止されます。
8: 実行プロセスは保留中です。リリースバッチを手動で決定する必要があります。
9: 実行プロセスは保留中です。 SAEは自動的にリリースバッチを決定します。
10: システム例外が原因で実行が失敗します。
11: 変更注文は承認待ちです。
12: 変更注文は承認され、実行待ちです。

変更注文が正常に実行されたかどうかを確認する

CreateApplicationやDeployApplicationなどのAPI操作を呼び出します。返されたSuccess値がtrueで、Code値が200の場合、ChangeOrderIdパラメーターも返されます。
DescribeChangeOrder操作を呼び出します。この操作では、ChangeOrderIdパラメーターを前の手順で取得した値に設定します。
応答のStatusパラメーターの値を確認します。値が2の場合、変更命令は正常に実行されます。

ロールバックシナリオ

単一バッチリリース
単一バッチリリースが失敗または停止した場合、SAEはアプリケーションを自動的にロールバックしません。 RollbackApplication操作を呼び出して、必要に応じてロールバックを実装できます。 DescribeChangeOrder操作を呼び出し、Statusパラメーターの戻り値が3または10の場合、変更命令は実行されません。
カナリアリリースまたはバッチリリース
変更命令の実行に失敗すると、SAEは自動的にアプリケーションをロールバックします。
StatusパラメーターとSubStatusパラメーターの戻り値が両方とも1場合、AbortAndRollbackChangeOrder操作を呼び出して変更注文の実行を停止する必要があります。

カナリアおよびバッチリリースでの手動操作

このセクションでは、バッチリリースでバッチを手動で決定する方法について説明します。カナリアリリースまたはバッチリリースでは、前のバッチが処理された後にのみ、新しいバッチの操作を開始できます。

DeployApplication操作を呼び出し、レスポンスでChangeOrderId値を取得します。
DescribeChangeOrder操作を呼び出します。この操作では、ChangeOrderIdパラメーターを前の手順で取得した値に設定します。
レスポンスのStatusパラメーターの値が8の場合、ConfirmPipelineBatchを呼び出してリリースを続行できます。 ConfirmPipelineBatch操作を呼び出すときは、PipelineIdパラメーターを指定する必要があります。このパラメーターは、リリース内の次のバッチのIDを示します。 DescribeChangeOrder操作の応答には、CurrentPipelineIdおよびPipelinesパラメーターが含まれます。 Pipelinesパラメーターは、すべてのバッチの配列を示します。 CurrentPipelineIdパラメーターは、現在のバッチのIDを示します。このステップは繰り返すことができる。 ConfirmPipelineBatch操作を呼び出したときに指定したPipelineIdがDescribeChangeOrder操作から返されたCurrentPipelineIdと同じである場合、ConfirmPipelineBatchを再度呼び出す必要があります。ここで、PipelineIdは、すべてのバッチの配列で現在のバッチのバッチのIDに続く

変更注文のプロセス設計

変更順序の実行に失敗した後に自動スケーリングルールが自動的に復元されないのはなぜですか?

リリースとロールバック
自動スケーリングルールは、変更命令が実行される前に無効になります。変更命令が正常に実行されると、SAEは自動スケーリングルールを自動的に復元します。実行が失敗した場合、SAEはルールを自動的に復元しません。実行プロセス中に複数のアプリケーションバージョンが生成されるため、SAEは実行するアプリケーションバージョンを決定できません。
アプリケーションのスケーリング
自動スケーリングルールは、手動スケーリング操作と競合する場合があります。たとえば、アプリケーションインスタンスの数を10から5に手動でスケーリングする場合、SAEは、自動スケーリングルールに基づいて15に増やす必要があると判断します。したがって、アプリケーションを手動でスケーリングする場合は、自動スケーリングルールを無効にする必要があります。

バッチリリースが失敗したときにSAEがアプリケーションを自動的にロールバックするのはなぜですか?

バッチリリースでは、一部のバッチのみが正常に処理されると、2つのバージョンのアプリケーションインスタンスが共存します。この場合、一括リリースの変更命令は実行されません。実行が停止してもアプリケーションがロールバックされていない場合、次にアプリケーションがリリースされたときに3つのバージョンのインスタンスが共存する可能性があります。したがって、SAEは、アプリケーションインスタンスが最大で2つのバージョンを持つように、アプリケーションを自動的にロールバックする必要があります。