教科書に載っていないけど、よい設計。 - Qiita
文献やネットを調べれば、どこかにあるのかもしれない。 入社3年目の頃、目から鱗が落ちるというか、ちょっとした感動、感銘を受けた良い設計の話。 とあるバッチ処理で感銘を受けた良い設計 I.感銘を受けた良い設計 II.業務要件通りの設計なのだが、今一歩足りていない設計 何故感銘を受けたか？ 業務要件では、「○○に合致したトランザクションレコードを削除のこと」というものでした。 そのまま写像すれば、II.の設計になると思いますが、I.の方が多少手間はかかっていますが、色々良いことがあり、それで感銘を受けました。 感銘を受けたこと(1)：テストがしやすい ①.削除対象リストを作るまでで、JOBを止めることができるので、要件通りに削除対象が抽出されているかテストしやすい。 (脱線：この「テストしやすい」については、他にも思うことがり、別記事を書きたいことです)。 上記II.の設計だとトランザクション
多い日も安心設計 - Qiita
アプリケーションエンジニアの多くは、眠れない夜を過ごしたことがあるでしょう。特に月に一度の…「月末締めバッチ」の日は。 そんなデータ量の多い日や、初モノのバッチが動く日でも安心して眠れるためのバッチ設計を考えてみます。 ログの設計 まず何はなくともログです。きちんとしたメッセージを出せていれば、専任の人がリカバリ可能にもなるってものです。 Audit用のログなど業務要件の強いものを除いては、だいたい3種類に分けるようにしています。 プログレスログ リカバリログ 例外ログ(調査のため) この分類でファイル単位も分けます。ログを必要とする人が、それぞれ異なるからです。 プログレスログ プログレスログは、特に長時間かかるバッチに対して、現在どのくらいまで処理が出来ているのかを目的として出力します。 トラブル発生時や、大規模移行作業時には、バッチの定期的なモニタリングと報告の必要が出てきます。「あ
AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05
This document provides an overview of Elastic Load Balancing (ELB) on AWS. It discusses the different types of ELBs (Application Load Balancer, Network Load Balancer, Classic Load Balancer), their key features and how they can be used to build scalable and highly available systems by distributing traffic across multiple Availability Zones and targets like EC2 instances or ECS containers. It also c
大量データをスムーズに処理 失敗しないバッチ処理のアーキテクチャ設計、5つのポイント
バッチ処理とは 前回はWebアプリのアーキテクチャ設計の基礎を解説しました。今回はバッチ処理を円滑に行うためのアーキテクチャ設計のポイントを紹介します。 バッチ処理とは、蓄積された複数件のデータを、まとめて一括処理する処理形態のことを指します。このような処理形態においては、大量データの処理を一定時間以内に完了させるためのアーキテクチャを、さまざまな角度から検討していく必要があります。 また、画面オンライン処理とは異なり、ユーザーとの対話なく処理が進められます。よって、バッチ処理の途中でエラーが発生した場合の対応を考慮して、アーキテクチャを設計しなければなりません。バッチ処理の基本についてより深く知りたい方は、下記参考記事をご参照ください。 参考リンク:鉄板焼のお店から学ぶ、バッチ処理"超"入門（＠IT） バッチ処理におけるアーキテクチャ設計時の検討ポイント バッチ処理のアーキテクチャを考え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
