ワークロードの概念¶
ワークロードは、Workload APIの論理単位です。安定したID、呼び出しエンドポイント、および1つ以上の実行中のコンテナインスタンス（Proton）を囲むガバナンスラッパーです。ワークロードは、ユーザーが作成、監視、共有、および破棄する対象です。
オブジェクトモデル¶
ワークロードには常に少なくとも1つのProtonがあります。置換操作中は、アクティブと候補の2つを一時的に持つことができます。高可用性ワークロードでは、複数のProtonを永続的に実行できます。
ワークロードは、インラインアーティファクト仕様、または既存のartifactIdへの参照を使用して、POST /workloads/で作成されます。
ライフサイクルの状態¶
ワークロードは、プライマリーProtonのProtonStatusから派生したユーザー向けのWorkloadStatusを報告します。ワークロードビューは、内部のProtonのみのステータス（initializing、warming、draining、restarting）を隣接するワークロードに表示されるステータスにまとめます。次の表に、作成、更新、置換、停止、失敗、昇格操作のProtonレベルのシーケンスを示します。
| 操作 | 移行 |
|---|---|
| 作成 | submitted -> provisioning -> launching -> running |
| 更新 | running -> initializing -> running |
| 置換 | running -> running(active) + initializing/warming/running(candidate) -> switch -> draining(active) + running(new active) -> running(single active) |
| 停止 | running -> stopping -> stopped |
| 失敗 | initializing | running -> errored |
| 昇格 | running (draft) -> running (locked) (no restart) |
プラットフォームは、ワークロードのProtonをバックアップするKubernetesポッドからこれらのステータスを導出します。完全なWorkloadStatusおよびProtonStatus列挙型、ポッド状態の述語、マルチレプリカの最悪状態優先の集計、およびProtonのランタイムバックアップについては、ライフサイクルの状態を参照してください。
ライフタイムポリシー¶
ワークロードのライフタイムは、参照するアーティファクトのステータスによって決定されます。ドラフトアーティファクトは、一度に1つのアクティブなワークロードのみをサポートします。ロックされたアーティファクトは、任意の数のワークロードを同時に処理できます。マルチリージョンまたはマルチテナントのデプロイに役立ちます。
ドラフト（短命）¶
ドラフトワークロードは短命であり、単一の反復するアーティファクトに関連付けられています。これらは8時間のTTL（Time-to-Live：有効期間）を持ちます。作成から8時間後にワークロードを自動終了させるカウントダウンであり、他の作業のためにリソースを解放し、手動のクリーンアップなしで反復を可能にします。
ドラフトはアクティビティではなくガバナンスを表します
draftはアーティファクトのガバナンスステータスであり、ワークロードが実行されているかどうかを示すものではありません。ドラフトワークロードは、ロックされたワークロードと同じようにrunningに到達し、ライブトラフィックを処理します。draftは、アーティファクトの仕様がまだ変更可能であり、ワークロードが8時間のTTLクロック上にあることを意味するだけです。ドラフトワークロードのIDやエンドポイントに触れることなく、そのライフタイムを無期限に移行するには、本番環境への昇格を参照してください。
| ポリシー | 動作 |
|---|---|
| Auto-cleanup | 作成から8時間後に終了します（TTL）。 |
| タイマーの再起動 | ワークロードを再起動するたびに、TTLは8時間にリセットされます。 |
| Workloads per artifact | ドラフトアーティファクトごとに最大1つのアクティブなワークロード。 |
TTLと監視データの保持は別のクロックです
8時間のTTLは、プラットフォームがワークロードをいつ自動終了するかを制御します。これはOTelテレメトリーの保持とは別のポリシーであり、これは組織レベルで設定され（トライアル組織の場合は14日、有料組織の場合はデフォルトで30日、60～360日に延長可能）、ドラフトワークロードとロックされたワークロードに同じように適用されます。監視の概念：保持の概要を参照してください。組織の保持期間が8時間より長い場合（デフォルトでは常にそうなっています）、ドラフトワークロードのテレメトリーはワークロード自体よりも長生きする可能性があります。この2つのポリシーは無関係なこと（ライフタイムとデータ保持）を記述しており、矛盾するものではありません。
ロック（永続的）¶
ロックされたワークロードは、不変のアーティファクトに対して無期限に実行され、明示的な有用性が必要です。これらにはTTLはありません。手動で停止または削除するまで、あるいは新しいアーティファクトに置き換えるまで実行されます。
| ポリシー | 動作 |
|---|---|
| Lifetime | 明示的に停止または削除されるまで実行されます。 |
| 監視データの保持 | 30 days. |
importance |
オプション。デフォルトはlowです。クラスターが競合しているときに、プラットフォームがリソースの優先順位付けと運用上のトリアージに使用する優先度のヒントです。ルーティング、オートスケーリング、またはQoSの保証には影響しません。これはガバナンスのシグナルです。値：critical、high、moderate、low。 |
| Workloads per artifact | 複数のワークロードで1つのロックされたアーティファクトを共有できます。 |
ドラフトとロックの選択¶
アーティファクト側の定義（アーティファクトのステータスとしてのdraftとlockedの意味、ロックする方法、および一方向のルール）については、アーティファクトのライフサイクルを参照してください。
| 側面 | ドラフトアーティファクトのワークロード | ロックされたアーティファクトのワークロード |
|---|---|---|
| 可変性 | 反復処理中にアーティファクトの仕様を変更できます。 | ロック後、アーティファクトは不変になります。 |
| ライフタイム | 作成から8時間のTTL。ワークロードを再起動するとタイマーがリセットされます。 | 停止または削除するまで実行されます。 |
importance |
オプション。デフォルトはlowです。 |
オプション。デフォルトはlowです。本番環境のワークロードには明示的に設定します。 |
| アーティファクトあたりのワークロード数 | ドラフトアーティファクトごとに最大1つのアクティブなワークロード。 | 多くのワークロードで1つのロックされたアーティファクトを共有できます。 |
| 置換ルール | エクスペリメントを交換する場合は、別のドラフトアーティファクトに置き換えます。 | 制御された本番環境へのロールアウトの場合は、別のロックされたアーティファクトに置き換えます。 |
| 昇格 | POST /workloads/{id}/promoteを使用して、同じワークロードIDを本番環境のセマンティクスに移行します。 |
該当なし。すでにロックされたパス上にあります。 |
アクティブな開発と反復処理には、ドラフトアーティファクトのワークロードを使用します。安定したエンドポイントを必要とする本番サービスには、ロックされたアーティファクトのワークロードを使用します。
アーティファクトのライフサイクルおよび本番環境への昇格も参照してください。
有用性¶
importanceは、競合時のリソースの優先順位付けと運用上のトリアージに使用される優先度のヒントです（デフォルトはlow）。これ自体でルーティングやオートスケーリングのターゲットが変更されることはありません。
| 有用性 | 使用するタイミング |
|---|---|
low |
内部ツール、開発ワークロード、重要度の低いサービス。 |
moderate |
影響範囲の限られた内部サービス。 |
high |
排除されにくいことを意図したユーザー向けのサービス。 |
critical |
ミッションクリティカルなワークロード。排除しないでください。 |
importanceは、実行中のワークロードで変更可能です（{"importance": "..."}を指定したPATCH /workloads/{id}）。
可用性の保証
importanceは、高可用性の配置や稼働時間の保証には影響しません。 可用性は、ランタイム設定によって完全に決定されます。ダウンタイムを発生させずに単一のレプリカの障害に耐えられるようにするには、replicaCountを2以上に設定するか、minReplicaCount >= 2を指定してオートスケーリングを使用してください。 レプリカの設定で提供される範囲を超える、プラットフォームレベルのSLA保証はありません。
共有¶
ワークロードは、PATCH /workloads/{workload_id}/sharedRolesによる共有ロールをサポートしています。共有ロールはワークロードの特定のアクセスレベルを付与します（SubjectTypeの値はuser、group、organization、およびroleです）。 ロールはSharingRole列挙型を使用します。ほとんどの連携ではOWNER、USER、またはCONSUMERを使用します。 共有ロールは、イベント、統計情報、および/protons/サブリソースに伝播します。ワークロードをバックアップするアーティファクトには独自の共有ポリシー（PATCH /artifacts/{artifact_id}/sharedRoles）があります。
curl -X PATCH "${DATAROBOT_ENDPOINT}/workloads/${WORKLOAD_ID}/sharedRoles" \
-H "Authorization: Bearer ${DATAROBOT_API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"operation": "updateRoles",
"roles": [{"id": "USER_ID", "role": "EDITOR", "shareRecipientType": "user"}]
}'
ロールの詳細な一覧、プロパゲーション、および受信者の特定に関するオプションについては、共有とアクセス制御を参照してください。