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
81
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
450
Other Decks in Technology
See All in Technology
Agentic DevOps時代の生存戦略
kkamegawa
1
1.1k
_第3回__AIxIoTビジネス共創ラボ紹介資料_20250617.pdf
iotcomjpadmin
0
150
Oracle Audit Vault and Database Firewall 20 概要
oracle4engineer
PRO
3
1.7k
菸酒生在 LINE Taiwan 的後端雙刀流
line_developers_tw
PRO
0
1.1k
ハノーバーメッセ2025座談会.pdf
iotcomjpadmin
0
150
A2Aのクライアントを自作する
rynsuke
1
160
ObsidianをMCP連携させてみる
ttnyt8701
2
140
BigQuery Remote FunctionでLooker Studioをインタラクティブ化
cuebic9bic
2
230
JSX - 歴史を振り返り、⾯⽩がって、エモくなろう
pal4de
4
1.1k
Liquid Glass革新とSwiftUI/UIKit進化
fumiyasac0921
0
150
Uniadex__公開版_20250617-AIxIoTビジネス共創ラボ_ツナガルチカラ_.pdf
iotcomjpadmin
0
150
実践! AIエージェント導入記
1mono2prod
0
150
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
Raft: Consensus for Rubyists
vanstee
140
7k
Site-Speed That Sticks
csswizardry
10
650
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
16
940
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.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