バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング
こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する
多い日も安心設計 - Qiita
アプリケーションエンジニアの多くは、眠れない夜を過ごしたことがあるでしょう。特に月に一度の…「月末締めバッチ」の日は。 そんなデータ量の多い日や、初モノのバッチが動く日でも安心して眠れるためのバッチ設計を考えてみます。 ログの設計 まず何はなくともログです。きちんとしたメッセージを出せていれば、専任の人がリカバリ可能にもなるってものです。 Audit用のログなど業務要件の強いものを除いては、だいたい3種類に分けるようにしています。 プログレスログ リカバリログ 例外ログ(調査のため) この分類でファイル単位も分けます。ログを必要とする人が、それぞれ異なるからです。 プログレスログ プログレスログは、特に長時間かかるバッチに対して、現在どのくらいまで処理が出来ているのかを目的として出力します。 トラブル発生時や、大規模移行作業時には、バッチの定期的なモニタリングと報告の必要が出てきます。「あ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
