もはや3、4年前ですが丸山先生よりCAP定理やBASEトランザクションの講義をうかがう機会がありました。今回改めてまとめてみました。
＜参考資料＞
丸山不二夫、「Cloudの技術的特徴について」：http://qcontokyo.com/tokyo-2009/pdf/GeneralSession-Day2-Maruyama.pdf
本記事は上記丸山先生の資料を基に学んだことについての考察となりますので、まずは上記資料を読んでみてください。
■ CAP定理、Availability優先かConsistency優先か（※資料の43〜53ページについて）
CAP定理とは、「Consistency、Availability、Partition（※分散構成の意味）の三つのうち、同時には二つまでしか達成できない」、とする主張です。ここで一つの命題、「Scalabilityが求められる故、分散構成（Partition）が必須だとするなら、AvailabilityとConsistencyのいずれかを諦めなくてはならない。であるならばどう選択するか？」、が示されます。
丸山先生は次のような結論を導いています。
-----(ここから)-----基本的なソリューションは、先のe-サイトの例でも見たように、扱うデータとその処理のタイプに応じて、クラウド上のアプリケーションの側が、Availability優先か、Consistency優先イプを選択していくことに帰着する。-----(ここまで)-----
そして、「e-サイトの例」（※ネットショップの例）では、「ユーザーがカートに商品を詰めて注文確定する場面ではAvailabilityが優先され、その後在庫引き当てする場面ではConsistencyが優先される」としています。
・
この丸山先生の結論は、
フロントエンド・アプリが装備するような機能こそがAvailabilityを優先すべきもので、バックエンド・サービスが提供するような機能こそがConsistencyを優先すべきものである
というかたちで適用させることができそうです。
丸山先生の論じる「Availability-Consistency選択問題」は、フロントエンド－バックエンドという分割アーキテクチャーによって、極めて自然に解決できそうに思えます。
■ BASE Transaction、Eventually Consistency（※資料の65〜75ページについて）
BASEトランザクションの「BASE」は、
Basically AvailableSoft-StateEventually Consistency
の略とのこと。
ACIDトランザクションが、
ある単一ノード（もしくは、せいぜいサイトローカル）における、極めて短い単位時間内の、"All or Nothing"な、
データ更新の一貫性について論じているのに対し、BASEトランザクションは、
（リモートサイトに跨るような、超）分散環境における、
長い時間単位の、
その長い時間単位が終了する時点で最終的に達成される、
一貫性維持について言及しているものです。クラウドのような（超）分散環境においては、技術的というより物理的制約から、その（超）分散環境全域に対してACID性を求めることはできません。そこで、構成するノード間（群）の一貫性は、"All or Nothing”に達成されなければならないと考えず、メッセージング機構などを通して漸進的に波及して、一定時間後に最終的に達成されればよい、と考えます。このことを「Eventually Consistency」といいます。
・
ノード間の情報伝達の一貫性を、Atomicではなく、メッセージング機構などを通してEventually Consistencyに実現する方式について、2015年時点、それが「マイクロサービス」の概念を構成する主要な要素として扱われていることに注目しています。「マイクロサービス」は、2014年に書かれた下記記事が“原典”のようになっています。
Martin Fowler、"Microservices"：http://martinfowler.com/articles/microservices.html
丸山先生の講義のテーマであるように、「Eventually Consistency」は、元来Scalabilityを実現する場合のノード（群）間の一貫性実現の手立てとして議論されていたものです。そこでは、ノード群は「Parallel（※同一のものを多数並べて性能を得る、という意味）」の関係にあります。一方、「Microservice」で語られる「Eventually Consistency」は、「Concurrent（※異なるものが同時に稼働して高度な機能性を得る、という意味）」な関係にあるノード間における一貫性実現の手立てとして捉えられています。（※「Microservice」では、基本的に性能確保のための多重化、分散化については語られていません。）
「マイクロサービスはSOAとどこが違うのか？」、「マイクロサービスはアクターとはどういう関係にあるのか？」などについて多く議論されている様子ですが、ひとつ「Eventually Consistency」を意識していることが他と最も異なっている点であろうと私は理解しています。
■ 「新陳代謝して生き続けるシステム」（※資料の89〜95ページについて）
この節の見出しのフレーズは私が付けたものです。（この節は息抜きの小話です。）
分散環境で、分散ハッシュテーブルなどの方式で、In-Memory Databaseが構築される事例があります。このIn-Memory Databaseは、一時的なキャッシュではなく、永続記憶装置として用いられます。多数のノードのクラスターで構成されるIn-Memory Databaseは、構成するノードが一部故障して欠落しても、クラスター全体としてデータは保全されています。また、ノードの欠落は（新しいノードを自動組み入れするなどによって）自動修復します。結果的に、完全In-Memoryにも拘わらず、永続記憶装置としてのAvailabilityを発揮しているのです。
この事例を聞いて私は、まるで、新陳代謝をしてその細胞は次々と入れ替わるのに、個体としては同一性を維持し続ける生物のようだと思いました。シンギュラリティ論が盛んですが、それとは別にこのような方面からの「生命体のような方式で“生き続ける”（＝AvailabilityやIntegrityを発揮する）情報システム」というテーマもあるやもしれません。
〜・〜
＜追記＞
ACID Transactionに対するBASE Transactionという用語について、「Acid」と「Base」というと化学（Chemistry）の素養を持ってる方はピンとくるでしょう、化学における基本中の基本の一つ「酸」と「塩基」（の英単語）ではないですか。ACID Transactionが「酸」と同一の綴りになったのは偶然と思いますが、BASE Transactionの命名者は絶対「酸・塩基」を意識して命名したと思っています！これはどうしても指摘しておきたい点でありました:-)（※なお、AcidとBaseの、Transactionの特性と化学的な特性の間には、比喩としても何の絡みも見出されません。）
◆以上
