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
バッチ処理と冪等性 / 20191218_merpay_techtalk
Search
kaznishi
December 18, 2019
Technology
2
4.6k
バッチ処理と冪等性 / 20191218_merpay_techtalk
kaznishi
December 18, 2019
Tweet
Share
More Decks by kaznishi
See All by kaznishi
Finally_I_can_kichijojipm32
kaznishi
0
450
Bounds Check Eliminationについて調べてみた / 1218-lt
kaznishi
0
360
Hello, Prometheus!! Goで作るexporter自作入門 / 180727 LT
kaznishi
6
3.4k
Goのスライス容量拡張量がどのように決まるのか追った / 180713 LT
kaznishi
3
3.5k
スライス容量拡張量がどのように決まるのか追った / 180709 LT
kaznishi
0
110
Other Decks in Technology
See All in Technology
シフトレフトで挑む セキュリティの生産性向上
sekido
PRO
0
270
エンジニアの生存戦略 〜クラウド潮流の経験から紐解く技術トレンドのメカニズムと乗りこなし方〜
shimy
9
1.9k
Datadog Cloud SIEMを使ってAWS環境の脅威を可視化した話/lifeistech-datadog-cloud-siem
gidajun
0
480
OSSコミットしてZennの課題を解決した話
dyoshikawa1993
0
150
データベース研修 分析向けSQL入門【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
110
How to Think Like a Performance Engineer
csswizardry
4
590
Classmethod Odyssey 登壇資料
yamahiro
0
390
ABEMAにおけるLLMを用いたコンテンツベース推薦システム導入と効果検証
cyberagentdevelopers
PRO
1
700
Flutter研修【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
160
サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / Steps Taken by a Novice Lead Engineer to Advance Service Development
nologyance
0
180
コミュニティサービスに「あなたへ」フィードを リリースするまでの試行錯誤
takapy
1
140
AWSサービスメニュー開発をしていてAWSを好きだ!と感じた瞬間
toru_kubota
0
130
Featured
See All Featured
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
105
6.8k
Rails Girls Zürich Keynote
gr2m
93
13k
Writing Fast Ruby
sferik
623
60k
Building an army of robots
kneath
301
42k
Imperfection Machines: The Place of Print at Facebook
scottboms
262
13k
How STYLIGHT went responsive
nonsquared
93
5k
Creatively Recalculating Your Daily Design Routine
revolveconf
214
11k
[RailsConf 2023] Rails as a piece of cake
palkan
35
4.4k
What's in a price? How to price your products and services
michaelherold
239
11k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
34
1.9k
The Cost Of JavaScript in 2023
addyosmani
31
4.7k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Transcript
2019.12.18 Wed. 1 Tech Talk vol.2 Backend Engineer ~マイクロサービスの冪等性 ~
バッチ処理と冪等性 kaznishi
自己紹介 • kaznishi • Twitter: @kaznishi1246 • Backend Engineer •
Code Payment Team • 2018年11月入社 15% 35% 50% 2
自己紹介 • 担当しているマイクロサービス ◦ 加盟店精算 ◦ 補助金接続 ◦ 加盟店レポート •
いずれもバッチ処理がメイン! 15% 35% 50% 3
バッチ処理の紹介 4
加盟店精算の様々なバッチ処理 5 会計 精算 決済 銀行 残高 会計データ取り込み処理 (毎日) ※会計サービスにリクエストを送って取得するのではなく、
会計サービスがストレージ(GCS)にファイルとして 吐き出したものを取り込み
加盟店精算の様々なバッチ処理 6 会計 精算 決済 銀行 残高 会計データ中間集計処理 (毎日)
加盟店精算の様々なバッチ処理 7 会計 精算 決済 銀行 残高 精算金額集計(締め)処理(月2回)
加盟店精算の様々なバッチ処理 8 会計 精算 決済 銀行 残高 入金指示処理(月2回)
バッチ処理と冪等性 今回のテーマ 9
冪等性 • ある操作を1回実行しても、複数回実行しても、同じ結果になる • 冪等性がある処理の例 ◦ 「ある変数の値を x に更新する」 ◦
何回実行しようが結果は x 10 process x x x
冪等性 • ある操作を1回実行しても、複数回実行しても、同じ結果になる • 冪等性がない処理の例 ◦ 「ある変数の値を 現在値 + x
に更新する」 ◦ 実行のたびに違う値に更新される 11 process 初期値 + x 初期値 + 2x 初期値 + 3x
バッチ処理を冪等に作るモチベーション • バッチ処理設計の重要な考慮事項の一つが「回復可能か」 ◦ 「バッチ処理の採用と設計を考えてみよう」 (https://tech.mercari.com/entry/2019/02/27/112650) より • バッチ処理は様々な理由によって失敗する •
失敗したときのリカバリー容易性は非常に大事 • 冪等に作ることで、原因除去後に単純なリトライで回復可能に 12 recovery
何回実行されても大丈夫な バッチ処理を作る 13
方針は大きく2種類 • 処理済み含めてやり直すパターン • 一度処理したものをスキップするパターン 14
処理済み含めてやり直すパターン • バッチ処理が実行されるたびに全部の処理をやり直す • バッチ処理の個々のステップが冪等である前提が必要 • 他マイクロサービス(or外部サービス)にもリクエストを送る処理の場合は リクエスト先にも冪等性が必要 • 条件分岐を細かく考える必要がない
• 再実行には時間がかかる 15
一度処理したものをスキップするパターン • ステータス等で条件分岐し、処理済みのものをスキップする • 未処理のものだけを対象とするため、所要時間が短くて済む ◦ (未処理かどうかを判別するステップは必要だが) • 実装は条件分岐で複雑になりがち 16
どちらで実装している? • どちらのパターンも存在している • 要件によって選択 • ステート管理が必要なものについては自ずと「一度処理したものをス キップするパターン」になるのではないかと • 中間集計など単純にレコードを生成するような処理かつ、全部やり直し
ても大丈夫なぐらい時間的制約が緩いものは「処理済み含めてやり直 すパターン」により実装している ◦ もちろんレコードが重複して生成されないように適切なユニークキーを定義しておく前提 17
一度処理したものをスキップするパターンでの実装 • バッチが失敗したときに中途半端状態が生じないように実装を気をつけ る • 処理の再開地点以外の状態で落ちていることがないように。DBのトラン ザクション機能などを使って防ぎましょう 18 トランザクションの単位
再開地点
一度処理したものをスキップするパターンでの実装 • ステップの中に他サービスへのリクエスト処理が含まれている場合はど うすればいいか? ◦ 他サービスにリクエストを送ったあとにリクエスト済みステータスに DB更新するようなケースを想定 ◦ DB更新でエラーが発生したら? ◦
他サービスにキャンセルリクエストを送る? ◦ 他サービスが冪等に作られているならば、もう一度同じリクエストを 送るのは問題ないと考え、キャンセルせずにそのままリトライして解 消する 19
その他の取り組み 20
1. バッチを回す前の確認 • バッチ処理が処理する材料データは揃っているか? • 前段バッチが異常なく終了していることを確認しよう • バッチ履歴管理テーブルを作り、正常に終了したことを記録 • 後段のバッチ起動時に前段が終わっているかの確認を行っている
21
1. バッチを回す前の確認 • 前段の処理が別のマイクロサービスの場合は難しい • チーム間でどうやって前段の処理を知らせるか調整が必要 • 加盟店精算の会計データ取り込み処理の場合 ◦ 前段は会計システムのGCSへのデータエクスポート処理
◦ エクスポート処理終了時に指定名(export.done)の空ファイルを設 置してもらっている ◦ データ取り込み処理開始時にexport.doneが存在していない場合 はまだ前段が終わっていないとみなす 22
2. バッチが複数回処理された想定のテストを書く • 作ったバッチ処理、冪等になっていますか? • 下記のようなテストコードを書いて保証 ◦ 正常にバッチが回った状態に再度バッチ処理を実行する ◦ 途中でバッチがコケた状態に再度バッチ処理を実行する
23
まとめ 24
まとめ • 回復可能性を高めるためにバッチ処理を冪等に作ろう • 何回バッチを実行しても結果が変わらないように処理を作る • 処理済み含めてやり直す or 処理済みのものをスキップするように作る •
中途半端状態を作らないように設計しよう • 前段のバッチ処理が成功しているかを確認しよう • テストコードで冪等になっていることを保証しよう 25