昨日に引き続き、クラウドの衝撃を読んでいて考えたことです。本の本筋の内容ではないのですが、凄く納得した一節が次の文章です。P60(中略)アマゾンの経験では、ACID(Atomicity(原子性)、Consistency(一貫性)、Isolation(独立性)、Durability(永続性))を保証するデータストアは高可用性が維持できない。これは産業界でも学会でも広く認められていることだ。Dynamoでは高可用性につながるならば、一貫性を多少犠牲にしても運用できるアプリケーションをターゲットにしている昔仕事で、ピーク時にはかなりアクセスが集中するショッピングサイトの仕組みを作ったことがあります。そこで一番頭を悩ませたのが、在庫の管理をどこまで厳密に行うかという所です。厳密にやろうとすればするほど、ロックをかけないといけない時間が長くなります。この時の二律背反として、在庫を確保した段階でないとクレジットカードのオーソリは投げられないし、オーソリを投げないとユーザは購入余力があるか解らないといった要因がありました。(先にオーソリ枠の確認の為に、オーソリを投げるという方法もありますがコストの関係で却下。)一貫性を追求すると、オーソリを投げている間は在庫にロックをかける必要があります。するとキューがどんどん溜まり破綻します。この方法は採りませんでした。Hibernateのキャッシュ戦略(read-only,read-write,nonstrict,transactional)と実装(EHCache,OSCache,SwarmCache,JbossTreeCache)を調べてみたこともあるのですが、ソースを見てみると一貫性を取るか速度を取るかの狭間で工夫をこらしているのが見て取れました。別の例で言うとオープンソースのDBではレプリケーションの実装は多くても、クラスターの実装は中々これといって良いのは無いように思えます。オープンソース物だとどうしても、ディスクはシェアードナッシング型で設計しないといけないので、厳密な意味でのクラスタは難しいのではないのかなと思います。そんなこんなで、高可用性と一貫性の両立は難しいというのがよく解るのですが、どうしたら良いのだろうといつも悩んでいました。この本を読んでいて多少一貫性を犠牲にしても大丈夫な設計を考えるべきなのかなと思うようになってきました。はてなブログをはじめよう!dkfjさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。