システムアーキテクトの役割の重要な側面の１つに、相反する必要条件を比較評価の上、ソリューションを決定することが挙げられるが、１つの特徴のために別の特徴を犠牲にすることで、ソリューションを決定することもしばしばある。システムの規模と複雑性が増すにつれ、アプリケーション構築方法に関する従来の知識が疑われることが益々増えている。例えば、昨年3月にロンドンで開催されたQConカンファレンスにおいて、Dan Pritchard氏がeBayのアーキテクチャについて講演した。この講演の主な要目の１つで、後にあちこちで報道されたのが、eBayはトランザクションを使わず、システムの全体的なスケーラビリティとパフォーマンスをかなり向上させる見返りに、容易なデータ一貫性を手放しているという事実であった。
QConでの話の続きとして、InfoQはDan Pritchard氏にインタビューし、さらに情報を得た。
eBayはなぜトランザクションを使わないのでしょうか。また、アプリケーションレベルのトランザクションに反対する決定はどのように下されるのでしょうか。
トランザクションを使わない、ということではないのです。複数の構成要素にまたがった依存性を作りだしてしまうため、複数の物理的リソースに及ぶトランザクションを使わないのです。クライアント側の１つの障害によって、データベースリソースがこちらの許容範囲を超える長さで停止する可能性があるため、こうした構成要素がアプリケーションサーバーやデータベース（例えば、クライアント側で管理するトランザクション）の可能性もあります。また、分散トランザクションも使いません。なぜなら、アプリケーションが多数のデータベースに依存することにより、クライアントの効果的な可用性が減少するからです。その代わりに、トランザクション欠如を目指して設計すること、また、データベースの可用性問題が発生した場合でさえも、クライアントがうまく動くように故障モードを組み込むことを選択するのです。
アプリケーションレベルのトランザクションは常に何らかの問題をはらんでいるでしょう。開発者に資源ライフサイクルを管理するように頼むとします。その管理がうまくいかなくなると、バグの発生に直面するでしょう。トランザクションはメモリと大して相違がなく、ライフサイクル問題が原因で、開発者をメモリ管理の責任から解放しようという傾向が言語に共通して見られます。Beanの裏にあるすべてのデータベースオペレーションが同等の重要性を持っていると仮定した場合、EJBに見られるような宣言的トランザクションは、トランザクション管理を単純化する強力なアプローチです。
トランザクションを使うべきか否かの決定は、実際のところ、スケーラビリティと可用性の目標に帰着します。アプリケーションが毎秒何百というトランザクションに手を出す必要があるなら、分散トランザクションではうまくいかないことに気付くでしょう。可用性の3つの9（99.9%）の後にもう１桁加えて4つの9にしたいなら、すべてのデータベースコミットがWebページのコンテキスト内で完了すべきとは決めてかかれないし、まったく完了しないケースもあるでしょう。残念ながら、アプリケーションレベルのトランザクションをいつ取り下げればよいかという、単純な定式はありません。その代わり、あなたはアーキテクトとして、システム上の制約１つを原因として、別の制約を緩和する時期を決めなければなりません。
どのようにして「入札する（place bid）」のようなもの向けの、独自の原子性を構築したのでしょうか。
「入札する」は原子性よりも、オークションで非常に重要となる最後の数秒間に入札者の邪魔をしないことを目的としているので、「入札する」それ自体が興味深い問題です。入札時間ではなく、表示時間における高位の入札者と入札価格を計算すると決めれば、とても単純であることが分かります。付け値を別の子テーブルに挿入しますが、これは回線争奪性の低いオペレーションです。当該アイテムが示されるたびに、全付け値を取り出し、高位の入札者を決定するビジネスルールを適用します。
あなたの質問の裏にある真の質問は、私たちがどうやって一貫性を達成しているかではないでしょうか。大規模システムで一貫性を達成するためにはACIDを諦め、その代わりにBASEを使う必要があります。BASEは以下を意味します。基本的に:
利用可能
柔軟な状態
最終的な一貫性
クライアントが各要求の最後にデータに求める一貫性を緩和すれば、分散トランザクションを排除し、他のメカニズムを使って矛盾のない状態に到達できるチャンスを得たことになるのです。例えば、上の入札ケースでは、My eBayページのクイック表示で入札者ごとに整理した一覧表もアップデートしています。これには非同期イベントを１対にして使っています。入札してから、その入札がMy eBayに表示されるまでの待ち時間は非常に短い方が望ましいため、メモリ内キューに依存します。しかしながら、メモリ内キューは当てにならないため、入札オペレーションのサーバー側トランザクションを使って、入札イベントをデータ捕捉します。万一、メモリ内キューのオペレーションに支障が生じれば、この入札イベントがリカバリメカニズムとして処理されます。したがって、入札者一覧表は切り離されており、入札テーブルと常に一貫した状態にあるわけではありません。けれども、それは許容範囲であって、入札と入札一覧表の間のACID遵守を回避可能にしてくれるのです。
大規模システムに携わる他のアーキテクトに何かアドバイスはありませんか。
最も単純なアドバイスは、小さくスケールするように設計されたアーキテクチャに資源を追加しても、大きなスケーリングにはならないということです。ACIDや分散トランザクションのような、従来のパターンから脱しなければなりません。慣例に従えば緩和してはいけないような制約でも、緩和するチャンスを自発的に探すようにしましょう。
単純な原理を2つ。何事も分割を予定すること。ACIDではなく、BASEを念頭に置くこと。
Amazon最高技術責任者のWerner VogelsもQConで講演(参考プレゼン・英語)したが、Eric BrewerのCAP定理を引用して、トレードオフの背景をさらに提供した。この定理は、ACID対BASEについても取り上げた2000年のPODC会議（PDF書類）の講演(PDF・英語)で説明されたもので、共有データシステムの3つの特性である「データ一貫性」、「システム可用性」、「ネットワークのパーティショニング耐性」のうち、同時に起こり得るのは2つだけと述べている。つまり、ネットワークのパーティショニングに耐性のないシステムが、トランザクションのような一般のテクニックを使って、一貫性と可用性を達成することができる。しかし、AmazonやeBayのような大規模分散システムでは、ネットワークパーティショニングは当然である。その結果、超大規模な分散システムを扱うアーキテクトは、一貫性もしくは可用性の必要条件緩和を決断しなければならないということである。両選択肢とも開発者に何らかの負担を強いるものであり、開発者は自らが取り組んでいるアーキテクチャの特徴を理解している必要がある。例えば一貫性の緩和を決めたなら、システムへ書き込んでも、それに対応する読み込みが即座に反映されない状態にどのように対処すべきかを、開発者は決定する必要がある。Windows LiveプログラムマネージャーのDare Obasanjo氏は自身のブログ(source)に次のように書いている。
Windows Liveプラットフォームでも場合によっては、同様のことを実行しますが、トランザクションにタダでついてくるエラーリカバリがアプリケーション開発者の手に委ねられる事実について、開発者が不平を言うのを聞いてきました。最大の不満はいつも、複雑なバッチオペレーションをロールバックすることに関係しています。
興味深いのは、大規模Webサイトの多くが、独力で同じ結論に達したように思われることである。ノード数の少ないより小規模なシステムは、まだこうしたトレードオフを心配する必要はないが、増大を続ける利用者に対してスケールして拡大する企業システムでも、eBayやAmazonが対処しているような種類の問題が発生し始める可能性は高い。