EAS サービスを再起動したり、そのパラメーターを更新したりすると、ローリングアップデートがトリガーされます。このデプロイ戦略では、古いレプリカを段階的に新しいレプリカに置き換えることで、ゼロダウンタイムと高可用性を実現しながらサービスをアップグレードできます。
ローリングアップデート
アップデート中、システムは設定に基づいて新しいレプリカを作成し、古いレプリカを段階的に置き換えます。新しいレプリカの起動に失敗した場合、アップデートは一時停止されます。失敗したレプリカはトラフィックを受信せず、残りの古いレプリカがリクエストを処理し続けるため、サービスに影響はありません。アップデートをロールバックするか、新しいアップデートを開始するかを選択できます。新しいアップデートでは、前回失敗した試行で発生した失敗レプリカの削除を優先します。
主に 2 つのパラメーターがローリングアップデートプロセスを制御します：
-
[Exceeds the expected number of replicas] (JSON パラメーター：
rolling_strategy.max_surge)-
説明： アップデート中にシステムが作成できる追加のレプリカの最大数です。正の整数またはパーセンテージで指定できます。値を大きくすると、アップデートプロセスが高速化されます。
-
例： 100 個のレプリカを持つサービスでこの値を 20 に設定した場合、アップデートが開始されると、システムは 20 個の新しいレプリカを作成します。
-
デフォルト： レプリカ総数の 2% で、最小値は 1 です。
重要[Exceeds the expected number of replicas]を高く設定しすぎると、システムは多数の新しいレプリカをオンラインにし、同数の古いレプリカを直ちに置き換えます。新しいレプリカがウォームアップされていない場合、トラフィックの急増がサービスの安定性に影響を与える可能性があります。
-
-
[Maximum Unavailable Replicas] (JSON パラメーター：
rolling_strategy.max_unavailable)-
説明： アップデート中に利用不可にできるレプリカの最大数です。この設定により、リソースが解放され、リソース不足によるアップデートのブロックを防ぎます。
-
例： この値を N に設定すると、アップデートの開始時にシステムは N 個の古いレプリカを直ちに停止します。
-
デフォルト：
-
専用リソースグループの場合： 2023年9月1日より前に作成されたサービスの場合、デフォルトは 1 です。2023年9月1日以降に作成されたサービスの場合、エラスティックプールが有効な場合は 0、有効でない場合は 1 がデフォルトです。
-
パブリックリソースグループの場合： 0 です。
-
Lingjun AI 計算サービスの場合： 2023年9月1日より前に作成されたサービスの場合、デフォルトは 0 です。2023年9月1日以降に作成されたサービスの場合、レプリカ数の 2% がデフォルトとなり、最小値は 1 です。
-
重要-
単一レプリカのサービスで[Maximum Unavailable Replicas]を 1 に設定すると、新しいレプリカが開始される前に古いレプリカが停止するため、サービスが一時的に利用できなくなります。
-
[Maximum Unavailable Replicas]を高く設定しすぎると、多くのレプリカが同時にオフラインになる可能性があります。残りのレプリカではトラフィックを処理するのに不十分な場合があり、サービス可用性が低下します。
-
グレースフルシャットダウン
グレースフルシャットダウンのパラメーターは、ローリングアップデート中のレプリカ終了の安定性に影響します。
-
[Graceful Shutdown Time] (JSON パラメーター：
eas.termination_grace_period)-
説明： システムがレプリカのグレースフルシャットダウンを待機する時間 (秒単位) です。レプリカが Terminating 状態に入ると、システムはそのレプリカへのトラフィックのルーティングを停止します。その後、システムはこの期間待機し、レプリカがインフライトリクエストの処理を完了してから終了させます。リクエストの処理時間が通常長い場合は、この値を増やすことを推奨します。
-
デフォルト： 30 です。
重要この値を小さくするとサービスの安定性に影響する可能性があり、大きすぎるとサービスのアップデートが遅くなる可能性があります。特別な要件がない限り、このパラメーターは変更しないでください。
-
-
[Send SIGTERM] (JSON パラメーター：
rpc.enable_sigterm)-
説明： SIGTERM はプロセスを終了させるためのシグナルです。JSON パラメーターには
trueまたはfalseを指定できます。-
false： レプリカが終了する際に、システムは SIGTERM シグナルを送信しません。 -
true： レプリカが終了する際に、システムは直ちに SIGTERM シグナルを送信します。サービスのメインプロセスは、シグナルハンドラにカスタムのグレースフルシャットダウンロジックを実装する必要があります。そうしない場合、システムがプロセスを直接終了させ、グレースフルシャットダウンが失敗する可能性があります。
-
-
デフォルト： 無効 (
false) です。
-
デフォルトでは、システムは SIGTERM シグナルを送信しません。これは、ほとんどのアプリケーションコンテナがデフォルトで SIGTERM シグナルを処理しないためです。コンテナが対応するハンドラなしで SIGTERM シグナルを受信すると、そのプロセスは直ちに終了します。これにより、グレースフルシャットダウンプロセスがバイパスされ、サービスが中断されます。
リクエストの処理時間に大きなばらつきがあるサービスでは、SIGTERM を有効にすることを推奨します。たとえば、リクエストの処理時間が数秒から 30 分の範囲にわたる場合、グレースフルシャットダウン時間を 30 分に固定すると、サービスのアップデートが遅くなります。このようなシナリオでは、アプリケーションコンテナが SIGTERM シグナルを処理し、インフライトリクエストの処理を完了してから終了するように設定する必要があります。これにより、シャットダウンプロセスをより柔軟に制御できます。
非同期推論サービスでは、SIGTERM を有効にする必要はありません。レプリカが終了すると、EAS コントロールプレーンが SIGTERM シグナルを自動的に処理します。新しいリクエストのサブスクライブを停止し、既存のリクエストが完了するのを待ってからレプリカを終了させます。