ジョブの再試行とチェックポイントのベストプラクティス

個々のジョブタスクやジョブ実行はさまざまな理由で失敗します。このページでは、タスクの再起動とジョブのチェックポイントを中心に、これらのエラーを処理するためのベストプラクティスについて説明します。

ジョブタスクの再起動を計画する

タスクの再起動で出力が重複したり、破損しないように、ジョブをべき等にします。つまり、反復入力の回数やタイミングに関係なく、特定の入力セットに対して同じ動作を行う反復可能なロジックを記述します。

入力データは変更せずに、入力データと別の場所に出力を書き込みます。そうすることで、ジョブを再度実行するときに、ジョブを最初からやり直して同じ結果を得ることができます。

同じ固有識別子を再利用するか、出力がすでに存在するかどうか確認することで、出力データの重複を避けることができます。重複データは、コレクションレベルのデータの破損を表します。

ジョブにチェックポイントを設定することで、障害発生後にタスクが再開したときに、タスクを最初からではなく、中断したところから再開できます。これにより、ジョブが高速化されるだけでなく、不要なコストを最小限に抑えることができます。

結果の一部を定期的に書き込み、Cloud Storage やデータベースなどの永続ストレージロケーションに対する進行状況を確認します。タスクを開始するときに、起動時の結果の一部を確認します。結果の一部が見つかった場合は、その続きから処理を開始します。

ジョブがチェックポインティングに適していない場合は、ジョブを小さなチャンクに分割して、より多くのタスクを実行することを検討してください。

再帰的アルゴリズム（円周率を小数点以下まで計算するなど）を実行し、並列処理の値を 1 に設定したジョブがあるとします。

10 分ごと、または失われる作業許の容範囲内で、進捗状況を pi-progress.txt Cloud Storage オブジェクトに書き込みます。
タスクが開始したら、pi-progress.txt オブジェクトをクエリして、その値を出発点として読み込みます。この値は、関数の最初の入力として使用します。
最終結果を pi-complete.txt というオブジェクトとして Cloud Storage に書き込み、並列実行や繰り返し実行による重複を回避します。また、完了日で区別するために pi-complete-DATE.txt を使用します。

Cloud SQL などのリレーショナルデータベースで 10,000 件のレコードを処理するジョブがあるとします。

SELECT * FROM example_table LIMIT 10000 などの SQL クエリで処理するレコードを取得します。
更新されたレコードを 100 個のバッチで書き出します。これにより、中断しても重要な処理が失われることはありません。
レコードが書き込まれたら、どのレコードが処理されたかをメモします。処理が確認された場合にのみ、1 に設定されたブール値の列をテーブルに追加できます。
タスクの開始時に、処理するアイテムを取得するクエリを実行すると、処理された条件が 0 になっているはずです。
この手法では、クリーンな再試行だけでなく、クエリを分割して小さなタスクに分割することもできます。たとえば、クエリを変更して一度に 100 件のレコード（LIMIT 100 OFFSET $CLOUD_RUN_TASK_INDEX*100）を選択し、100 件のタスクを実行して 10,000 件のすべてのレコードを処理します。CLOUD_RUN_TASK_INDEX は、Cloud Run ジョブを実行するコンテナ内に存在する組み込み環境変数です。

これらの要素をすべて組み合わせると、最終的なクエリは次のようになります。 SELECT * FROM example_table WHERE processed = 0 LIMIT 100 OFFSET $CLOUD_RUN_TASK_INDEX*100