1. 導入
マイクロサービスにおいて、データベースのマイグレーションや定期的なデータ集計、ログのクリーンアップといった「バッチ処理」は不可欠です。しかし、Podがいつ終了するか分からない環境で、単なるスクリプト実行では信頼性が確保できません。KubernetesのJobとCronJobを活用することで、処理の成功保証、失敗時のリトライ、並列実行制御を宣言的に管理でき、運用負荷を大幅に軽減できます。
2. 基礎知識
Jobは、指定されたタスクを完了するまでPodを実行し、成功したら終了するリソースです。一方、CronJobは、UNIXのcronのようなスケジュール（分 時 日 月 曜日）に基づいて、定期的にJobを生成します。これらは単なるコンテナ起動とは異なり、Podが異常終了した際に自動で再試行する仕組みや、完了後にリソースを解放するライフサイクル管理が組み込まれている点が重要です。
3. 実装/解決策
バッチ処理を設計する際は、冪等性（べきとうせい）を意識することが重要です。リトライが発生した際、同じ処理が二度実行されてもデータが壊れないように設計します。また、`backoffLimit`（リトライ回数）や`activeDeadlineSeconds`（処理のタイムアウト制限）を適切に設定することで、ゾンビ化したバッチがリソースを占有し続ける事態を回避します。
4. サンプルプログラム
以下は、毎日午前3時にデータバックアップを実行し、失敗時は3回までリトライするCronJobの定義例です。
＜YAMLファイル: backup-cronjob.yaml＞
apiVersion: batch/v1
kind: CronJob
metadata:
name: daily-backup
spec:
# 毎日午前3時に実行
schedule: “0 3 ”
# 正常終了したJobの履歴を3つ保持
successfulJobsHistoryLimit: 3
jobTemplate:
spec:
# 失敗した場合、3回まで再試行
backoffLimit: 3
template:
spec:
containers:
- name: backup-container
image: my-backup-tool:latest
# 処理を実行するコマンド
command: [“/bin/sh”, “-c”, “python3 /app/run_backup.py”]
# 再起動ポリシーはOnFailureかNeverを指定
restartPolicy: OnFailure
5. 応用・注意点
現場でよくある失敗として、「並列実行制御」の考慮漏れがあります。`concurrencyPolicy`をデフォルトの`Allow`にしていると、前回の処理が終わっていないのに次のスケジュールが来てしまい、処理が重複してデータ競合を引き起こすことがあります。確実に1つずつ実行したい場合は、`concurrencyPolicy: Forbid`を設定してください。また、バッチ処理が長引く場合は、監視システムと連携して「ジョブが規定時間内に終了したか」をアラート通知するようにすると、運用の安全性が格段に高まります。
コメント