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は単に作成されるだけではなく、状態を持って管理されます。状態は実装詳細に依存しますが、概念的には以下のようなライフサイクルになります。
-
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を受け取る
-
状態を確認する
-
必要に応じて待つ
-
結果を取得する
このモデルにより、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や継続処理として分離されます。
-
Task
Jobを構成する観測可能な作業単位です。
Taskは必ずしもJob全体と一対一ではありません。Command本体を実行するTaskと、Event発行後に起動される派生Taskを分けることで、主処理と副作用的な後続処理を独立して観測・再実行・診断できます。ただし、すべてのEvent購読が別Taskになるわけではありません。同期型の購読は同じ実行フロー内で処理され、非同期型の購読だけが独立したTaskとして管理されます。
Event
状態変化や業務上の事実を表します。
Eventは単なる履歴ではなく、後続処理を開始する接続点にもなります。Event発行時の後続処理には、同期型と非同期型があります。同期型はEvent発行元の実行フローの中で処理され、同じTaskまたはTransaction境界の近くで完了します。非同期型はEventを契機に別Taskとして起動され、呼び出し元の完了とは分離して管理されます。このため、CNCFではCommandの同期的な中核処理と、Event以降の同期/非同期の派生処理を分けて扱えます。
まとめ
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 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。
- エラー (error)
-
汎用的な表現として用いられる用語。ソフトウェア工学では多義的に使われ、バグや障害全般を指す。SimpleModeling では広義のラベルとして使用し、個別には Mistake・Defect・Fault・Failure・Deviation に整理する。