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

この発表は何冪等性とは何か、何の役に立つのか、どう実践するのかを学ぶ購入と決済の（それぞれ異なる）難しさを学ぶ ACID のうち A( 原子性 ) 、 C(
整合性 ) について学ぶ

冪等性とは何か？下記AWSの資料が参考になる REL04-BP04 すべての応答に冪等性を持たせる by AWS WellArchitected Framework 「リクエストが最初に完了したときに返された応答と同じ応答を返します。」

どんな時に冪等性が必要か？すべての応答に冪等性を持たせる by AWS Well- REL04-BP04 Architected Framework 要するに「すべて」である。

どんな時に冪等性が必要か？が、今回はSODAでの実経験から「システム間の連携が必要な時」というのを強調してみたい。一連の処理を自己完結できるなら冪等性は無くても良いが、連携する場合はA(原子性)、C(整合性)を守るために冪等性が欲しくなる。ところで、モノリスからモジュラーモノリスに移行するということは、複数モジュールの協調が発生することを意味する。よってモジュラーモノリスには冪等性遵守が肝となる。

モジュラーモノリスの冪等性ルールを作った「モジュールから公開するAPIには冪等性を持たせる」 API が同じキーで複数回呼ばれた場合に 2 回目以降をエラーにしない。更新(PUT)は遵守必須新規作成(POST)は任意※ 守らない場合はDocを記述する
※冪等キーを定義すれば冪等性を持たせることが可能だが、必須とはしていない

事例1. 購入購入フローを「購入完了」「ロールバック」のどちらかに確実に遷移させる（途中で中断させないようにする）には？

SODA の購入モジュールのアーキテクチャ購入モジュール自身はビジネスロジックをほとんど持たず、別モジュールの手続きを順に実行していくのが「購入」の責務。

購入オーケストレータの課題原子性をどう守るか？一連のトランザクションが「全て成功する」か「全て失敗する」かのどちらかに倒さないといけない（分散TXのアトミック性を守る）。

購入の原子性を守るには？案A. トランザクションを繋げる異なるモジュール間で単一のDBトランザクションを使えるようにする →結合度が上がる、ロック時間が延びる、外部連携が含まれると採用しにくい案B. 状態管理する (Sagaパターン) 購入オーケストレータが進捗管理して、中断してた購入データがあれ
ば中断したところから処理を再開できるようにする →複雑度増加、整合性解消システムが必須

採用: 冪等性ルールを導入する案C. 各処理に冪等性を守らせる各TXが何度実行されても同じ結果になるように実装する。そうすればフローが中断した時にどこから再開しても、購入完了 or ロールバックまで遷移させることができる。

実際の不整合解消バッチの設計最初に決済のチェックから行う。ユーザの決済が完了していたら購入確定処理を再開し、していなかったらロールバックする。

事例2. 決済ユーザの実際の決済状態と、ECサイトの購入状態の整合性を取る方法

EC サイトの決済不整合リスクサイトの決済は、ユーザと決済プロバイダとの間で行われ、ECサイトは直接関与せず結果を後から受け取る形をとる。よって、下記の(1)と(2)のあいだに不整合のリスクがある。 EC

EC サイトの決済不整合対策多くの決済プロバイダは、決済プロバイダのサーバからECサイトに決済結果を通知する仕組み(Webhook)を提供している。 Webhook を正しく受信することができれば、決済の結果が EC サイトに確実に届くようになる。これが不整合対策の基本となる。

Webhook Webhook 受信アーキテクチャの基本形受信用のAPIを作って、ログをDBに残す

実際に採用しているアーキテクチャ受信処理でエラーが起きた場合、Webhookは再送してもらえることが多いが、その仕様はプロバイダ依存となる。Webhook受信 API を薄くして、ビジネスロジックは非同期処理に逃して結合度を下げている。 Webhook

冪等性の遵守同期処理とWebhookのハンドリングは冪等にする

それでも不整合は起きるリコンサイルする仕組みを入れておく Webhook 受信ログと決済ステータス決済ステータスと購入ステータス

まとめ他人に提供する機能には冪等性を持たせましょう

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

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

τ μ [taumu]

More Decks by τ μ [taumu]

Featured

Transcript