Freigeben über

トランザクション処理の現状

  • Artikel

トランザクション処理はデータ管理の必須機能で、プログラミングモデルの進化とともに容易に利用できるようになってきました。

このプログラミングモデルの進化で記念的な出来事がMicrosoft Transaction Server（MTS）のプログラミングモデルの登場です。COMコンポーネントに属性による宣言を付け加えることで、トランザクションの実行スコープをメソッドのブロックに限定する発想でした。これ以降は、コンポーネントないしオブジェクトと、トランザクション処理に関するリソースマネージャとの親和性がよくなりました。現在のEJBやその他の属性ベースプログラミングモデルはこのモデルを基盤としているといっても過言ではありません。XMLを使う構成定義でも、.NETのカスタム属性でも、EJBのアノテーションでも基本的な考え方は同じです。属性の宣言により、振る舞いに関するコードを代替えできるので、開発コードの削減や保守の容易化をもたらしました。しかし、一方では属性の氾濫は、コードの可読性や管理の容易性を損なう原因ともなっています。そのために、convention over configurationの考え方が出てきています。

さて、現在のトランザクション処理の現状はどうなっているのでしょうか？

この点では2つの側面があります。1つは、トランザクションモデルの多様性、そして、もう1つはトランザクション処理のスケールアップのためのアーキテクチャの発展です。
これまでのトランザクション処理の原理の説明では、ACIDの属性や、2相コミットなどのプロトコルの説明はよくあるのですが、トランザクションモデルの説明についてはあまりありません。たとえば、アイソレーションレベルの選択肢、あるいは、メッセージベースのリソースマネージャに有効なトランザクションモデルの選択の問題があります。アイソレーションレベルの選択肢は、トランザクション処理の同時処理とデータ一貫性のトレードオフを、いくつかの選択肢のレベルを設けることで解決しようとします。確実なデータ一貫性の保証は最も同時処理が犠牲になる選択肢でもあります。serializableのレベルがこれに相当します。一方、これ程のレベルを必要としない、より緩和されたレベルのデータ処理もありえます。トランザクション設計の原則は、できるだけ同時処理が可能なように、レベルの緩和をどこまで許容するかを決定することとも言えます。しかし、必要以上のレベルでトランザクションが実行されているのが現状です。

もう１つのトランザクションモデルの議論は、たとえば、Webサービスのトランザクション、特にロングトランザクションの仕様化でかなり問題となりました。RDBMSのようなリソースマネージャと、メッセージベースやインメモリのグリッドのリソースマネージャ、IMのようなP2Pの通知アプリケーションではトランザクションのセマンティックスが異なるので、それぞれのアプリケーションの要求に応じたデータの一貫性の定義と保証の方法が必要となります。これがトランザクションモデルです。トランザクションモデルの詳細については、かなり学術的になるので省きますが、トランザクション処理のプログラミングモデルの設計では、アプリケーションの構造に影響を与えるので、必要な知識になります。

現在のトランザクション処理はWebアプリケーションに代表されるような階層型のシステム構成を前提としています。しかし、この階層型構成のアーキテクチャはそろそろ時代遅れとなってきました。アプリケーションの複雑性、管理の煩雑さ、ネットワーク転送効率の悪さ、スケーラビリティが線形的でない、対障害性の実現法が一貫性がないなどの問題があるからです。各階層を構成する、アプリケーションサーバ、データサーバ、ロードバランサ、クラスタシステムなど、それぞれが技術的な発展を見せ、それらの最適解を組み合わせたこのシステム構成は、全体としては最適になっていない典型例です。

クライアント/サーバ型システムの欠点を改善するために、nティアモデルのシステム構成が登場しました。さらに、ESBなどのバス型、正確には、ブローカ型、の構成を追加して発展し、現在の主流になっているこのシステムは、複雑で扱いにくく、不格好でもあります。こうしたシステム構成を頭の中に叩き込まれたアーキテクトも、かなり不格好で石頭といえなくもないでしょう。

Oracle社はご存じのようにRDBMSでの主要ベンダーです。しかし、Oracle社がインメモリデータベースや、Data Gridの会社を買収している事実は、裏返せば、RDBMSが持つ限界を自ら認めているということでもあります。すなわち、RDBMSの高トランザクション時での性能面の問題、OOPのアプリケーションコードとの整合性の問題、クラスタやフェイルオーバモデルの一貫性、SOAとの親和性などの問題を含んでいるからです。

こうした問題を解決するヒントはGigaSpacesなどの新しいアーキテクチャ、SQL Serverのサービスブローカーのようなメッセージ駆動のミドルウェアにあります。また、マルチコアの並列処理プログラムの開発がOOPではなく、関数型言語やデータフロー言語、ないし、そのDSLを使う方法に進化していると同期して、データフロー言語が有望な技術となるでしょう。

ただし、Martin Fowler氏の最近のブログで、アプリケーションレベルでトランザクション処理機能を実現する方がスケーラブルな実装となりうる例をeBayのアーキテクチャを引用して説明しています。この方向での発展はありえます。この場合は、アーキテクチャパターン、ないし、DSLの実装というところに落ち着くと思えます。

Comments

  • Anonymous
    May 29, 2009
    原理・プロトコル・アーキテクチャ 今はもっとわかりやすい本があるからいいよね、と思う私は老人なのだろうか。 すくなくとも...

  • Anonymous
    June 16, 2009
    PingBack from http://fixmycrediteasily.info/story.php?id=16106