Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
NetadashiMeetup#13 バッチは地味だが役に立つ2
Search
HayashiYuichiro
January 30, 2025
Technology
0
25
NetadashiMeetup#13 バッチは地味だが役に立つ2
NetadashiMeetup#13
https://peatix.com/event/4164349?lang=ja-jp
HayashiYuichiro
January 30, 2025
Tweet
Share
More Decks by HayashiYuichiro
See All by HayashiYuichiro
社内での開発コミュニティ活動 ~バッチ処理方式設計とSpringBootでのバッチ開発~
hayashiyuu1
1
230
Other Decks in Technology
See All in Technology
CNAPPから考えるAWSガバナンスの実践と最適化
nrinetcom
PRO
1
330
Amazon Location Serviceを使ってラーメンマップを作る
ryder472
2
150
Grafanaのvariables機能について
tiina
0
180
[TechNight #86] Oracle GoldenGate - 23ai 最新情報&プロジェクトからの学び
oracle4engineer
PRO
1
170
20250129 Findy_テスト高活用化
dshirae
0
220
CloudWatch Container Insightsを使ったAmazon ECSのリソース監視
umekou
1
120
panicを深ぼってみる
kworkdev
PRO
2
150
Postman Vaultを使った秘密情報の安全な管理
nagix
3
120
ChatGPTを使ったブログ執筆と校正の実践テクニック/登壇資料(井田 献一朗)
hacobu
1
160
GraphRAG: What I Thought I Knew (But Didn’t)
sashimimochi
1
230
20250125_Agent for Amazon Bedrock試してみた
riz3f7
2
110
AIエージェントについてまとめてみた
pharma_x_tech
9
6.5k
Featured
See All Featured
Designing for Performance
lara
604
68k
RailsConf 2023
tenderlove
29
980
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Embracing the Ebb and Flow
colly
84
4.5k
Scaling GitHub
holman
459
140k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
VelocityConf: Rendering Performance Case Studies
addyosmani
327
24k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Statistics for Hackers
jakevdp
797
220k
Documentation Writing (for coders)
carmenintech
67
4.6k
Being A Developer After 40
akosma
89
590k
Why Our Code Smells
bkeepers
PRO
335
57k
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