ジョブの並列実行

IBM Cloud® Code Engine でジョブを運用効率よく実行する方法をご紹介します。

ジョブ処理で多数のファイルを効率的に処理

IBM Cloud Object Storage バケットに保管されているファイルが多数あり、 Code Engineでバッチ処理を使用するとします。目的は、1 つのバケットからファイルを読み取り、最も効率的な方法でファイルを操作し、それらのファイルを別の Object Storage バケットに保管することです。毎日、入力バケットに 2000 個のファイルがあるとします。すべてのファイルは異なるファイル名を持ち、ファイル名は英字 (A から Z、a から z) で始まります。

このシナリオのソリューションを計画する際には、まずイベント・ベースのソリューションについて考えます。この場合、入力 Object Storage バケットに書き込まれるすべてのファイルに対して、イベントが作成され、 Code Engine アプリケーションが呼び出されます。イベントを使用すると、1 つのファイルで個々の処理がトリガーされることがあります。これは、多くのファイルでは非効率的な場合があります。

バッチ・ジョブを実行する方がより良い方法ですか? はい、できます。バッチ・ジョブが複数のファイルを一緒に処理するのに適している理由を説明します。

ファイルのセットを並列ストリームに分割する方法を決定します。ファイル名の最初の文字に基づいてファイルを分割しましょう。この方法では、26 個のストリームを持つことができます。各ストリームは、1 つの特定の文字で始まるファイルを処理します。実行中のジョブ・インスタンスの自動注入された JOB_INDEX 環境変数を読み取ることにより、特定のストリームを識別できます。「ジョブの環境変数の自動注入」を参照してください。この例では、インスタンスの数を 26 として指定するか、配列索引を 0-25 として指定することにより、ジョブ・インスタンスを構成できます。

実行中の各ジョブ・インスタンスには、0 から 25 の索引が割り当てられます。コードで、以下のパターンを使用して、入力データをジョブ・インスタンスに配布します。
- JOB_INDEX=0 のジョブ・インスタンスは、 A または a で始まるファイルに対して機能します。
- JOB_INDEX=1 のジョブ・インスタンスは、 B または b で始まるファイルに対して機能します。
- JOB_INDEX=2 のジョブ・インスタンスは、 C または c で始まるファイルに対して機能します。
- [D ... y]
- JOB_INDEX=25 のジョブ・インスタンスは、 Z または z で始まるファイルに対して機能します。
各ストリームは複数のファイルを処理するため、ストリームのキューの長さは、単一ストリームによって処理されるファイルの数として定義します。
Code Engineで、ジョブとその構成を作成します。
- ジョブ配列索引を 0-25 として指定します。これは、26 個の並列ストリームを表します。
- ジョブの CPU およびメモリー・リソースを指定するか、デフォルトを使用します。各ジョブ索引は、ジョブに指定したものと同じ CPU およびメモリー・リソース (例えば、1 vCPU と 4 GB のメモリー) を取得します。
ジョブを実行します。 Code Engine コンソールで、保留中、実行中、および完了済みのジョブ索引の数を表示できます。最後のジョブ索引の実行が完了すると、ジョブは終了します。

データのサブセットを処理し、並列ジョブ実行インスタンスに動的に作業を割り当てる

特定の数の並列インスタンスに制限されないようにするとします。

前のシナリオでは、26 個の並列ストリームが定義され、実行依頼されたジョブ実行が、定義された 26 個の並列ストリームで実行されました。

ただし、特定の数の並列インスタンスに制限したくない場合に、特定のジョブ実行インスタンスにワーク・ストリームを動的に割り当てるジョブを実行するとします。この場合、 JOB_INDEX 環境変数と JOB_ARRAY_SIZE 環境変数の両方を使用して、処理する作業ストリームを決定する値を派生させることができます。これらの環境変数は、ジョブに対して自動的に注入されます。

JOB_INDEX 環境変数は、特定のジョブ実行インスタンスの索引の値です。
JOB_ARRAY_SIZE 環境変数は、並行して実行するジョブ・インスタンスの数を指定します。この値は、ジョブ実行の配列サイズとして直接指定されるか、指定された配列索引をカウントして計算されます。

例えば、配列サイズを 10 に構成して、各ジョブ実行インスタンスがデータ全体の 10% を処理するようにしたとします (10 個のジョブ実行インスタンスが並行して実行されます)。この構成設定では、 JOB_INDEX 環境変数によって、データの 10% チャンクのうちのどれを処理するかが決定され、 JOB_ARRAY_SIZE の計算値は 10 になります。

ただし、最初の 10 個のジョブ実行インスタンスのうち 3 個を再実行するとします。これらのインスタンスは以前に失敗したためです。データの残りの 70% は正常に処理されました。ジョブ実行を再実行依頼するときに、特定の 3 つの失敗した索引を指定する必要があります。索引 3、 7、および 9 を再実行するとします。

この新しいジョブ実行では、例えば "3, 7, 9" のように、配列添字のみを更新します。 JOB_ARRAY_SIZE 環境変数の値は、配列サイズではなく配列添字が指定されたときに自動的に計算されるため、 JOB_ARRAY_SIZE の値は、3 つの配列添字が指定されたため、10 ではなく 3 になります。

代わりに、ジョブ実行依頼 (または再実行依頼) アクションが、指定された索引 3、 7、および 9 の正しいデータ・チャンクを確実に処理するようにするために、CLI で --array-size-var-override オプションを使用するか、コンソールの JOB_ARRAY_SIZE 入力フィールドにカスタム値を指定することで、 JOB_ARRAY_SIZE 環境変数の自動計算値をオーバーライドできます。

カスタム配列サイズのオーバーライド値を10に設定することで、ジョブ実行インスタンスはチャンクサイズを10%として正しく計算し、再提出されたジョブ実行インスタンスは希望するデータ（インデックス 3、 7、 9 ）を処理します。このオプションを使用すると、一部のジョブ・インスタンスのみが実行依頼または再実行依頼されるジョブ再実行シナリオで、配列サイズの値を一定にすることができます。

このジョブ実行アプローチを実装した後、パラレル・ジョブ実行の数を動的に増減できます。

JOB_INDEX 環境変数を使用してジョブ実行作業ストリームの関係を定義する方法とは異なり、この方法では、 JOB_ARRAY_SIZE 環境変数をオーバーライドして作業ストリームを動的に割り当てる方法の方が柔軟性が高く、ニーズに合わせて特定のジョブ実行を適応させることができます。

並列バッチ・ジョブの実行の利点

この並列バッチ・ジョブの実装方法には、利点があります。

初期化の削減-1 つのジョブ索引が類似した開始文字を持つファイルを処理するため、ジョブ索引ごとに必要な初期化または接続セットアップは 1 つのみです。この方法により、ファイルごとに個別に初期化する場合と比較して、リソースとコストを節約できます。パラレル・ジョブ・ソリューションには、2000 個の初期化ではなく、26 個の初期化があります。
効率的なリソース使用-タスクを並列の長時間実行ストリームに分割することで、このソリューションは使用可能なリソースをより効率的に使用し、処理速度は最大化されます。

並列バッチ・ジョブを計画する際の考慮事項

並列バッチ・ジョブ・ソリューションを計画する際には、以下の点を考慮してください。

並列ジョブ索引とキューの長さのバランスを取る-ストリームの数 (並列ジョブ索引) とキューの長さのバランスをうまく取ることが不可欠です。ジョブ索引が少なすぎると、使用可能なリソースを完全に使用できません。一方、索引が多すぎると、初期化処理が増加し、クラウド・サービス ( Object Storageなど) の負荷が増大する可能性があります。この影響により、他のクラウド・サービスを呼び出すときにレート制限が発生する可能性があります。
類似したジョブ処理時間-ソリューションを計画する際には、各ジョブ索引がそのタスクを完了するのにほぼ同じ時間を要することを考慮してください。処理時間が原因でリソース使用量が非効率的になり、ジョブ処理時間が長くなる可能性があるため、1 つのジョブ索引が他のジョブ索引よりも著しく時間がかかるシナリオは避けてください。
複数のジョブの使用-前のシナリオでは、複数のジョブを使用する方法が異なります。これらの複数のジョブは、構成されたアレイ索引に依存しません。代わりに、2 つのバッチ・ジョブを作成することを検討してください。1 つは A - Z で始まるファイル用で、もう 1 つは a - z で始まるファイル用です。コードを変更しなくても、処理要件とリソースの可用性に基づいて、これら 2 つのジョブを並列または順次にトリガーすることができます。
ジョブ・トリガー・メカニズム-特定の間隔で cron サブスクリプションを使用してジョブをトリガーするか、 Object Storage バケットで新規ファイルをモニターし、必要に応じてバッチ処理を開始するトリガー・アプリケーションを使用してジョブをトリガーするかを選択できます。シナリオに応じて、ファイルがバケットに書き込まれた後に処理される速度の応答時間と比較して、コスト効率のために Code Engine の使用を最適化できます。