バッチを作成する勘所

サービスを開発して保守開発に移っていくとバッチでデータをまとめて処理することって絶対ありますよね。

最近結構バッチを作成する機会があったので、開発する上での気付きがあったのでまとめようと思います。

起動時間

まずそのバッチをいつ起動するかって話です。

処理の内容にもよりますが、ログやGoogleAnalyticsでユーザの行動を確認して、ユーザの少ない時間帯に起動するなど起動する時間を決めます。ユーザが多い時間帯に起動するとCPUやメモリを余計に使いますし、ユーザも使っていて急に表示が変わったりして混乱します。また、問題があった場合も簡単に戻せなくなったりユーザにエラーを表示したままになる可能性もあります。

実装する際はバッチ処理中に何か操作された場合、データが重複して登録されないかなども気をつけてましょう。

メモリ

次はメモリです。バッチ処理だとデータを一括更新するなどの機能が主になるかと思います。つまり、処理するデータ量が多いんですよね。なのでメモリに持つデータはなるべく少なくして無駄な処理を減らすのがベターです。

どれぐらいのデータを処理するのか、どのぐらいの要領になり余裕はどれぐらいあるのか予め確認しておく必要があります。

特に機能追加なのでデータを追加する際はデータが大きくなることがあるので確認しましょう。

SQL

上のメモリにも絡むのですが、扱うデータは必要なだけ取得し、必要な分だけ更新しましょう。

登録する時は登何万件もループ処理で１件づつ登録してるとかなり時間がかかるので、バルクインサートする様にしたほうがいいです。

更新はあまり時間やwebサーバのメモリを使いませんが、データを取得するとメモリを使いますし、処理の内容によってはかなり時間がかかります。

ポイントはどこまでアプリケーション側で処理してどこまでRDBSで処理するかってところです。

環境

ローカル環境で動作確認できても本番環境だと実際に登録されているデータの数が異なります。起動してみたらデータが多すぎて何時間も処理が重くなったり、メモリが足らなかったりってこともあるかもしれません。なので、本番環境に近い検証環境で実際にバッチを起動してみて、問題ないか確認しましょう。

確認用SQL

バッチを起動してみても、ミスをしている可能性がないこともないので、実際に実行したあとの結果を確認するSQLも確認しておきましょう。

あまり多くのデータを処理しないなら目視でもいいですが、大事な部分のデータでおかしいことに気づかないとあとで厄介な問題になったりすることがあります。

想定した分のデータが処理されているかはしっかり確認しましょう。