フリートのスケーリングの設定

フリートを作成する際は、スケーリングパラメータを使用して、 Code Engine フリートがデプロイするワーカーの数や、タスク負荷の変化に対するフリートの対応方法を制御してください。

すべてのスケーリングパラメータはオプションであり、フリートを作成する際に設定することができます。

Code Engine CLI のスケーリングパラメータ

フリートを作成するには、 ibmcloud ce fleet run または ibmcloud ce fleet create コマンドを使用します。フリートのスケーリングには、以下のオプションが必要です。利用可能なすべてのコマンドオプションの一覧については、 CLIリファレンスを参照してください。

--scale-max

すべてのワーカーにわたる同時実行タスクスロットの総数の上限。ワーカーは、最大でこの数の同時タスクに対応できるようスケールアップします。デフォルトは 10 です。

--scale-min

保留中または実行中のタスクがない場合でも、常に確保されたままとなる同時実行タスクスロットの最小数。この処理能力を提供するワーカーは稼働し続け、自動的に削減されることはありません。

この設定によりアクティブなワーカーが存在するものの、保留中または実行中のタスクがないフリートは、「 スタンバイ 」ステータスになります。

--scale-max 以下でなければなりません。デフォルトは 0 です。

--scale-spare

現在実行中のタスク数よりも多く確保される、空き同時実行タスクスロットの数。すべての作業員が忙しくなっている場合、フリートは予備のバッファを回復するために追加の作業員を派遣します。その数は最大 --scale-max までです。余剰処理能力がある間に新しいタスクが到着した場合、新しいワーカーを待つことなく、そのタスクは直ちに開始されます。

--scale-max 以下でなければなりません。デフォルトは 0 です。

--scale-down-delay

ワーカーが最後のタスクを完了した後、 Code Engine によってスケールダウンされるまでの間、そのワーカーが実行を継続する期間を指定します。遅延ウィンドウ内で直近のタスクを完了した作業者は、新しいタスクが割り当てられるとすぐにそれを引き受けます。

秒数として正の整数を指定してください。デフォルトは 0 です（ワーカーは不要になるとすぐにスケールダウンされます）。

Code Engine コンソールのスケーリングパラメータ

コンテナスロットの最大数

コンテナスロットの最小数

「 コンテナの最大スロット数 」以下でなければなりません。デフォルトは 0 です。

空きコンテナ枠

現在実行中のタスク数よりも多く確保される、空き同時実行タスクスロットの数。すべての作業員が忙しくなっている場合、フリートは予備のバッファを回復させるために追加の作業員を派遣します。その数は、 コンテナスロットの最大数までとなります。余剰処理能力がある間に新しいタスクが到着した場合、新しいワーカーを待つことなく、そのタスクは直ちに開始されます。

「 コンテナの最大スロット数 」以下でなければなりません。デフォルトは 0 です。

スケールダウン遅延

分単位で指定してください。デフォルトは 0 です（ワーカーは不要になるとすぐにスケールダウンされます）。

作業負荷のパターンと関連パラメータ

どのパラメータを使用するかは、タスクの生成方法、レイテンシの要件、およびフリートの構成の安定性によって異なります。

Code Engine CLI におけるワンショット・バッチ・ワークロード

すべてのタスクは最初から把握しており、フリートを作成する際にそれらを割り当て、最後のタスクが完了した時点でフリートは終了します。これは最もシンプルなモデルであり、並列で実行するタスクの数を制御するために --scale-max を設定する以外に、特別なスケーリング設定は必要ありません。一連のタスクに対して専用のフリート構成が必要な場合は、このアプローチを使用してください。

関連するオプション： --scale-max

Code Engine コンソールにおけるワンショットバッチワークロード

すべてのタスクは最初から把握しており、フリートを作成する際にそれらを割り当て、最後のタスクが完了した時点でフリートは終了します。これは最もシンプルなモデルであり、「 最大コンテナスロット数 」を設定して並列実行するタスクの数を制御する以外、特別なスケーリング設定は必要ありません。一連のタスクに対して専用のフリート構成が必要な場合は、このアプローチを使用してください。

関連パラメータ： コンテナスロットの最大数

Code Engine CLI におけるスケジュールされたバッチワークロード

艦隊を常時配備しておき、スケジュールに従って新しいタスクを追加します。バッチ間の期間、フリートには保留中のタスクがありません。バッチ間の間隔は予測可能であり、作業員を暖かく保つ価値がないほど十分に長いので、 --scale-min、 --scale-spare、あるいは --scale-down-delay を使用してもメリットはありません。すべてのバッチにおいて、フリートの構成は安定しています。

関連するオプション： --scale-max

Code Engine コンソールでのスケジュールされたバッチワークロード

艦隊を常時配備しておき、スケジュールに従って新しいタスクを追加します。バッチ間の期間、フリートには保留中のタスクがありません。バッチ間の間隔は予測可能であり、かつ十分に長いため、作業員を暖かく保つことは割に合わない。したがって、「最小コンテナスロット 」、「予備コンテナスロット 」、および「 スケールダウン遅延 」を使用してもメリットはない。すべてのバッチにおいて、フリートの構成は安定しています。

関連パラメータ： コンテナスロットの最大数

Code Engine CLI における、継続的かつレイテンシに敏感なワークロード

タスクは、ユーザーの操作やセンサーの測定値、その他のリアルタイムのイベントによってトリガーされ、1日を通して予測不能なタイミングで発生します。タスクが到着するたびに新しいワーカーの起動を待つと、許容できないほどの遅延が生じてしまう。その代わりに、タスクを直ちに開始できるよう、待機状態のワーカーのプールを常に確保しておくよう、フリートを設定してください。

関連するオプション： --scale-max、 --scale-min、 --scale-spare、 --scale-down-delay

--scale-max を使用して、プロビジョニング可能なコンテナスロットの最大数を定義します。お客様のフリートは、ワークロードの需要に応じて、この同時実行数の上限まで拡張されます。
--scale-min を使用すると、キューにタスクが登録されていない場合でも、ベースラインのワーカープールが常に稼働している状態を維持できます。トラフィックが一時的にゼロになる可能性があるものの、トラフィックが再開した際には即座に起動させたい場合に、このオプションを使用してください。
--scale-spare を使用すると、現在実行中のタスク数よりも多くの空きタスクスロットを確保できます。タスクが到着すると、処理はすでに稼働中のワーカーで直ちに開始され、フリートはバックグラウンドでワーカーを追加して、余剰容量を補充します。
--scale-down-delay を使用すると、作業者が最後のタスクを完了した直後にスケールダウンするのを防ぐことができます。この設定は、タスクが断続的に到着し、その間に一時的な間隔が生じる場合に役立ちます。これにより、ワーカーが常に利用可能な状態を維持でき、不必要なスケールダウンやスケールアップのサイクルを回避できます。ワーカーを温存しておくことで、タスクの起動遅延が短縮され、ワーカーの初期化にかかるオーバーヘッドが最小限に抑えられ、新しいワーカーを繰り返しプロビジョニングするコストが削減されます。

Code Engine コンソールにおける、継続的でレイテンシに敏感なワークロード

関連パラメータ： コンテナスロットの最大数、 コンテナスロットの最小数、 予備のコンテナスロット、 スケールダウン遅延

「コンテナスロットの最大数」 を使用して、プロビジョニング可能なコンテナスロットの最大数を指定します。お客様のフリートは、ワークロードの需要に応じて、この同時実行数の上限まで拡張されます。
「最小コンテナスロット」 を使用すると、キューにタスクがない場合でも、基本となるワーカープールが常に稼働し続けるようになります。トラフィックが一時的にゼロになる可能性があるものの、トラフィックが再開した際には即座に起動させたい場合に、このオプションを使用してください。
予備のコンテナスロットを使用して、現在実行中のタスク数よりも多くの空きタスクスロットを確保してください。タスクが到着すると、処理はすでに稼働中のワーカーで直ちに開始され、フリートはバックグラウンドでワーカーを追加して、余剰容量を補充します。
「スケールダウン遅延 」を使用すると、ワーカーが最後のタスクを完了した直後にスケールダウンしてしまうのを防ぐことができます。この設定は、タスクが断続的に到着し、その間に一時的な間隔が生じる場合に役立ちます。これにより、ワーカーが常に利用可能な状態を維持でき、不必要なスケールダウンやスケールアップのサイクルを回避できます。ワーカーを温存しておくことで、タスクの起動遅延が短縮され、ワーカーの初期化にかかるオーバーヘッドが最小限に抑えられ、新しいワーカーを繰り返しプロビジョニングするコストが削減されます。