読者です 読者をやめる 読者になる 読者になる

プログラマでありたい

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

続クラウドの衝撃 一貫性を保証するのは一貫して難しい

 昨日に引き続きクラウドの衝撃を読んでいて考えたことです。

 本の本筋の内容ではないのですが、凄く納得した一節が次の文章です。
P60

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

 昔仕事で、ピーク時にはかなりアクセスが集中するショッピングサイトの仕組みを作ったことがあります。そこで一番頭を悩ませたのが、在庫の管理をどこまで厳密に行うかという所です。厳密にやろうとすればするほど、ロックをかけないといけない時間が長くなります。この時の二律背反として、在庫を確保した段階でないとクレジットカードのオーソリは投げられないし、オーソリを投げないとユーザは購入余力があるか解らないといった要因がありました。(先にオーソリ枠の確認の為に、オーソリを投げるという方法もありますがコストの関係で却下。)一貫性を追求すると、オーソリを投げている間は在庫にロックをかける必要があります。そうするとキューがどんどん溜まり破綻します。当然、この方法は採りませんでした。
 また、Hibernateのキャッシュ戦略(read-only,read-write,nonstrict,transactional)と実装(EHCache,OSCache,SwarmCache,JbossTreeCache)を調べてみたこともあるのですが、ソースを見てみると一貫性を取るか速度を取るかの狭間で工夫をこらしているのが見て取れました。別の例で言うとオープンソースのDBではレプリケーションの実装は多くても、クラスターの実装は中々これといって良いのは無いように思えます。オープンソース物だとどうしても、ディスクはシェアードナッシング型で設計しないといけないので、厳密な意味でのクラスタは難しいのではないのかなと思います。


 そんなこんなで、高可用性と一貫性の両立は難しいというのがよく解るのですが、どうしたら良いのだろうといつも悩んでいました。この本を読んでいて多少一貫性を犠牲にしても大丈夫な設計を考えるべきなのかなと思うようになってきました。具体的な事例は思い浮かばないのですが、Amazonでもその方針だということが解るだけで少し安心しましたw


クラウドの衝撃――IT史上最大の創造的破壊が始まった
野村総合研究所 城田 真琴
東洋経済新報社
売り上げランキング: 418