はじめに

前回記事の振り返り

前回の記事「Step FunctionsからEKSへPyTorchJobを投入できない？ConfigMapで華麗に解決する方法」では、AWS Step FunctionsからKubeflow PyTorchJobを投入する方法について解説しました。ConfigMapをテンプレートとして使用し、Kubernetes Jobを介してPyTorchJobを間接的に作成する手法を紹介しました。

本記事の目的

今回は、投入したPyTorchJobの状態監視と同期実行の実装について詳しく解説します。PyTorchJobの完了を待機し、成功・失敗を適切に判定する仕組みにより、エンドツーエンドの機械学習パイプラインを実現します。

背景とモチベーション

PyTorchJobの同期実行の必要性

機械学習パイプラインでは、以下の理由からPyTorchJobの同期実行が必須です：

1. 後続処理の依存関係

学習完了後のモデル評価やデプロイ処理
学習結果に基づく次ステップの条件分岐
パイプライン全体の成功・失敗判定

2. エラーハンドリング

失敗時の適切なリトライ処理
エラー通知とアラート送信
障害原因の特定と復旧処理

3. リソース管理

GPU等の高価なリソースの適切な解放
次のジョブへのリソース引き継ぎ
コスト最適化のための実行時間管理

eks:runJob.syncの制約

Step Functionsのeks:runJob.syncは優れた同期実行機能を提供しますが、標準のKubernetes Job（batch/v1）のみをサポートしています：

{
  "Resource": "arn:aws:states:::eks:runJob.sync",  // ← .syncで同期実行
  "Parameters": {
    "Job": {
      "apiVersion": "batch/v1",  // ← 標準Jobのみサポート
      "kind": "Job"               // ← PyTorchJobは非対応
    }
  }
}

この制約により、以下の機能が利用できません：

PyTorchJobの直接的な同期実行
自動的な完了待機
ログの自動取得

なぜeks:callによる監視が必要なのか

PyTorchJobのようなカスタムリソース（CRD）の同期実行には、eks:callを使った独自のポーリングループ実装が必要です：

{
  "Resource": "arn:aws:states:::eks:call",  // ← 非同期APIコール
  "Arguments": {
    "Path": "/apis/kubeflow.org/v1/...pytorchjobs",  // ← CRD操作可能
    "Method": "GET"  // ← 状態取得
  }
}

本記事では、この制約を克服し、PyTorchJobの擬似的な同期実行を実現する実装テクニックを紹介します。

解決アプローチの全体像

非同期から同期への変換戦略

以下の戦略により、非同期のeks:callを使って同期的な動作を実現します：

PyTorchJob投入（前回記事の手法）
- ConfigMap + Kubernetes Jobによる間接作成
- Job名の取得と保持
状態監視ループ（本記事の焦点）
- eks:callによる定期的な状態取得
- status.conditions配列の評価
- 完了判定またはループ継続
同期的な完了待機
- ポーリング間隔の最適化
- タイムアウト処理
- 成功・失敗の適切な判定

監視アーキテクチャ図

上図に示すように、処理は以下の流れで実行されます：

Get Training Job Name: PyTorchJob作成結果からJob名を抽出
Query Training Job Status: eks:callでPyTorchJobの状態を取得
Evaluate Job Completion: status.conditions配列を評価

ポーリングループ: Running状態の場合は600秒待機して再チェック

整理すると以下の様な流れになります。

実装の工夫点

Job名とPyTorchJob名の同一化戦略

本実装の最大の工夫は、Kubernetes JobとPyTorchJobで同じ名前を使用することです。これにより、PyTorchJobの追跡が確実かつ効率的になります。

ConfigMapテンプレートでの名前設定

# pytorch-job-template-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: pytorch-job-template-configmap
  namespace: ml-training-pipeline
data:
  pytorchjob.yaml: |
    apiVersion: kubeflow.org/v1
    kind: PyTorchJob
    metadata:
      name: ${PYTORCH_JOB_NAME}  # ← 環境変数から注入
      labels:
        job-name: ${PYTORCH_JOB_NAME}  # ← 重要：同じ名前をラベルに設定
      namespace: ml-training-pipeline

Kubernetes Job作成時の環境変数設定

{
  "containers": [
    {
      "env": [
        {
          "name": "PYTORCH_JOB_NAME",
          "value": "training-job-20241225-123456"  // ← この名前が両方で使われる
        }
      ]
    }
  ]
}

メタデータラベルによる名前取得

PyTorchJob作成時に設定したjob-nameラベルを通じて、後続の監視処理でPyTorchJob名を取得します：

// Get Training Job Name タスク
{
  "Type": "Pass",
  "Parameters": {
    "pytorchJobName.$": "$.pytorchJobResult.metadata.name"  // ← 作成結果から名前取得
  },
  "ResultPath": "$.jobName"
}

実装上の工夫を整理すると以下の様になります。

なぜこの設計が重要なのか

追跡可能性: Kubernetes JobからPyTorchJobまでの一貫した名前により、デバッグが容易
検索効率: labelSelectorで確実にPyTorchJobを特定可能
運用性: ログやメトリクスで同じ名前を使用でき、問題追跡が簡単

// labelSelectorによる効率的な検索
"QueryParameters": {
  "labelSelector": [
    "job-name=training-job-20241225-123456"  // ← 確実に特定のPyTorchJobを取得
  ]
}

実装の詳細

Step 1: Get Training Job Name - 巧妙な名前取得

PyTorchJob作成結果から名前を抽出し、後続の監視処理で使用します：

{
  "Get Training Job Name": {
    "Type": "Pass",
    "Comment": "Extract PyTorchJob name from job result",
    "Parameters": {
      "pytorchJobName.$": "$.pytorchJobResult.metadata.name"
    },
    "ResultPath": "$.jobName",
    "QueryLanguage": "JSONPath",
    "Next": "Query Training Job Status"
  }
}

このステップにより、作成されたPyTorchJobの名前が$.jobName.pytorchJobNameとして保存され、後続のステップで参照可能になります。

Step 2: Query Training Job Status - eks:callでの状態取得

eks:callを使用してPyTorchJobの現在の状態を取得します：

{
  "Query Training Job Status": {
    "Type": "Task",
    "Resource": "arn:aws:states:::eks:call",
    "Arguments": {
      "ClusterName": "eks-cluster-training",
      "CertificateAuthority": "{% $pytorchCertificateAuthority %}",
      "Endpoint": "{% $pytorchEndpoint %}",
      "Path": "/apis/kubeflow.org/v1/namespaces/ml-training-pipeline/pytorchjobs",
      "Method": "GET",
      "QueryParameters": {
        "labelSelector": [
          "{% 'job-name=' & $states.input.jobName.pytorchJobName %}"
        ]
      }
    },
    "Output": "{% $merge([$states.input, $states.result, {'pytorchCertificateAuthority': $pytorchCertificateAuthority, 'pytorchEndpoint': $pytorchEndpoint}]) %}",
    "QueryLanguage": "JSONata",
    "Next": "Evaluate Job Completion"
  }
}

重要なポイント

labelSelector: job-nameラベルで特定のPyTorchJobを確実に取得
JSONata Output: 認証情報を含む必要なデータを次のステップに引き継ぎ
Kubeflow API Path: /apis/kubeflow.org/v1/はKubeflow Training Operatorのエンドポイント

Kubernetes APIエンドポイントの詳細

使用されているAPIパス /apis/kubeflow.org/v1/namespaces/ml-training-pipeline/pytorchjobs について詳しく解説します：

/apis/kubeflow.org/v1/namespaces/ml-training-pipeline/pytorchjobs
  │     │            │       │              │                │
  │     │            │       │              │                └─ 6. リソース名（複数形）
  │     │            │       │              └──────────────── 5. Namespace名
  │     │            │       └──────────────────────────────── 4. namespaces（固定）
  │     │            └──────────────────────────────────────── 3. APIバージョン
  │     └────────────────────────────────────────────────────── 2. APIグループ
  └──────────────────────────────────────────────────────────── 1. APIプレフィックス

各要素の説明：

/apis: カスタムAPIグループ用プレフィックス（標準リソースは/api/v1）
kubeflow.org: Kubeflowプロジェクトが所有するAPIグループ
v1: Kubeflow Training OperatorのAPIバージョン（安定版）
namespaces: Namespace指定を示す固定キーワード
ml-training-pipeline: 対象のNamespace名
pytorchjobs: PyTorchJobリソースの複数形

標準JobとPyTorchJobのAPIパス比較：

# 標準Job（Kubernetes native）
/api/v1/namespaces/ml-training-pipeline/jobs

# PyTorchJob（CRD）
/apis/kubeflow.org/v1/namespaces/ml-training-pipeline/pytorchjobs

labelSelectorによる検索：

{
  "QueryParameters": {
    "labelSelector": [
      "job-name=training-job-20241225-123456"
    ]
  }
}

この方法の利点：

返り値の一貫性: 常に{"items": [...]}形式
エラーハンドリング: 存在しない場合も空配列で安全
効率性: 大量のPyTorchJob中から特定のものを高速検索

実際のHTTPリクエスト例：

GET https://xxx.eks.amazonaws.com/apis/kubeflow.org/v1/namespaces/ml-training-pipeline/pytorchjobs?labelSelector=job-name=training-job-20241225-123456

Step 3: Evaluate Job Completion - 複雑な状態判定

PyTorchJobのstatus.conditions配列を評価し、適切な分岐を行います：

{
  "Evaluate Job Completion": {
    "Type": "Choice",
    "Choices": [
      // Succeeded判定（conditions[0]〜[4]をチェック）
      {
        "And": [
          {
            "Variable": "$.ResponseBody.items[0].status.conditions[0].type",
            "IsPresent": true
          },
          {
            "Variable": "$.ResponseBody.items[0].status.conditions[0].type",
            "StringEquals": "Succeeded"
          }
        ],
        "Next": "Training Completed Successfully"
      },
      // ... conditions[1]〜[4]も同様にチェック
      
      // Failed判定（conditions[0]〜[4]をチェック）
      {
        "And": [
          {
            "Variable": "$.ResponseBody.items[0].status.conditions[0].type",
            "IsPresent": true
          },
          {
            "Variable": "$.ResponseBody.items[0].status.conditions[0].type",
            "StringEquals": "Failed"
          }
        ],
        "Next": "Training Failed"
      }
      // ... conditions[1]〜[4]も同様にチェック
    ],
    "QueryLanguage": "JSONPath",
    "Default": "Prepare Next Query"
  }
}

Step 4: ポーリングループの実装

Running状態の場合、待機してから再度状態をチェックします：

{
  "Prepare Next Query": {
    "Type": "Pass",
    "Parameters": {
      "jobName": {
        "pytorchJobName.$": "$.ResponseBody.items[0].metadata.labels['job-name']"
      },
      "pytorchCertificateAuthority.$": "$.pytorchCertificateAuthority",
      "pytorchEndpoint.$": "$.pytorchEndpoint"
    },
    "ResultPath": "$",
    "QueryLanguage": "JSONPath",
    "Next": "Wait Polling Interval"
  },
  "Wait Polling Interval": {
    "Type": "Wait",
    "Seconds": 600,
    "Next": "Query Training Job Status"
  }
}

PyTorchJobの状態監視の詳細

status.conditions配列の構造と課題

PyTorchJobのstatus.conditions配列は、ジョブの状態を表す複数の要素を含みます：

{
  "status": {
    "conditions": [
      {
        "type": "Running",    // または "Succeeded", "Failed"
        "status": "True",
        "lastUpdateTime": "2024-12-25T10:00:00Z",
        "lastTransitionTime": "2024-12-25T10:00:00Z",
        "reason": "JobRunning",
        "message": "PyTorchJob is running"
      }
    ]
  }
}

5つのconditions要素をチェックする理由

conditions配列の要素順序は不定であるため、以下の理由で0〜4の全要素をチェックする必要があります：

Kubeflow実装の特性: 配列の順序が保証されない
バージョン間の差異: Kubeflowのバージョンによって動作が異なる可能性
確実な状態判定: すべての可能性をカバーして見逃しを防ぐ

Succeeded/Failed判定のロジック

conditions[0].type == "Succeeded" → 成功
conditions[1].type == "Succeeded" → 成功
conditions[2].type == "Succeeded" → 成功
conditions[3].type == "Succeeded" → 成功
conditions[4].type == "Succeeded" → 成功

conditions[0].type == "Failed" → 失敗
conditions[1].type == "Failed" → 失敗
conditions[2].type == "Failed" → 失敗
conditions[3].type == "Failed" → 失敗
conditions[4].type == "Failed" → 失敗

それ以外 → 実行中（ポーリング継続）

同期実行を実現するポーリング設計

600秒待機の設計根拠

ポーリング間隔を600秒（10分）に設定した理由：

典型的な学習時間

小規模学習: 10-30分
中規模学習: 1-3時間
大規模学習: 3-24時間

バランスの考慮

API負荷: 頻繁すぎる呼び出しは避ける
レスポンス性: 完了後の待機時間を最小化
コスト: Step Functions実行時間の最適化

状態データの引き継ぎ戦略

各ループで必要なデータを確実に引き継ぐため、JSONataを活用：

{
  "Output": "{% $merge([$states.input, $states.result, {
    'pytorchCertificateAuthority': $pytorchCertificateAuthority,
    'pytorchEndpoint': $pytorchEndpoint,
    'jobName': $jobName
  }]) %}"
}

無限ループの回避策

実装上の考慮事項：

Step Functions実行時間制限: 最大1年の制限内で動作
タイムアウト設計: 必要に応じてカスタムタイムアウトロジックを追加
異常検知: 長時間Runningの場合のアラート設定

実装コードの完全解説

PyTorchJob作成時のラベル設定

ConfigMapテンプレートで、PyTorchJobにラベルを設定することが重要です：

apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  name: ${PYTORCH_JOB_NAME}
  labels:
    job-name: ${PYTORCH_JOB_NAME}  # ← 監視で使用するラベル
    environment: production
    team: ml-team
  namespace: ml-training-pipeline
spec:
  pytorchReplicaSpecs:
    Worker:
      replicas: 1
      restartPolicy: Never
      template:
        spec:
          containers:
          - name: pytorch
            image: 123456789012.dkr.ecr.us-west-2.amazonaws.com/ml-training:latest
            resources:
              limits:
                nvidia.com/gpu: "8"

labelSelectorによる効率的な検索

labelSelectorを使用することで、大量のPyTorchJobが存在する環境でも効率的に特定のジョブを取得できます：

{
  "QueryParameters": {
    "labelSelector": [
      "job-name=training-job-20241225-123456"
    ]
  }
}

この方法の利点：

高速: 全リソースをフェッチする必要がない
確実: 名前の一致により確実に特定
スケーラブル: ジョブ数が増えても性能劣化しない

状態評価のChoice実装

完全なChoice実装の例：

{
  "Evaluate Job Completion": {
    "Type": "Choice",
    "Choices": [
      // Succeeded判定 - conditions[0]
      {
        "And": [
          {
            "Variable": "$.ResponseBody.items[0].status.conditions[0].type",
            "IsPresent": true
          },
          {
            "Variable": "$.ResponseBody.items[0].status.conditions[0].type",
            "StringEquals": "Succeeded"
          }
        ],
        "Next": "Training Completed Successfully"
      },
      // Succeeded判定 - conditions[1]
      {
        "And": [
          {
            "Variable": "$.ResponseBody.items[0].status.conditions[1].type",
            "IsPresent": true
          },
          {
            "Variable": "$.ResponseBody.items[0].status.conditions[1].type",
            "StringEquals": "Succeeded"
          }
        ],
        "Next": "Training Completed Successfully"
      },
      // ... conditions[2]〜[4]も同様
      
      // Failed判定も同様の構造で実装
    ],
    "QueryLanguage": "JSONPath",
    "Default": "Prepare Next Query"
  }
}

eks:runJob.sync vs eks:call 詳細比較

同期実行サポートの違い

機能	eks:runJob.sync	eks:call
標準Job (batch/v1)	✅ 完全同期サポート	✅ 操作可能（非同期）
PyTorchJob (CRD)	❌ 非対応	✅ 操作可能（非同期）
完了待機	✅ 自動	❌ 手動実装必要
ログ取得	✅ 自動	❌ 別途実装必要
実装の複雑さ	⭐ シンプル	⭐⭐⭐ 複雑
API負荷	⭐ 低（内部管理）	⭐⭐ 中（ポーリング）

使い分けの判断基準

eks:runJob.syncを使用すべきケース

標準のKubernetes Jobのみを使用
シンプルな同期実行が必要
ログの自動取得が必要

eks:callを使用すべきケース

カスタムリソース（CRD）を操作
複雑な状態管理が必要
細かい制御が必要

パフォーマンスとコストの観点

[PyTorchJob作成]
    ↓
eks:runJob.sync（標準Job）  ← ConfigMap経由でPyTorchJob作成
    ↓                         コスト: 低、実行時間: 短
[PyTorchJob監視]
    ↓
eks:call（ポーリング）      ← CRDの状態を定期的にチェック
    ↓                         コスト: 中、実行時間: 長
[完了/失敗判定]

この組み合わせにより、PyTorchJobの擬似的な同期実行を実現しながら、コストと複雑性のバランスを取っています。

トラブルシューティング

PyTorchJob名が取得できない場合

症状

{
  "error": "Cannot read property 'metadata' of undefined"
}

原因と対処

PyTorchJob作成の失敗: 前段のジョブログを確認
名前の不一致: 環境変数PYTORCH_JOB_NAMEが正しく設定されているか確認
タイミング問題: PyTorchJob作成直後の場合、若干の待機時間を追加

{
  "Wait Before Extract": {
    "Type": "Wait",
    "Seconds": 30,
    "Next": "Get Training Job Name"
  }
}

状態が正しく判定されない場合

症状

Succeededなのに監視が継続する
Failedが検出されない

原因と対処

conditions配列の構造確認:

kubectl get pytorchjob training-job-xxx -n ml-training-pipeline -o json | jq '.status.conditions'

配列要素数の確認: 5要素より少ない場合は、Choice定義を調整
Kubeflowバージョン確認: バージョンによってstatus構造が異なる可能性

ポーリングがタイムアウトする場合

症状

Step Functions実行が長時間継続
コストが予想以上に発生

対処法

最大実行時間の設定:

{
  "TimeoutSeconds": 86400,  // 24時間
  "HeartbeatSeconds": 600
}

カウンターによる制限:

{
  "Initialize Counter": {
    "Type": "Pass",
    "Result": 0,
    "ResultPath": "$.loopCount"
  },
  "Increment Counter": {
    "Type": "Pass",
    "Parameters": {
      "loopCount.$": "States.MathAdd($.loopCount, 1)"
    }
  },
  "Check Max Loops": {
    "Type": "Choice",
    "Choices": [{
      "Variable": "$.loopCount",
      "NumericGreaterThan": 144,  // 24時間（10分 × 144）
      "Next": "Timeout Error"
    }]
  }
}

ベストプラクティス

命名規則の統一

一貫性のある命名規則により、運用性が大幅に向上します：

# 推奨フォーマット
training-job-{purpose}-{date}-{timestamp}

# 例
training-job-mnist-20241225-123456
training-job-bert-20241225-234567

エラーハンドリング

各ステップに適切なエラーハンドリングを実装：

{
  "Query Training Job Status": {
    "Type": "Task",
    "Resource": "arn:aws:states:::eks:call",
    // ... 通常の設定
    "Retry": [
      {
        "ErrorEquals": ["States.TaskFailed"],
        "IntervalSeconds": 30,
        "MaxAttempts": 3,
        "BackoffRate": 2.0
      }
    ],
    "Catch": [
      {
        "ErrorEquals": ["States.ALL"],
        "Next": "Handle Error",
        "ResultPath": "$.error"
      }
    ]
  }
}

監視の可観測性向上

CloudWatchメトリクスとログを活用：

{
  "Log Status": {
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Parameters": {
      "FunctionName": "LogPyTorchJobStatus",
      "Payload": {
        "jobName.$": "$.jobName.pytorchJobName",
        "status.$": "$.ResponseBody.items[0].status",
        "timestamp.$": "$$.State.EnteredTime"
      }
    },
    "ResultPath": null,
    "Next": "Continue"
  }
}

リソースタグの活用

PyTorchJobに適切なタグを設定し、コスト管理と追跡を容易にする：

metadata:
  labels:
    job-name: ${PYTORCH_JOB_NAME}
    environment: production
    team: ml-team
    project: recommendation-engine
    cost-center: ml-research

まとめ

実装のポイント

eks:callによるポーリング: PyTorchJobのようなCRDの同期実行を実現
Job名の一貫性: 投入から監視まで同じ名前を使用し、確実な追跡を実現
status.conditions配列の全要素チェック: 配列順序の不定性に対応
600秒のポーリング間隔: API負荷と応答性のバランス
エラーハンドリング: 本番環境での安定性を確保

今後の改善案

1. イベントドリブンな監視

Kubeflow → EventBridge → Step Functions

ポーリングではなく、イベントベースの監視により効率化

2. メトリクスベースの動的間隔調整

{
  "CalculateWaitTime": {
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Parameters": {
      "FunctionName": "CalculateDynamicWaitTime",
      "Payload": {
        "expectedDuration.$": "$.estimatedTrainingTime",
        "elapsedTime.$": "$.elapsedTime"
      }
    }
  }
}

3. 並列監視の実装

複数のPyTorchJobを並列で監視し、全体のスループットを向上

完成した同期実行ワークフロー

前回記事の「投入」と今回の「監視」を組み合わせることで、完全な同期実行ワークフローが実現できます：

1. ConfigMap準備
    ↓
2. PyTorchJob投入（前回記事）
    ↓
3. Job名抽出（本記事）
    ↓
4. 状態監視ループ（本記事）
    ↓
5. 成功/失敗判定
    ↓
6. 後続処理（モデルデプロイ等）

これにより、Step FunctionsでPyTorchJobを含む複雑な機械学習パイプラインを構築できます。

付録

完全な実装コード

Step Functions定義（監視部分）

{
  "Comment": "PyTorchJob Monitoring State Machine",
  "StartAt": "Get Training Job Name",
  "States": {
    "Get Training Job Name": {
      "Type": "Pass",
      "Comment": "Extract PyTorchJob name from job result",
      "Parameters": {
        "pytorchJobName.$": "$.pytorchJobResult.metadata.name"
      },
      "ResultPath": "$.jobName",
      "QueryLanguage": "JSONPath",
      "Next": "Query Training Job Status"
    },
    "Query Training Job Status": {
      "Type": "Task",
      "Resource": "arn:aws:states:::eks:call",
      "Arguments": {
        "ClusterName": "eks-cluster-training",
        "CertificateAuthority": "{% $pytorchCertificateAuthority %}",
        "Endpoint": "{% $pytorchEndpoint %}",
        "Path": "/apis/kubeflow.org/v1/namespaces/ml-training-pipeline/pytorchjobs",
        "Method": "GET",
        "QueryParameters": {
          "labelSelector": [
            "{% 'job-name=' & $states.input.jobName.pytorchJobName %}"
          ]
        }
      },
      "Output": "{% $merge([$states.input, $states.result, {'pytorchCertificateAuthority': $pytorchCertificateAuthority, 'pytorchEndpoint': $pytorchEndpoint}]) %}",
      "QueryLanguage": "JSONata",
      "Next": "Evaluate Job Completion"
    },
    "Evaluate Job Completion": {
      "Type": "Choice",
      "Choices": [
        {
          "And": [
            {
              "Variable": "$.ResponseBody.items[0].status.conditions[0].type",
              "IsPresent": true
            },
            {
              "Variable": "$.ResponseBody.items[0].status.conditions[0].type",
              "StringEquals": "Succeeded"
            }
          ],
          "Next": "Training Completed Successfully"
        },
        {
          "And": [
            {
              "Variable": "$.ResponseBody.items[0].status.conditions[0].type",
              "IsPresent": true
            },
            {
              "Variable": "$.ResponseBody.items[0].status.conditions[0].type",
              "StringEquals": "Failed"
            }
          ],
          "Next": "Training Failed"
        }
      ],
      "QueryLanguage": "JSONPath",
      "Default": "Prepare Next Query"
    },
    "Prepare Next Query": {
      "Type": "Pass",
      "Parameters": {
        "jobName": {
          "pytorchJobName.$": "$.ResponseBody.items[0].metadata.labels['job-name']"
        },
        "pytorchCertificateAuthority.$": "$.pytorchCertificateAuthority",
        "pytorchEndpoint.$": "$.pytorchEndpoint"
      },
      "ResultPath": "$",
      "QueryLanguage": "JSONPath",
      "Next": "Wait Polling Interval"
    },
    "Wait Polling Interval": {
      "Type": "Wait",
      "Seconds": 600,
      "Next": "Query Training Job Status"
    },
    "Training Completed Successfully": {
      "Type": "Pass",
      "Comment": "PyTorchJob completed successfully",
      "End": true
    },
    "Training Failed": {
      "Type": "Fail",
      "Error": "PyTorchJobFailed",
      "Cause": "The PyTorchJob execution failed"
    }
  }
}

PyTorchJob status構造の詳細

典型的なPyTorchJob statusの例：

{
  "status": {
    "conditions": [
      {
        "lastTransitionTime": "2024-12-25T10:00:00Z",
        "lastUpdateTime": "2024-12-25T12:30:00Z",
        "message": "PyTorchJob training-job-20241225-123456 is successfully completed.",
        "reason": "JobSucceeded",
        "status": "True",
        "type": "Succeeded"
      }
    ],
    "replicaStatuses": {
      "Worker": {
        "succeeded": 1
      }
    },
    "completionTime": "2024-12-25T12:30:00Z",
    "startTime": "2024-12-25T10:00:00Z"
  }
}

参考リンク