【要約】大量ファイル移行を実装して見えた、バッチ処理で考慮すべきこと [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
ソーイ株式会社のエンジニアが、S3からWasabiへの大量データ移行において、単純な実装では運用に耐えられない課題に直面した。大量のデータを扱う際、単一のプロセスで処理を完結させようとすると、以下の問題が発生する。
- ・全件ループによる処理時間の増大とメモリ消費。
- ・巨大なジョブによる管理・リトライの困難さ。
- ・再実行時に重複処理が発生し、リソースを浪費する。
- ・進捗が不明で、障害時の原因特定や復旧が困難。
- ・移行直後のデータ削除により、不具合時の切り戻しができなくなる。
// Approach
開発者は、処理を細分化し、障害発生時でも安全に再開できるオーケストレーション構成を採用した。単一の巨大なジョブを避け、以下の手法で設計を最適化した。
- ・
chunkByIdによるメモリ負荷の抑制と非同期ジョブ化。 - ・責務を分離した4段階のジョブ構成（開始、チャンク、単一アイテム、削除）。
- ・移行管理テーブルを用いた冪等性の確保。
- ・進捗管理用テーブルによる可視化。
- ・猶予期間を設けた後続ジョブによるデータ削除。
// Result
この設計により、大規模なデータ移行における運用性と安全性が大幅に向上した。具体的な成果は以下の通りである。
- ・未処理データのみを対象とした効率的な再実行が可能。
- ・全体の進捗や失敗箇所が即座に特定可能。
- ・移行失敗時の切り戻し手段を確保し、データ消失リスクを低減。
Senior Engineer Insight
> 実戦的な設計思想である。単なる「実装」ではなく「運用」に主眼を置いている点が評価できる。特に、ジョブの分割と冪等性の担保は、分散システムにおける定石だ。ただし、管理テーブルの設計コストと、ジョブ投入によるDB負荷のトレードオフには注意が必要である。大規模環境では、ジョブの投入頻度によるDBのI/O負荷がボトルネックになり得るため、チャンクサイズの適切な調整が鍵となる。