クラウドでの新しいACID、そしてBASEトランザクションとCAP定理

仕事 | 03:47 |

クラウドではアーキテクチャやプログラミングモデルが今までと変わる。

QConでは複数の人からそういう話が出ていた。

ちょっと自分なりにまとめてみる。間違っているかもしれないので、見つけた人はご指摘ください。

新しいACID

従来のモデルでのACIDは、特にRDBMS関連でよく耳にすると思う。

• Atomic(原子性)
• Consistent(一貫性)
• Isolated(独立性)
• Durable(永続性)

だ。

QConでGoogleのGregor Hohpe氏は、クラウドにおいてACIDは次のような意味になると言っていた。

資料はここ。https://sites.google.com/site/gcodejp/slides/ProgrammingCloud_QCon.pdf?attredirects=0

• Associative(結合の)
• Commutative(相互の)
• Idempotent(べき等の)
• Distributed(分散の)

クラウドでのプログラミングモデルは次のようなものとも言ってる。

• クラウドでのプログラミングは従来と異なるプログラミングモデルと実行モデルを必要とする
• 並列実行と束縛ベースのプログラミングが線形ループに取って代わる
• 分散データストレージがRDBMSに取って代わる

BASEトランザクション

そのクラウドにおいて、中心的な概念になるのがBASEトランザクションとCAP定理のようだ。

クラウドを語るときに必ず出てきた単語だったから。

クラウドでは従来のACIDを実現するのは困難だ（ただし困難なだけであって矛盾はしていない）。

なぜなら分散しているため、一貫性を保とうとするとそれこそ2フェーズコミットのような大掛かりな仕組みになってしまう。

BASEは次の頭文字だ。

• Basically Available
• Soft-State
• Eventual Consistency

BASEトランザクションについては、QConの丸山先生の資料に詳しい。

http://qcontokyo.com/tokyo-2009/pdf/GeneralSession-Day2-Maruyama.pdf

Basically Available

分散システムであるがゆえに、可用性が高く常に利用できることを重視する。

逆に言うと、クラウドにとって分散していることは必須である。

クラウドにおけるBasically Availabilityの実現は、おなじみ楽観ロックやキューなどがある。

このあたりは今でも一般的な技術だ。

Soft-State

丸山先生の資料から引用すると、Soft-Stateとは「あるノードの状態は、その内部に埋め込まれた情報によって決まるのではなく、外部から、送られた情報によって決まるという状態の考え方。」だ。

重要なのは「外部から、送られた情報によって決まる」ということ。

離れたノード間でのデータの更新は、そのデータがノードに到達した時点で更新される。

外から届いた情報で状態が更新されるため、Soft-Stateである、と。

Eventually Consistent

が、さっきの例だと、データがノードに到達するまでの間はデータに整合性がない状況になる。

Consistencyは満たせない。

ただし、データが届きさえすればまた整合性がとれるので、その状況は一時的である。

ある期間が経てば、Consistencyを満たせる。

これをEventually Consistentという。

丸山先生の資料から引用すると、「システム内に、一時的にConsistentでない状態が生まれても、ある期間の後には、Consistentな状態になるような性質を、Eventually Consistencyという。」とある。

例としてDNSシステムが挙げられていた。

CAP定理

Eventually Consistentの例でもあったように、分散と可用性と(厳密な)整合性の3つを同時に実現できないとわかる。これがCAP定理。

• Consistency(整合性)
• Availability(可用性)
• Partition(分散)

CAP定理では、3つのうち2つまでしか同時に満たせないと説いている。

クラウドでは分散(P)は必須であるので、どちらか1つを選ぶことになる。

# これはシステムへの要求によって選択する必要がある。

ただ、クラウドの帰結としてはAPは必須となる。

そのとき、Cをどうするか。

丸山先生の資料から引用する。

• クラウド・システムがConsistencyにインパクトを与える状況というのは、基本的には、Availabilityを支える複数のレプリカ・ノードに同一のデータを送ろうとする時に生ずる
• あるノードでは書き込みに成功しても、他のノードでなんらかの事情で書き込みに失敗すれ

ば、システム内に異なるデータの状態が併存し、Consistentでない状態が生まれる

このとき、厳密なConsistentではなくEventually Consistentなら実現できるということになる。

Cを緩めてEventually Consistentにするということ。

丸山先生の言葉を借りれば、

「ScalableでAvailableで、かつ、Eventually Consistentなシステムは可能である。」

となる。

そして、厳密なConsistentというのも、深く考えるとタイムラグが極小であるようなEventually Consistentでしかありえないと気づく。

また引用になるけど、「「二つのノードのConsistency」という概念は、原理的には、Soft-Stateに基づく、Eventually Consistencyでしかありえない」からだ。

「Eventually Consistencyは、便宜的にConsistency概念を緩めたものではなく、むしろ、Consistency概念の基礎原理」であるとわかる。

クラウド、ただのバズワードじゃないな。

ツイートする