結果整合性の意外な適用場所

ブログを相当長いこと放置していたので、たまには生存確認をかねて、投稿を・・・。

お金が絡むところでは厳密な一貫性が要求され云々言うわけだけども、一貫性を妥協すると全てが得られる。少なくとも高い可用性とスケーラビリティーが。*1

以下のような CAP 定理に関する反証もあるけど、

While the impossibility proof of CAP is mathematically correct, it is based on assumptions that are too strict. By relaxing these assumptions, I found the solution presented here.

Guy's Blog: A CAP Solution (Proving Brewer Wrong)

「Proving Brewer Wrong」と言っている割には、「CAP の並立不可能性は数学的には正しい」と認めていて、反証だか何だかよくわからない。時間を味方に付ければ CAP が並立することはブリュワーだって否定していないだろう。*2

さて、本題の意外な結果整合性の適用箇所だけど、某大手銀行の Web システム。

1. A 銀行の Web システムで自分の口座にログインして、B 銀行の自分の口座に送金。
2. A 銀行の Web システムで「着金完了」を確認。
3. B 銀行の Web システムで自分の口座にログインして残高を確認するも残高は変わらず。（別にこの時点であわてたりはしない。ここで時差が出るのは普通の事なので。）
4. B 銀行に電話して、Web 画面での残高を超える金額の送金指示を出す。
5. 普通に受理される
6. 送金完了を伝えられ、Web 画面で残高を確認するもまだ変わらず。
7. 残高ではなく、入出金履歴を見ると入金と送金の履歴が。残高も変わっている。
8. 再度残高確認画面に行くと、まだ残高は変わっていない・・・。

まあ結局しばらく待っていると残高は正しい数字になったけど、要するにこの銀行はどこで一貫性が取れている必要があるかをちゃんと認識していて、一貫性が取れている必要が無い部分については結果整合性が取れればよしとしているということになる。何の問題もないけど、銀行ってたとえ Web システムだろうが一貫性を重視してる*3んじゃないかっていうような思い込みがあって意外に思ってしまった*4。

この事例で学んだことは、「一貫性を保持する範囲を可能な限り絞り込む」こと。CAP 定理により、一貫性を重視することは他の2つの特性（可用性、分割耐性）のうちのどちらかを犠牲にすることにつながる。しかし、時間軸を考慮に入れるなら CAP は成立しうる。そして一貫性を保持する範囲を絞り込むならばさらに可用性と分割耐性を向上させることができる。

この辺は何々データベースの導入やら分散データストア製品の何々を導入したらという範疇に話が収まらず、要件定義、基本設計レベルでの考慮が必要になるため、アーキテクトと要件定義者双方に認識が必要。

*1:CAP定理 - Wikipediaを参照。

*2:「タイトルは釣り」かもしれない。コメントでも「同時に」がポイントとやんわり突っ込みが・・・。

*3:とはいえ、銀行間の送金にはすごい時間がかかる時がある。月末の送金はその日中に着金が完了しないことも経験済み。これは銀行のシステム間では「結果整合性」が実現されておりかつ、何の問題もないという良い例とも言える

*4:私は金融系のシステムなんて実質未経験みたいなものなんで、まったくの想像だけど、銀行がこういう結果整合性の概念を持っているのはある意味当然というか、実は彼らは結果整合性のエキスパートなのかもしれない。だって歴史的に金融系のシステムってバッチ処理中心に構築されてきただろうし、そのバッチ処理って、要するに非同期処理なわけだし。どこに一貫性が必要でどこに不要か、なんて事はいの一番に考える事なのかも知れない。