絶対に失敗してはいけないバッチ処理の作り方

この記事は NE Advent Calendar 2024 の14日目の記事です。

はじめに

こんにちは。NE開発部 CREチームの にしやまかなこ といいます。
6,000社の日々の運用を支えています。

クリスマスに似つかわしくない物騒なタイトルですが、絶対に失敗してはいけないバッチ処理をリリースするまでに考えたことを共有したいと思います

絶対に失敗してはいけないバッチ処理の特徴

今回開発したのは、弊社プロダクトのユーザのライフサイクルが終焉を迎え、弊社が保持してはいけなくなった個人情報を含むユーザの全データを、ルールに従って粛々と削除するバッチです。
概要からわかるように、このバッチは

• 性質上バックアップが取れない(個人情報を消さなければいけないので)
• 成功しても誰からも喜ばれはしない(※)が、失敗したら即インシデントになる

という、開発者としてはかなりのプレッシャーを感じる代物。
このバッチを如何に安全に実行できるか、というところがポイントになります。
(※プロダクトの機能的に充実するわけではない、という意味で)

失敗 = 絶対にあってはならない状態 を定義する

今回のバッチにおける失敗（絶対にあってはならない状態）とは何かを考えます。

無効になったアカウントを削除する処理での絶対にあってはならない状態 とは
処理が途中で止まった結果データが削除されない、ということではありません。
(正確にはそれも失敗ですが、後からいくらでもリカバリできます)

「想定していない状態の有効なアカウントが削除対象になってしまい、それが削除されてしまうこと」
です。

これは想像するだに恐ろしい事態です。
逆に言えば、これを防ぐことができれば、バッチ実行の度に怯えることなく、安心してバッチ実行できる、と言えます。

失敗を防ぐための条件

世の中に絶対はありませんが、限りなく0にすることはできそうです。

今回のバッチ処理では、管理システム上で対象企業を抽出し、対象となったアカウントをアプリ本体から内部API経由でデータを削除する、という仕組みでした。

管理システムの通常の運用であれば正しく対象企業を抽出する条件がもちろん組み込まれています（削除対象のステータスになってから◯◯日経過後、みたいなやつです）
しかし、そのステータス移動や契約の終了日付等の情報の変更は、一部人の手による温かみのある運用によって行われているものです。

人の手を介した運用によって移動したステータスや日付を元に対象データを抽出する際には、ルールから逸脱したデータが発生することを常に考える必要があります。
特にレガシーなシステムではよくあることです。（運用の都合上厳しいバリデーションがかけられないこともある）
また、２つのシステム間で整合性が取れていないケースも考えられます。
そんな不確実な状況下でも、

絶対に有効なアカウントは消さない

を実現するには、管理システム上で抽出したアカウントに対し、「指定した日より後にユーザが実際にアプリ本体にログインしている」という事実が無い
かどうかを追加で確認すればよさそうでした。

責任者と合意を取る

この条件で最悪の事態は防げそうだ、ということがわかったら関係者と合意を取ります。
何度も言いますが、世の中に絶対はありません。
考えたくはありませんが、ここまでチェックしただめだった、ということが万が一にも起こることは想定しておく必要があります。
そのため、責任者と合意を取っておくことは非常に重要です。

想定外の事態が発生したときの対処方法をあらかじめ考えておく

ここで言う想定外というのは、本来はありえないはずのことが起こる、という意味です。
今回の２つのシステムを股にかける処理では、アプリ本体側をロールバックする事ができなかったので、失敗したらそこで処理を終了し、通知だけする、というシンプルな処理になっています。
通知する内容には

• どのアカウントで
• どの処理で
• 何が起こった

という最低限のことと、FAQドキュメントへのリンクを記載するようにしました。

対象データをあらかじめ抽出しておく

抽出するクエリはあらかじめわかっているので、
バッチ実行時に対象になるアカウントをあらかじめ抽出し
関係各所に周知しておきました。

おわりに

絶対に失敗してはいけないバッチ処理を安全にリリースするためにやったことをご紹介しました。
今のところ、このバッチは順調に動いています。
クリスマスを平和に過ごすためにも、不必要な心配事はなるべく排除したいものですね。
ではみなさん、よいクリスマスを〜🎄