LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@banquet_kuma(マルチンゲール)

PyTorchJobを投入した後は？Step Functionsで同期実行を実現する監視テクニック

Posted at

はじめに

前回記事の振り返り

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

本記事の目的

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

目次

  1. 背景とモチベーション
  2. 解決アプローチの全体像
  3. 実装の工夫点
  4. 実装の詳細
  5. PyTorchJobの状態監視の詳細
  6. 同期実行を実現するポーリング設計
  7. 実装コードの完全解説
  8. eks:runJob.sync vs eks:call 詳細比較
  9. トラブルシューティング
  10. ベストプラクティス
  11. まとめ
  12. 付録

背景とモチベーション

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を使って同期的な動作を実現します：

  1. PyTorchJob投入（前回記事の手法）

    • ConfigMap + Kubernetes Jobによる間接作成
    • Job名の取得と保持

  2. 状態監視ループ（本記事の焦点）

    • eks:callによる定期的な状態取得
    • status.conditions配列の評価
    • 完了判定またはループ継続

  3. 同期的な完了待機

    • ポーリング間隔の最適化
    • タイムアウト処理
    • 成功・失敗の適切な判定

監視アーキテクチャ図

image.png

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

  1. Get Training Job Name: PyTorchJob作成結果からJob名を抽出

  2. Query Training Job Status: eks:callでPyTorchJobの状態を取得

  3. image.png

  4. Evaluate Job Completion: status.conditions配列を評価

image.png

image.png

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

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

実装の工夫点

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"
}

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

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

  1. 追跡可能性: Kubernetes JobからPyTorchJobまでの一貫した名前により、デバッグが容易
  2. 検索効率: labelSelectorで確実にPyTorchJobを特定可能
  3. 運用性: ログやメトリクスで同じ名前を使用でき、問題追跡が簡単
// 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プレフィックス

各要素の説明：

  1. /apis: カスタムAPIグループ用プレフィックス（標準リソースは/api/v1）
  2. kubeflow.org: Kubeflowプロジェクトが所有するAPIグループ
  3. v1: Kubeflow Training OperatorのAPIバージョン（安定版）
  4. namespaces: Namespace指定を示す固定キーワード
  5. ml-training-pipeline: 対象のNamespace名
  6. 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の全要素をチェックする必要があります：

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

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
  }]) %}"
}

無限ループの回避策

実装上の考慮事項：

  1. Step Functions実行時間制限: 最大1年の制限内で動作
  2. タイムアウト設計: 必要に応じてカスタムタイムアウトロジックを追加
  3. 異常検知: 長時間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"
}

原因と対処

  1. PyTorchJob作成の失敗: 前段のジョブログを確認
  2. 名前の不一致: 環境変数PYTORCH_JOB_NAMEが正しく設定されているか確認
  3. タイミング問題: PyTorchJob作成直後の場合、若干の待機時間を追加
{
  "Wait Before Extract": {
    "Type": "Wait",
    "Seconds": 30,
    "Next": "Get Training Job Name"
  }
}

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

症状

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

原因と対処

  1. conditions配列の構造確認:
kubectl get pytorchjob training-job-xxx -n ml-training-pipeline -o json | jq '.status.conditions'

  1. 配列要素数の確認: 5要素より少ない場合は、Choice定義を調整

  2. Kubeflowバージョン確認: バージョンによってstatus構造が異なる可能性

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

症状

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

対処法

  1. 最大実行時間の設定:
{
  "TimeoutSeconds": 86400,  // 24時間
  "HeartbeatSeconds": 600
}
  1. カウンターによる制限:
{
  "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

まとめ

実装のポイント

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

今後の改善案

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"
  }
}

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?