厳密にデータ矛盾を引き起こさず、複数の場所に分散したデータベースを同期させようとするなら、本来は運用方法や手順までを含め、キッチリとシステムの設計を行なわなければならない。
もっとも単純な方法は、元本となるデータベースのみ更新可能とし、複製先のデータベースは参照のみに設定することだが、それでは運用の幅は狭すぎる。ユーザーはもっとコンピュータを自由に使いたい。そもそも使い方を覚えなければならない、という時点で、使ってもらえない。
このため、"複製"などという言葉もなくしてしまい、コンピュータ同士が1対1でデータベースの中身を(場合によっては条件付きで)マージすることで、複製と同期を一度にやってしまおうという流れがPalm OS機などが流行したPDA
ブーム期に定着した。
同期タイミングと更新方法によってはデータ矛盾も起こるが、大人数でデータベースを更新しないのなら、矛盾時の処理はユーザー自身で判断できる程度の軽い問題で収まってくれる。ならば、難しいことを考えず、シンプルにデータベースの中身の同一化だけでいいや、というわけだ。
だが、同期という考え方が拡がり、さまざまなアプリケーションやサービスが同期機能を持つようになり、また同期すべき機器の台数も種類も増えてくると、それまでの"ゆるやかな"同期ルールでは、うまく回らないケースが出てくる。
かつては、PDA(今で言えばスマートフォンがその役割を担う)内のデータベースを、すべての情報のオリジナルとして、さまざまなサービスやコンピュータと同期させるという、綱渡り的なデータ運用をしている人もみかけたが、こうしたゆるやかなルールでの同期では、いったいどれがオリジナルのデータなのか、すべてのオリジナルとなる"マスター"が曖昧になりやすい。
自分ルールでマスターを決めていても、ちょっとした運用のミスや新しいデバイス、新しい同期ツールの影響で、マスターデータにダメージを受けるということもある。実際、筆者もかつてはかなり苦労したものだ。
そのようなわけで、クラウドという言葉が生まれるずっと前から、インターネット上に唯一無二のリポジトリを持ち、それをマスターとしようという考え方はあった。しかし、そのための共通の枠組みがなかったのだ。異なる機器やソフトウェアをまたいで、同じ意味の情報を1つにまとめて同期させるには、標準的なデータ構造と意味解釈を決めなければならない。
技術的な障害はなにもないので、すぐに解決しそうだが、これまで解決していないのには理由がある。従来はパーソナルコンピュータを基準にサービス設計を行なっていたが、パーソナルコンピュータのようにフリーハンドに多様なアプリケーション、データタイプを扱う機器では、標準の枠組みを作ることができず、たとえ標準的なデータ形式を決めても、みんな無視してしまう。
話がやや横道に逸れたが、iCloudはiPhone(iOS)を基準にデータの同期を行なう。iPhoneに限らずスマートデバイスは、標準的なデータの形式をシンプルに扱うため、システム内での情報の扱いを統一しているのでリポジトリという考え方を盛り込みやすい。扱うデータタイプは、カレンダー、連絡先、To-Do、メモ、iWorkのファイルなどだ。
マスターがクラウドに置かれる利点は、どんな機器からでも、オンラインになれば時と場所を選ばず、マスターにアクセスできることだ。Appleが"同期"という言葉を使わない理由もここにある。同期をユーザーに意識させなくとも、オンラインになれば常に"マスターデータ"に手が届くのだから、システム側で都合の良いタイミングで、なるべく早く同期を済ませてしまえばいい。
ではGoogleとの違いは? という質問も出てくるだろう。本質的には同じと言える。しかし、GoogleはMac、Windowsともにパーソナルコンピュータに対するサービスが不十分だ。Googleはパーソナルコンピュータに対しては、ブラウザという窓を通してオン/オフともにアプリケーションを使わせようとしている。対するAppleは、利用する道具をフラットに並べる構成を今回から採るようになった。iCloudの利点はなにより、ユーザーに同期を意識させないことになるだろう。この部分を解決できているコンシューマ向けソリューションは他に知らない。
もちろん、iCloudにはフォトストリームやiTunes Matchなど、機能面でも興味深いものが組み込まれている。Windowsに対しても提供されるストレージアクセスのためのAPI(iCloud Storage APIを見てWindowsのブリーフケー
スAPIを思い出したのは筆者だけだろうか。あれも拡張可能な同期スキームだった)などもあるが、これらはもうしばらく評価してから話をしたい。
