プログラマでありたい

おっさんになっても、プログラマでありつづけたい

CAPの定理と分散データベースの話


 前回、セッションストアについて悩んでいますという何も解決しないエントリーを書いたら、はてブやTwitterで非常に沢山のコメントを頂きました。色々な考え方があって、非常に参考になりました。ありがたい限りです。別途、考えを整理してまとめようと思いますが、下記の2つの考え方が多いようです。

  • 共用セッションストアの格納先を分散データベースにすれば良いよ
  • セッション設計をちゃんとすれば、クッキーストアを使ってもセキュリティや容量の問題はないよ


 私も、どちらかと言えば上2つの方針で考えています。一方で、分散データベースは一貫性を保証しつつ可用性を高めるのは難しいという基本姿勢と、クッキーストアについては設計ミスや実装ミスが起こりうるという現実の中で、どう安全側に倒していけるかという点を考える必要があると考えています。今回は、分散データベースの一貫性について考えていることをまとめてみます。

CAPの定理



 分散データベースを考える上で、外せないのがCAP定理です。別名、ブリュワーの定理でEric Brewer氏が提唱し、分散コンピュータ間でのデータ複製に関する定理です。非常に簡単にいうと、一貫性(Consistency)と可用性 (Availability)と分断耐性 (Partition-tolerance)の3つの保証のうち、2つまでしか同時に保証出来ないということです。
 一般的には、RDBMSはCAを選択し、分散DBは目的によってCPなのかAPなのかを選択しています。要は、一貫性をとるか可用性をとるかの2択なのです。最近は単純に二者択一ではなく一貫性のうち、どこまで保証するかといった焦点になってきているので、単純なCAPの世界ではないという話も出てきているようです。

AmazonのDynamo論文と通信の話



 続いてはクラウドの雄のAmazonですが、自身のサービスを含め分散環境でのデータ処理で生きている会社なので、当然ながら世界のトップクラスのノウハウが溜まっていると思われます。そんな中でクラウドの衝撃の一節にアマゾンのDynamoの論文について言及している箇所がありますが、一貫性を保証しつつ可用性を担保するのは難しいという認識があります。

(中略)アマゾンの経験では、ACID(Atomicity(原子性)、Consistency(一貫性)、Isolation(独立性)、Durability(永続性))を保証するデータストアは高可用性が維持できない。これは産業界でも学会でも広く認められていることだ。Dynamoでは高可用性につながるならば、一貫性を多少犠牲にしても運用できるアプリケーションをターゲットにしている


 はるか昔に、Hibernateのキャッシュ戦略(read-only,read-write,nonstrict,transactional)と実装(EHCache,OSCache,SwarmCache,JbossTreeCache)を調べていたことがあるんですが、通信の問題によって最終的には一貫性を保証するのは非常に難しいということが解りました。通信断が発生した時には、どうやっても状態が解らなくなるタイミングがあるので、一貫性の方向に倒すか可用性の方向に倒すかがキャッシュ戦略の肝のようです。

まとめに代えて、必要なこと



 ということで可用性と一貫性を保証するのは、非常に難しいという前提があります。その上で、共用セッションストアに分散DBをしようするのであれば、よくよくアプリの特性を考えて選択しないとハマることになります。例えば同期モードにsynchronousとあるものも、調べてみれば複数のサーバに同期するまでタイムラグがあるものも多々あります。なので、選択は慎重にと考えています。ちなみに私がよく取る方法としては、分散DBをデュアル・マスターにしておいて、どちらに接続しても良い状態にします。その上で、アプリケーションからは、分散DBをマスター・スレイブとして扱い、どちらかを優先してアクセスするようにしています。一貫性と可用性の両立の回避策の1つです。ただ、この方法だと分散DBをスケールアウトする際は、アプリ側の設定変更が必要です。頻度が少ないので、まぁ良いかなというところです。
 最近では、セッションストアにもよく使われる分散データベースの実装として、RiakやRedisなど評判の高いのも多々あります。またAmazonが誇るDynamoDBもあります。一度、一貫性や可用性をとことん調べてみたいなぁと思っています。


See Also:
アプリケーション・サーバのセッションの保存先の話


参照:
CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった
BrewersCapTheorem - ブリュワーの CAP 定理
12年後のCAP定理: "法則"はどのように変わったか
今更CAP定理で分散データストアの勉強を始めてみた
Visual Guide to NoSQL Systems - Nathan Hurst's Blog