購入/決済のACIDを守るための冪等性の話

Transcript

1. 購入/決済のACIDを守るための 冪等性の話
3. この発表は何 冪等性とは何か、何の役に立つのか、どう実践するのかを学ぶ 購入と決済の（それぞれ異なる）難しさを学ぶ ACID のうち A( 原子性 ) 、 C( 整合性 ) について学ぶ
4. 冪等性とは何か？ 下記AWSの資料が参考になる REL04-BP04 すべての応答に冪等性を持たせる by AWS WellArchitected Framework 「リクエストが最初に完了したときに返された応答と同じ応答を返し ます。」
5. どんな時に冪等性が必要か？ すべての応答に冪等性を持たせる by AWS Well- REL04-BP04 Architected Framework 要するに「すべて」である。
6. どんな時に冪等性が必要か？ が、今回はSODAでの実経験から「システム間の連携が必要な時」と いうのを強調してみたい。 一連の処理を自己完結できるなら冪等性は無くても良いが、連携する 場合はA(原子性)、C(整合性)を守るために冪等性が欲しくなる。 ところで、 モノリスからモジュラーモノリスに移行するということ は、複数モジュールの協調が発生することを意味する。 よってモジュラーモノリスには冪等性遵守が肝となる。
7. モジュラーモノリスの冪等性ルールを作った 「モジュールから公開するAPIには冪等性を持たせる」 API が同じキーで複数回呼ばれた場合に 2 回目以降をエラーにしな い。 更新(PUT)は遵守必須 新規作成(POST)は任意※ 守らない場合はDocを記述する ※冪等キーを定義すれば冪等性を持たせることが可能だが、必須とは していない
8. 事例1. 購入 購入フローを「購入完了」「ロールバック」のどちらかに確実に遷移 させる（途中で中断させないようにする）には？
9. SODA の購入モジュールのアーキテクチャ 購入モジュール自身はビジネスロジックをほとんど持たず、別モジュ ールの手続きを順に実行していくのが「購入」の責務。
10. 購入オーケストレータの課題 原子性をどう守るか？ 一連のトランザクションが「全て成功する」か「全て失敗する」かの どちらかに倒さないといけない（分散TXのアトミック性を守る）。
11. 購入の原子性を守るには？ 案A. トランザクションを繋げる 異なるモジュール間で単一のDBトランザクションを使えるようにする →結合度が上がる、ロック時間が延びる、外部連携が含まれると採用 しにくい 案B. 状態管理する (Sagaパターン) 購入オーケストレータが進捗管理して、中断してた購入データがあれ ば中断したところから処理を再開できるようにする →複雑度増加、整合性解消システムが必須
12. 採用: 冪等性ルールを導入する 案C. 各処理に冪等性を守らせる 各TXが何度実行されても同じ結果になるように実装する。 そうすればフローが中断した時にどこから再開しても、購入完了 or ロ ールバックまで遷移させることができる。
13. 実際の不整合解消バッチの設計 最初に決済のチェックから行う。ユーザの決済が完了していたら 購入確定処理を再開し、していなかったらロールバックする。
14. 事例2. 決済 ユーザの実際の決済状態と、ECサイトの購入状態の整合性を取る方法
15. EC サイトの決済不整合リスク サイトの決済は、ユーザと決済プロバイダとの間で行われ、ECサイ トは直接関与せず結果を後から受け取る形をとる。 よって、下記の(1)と(2)のあいだに不整合のリスクがある。 EC
16. EC サイトの決済不整合対策 多くの決済プロバイダは、決済プロバイダのサーバからECサイトに決 済結果を通知する仕組み(Webhook)を提供している。 Webhook を正しく受信することができれば、決済の結果が EC サイト に確実に届くようになる。これが不整合対策の基本となる。
17. Webhook Webhook 受信アーキテクチャの基本形 受信用のAPIを作って、ログをDBに残す
18. 実際に採用しているアーキテクチャ 受信処理でエラーが起きた場合、Webhookは再送してもら えることが多いが、その仕様はプロバイダ依存となる。Webhook受信 API を薄くして、ビジネスロジックは非同期処理に逃して結合度を下 げている。 Webhook
19. 冪等性の遵守 同期処理とWebhookのハンドリングは冪等にする
20. それでも不整合は起きる リコンサイルする仕組みを入れておく Webhook 受信ログと決済ステータス 決済ステータスと購入ステータス
21. まとめ 他人に提供する機能には冪等性を持たせましょう