クラウドの根底にある「当たらなければどうということはない」的発想

前回に続いて百式＝Live Servicesを紹介したい。
今回はMeshを構成する基礎技術のひとつ、フィードにフォーカスを当てる。

Live Mesh ベータ版の基本機能、データ同期はどのように実現されているのだろうか。
Live Meshでコンテンツ同期を使ってみた方はわかると思われるが、
同期対象に指定したフォルダでファイルを作成、上書き、削除すると、
まず更新情報が通知された後、コンテンツのデータ送信が行われる。

この様子は、Live実行環境の「News」で表示されるほか、
新規作成の場合には該当フォルダにまずファイル名.wlxというテンポラリファイルが
作成され、データ転送が完全に完了すると拡張子がはずれるといった動作で
見ることができる。また、これら通信はオープンかつ標準的ななプロトコルで行われるため、
fiddlerなどの一般的なツールでその状況を確認することも可能だ。

ただ、いくつかの疑問がわいてくる。例えば、
「複数の人が同じファイルを同時に編集したらロックはどのように制御されるのか？」
「頻繁に自動保存を行ってしまった場合、共有フォルダに連なるユーザーやデバイスに余計な負荷をかけないか？」
クラウドといっても、サーバー側のストレージ容量やCPU負荷を気にかけなくてよくなる以外、
アーキテクチャ上考慮すべきポイントはそれほど変わらない。

まず、ロック制御に関しては、競合有無の判定、通知までしか行わない。
最終更新が新しい方を勝ちとしたり、バージョン枝番を勝手につけたりする仕様も
考えられなくはないが、どのような挙動が正しいかは、結局のところファイルを
編集している人間様にしかわからない。これは、Lotus NotesにおけるDB、
文書のレプリカなどと同じような考え方であり、ある意味潔い。

また、Live Servicesの場合、APIを含む開発フレームワークが提供されているため、
不満があれば追加ロジックを組み込んだアプリを作ってしまえばよいだけのことである。
誰かが開いているファイルを他のユーザーが削除したらどう処理すべきか、
など考慮すべき点はさまざまだが、これらは利用シーンのニーズにより、行うべき処理は
自ずと明らかになる。中途半端な実装をされてしまうより
個別状況に応じた開発を行える自由度を残しておく方が現実的である。

また、過度な更新によるシステム系全体への影響は、
クラウド起点のニュースフィードとソフトステート型の状態管理で回避している。
エクスプローラー拡張により同期設定をして蒼いアイコンになっているフォルダにおいて
ファイルの作成・上書き・削除を行うと、その状況がLive実行環境を通じてクラウド側に
通知される。そして、共有設定がなされている他のメンバーやデバイスには、
負荷の少ないフィードとして「このファイルが更新されたよ」と配信されるのである。
配信を受けたクライアント側でファイルの比較を行い、必要があればデータ実体の
転送を開始する。

そして、更新の確認頻度も、変にリアルタイムに固執することなくソフトステート型の
状態管理をとっているため、例えばOfficeファイルを共有フォルダで直接編集している際に
1分おきに自動保存を行っても、愚直にその都度ファイル実体を送るわけではない。

このように、すべてが良くも悪くもクラウド的な割り切りで成り立っている仕掛けである。
リアルタイム性を追求しない代わりに、スケーラビリティや可用性、シンプルな
アーキテクチャを優先している。

私の心の師匠である東工大名誉教授の森政弘先生の「非まじめ」的発想で考えると

不まじめ：同期なんてどうでもいい。ファイルサーバーでユーザーにやらせればいいじゃない
クソまじめ：リアルタイム、トランザクション処理ガチガチで組まないと監査上困るんです！
非まじめ：適度な間隔で無理なく自然に同期しよう。不都合があったら直せばいいし
という感じだろうか。

百式は、内部構造が露出している脚部にみられるように、装甲を思い切って省略している。
専用シールドもない。その潔さが高い機動性、回避性能を実現し、結果、グリプス戦役から
第一次ネオジオン抗争まで戦い抜くことができた。

U.C.0079年、当時の主力機MS-06FザクIIを一撃で撃破するビームライフルをもった
RX-78-2ガンダムと対峙してひよる部下を前に、
「当たらなければどうということはない」と言い切ったように、
不必要な部分は拘りや固定観念を捨ててしまえばよいのである。

クラウドのFail Fast的な発想は、どことなくシャアの発想、
百式のコンセプトに通じるところがある。