【バッチ設計・バッチ処理】

過去にバッチ処理の実務を経験しました。
再度振り返り、学習しました。

野村友規様 ありがとうございます。

参考：実践Terraform AWSにおけるシステム設計とベストプラクティス 電子書籍版 / 野村友規

バッチ設計

バッチ処理は、オンライン処理とは異なる関心事を有している。

オンライン処理とは、コンピュータシステムの処理方式の一種で、
端末が通信回線などを通じてコンピュータ本体に接続し、
処理要求が発生した時点で即座に送信する方式。

IT用語辞典 e-Words より引用

アプリケーションレベルでどこまで制御して、ジョブ管理システムでどこまでサポートするかしっかり設計する必要がある。

バッチ設計の基本原則

ジョブ管理

一定の周期で実行されますが、誰かがジョプの起動タイミングを制御しなければならない。
　→ これがジョブ管理になる。この仕組みがが悪いと、最悪の時はジョブが全停止する。

cron

ジョブの管理実装で最も簡単なcronになる。
しかし、手軽な反面、きちんと管理することが難しい。
影響範囲の不明な謎のcronが発掘されるなど日常茶飯事です。
また、cronで管理されるバッチは大抵、エラーハンドリングやリトライも適当です。
依存関係制御もできず、cronを動かすサーバの運用にも手間がかる。

cronを用いた開発をしていた。
上記で書かれていたことを思い返してみるとそうだった気がしてくる。
エラーハンドリングやリトライについては、考えて開発されていなかったかも。
これらの重要かつ基本的な処理についてを抑えていこう。

ジョブ管理システム

システムが成長するとcronはすぐに限界がくる。
そこで多くの場合、「ジョブ管理システム」を導入します。
エラー通知やリトライ、依存関係制御の仕組みが組み込まれており、複雑なジョブの管理ができる。
ただし、ジョブ管理システムを稼働させるサーバーの運用は、課題として残ります。

cronとは、対照的こちらは経験したことがないので、改めて学習していく。

エラーハンドリング

エラーハンドリングでは「エラー通知」が重要。
なんらかの理由でバッチが失敗した場合、それを検知してリカバリーする必要がある。
スタックトレースなどの情報は、原因調査で必要になるため、確実にログ出力する。

Javaでの開発においては、例外処理で実装をした。
ログからエラーを追跡する処理の理解は今後の課題になる。
経験したことないので自作アプリの中で実装目指してみよう。

リトライ

リトライできるアプリケーションを設計することが超重要。

リトライバッチ処理が失敗した場合、リトライできなければなりません。
自動で指定回数リトライできることが望ましいです。少なくとも、手動ではリトライできる必要があります。

手動リトライは実装できていたと思う。
自動化で人的ミスを無くせるように今後意識していく。

依存関係制御

ジョブが増えてくると、依存関係制御が必要になる。
「ジョブAは必ずジョブBのあとに実行しなければならない」
単純に時間をずらして、暗黙的な依存関係生業を行う場合はあるが、アンチパターンなので避ける。

実務で実装した際は、初の開発だったこともあり、設計書通りの実装を求められていた。
上記の内容を振り返ってみると、アンチパターンの実装だった気がする。。
なぜ、アンチパターンなのかなど再学習する必要があると感じた。
過去のコードを見せてもらえると改善していけるから聞いてみよう。

おわりに。

去年の今頃の自分の振り返りをしてみた。
主体的に開発をおこなうことで気づきがあるとわかった。
今後もこれを続けていきたい。

自分の経験や知識や増えることが楽しい。
もっともっと貪欲に学んで、いろんな開発がしたい。