オフライン編集を端末間で統合するにはCRDTだけで十分？

CRDT（Conflict-free Replicated Data Type）は、複数の複製が独立して更新されても、同じ更新を受け取れば同じ状態へ収束するよう設計されたデータ構造群です。アプリ全体のオフライン同期、プライバシー、データ所有権まで自動で保証するという意味ではありません。Shapiroほか、CRDT論文

設計前に決めること

  • 1. データの意味を定義します。加算できる買い物数量、追加・削除するタグ集合、文書内の文章編集では必要な競合規則が異なります。「最終更新を採用」でよいか、削除と同時編集をどう扱うかを先に決めます。
  • 2. 状態ベース（CvRDT）と操作ベース（CmRDT）をデータの流れに合わせます。2011年論文は、状態統合に半束上の単調性条件が必要な方式と、操作ベースで同時操作の可換性・配送条件を使う方式を区別します。状態交換と操作配送では実装要件が違い、名称だけで同じ方法とみなせません。
  • 3. 切断、重複配送、順不同をテストします。2台でAは項目を追加し、Bは別項目を完了にしてから通信を切り、再接続します。同じ変更を複数回、異なる順で届けても製品の意図どおりの状態になるか確認します。
  • 4. 同じフィールドへの同時編集をどう扱うか決めます。Ink & SwitchのAutomerge例では、別オブジェクトへの変更は統合できますが、同じオブジェクトの同じ属性を同時に変更すると、アプリや利用者の判断が必要になる場合があります。「競合なし」は意味上の意見対立まで消えるという保証ではありません。

例：オフラインのタスクリスト

AとBの端末が同じリストを持ち、通信が切れたとします。Aは「食料品を買う」を追加し、Bは「洗濯」を完了にします。別項目への独立変更なら、再接続時に両方を残して統合できます。一方、同じタスク名を別々に書き換えた場合、一方を選ぶか両方を表示するか利用者に尋ねるかはアプリが決めます。適切な規則はタスクの意味によります。

CRDT以外に必要な実装

CRDTが提供するのはデータ複製と統合規則です。通信、ピア発見、認証・認可、暗号化、永続保存、バックアップ、スキーマ互換、アカウント復旧は自動では用意されません。Ink & SwitchはCRDT自体は変更の配送方法を規定せず、同社ライブラリがローカルファーストの理想を完全に実現するとも主張していません。変更履歴の増大や安全な削除時期も別途設計が必要です。

参考資料