CNCFにおけるジョブ管理
ジョブ管理が提供するもの
ジョブ管理は単なる非同期実行基盤ではありません。 実行の追跡、 失敗の診断、 再実行、 監査記録など、 運用上必要となる機能も提供します。
-
完了追跡
-
結果取得
-
再実行
-
キャンセル
-
診断
-
監査記録
AI時代では、実行データが保存・管理されていること自体が重要な価値を持ちます。 Jobが保持する履歴、入力、結果、失敗理由、再実行履歴、診断情報は、障害調査、性能分析、セキュリティ監査、生成AIによる原因分析のための運用データになります。
実行モード
CNCFでは、オペレーションはQueryまたはCommandとして実行します。 Queryは同期型ですが、Commandでは以下の4つの実行モードを提供しています。
JobAsync
非同期実行です。
呼び出し側にはJob IDが返され、 実際の処理は後続ワーカーによって実行されます。
ここでいう非同期とは、主に「呼び出し側から見た非同期」です。 Jobとして受理された後、ワーカー内で実行されるCommand本体は、基本的には同期的な処理単位として進みます。
ただし、Command本体の中でEvent (イベント)を発行した後、そのEventを契機に行われる派生処理は、別Taskとして非同期に分離できます。 Event発行時には、後続処理をその場で同期的に実行するか、別Taskとして非同期に実行するかを定義できます。 つまり、JobAsyncは「Job全体がすべて非同期に細切れで動く」という意味ではなく、「呼び出し側とは非同期に進み、内部では同期的なTaskとEvent以降の同期/非同期Taskを組み合わせられる」実行モードです。
Jobライフサイクル
Jobは単に作成されるだけではなく、状態 (State)を持って管理されます。 状態は実装詳細に依存 (Dependency)しますが、概念的には以下のようなライフサイクル (Lifecycle)になります。
-
Accepted: 受付済み -
Scheduled: スケジュール済み -
Running: 実行中 -
Succeeded: 成功 -
Failed: 失敗 -
Cancelled: キャンセル
JobAsyncでは、呼び出し時点では処理は完了していないため、呼び出し側はJob IDを使って状態を取得します。 JobSyncやJobSyncWithAsyncContでも、Job履歴として状態・結果・診断情報が残るため、後から実行内容を確認できます。
Jobが保持する代表的な情報は以下です。
-
Job ID
-
Operation (操作) / Command名
-
要求者 / principal
-
受付時刻
-
開始時刻
-
完了時刻
-
実行モード
-
結果概要
-
エラー (error) / 結論
-
診断情報
-
再実行回数
-
キャンセル理由
-
コール・ツリー
実行結果に加えて、コール・ツリーなどの内部実行情報も記録されるため、 障害調査や性能改善にも有効な情報を提供できます。
呼び出し側の利用モデル
非同期Commandでは、呼び出し側は最終結果を即座に受け取るのではなく、Job IDを受け取ります。 その後、必要に応じて状態確認、待ち合わせ、結果取得を行います。
-
Commandを投入する
-
Job IDを受け取る
-
状態を確認する
-
必要に応じて待つ
-
結果を取得する
このモデル (Model)により、UI、CLI、外部システム、AIエージェントは同じJob管理インタフェースを利用できます。
5層実行モデル
CNCFの実行モデルは、次の5層モデルで整理されています。
Saga
└─ Job
└─ Task
└─ Transaction
└─ Eventこの図は包含関係を示していますが、実行時にはEventが後続Taskを起動する境界にもなります。 典型的には、Command本体のTaskは同期的に実行され、その中でTransaction (トランザクション)が成立し、Eventが発行されます。 その後、Eventハンドラや外部通知、集計更新、インデックス更新などは、Event定義または購読定義に従って、同期的に継続することも、別Taskとして非同期に実行することもできます。
-
JobAsync-
Task A: Command本体。worker内では同期的に実行されます。 -
Transaction: 整合性境界です。 -
Event: Transactionの結果として発行されます。 -
同期型購読: 同じ実行フローで処理されます。
-
非同期型購読:
Task Bや継続処理として分離されます。
-
まとめ
CNCFのJob管理は、Commandの業務的意図と実行管理を分離するための仕組みです。 Commandは「何を行うか」を表し、Jobは「どのように実行され、どの状態にあり、どのような結果になったか」を管理します。
これにより、同期実行、同期実行＋履歴管理、非同期実行、同期実行＋非同期継続を一貫したモデルで扱えます。 さらに、Saga・Job・Task・Transaction・Eventの5層モデルにより、長時間実行、作業単位、整合性境界、業務イベントを分離して管理できます。
AI時代においては、Job管理が保持する実行データは、障害調査、監査、性能分析、運用自動化のための重要な知識源になります。
参照
用語集
- Cloud Native Component Framework (CNCF)
-
Cloud Native Component Framework（CNCF）は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server（REST / OpenAPI）、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。
- イベント (Event)
-
UMLにおけるEventは、Behaviorの実行中に発生し得る出来事を記述するものです。EventのOccurrenceを受け取ることで、StateMachineのTransitionなどのBehaviorが起動されます。
- 依存 (Dependency)
-
UMLにおけるDependencyは、ClientとなるModel Elementの仕様または実装が、Supplierとなる別のModel Elementの定義へ意味的または構造的に依存することを表すDirected Relationshipです。
- 状態 (State)
-
UMLにおけるStateは、ある不変条件が成立している状況をモデル化したものです。Objectの現在のStateによって、受け付けられるEventやOperation、成立するConstraint、次に可能なTransitionが変わります。
- ライフサイクル (Lifecycle)
-
Lifecycleとは、ある対象が生成されてから終了するまでに、Identityを保ちながら通過するStateとTransitionの範囲です。
- 操作 (Operation)
-
UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。
- エラー (error)
-
汎用的な表現として用いられる用語。ソフトウェア工学では多義的に使われ、バグや障害全般を指す。SimpleModeling では広義のラベルとして使用し、個別には Mistake・Defect・Fault・Failure・Deviation に整理する。
- モデル (Model)
-
Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
- トランザクション (Transaction)
-
Undefined