【雑記】 補償トランザクションの悪夢

　数年前、補償トランザクションを駆使したシステムを構築したのだが、うまくいかずに酷い目にあった経験がある。以下の、Aさん宛てに書いたメール内容を読んでもらえれば想像つくと思うが、これは本当に酷いものだった。私はこのとき、補償トランザクションは絶対やるべきではないと心に誓ったのだった。たぶん、スーパーなプログラマーであれば、こんな酷いことにはならないのだろう。でも、普通のプログラマーであれば、十中八九、同様の結果を招くのではないかと感じている。名誉のためにいっておくと、Aさんはかなり優秀なスーパープログラマーの部類に入ると思う。本来、補償トランザクションは、とても難しいものなのだが、Aさんだから大丈夫かなと安心もしていた。ソースレベルでは完璧なロジックに見えて、テストにおいても問題ないような結果が出るのが補償トランザクションの罠。そこまで示されて、「何をそんなに心配されるのか」といわれると否定のしようがない。しかし、その難しさは、実際に運用してみないと本当の意味でわからない。なぜなら、補償トランザクションが問題になってくるのは本番運用以降であるからだ。想定していなかった補正失敗が発生するのを目の当たりにして大騒ぎになるのはよくあることである。補正失敗時のリカバリーは基本的に運用マターであり、そのあたりの運用リスクをよくよく考慮しなければならないのだが、設計段階ではほとんど気づくことができないものなのだ。今から思えば、補償トランザクションの理屈の甘さが見抜けず、安易に採用を判断した私にも責任があると感じている。Aさんにも苦労をかけて申し訳なかった。しかし、頑張ってACIDにさえしておけば、これほどトラブらなかったのではないかとも思う。ACIDであれば、All or Nothing的に管理されるので大きな問題は起こらない。多少、遅くなったり、実装で苦労するかもしれないが、そこはなんとか乗り越えて、ACIDを使うべきと考える次第である。
　ということで、Entityとトランザクション３で述べたように、GAEにおいてもEntityGroupを使って、最低限のACIDトランザクションを使うべきだと思っている。

Aさん

かねてから申しているように、この不具合は致命的なもので、運用チーム、データリカバリーに深刻な影響を及ぼしています。結果、多くの方に迷惑、システムへの不信をいだかれていることになっています。トランザクション処理がきちんとできていないシステムは基幹システムとはいえません。

また、Bさんにも調査していただいておりますが、本来は開発者であるAさんが調査すべきところだと思います。データ修正も、運用チームやBさんではなく、実際にプログラムを作成されたAさんの方でリカバリーすべきでしょう。厳しいことを申し上げているように思いますが、不具合というのはそれほど重いものであるということを認識すべきだと私は思います。

さらにいえば、この不具合は昨年秋のサービスイン当初から続いており、ずっと問題報告がなされていたにもかかわらず今だに改善されていません。3月のXプロジェクトでも再度依頼しましたが、結局、直りませんでした。このプロジェクトは不具合をすべてなくすことが目的で、それなりの予算を組んで実施したプロジェクトでした。その際、私は会社に全部直すことを約束しております。Aさんもその認識はあったはずです。

もう、トラブルは半年以上続いています。当社としては、この件に関して相当なコストをかけてきましたし、今後も発生するのはいかがなものかと頭を悩ましています。

酷な言い方かもしれませんが、もし、ご自身の技術（スキル）的に解決する自信がない、ということでしたら、他の方に協力を仰ぎ、ソースコードを全部見てもらうぐらいのことはやっていただきたいと思います。いずれにせよ、何かのアクションプランを早急に提示ください。もう限界です。