丸山先生レクチャーシリーズにいってきた

丸山先生の"ScalabilityとAvailability"は面白かった。

障害は発生するものだ、だからそれを理解したうえでシステムを考えるということ。
これは重要。99.9%、99.99%の可用性という方向でがんばるのではなく、99%でも何とかなることを考えなきゃいけないんだよね。

そうするためには、CAP定理からでる問題点をBASEモデルで解決しようということ。
CAP定理は『Consistency(整合性)、Availability(可用性)、Partition(分散処理,Scalabilityと見てよい)は同時に2つまでしか満たすことができない。』ということ。

クラウドという文脈では分散と可用性は必須なので、整合性についての考えを改めることからはじめなきゃいけない。だからConsistency->Eventually Consistencyに変えていく。
この"Eventually Consistency"とは、『一時的に整合性の取れない状態はあるが、ある期間を過ぎれば整合性が保たれるという考え方。タイムスパンは違うが、DNSはその考え方。』ということ。同期ではなく非同期で物事を考えるのが重要なのでしょうか。

面白いのが、「現在あるシステムではConsistencyは保たれていない。Eventually Consistencyの中でConsisutencyを努力して実現しているように見せているだけ」という点。そもそも偽りの世界でがんばってても限界があるなら限界を認めてそういう設計に変化していくのは自然ですよね。

このあたりがBASE(モデルなんでしょうね。

BASE=Basically Avaiable, Soft-State, Eventually Consistent

ACIDは個別のデータベースに対するトランザクションの特性なのに対して、BASEはDBを含んだシステム全体に対するトランザクションらしい。

複数のテーブルを扱うトランザクションがある場合、それぞれのテーブル更新はローカルのトランザクションとしてACIDを利用し、全体はEventually Consistencyでよい。
そして、その場合は順序を扱う必要が出てくるためキューか何かが必要になるという・・・。

となると、メッセージングを利用した設計は今後は必須になるのでしょうかね。
DDD勉強会でもメッセージングがくるかなーといったけど、結構間違いではないのかも?!
それと、この考えって今までのWeb(ブラウザを使ったシステム)だと難しいでしょう。Webの場合、同期型で物事を考えてしまうから。これがリッチクライアント(Ajaxも含む)とかだとユーザへの見せ方が変わり、アプリケーションがサーバに勝手に問い合わせる実装かもしれないけど、状態が整ったことをユーザに通知することが可能になるしね。

いや、面白かった。