Batches

開発/運用においてバッチ処理が必要となることは往々に発生する

定期的にユーザーの状態を監視する

不要なデータを削除する

結果整合性を担保する処理

とか

ただ常駐しているアプリケーションサーバーとは実行するタイミング、内容など特徴が異なるため考慮すべきことがたくさんある

チェックリスト形式で実装するときに見直せるように書き出しておく

データベース

ロック

大量のレコードをロックしてしまうと他のクライアントからアクセスできなくなってしまう可能性がある

データベースによってロックのかかる範囲、挙動が異なるため要注意

トランザクション

レプリカ遅延

リアルタイム性が重要な処理の場合、レプリカ遅延を考慮する必要がある

一度に操作できるデータ量が多すぎないか

処理するデータ量は適切に分割して実行する

バッチによってデータベースに過度な負荷をかけてしまうとユーザー影響が出てしまう可能性がある

トランザクションのタイムアウトに引っかからないか

アプリケーションの実行

処理時間

サーバーは予期せず落ちることが普通に発生するので、実行時間が長いほど失敗する可能性が上がる

処理タイミング

イベントやゲームの日またぎなど、スパイクが発生しているタイミングは避けて実行する

並列性

並列に実行したときに問題なく動くか、or並列に動かせない場合は排他制御されているか

前述したデータベースのトランザクションの問題によって並列処理のタイミングによって結果が異なるといったことも発生しがち

ロールバック

途中で失敗してしまった場合のロールバック処理が適切に実装されているか

サーバーは予期せず落ちることが往々にして発生する

単一データベースの場合トランザクションのロールバックで事足りることが多いが、複数サービス、複数DBへのアクセスがある場合適切なロールバックを行うのは非常に難しい

リトライや結果整合のシステムによって解決できることがある

リトライ

処理に失敗した場合リトライするか否か

冪等性が担保されているか

冪等性

リトライなどで複数回実行した際に結果がずれないような処理になっているか

前の処理が成功したがリトライを行った場合、失敗する処理になっていないか

デバッグ

設定用にパラメータが用意されている場合、それは容易に変更できるか

問題が発生した場合すぐに処理を停止/再開することができるようになっているか

ログ

途中で失敗した場合でもどこまで作業が終わっているのか確認できるようにする

トランザクションを区切っている場合は特に重要

監視

どれくらいのリソースが使われているのか、問題は置きていないのか監視する

開始、進捗、終了など必要なタイミングで通知を行う

その他参考になりそうな記事