バッチ・ジョブ・ワークロード
IBM Cloud® Code Engine は、バッチ・ジョブやアプリケーション・ワークロードなど、コンテナー化されたワークロードを実行する、完全に管理されたサーバーレス・プラットフォームです。 バッチジョブの実行については Code Engineを参照してください。
バッチ・ジョブ・ワークロードとは
Code Engine のジョブは、あなたの実行コードの1つ以上のインスタンスを実行します。 HTTP リクエストを処理するアプリケーションとは異なり、ジョブは一度だけ実行して終了するように設計されており、ジョブのワークロードを実行するためのリソースが解放されます。
複数のインスタンスを定義することで、バッチ・ジョブをスケーリングできます。 ワークロードを並列タスクに分割して、計算時間を短縮することができます。 ジョブ・インスタンス内の失敗したワークロードに対処するために、自動再試行で実行するようにジョブを設定できます。 バッチ・ジョブは、手動、プログラム、およびイベント ( Object Storage イベントなど) によってトリガーできます。
ジョブの作成時に、ジョブが実行されるたびに使用されるワークロード構成情報を指定できます。
典型的なバッチジョブのワークロードは以下の通りである:
- マシンモデルのトレーニング
- 音声分析や画像認識などのファイル分析
- ファイルの圧縮・解凍
- 情報のアーカイブ
ジョブを作成するときには、ジョブの実行時に毎回使用するワークロードの構成情報を指定できます。
バッチ・ジョブのライフサイクルとは何ですか?
バッチ・ジョブをサブミットすると、バッチ・ジョブは完了するまで実行されます。 通常、バッチ・ジョブは入力データを取得し、計算作業を行い、結果を永続データ・ストアに保管します。 バッチ・ジョブが完了すると、ジョブの実行に使用されるリソースは削除され、スタンバイ・リソースのコストは発生しません。
ジョブアレイとジョブアレイステータスとは何ですか?
ジョブ配列の指定は、ジョブおよびジョブ実行の設定の一部です。 ジョブ配列には2つの機能があります
- ジョブ実行時に開始される同時インスタンスの数を決定します。
- これにより、ユーザーコードは、各インスタンスが実行すべき作業のどの部分を、個々の配列インデックスに基づいて決定することができます。
配列サイズまたは配列インデックスのセットのいずれかにより、ジョブ配列を指定します
-
配列サイズを値 n で指定すると、ジョブ実行用に開始されるインスタンスの数は n となります。 各インスタンスには、
JOB_INDEX環境変数を使用して、配列インデックス(0、1、2、...、 _n-1_まで )が割り当てられます。JOB_ARRAY_SIZE環境変数は、特定の値を指定しない限り 、n に設定されます。 -
1つまたは複数の配列インデックスを指定した場合、起動されるインスタンスの数はインデックスの数になります。 各インスタンスには、
JOB_INDEX環境変数を使用して、指定されたインデックスのいずれかが提供されます。JOB_ARRAY_SIZE環境変数に特定の値を指定しない限り、指定されたインデックス数が設定されます。
JOB_ARRAY_SIZE 環境変数はユーザーコードでも利用可能であり、デフォルトではインデックスの数に設定されています。
インスタンスが正常終了の戻りコードで終了した場合、関連付けられた配列インデックスのステータスが完了に変更されます。 それ以外の場合、設定された再試行回数をまだ超えていない場合は Code Engineが同じインデックスに対して新しいインスタンスを開始します。 インスタンスが失敗し、再試行が許可されていない場合、関連する配列のインデックスはそのステータスを「失敗」に変更します。
Code Engine バッチ・ジョブを操作する際の主な機能は何ですか?
Code Engineでバッチ・ジョブを処理する方法について詳しくは、以下のトピックを参照してください。
分離
Code Engine は、リージョン別のマルチテナント・サービスであり、複数のテナントが同じネットワークとコンピュート・インフラストラクチャーを共有します。 特に、ネットワークとコンピュート・インフラストラクチャーは共有リソースであり、一部の管理コンポーネントはすべてのテナントに共通です。 ただし、テナントとそのワークロードは、 Code Engine プロジェクトを使用して相互に分離されます。 Code Engine は、プロジェクト間の通信を防止し、マルチテナント環境内のアプリケーションを分離します。 さらに、リソース・レベルで実行されるアクセス制御により、許可されたユーザーのみがプロジェクト・リソース (アプリケーションやその他の Code Engine ワークロードなど) に対して特定の操作を実行できるようになります。
ワークロードの分離について詳しくは、 Code Engine ワークロードの分離 を参照してください。
ロギング
ロギングを有効にしてコンソールで 'Code Engineジョブを操作すると、ログは 'Code Engineプロジェクトに関連付けられている 'IBM Cloud Logsサービスインスタンスに転送されます。 IBM Cloud Logsサービスインスタンスでは、ログはインデックス化され、生成されたすべてのメッセージの全文検索と、特定のフィールドに基づく便利なクエリが可能になります。 ジョブのログの取得 を参照してください。
システムイベント情報は、ジョブを実行する際のトラブルシューティングにも役立ちます。 CLI を使用してシステム・イベント情報を表示できます。 ジョブのシステム・イベント情報の取得 を参照してください。
詳しくは、ログの表示を参照してください。
キューイング
実行依頼されたバッチ・ジョブは自動的にキューに入れられ、ディスパッチされるまで保留状態になります。 バッチ・ジョブは、 Code Engine プロジェクトで定義された使用可能な計算リソースに基づいて実行されます。 pending 状況のバッチ・ジョブは、キューから除去できます。 Code Engine コンソールまたはコマンド・ライン・インターフェースを使用して、保留中、実行中、または完了済みのバッチ・ジョブをモニターできます。
再試行
各ジョブ・インスタンスが完了するまで実行されます。 ただし、ジョブの実行中にワークロード・コードでエラーが発生する場合があります。 ジョブ・インスタンスがゼロ以外の戻りコードで完了すると、 Code Engine はジョブ・インスタンスを再始動します。 Code Engineで、失敗したジョブ・インスタンスの再始動を回避するために再試行回数を制限するように指定できます。
バッチ・ジョブの実行
コードがソースとしてローカルファイルや Git リポジトリに存在するか、コードがパブリックまたはプライベートレジストリに存在するコンテナイメージであるかにかかわらず、 Code Engine は、コードをジョブとして実行するための合理的な方法を提供します。
以下の方法で、 Code Engine でバッチ・ジョブを作成して実行できます。
- 既存のコンテナイメージを実行する。 ジョブを作成し、ジョブのサブミット時に使用するイメージへの参照を指定します。 例については、 ジョブの作成と実行 を参照してください。
- ソース・コードから開始します。 Git リポジトリーまたはローカル・ワークステーションにあるソース・コードから開始する場合は、ソースの場所を指すことができ、 Code Engine によってイメージの作成が行われます。 リポジトリー・ソース・コードからのジョブの作成 および ローカル・ソース・コードからのジョブの作成 を参照してください。
詳しくは、 ジョブの処理 を参照してください。
スケーリング
Code Engine (バッチ・ジョブ) 内のジョブは、1 つ以上のジョブ・インスタンスで構成されます。 ジョブ・インスタンスは互いに独立して実行されますが、同じコードを実行します。 分析するレコードが 100 個あるデータベースがあるとします。 各ジョブ・インスタンスがそれぞれ 10 個のレコードを分析するようにジョブを実行できます。 例えば、最初のジョブ・インスタンスはレコード 0 から 9 を分析し、2 番目のジョブ・インスタンスはレコード 10 から 19 を分析する、というようになります。
この例では、各ジョブ・インスタンスは、システム提供のジョブ入力パラメーター JOB_INDEX を環境変数として受け取ります。この環境変数を使用して、各ジョブ・インスタンスで分析するデータベース・レコードの範囲を計算できます。 ジョブ・インスタンスの数は、バッチ・ジョブの実行依頼時に指定されます。
バッチ・ジョブを実行すると、起動時に、インスタンスが開始されている間、ジョブ・インスタンスが保留状態のままになることがあります。 ジョブ・インスタンスの保留時間は、ジョブのこの実行に関連するリソース要求を満たすようにシステムが調整するため、システムおよびネットワーク・インフラストラクチャーによって異なる可能性があります。 システム・インフラストラクチャーが高い使用量の要求に対応している場合、ジョブ・インスタンスがジャストインタイムでプロビジョンされるため、結果としてジョブの始動が数分間遅延する可能性があります。
ステータス
すべてのジョブ実行インスタンスが完了すると、バッチ・ジョブは Succeeded 状況になります。
1 つ以上のジョブ実行インスタンスが再試行限度に達すると、バッチ・ジョブは Failed 状況になります。 また、ジョブの完了に時間がかかりすぎると、最大実行時間に達するたびにジョブは Failed 状況になります。 詳しくは、 ジョブ状況 を参照してください。
類似のバッチ・ジョブの実行依頼
ジョブを作成するときには、ジョブの実行時に毎回使用するワークロードの構成情報を指定できます。 Code Engineでバッチ・ジョブの共通構成情報セットを使用する場合、ジョブのサブミットに追加パラメーターを指定して、この特定のジョブのサブミットのバッチ・ジョブ・パラメーターを上書きすることができます。
イベントによるバッチ・ジョブのトリガー
バッチ・ジョブは、定期的タイマー、 Object Storage イベント、または Kafka トピックなどのイベントに基づいて自動的にサブミットできます。
ファイルが変更されるか、 Object Storage バケットに追加されるたびにイベントを生成する IBM Cloud Object Storage バケットへのサブスクリプションに基づいて、バッチ・ジョブを自動的にトリガーするとします。 Object Storage イベントを作成し、そのイベントを使用してバッチ・ジョブをトリガーする方法については、 Code Engine cos-event-job サンプル を参照してください。
Code Engine ジョブでのイベント処理の使用について詳しくは、 定期的タイマー(クーロン)イベント・プロデューサーの操作、 IBM Cloud Object Storage イベント・プロデューサーの操作、および Kafka イベント・プロデューサーの操作 の各トピックを参照してください。
コード・サンプルがさらに必要ですか? IBM Cloud Code Engine GitHub repoをチェックアウトします。
バッチ・ジョブを開始するにはどうすればよいですか?
icr.io/codeengine/firstjob サンプル・イメージを使用して単純な Code Engine バッチ・ジョブ・アプリケーションを作成して実行するには、 最初の Code Engine ジョブの実行 を参照してください。
また、バッチ・ジョブ・チュートリアルを試すこともできます。 ジョブの実行および更新 を参照してください。
バッチ・ジョブの処理について詳しくは、 ジョブおよびジョブ実行の処理 を参照してください。