分散データストアの戦略に関する考察と議論

Sadayuki Furuhashi @frsyuki

MVCCやSTMの発想は、おそらく分散でも非常に便利。と言うわけでCASは欲しいが、ノードが動的に増減する前提では、（厳密な）CASの実行は難しい。R+W>N ではダメ。厳密でなければOK。要求次第だけども、どんな要求があり得るんだろう。

Sadayuki Furuhashi @frsyuki

ノードが増減している間など、CAP定理で言うところの network partitioning が起こっている最中に、CAS操作が同時に行われると、R+W>N + Vector Clockでは、データの新旧が比較不能な２つのデータ=不整合が発生してしまう。これをどう扱うか。

Sadayuki Furuhashi @frsyuki

やり方は３つか。１つは別のところに一貫性重視の共有データを置く方法。Chubbyの戦略。もう１つは、そういうケースは"気にしない"方法。アプリケーションでがんばる。CassandraやDynamoの戦略。あるいは、always-writableを犠牲にする方法。

Sadayuki Furuhashi @frsyuki

Chubbyの戦略のデメリットは、スケールしにくい点。遅い。実装も大変。Cassandraの戦略は、アプリケーションが制約される。always-writableを犠牲にする方法は、可用性が落ちる。paritioning中にCAS操作を発行したときに、比較的大きな遅延が発生。

Sadayuki Furuhashi @frsyuki

一番実践的な方法は、W+R>Nモデルで、不整合は "気にしない" 方法だと思うけど、どうなんだろうなぁ。だいたい大丈夫だよねー戦略。

Sadayuki Furuhashi @frsyuki

"気にしない" という戦略を採るとありがちなのは、高負荷時になると問題が発生するケース。アクセスが増えてきたら、データを保存したつもりが保存できていないとか、追記したら古いデータが消えたとか。

Sadayuki Furuhashi @frsyuki

データセンタをまたぐ規模では、可用性が相当に重要なので、CAS操作を保証するのはかなり厳しい。クラウド事業者としては、"CAS操作は許可しない" のが、一番問題が発生しない選択肢だろう。

Sadayuki Furuhashi @frsyuki

要求によっては、今後はクラウド事業者でも"気にしない"系が出てくる可能性も高し。自前で用意するくらいの規模なら、可用性を落とす方法が現実的か。そういう分散データストアはあるのかな。

Sadayuki Furuhashi @frsyuki

DBの歴史からすると若干逆行する気がするけど、可用性は落とさずに、データモデルやデザインパターンでカバーするのが筋なのかなぁ。わりと読めない。

Shinpei Ohtani @shot6

@frsyuki アプリケーションのデータ特性による部分が大きいので、気にしない戦略一つだと心もとないです。Cassandraのアプリケーションの制約ってどこを指しています？

Sadayuki Furuhashi @frsyuki

@shot6 気にしないのはアリですよね。Cassandraは、W+R>Nでレプリカの一貫性を保証する点です。必ずデータは一発で（不可分に）最新の値に更新され、不整合が発生しない、という仮定を置いてアプリケーションを書けない。…それが必要なのかは微妙ですが。

Shinpei Ohtani @shot6

@frsyuki そうですね。それは出来ない前提という認識です。> 必ずデータは一発で（不可分に）最新の値に更新され、不整合が発生しない、という仮定

Sadayuki Furuhashi @frsyuki

ぁ、ハズしました。s/気にしないのはアリですよね/気にしないのも必要ですよね/　どうしても要求次第かなぁ。選択できるのはベスト。

Shinpei Ohtani @shot6

@frsyuki CassandraでもReplicationFactor=ノード数にして、ConsistencyLevel.ALLにするという裏技もｗｗｗ　ジョークです。すいませんｗ

Sadayuki Furuhashi @frsyuki

不整合は発生しない、という仮定を置けるようにするには、不整合が発生しそうになったら止まればいい。可用性を落とせば実現可能。可用性と一貫性のトレードオフを、状況やデータに応じて選択可能にするにはどうするか。ぃゃできるんだけど…

Sadayuki Furuhashi @frsyuki

@shot6 むー…もしや、その裏技でもダメでは？ 不整合が発生したときに、それをアプリケーションが検出することはできるけど、不整合が発生した状況が見えてしまうのは防げない。

Shinpei Ohtani @shot6

@frsyuki その状況下で不整合がおきれば、ですね。分断された状況下で起こるかもしれませんが僕の言っているのはノード数台かつ安定したネットワークの同一セグメントとかそういうレベルです。DCまたぐとかそういう状況なら無論起こりえますね。

Sadayuki Furuhashi @frsyuki

@shot6 なるほど。その前提なら問題ないですね＞ノード数台かつ安定したネットワークの同一セグメント

Shinpei Ohtani @shot6

つまり外的要因を使って分断化されていない状況にいかに押し込むか、ってことで、それ自体をNoSQL側であまりに気にしすぎてもダメかもという発想です。

Shinpei Ohtani @shot6

@frsyuki おそらく色々な状況に耐えうるには複数のやり方をうまいこときりかえれないとダメな気がしますが、全然アイデアが出ません。

Sadayuki Furuhashi @frsyuki

kumofsは"安定したネットワークの同一セグメント"を前提としてkumo-managerを冗長化しているけど…運用とハードと環境にどこまで依存できるのか。このあたり、いまいち整理できていないな…当然使い方に依るわけで、最善は選択可能なこと。

Sadayuki Furuhashi @frsyuki

@shot6 確実に難しいですね…。レプリケーションの方法と、障害の検出方法と、ノード一覧表の作り方･配り方と…要するにはぜんぶ関係してくるので…。不整合が発生したレプリカが見えない保証があったら、いったいどんな使い方ができるのか、私自身いまいち分かっていないのが悩ましいです。

Shinpei Ohtani @shot6

@frsyuki 難易度は高いですよね。私はもっと色々見えてないので、自分の不勉強さをかみしめつつ色々みている途中です。

Sadayuki Furuhashi @frsyuki

DC間（あるいはラック間）レプリカとDC内（ラック内）レプリカの２種類を導入して、DC内（ラック内）では、全順序保証（CASなどで必要）をありとなしを選択可能に、DC間（ラック間）では、eventual/strong consistencyを選択可能にする案。これはできると思う。

Sadayuki Furuhashi @frsyuki

全順序保証は、Quorum Server が要。DC間は…Vector Clockかなぁ。定期的にpull&マージを走らせるような。DC間でW+R>Nを採用してRを増やすと、遅延の問題があるので。semi-sync replを後付けするのは良いかもしれない。