Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
NetadashiMeetup#13 バッチは地味だが役に立つ2
Search
HayashiYuichiro
January 30, 2025
Technology
200
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
NetadashiMeetup#13 バッチは地味だが役に立つ2
NetadashiMeetup#13
https://peatix.com/event/4164349?lang=ja-jp
HayashiYuichiro
January 30, 2025
More Decks by HayashiYuichiro
See All by HayashiYuichiro
JJUG CCC 2025 Fall バッチ性能!!劇的ビフォーアフター
hayashiyuu1
1
950
社内での開発コミュニティ活動 ~バッチ処理方式設計とSpringBootでのバッチ開発~
hayashiyuu1
1
1.2k
Other Decks in Technology
See All in Technology
AIに会社の文脈を理解させる技術~上流工程・非エンジニアにも広げるハーネスエンジニアリング実践~
ochtum
0
190
DORA_Metrics.pdf
wagnerfusca
1
140
形式手法を使って仕様をコーディングしよう
mikanichinose
0
140
なぜAI任せのゲームは面白くならないのか?
hirohasuyoutube
0
320
手を動かして実感する、Kiro が変える開発体験
inariku
0
420
Lambda MicroVMsは常駐サーバーの代わりに なるか? Kiro Crew を動かして検証してみた / Kiro Crew on Lambda MicroVMs
k_adachi_01
2
340
顧客の成果創出とプロダクトの成長を 両立するためのFDE
sansantech
PRO
0
490
Claude起点の仕様駆動開発
tanakaseiya
0
200
Snowflake Horizon Catalog と Apache Iceberg で作る オープンなデータ基盤
kitagawaz
0
330
KanaAI
shreyas1009
0
120
なぜ「決定性」が 決定的に重要なのか? Durable Execution 基盤の数理的理解 #serverlessjp / ServerlessDays Tokyo 2026
ytaka23
4
1.4k
ボードゲームの遊び相手をFoundation Modelsで作る / iOSDC Japan 2026
genda
0
230
Featured
See All Featured
Ten Tips & Tricks for a 🌱 transition
stuffmc
1
240
Practical Orchestrator
shlominoach
192
12k
Exploring anti-patterns in Rails
aemeredith
4
520
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
How to Ace a Technical Interview
jacobian
280
24k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
50
10k
Reality Check: Gamification 10 Years Later
codingconduct
0
2.3k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
6.1k
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
3
4.3k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
360
31k
What does AI have to do with Human Rights?
axbom
PRO
1
2.4k
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.6k
Transcript
バッチは地味だが役に立つ2 2024/11/22 株式会社 野村総合研究所 林優一郎
「バッチは地味だが役に立つ」とは? 2017年(前職時)のJSGU(日本Springユーザグループ) 勉強会の発表したタイトルであり、SlideShareで一般公開 されています。 今回もバッチということで 「バッチは地味だが役に立つ2」 としてバッチ設計について話します!
今回の内容について 2024/10/27 開催のJJUG CCC 2024 Fall の続き的な内容です JJUG CCC では実装関係を中心に話しましたが、今回は設計メインの内容です
目次 バッチとは? 01 バッチアプリケーション設計で大切なこと 02
バッチとは? 01
バッチの定義 バッチの定義はヒトやプロジェクト等によって異なる! バッチの語源通りに分類する派 と考えています 語源の通り一定量のデータ処理するものを バッチ処理方式であるとしつつ、 ファイル削除やマスタレコード更新などの 単発処理もバッチ処理として見なす派 バッチ=群、団、束 (引用:weblio英和時点・和英辞典)
語源の通りバッチとは一定量のデータを 処理する処理方式であるとし、 ファイル削除やマスタレコード更新などの 単発処理はバッチ処理ではないとする派 実行形態で分類する派 言葉の定義としてはこちらが正 システム開発現場ではこちらの考えが多い印象 スケジュール/イベント/手動で起動
バッチの定義 バッチの定義はヒトやプロジェクト等によって異なる! バッチの語源通りに分類する派 と考えています 語源の通り一定量のデータ処理するものを バッチ処理方式であるとしつつ、 ファイル削除やマスタレコード更新などの 単発処理もバッチ処理として見なす派 バッチ=群、団、束 (引用:weblio英和時点・和英辞典)
語源の通りバッチとは一定量のデータを 処理する処理方式であるとし、 ファイル削除やマスタレコード更新などの 単発処理はバッチ処理ではないとする派 実行形態で分類する派 言葉の定義としてはこちらが正 システム開発現場ではこちらの考えが多い印象 スケジュール/イベント/手動で起動 私はこっち派
バッチに関連する単語 プロジェクトや利用ツールによって単語やニュアンスが異なる Webアプリ以上に単語の定義や包含関係の明確化が重要 バッチ ジョブ タスク ジョブ ネット グループ フレーム
ステップ ウインド ウ DAG ワーク フロー
バッチに関連する単語 プロジェクトや利用ツールによって単語やニュアンスが異なる Webアプリ以上に単語の定義や包含関係の明確化が重要 バッチ ジョブ タスク ジョブ ネット グループ フレーム
ステップ ウインド ウ DAG ワーク フロー 単語の定義をはじめとしてバッチアプリケーション開発では バッチ独自観点で考えなければならないことがいくつかあります
バッチアプリケーション 設計で大切なこと 02
バッチアプリケーション設計の主な観点 障害発生時のリランをいかに簡略化するか (運用対応をどれだけ減らせることができるか) 対象のデータをいかに効率よく処理するか (性能改善) ジョブマネージャとの役割分担 (アプリでどこまで実装するか)
ジョブマネージャとの役割分担 (アプリでどこまで実装するか)
ジョブマネージャーとは? ジョブネットを定義や実行を管理するソフトウェア
主なジョブマネージャー 非OSS製品 JP1 System Walker OSS製品 ソフトウェアによってバッチ処理に対する考え方や単語の定義、 アーキテクチャ構成、提供機能など異なる
アプリとジョブマネージャー間での役割分担方針 アプリは業務処理に関する最低限の機能のみを実装する それ以外の機能はできる限りジョブマネージャー側に寄せる • ジョブネットの定義 • ジョブ実行結果による後続ジョブの実行制御(実行するジョブの分岐等) • ジョブのスケジューリング起動/手動起動 •
カレンダーによるジョブ実行日の管理(祝日における実行抑止制御など) • ジョブ実行時間の監視と想定実行時間超過時のアラート発報 • ジョブのリトライ制御(ジョブ内の特定処理ではなくジョブ本体のリトライ制御) • ジョブ実行結果やログ監視およびアラート発報 ガイドラインでは下記機能はジョブマネージャー側で制御する方針
障害発生時のリランをいかに簡略化するか (運用対応をどれだけ減らせることができるか)
ジョブとジョブネット 最小に分割可能な処理をジョブとし、 ジョブに実行順序性を与えることでジョブネットを定義する ジョブ 処理の最小実行単位 ジョブネット ジョブネットを連結し実行順序を定義したもの
ジョブ分割について Q:なぜジョブを分割するのか? A:障害発生後のジョブ再実行における実行時間を最小化するため。
ジョブ分割について Q:なぜジョブを分割するのか? A:障害発生後のジョブ再実行における実行時間を最小化するため。 ただし、ジョブを分割しすぎると今後はジョブ管理の煩雑化、 ジョブ起動のオーバヘッドが積み重なる事による 性能劣化に注意!!
障害発生時のデータ整合性 リカバリ方式 概要 All or Nothing方式 全てのデータをロールバックしジョブを停止させる。 その後ジョブをリランすることで最初から処理をやり直す。 ジョブ停止方式 処理済みのデータは永続化させジョブを停止させる。
その後ジョブをリランし未処理データを対象として処理する。 スキップ方式 処理済みのデータは永続化し、障害が起きたデータの処理をスキップする。 ジョブ実行終了後にジョブをリランし未処理データを対象として処理する。 ジョブ実行時に障害が発生した場合のリカバリ運用方式 この方式がベストである!という簡単な結論はない。 処理対象データの状態管理方針や要件によって選択肢は変わる!
外部システムのデータを更新する場合のリラン 外部システムと自システムで 常にデータの整合性を担保する必要があるのかが重要 (結果整合性でも良いのか?)
外部システムのデータを更新する場合のジョブ分割方針 できる限りジョブ分割パターンで実装することが望ましい。 ただし、処理対象データに順序性が求められる場合は 同一ジョブパターンで実装する必要がある。
ジョブ分割パターンにおけるリラン設計 APIが冪等性機能を提供しているのか等によってリラン設計は 異なるが、時間がないので割愛!!!! (ごめんなさい)
対象のデータをいかに効率よく処理するか (性能改善)
ロギング ジョブが出力するログは必要最低限とする。 (データ単位でログを出力しない) バッチ処理は大量のデータをターゲットとする処理となるため 大量のログを出力すると下記問題を引き起こす可能性がある。 • 大量のログ出力処理による処理性能低下 • ログ出力先のストレージの圧迫によるコスト増やジョブの異常停止
ガイドラインにおけるログ分類と出力方針 ログ種別 概要 出力方針 ジョブ実行ログ ジョブの起動・終了・稼働状況を通知す るログ。 ジョブ実行時に必ず出力する。 アプリログ 業務処理が出力するログ。
100件単位など特定の件数を処理した タイミングで出力することを推奨する。 エラーログ ジョブ実行時に発生したエラー内容 (スタックトレース等)を出力するログ。 エラー発生時には必ず出力する。 SQLログ 実行したSQLの内容を出力するログ。 基本的に出力しない。 通信ログ 外部APIとの通信内容を出力するログ。 更新系API呼び出しのみ必ず出力する。 参照系API呼び出し時のログ出力は任意。
DBやファイルのIO(データ入力方式) ※他にも上限一括取得方式(100件や1000件などの単位で取得する方式)もある。 「実行環境」「読み込みデータ量」を前提として、 どちらの方式でデータを読み込むかを検討する
DBやファイルのIO(データ出力方式) どの方式を選択するかは、 処理対象データ件数 /ジョブ実行時間/障害発生時のデータ整合性 を前提として検討する
並列と多重 異なるジョブを横並びで同時に実行する 異なるデータに対して同じジョブを 横並びで同時に実行する
ジョブの並列化 並列ジョブ実現時の注意点 • ジョブの依存関係 • バッチアプリケーション実行環境のリソース • ジョブマネージャーの仕様 ジョブマネージャーによる並列化を前提とし、 アプリ側で並列実装しない
ジョブの多重化 ジョブマネージャー、マルチスレッドジョブで実現する ただし、処理対象データについて処理実行の順序性がないこと、 各ジョブが同じデータを更新しないことが前提 ー マルチプロセス方式 マルチスレッド方式 概要 ジョブを異なるプロセスとして起動する方式。 ジョブネットとして定義する。
多重化したい処理をマルチスレッドで実行する方 式。 メリット • ジョブ実装コストは通常ジョブと同じ • マルチスレッド方式よりも処理高速化の効果 が高い • 多重度は固定・可変の両方が選択可能。 • データ分割ジョブと多重化ジョブを統合する ことでジョブ間のデータ連携方式の考慮が不 要となる。 デメリット • 可変な多重度は設定できない(ただし、利用 するジョブマネージャの機能依存するため) • データ分割ジョブと多重化ジョブ間で処理対 象データなどを連携する必要がある。 • 多重度やスレッドセーフを意識した実装が必 要となるため実装コストが高い • 処理高速化の効果はマルチプロセス方式より も低い
None